My public IP is static, as seems the one of the VPN server, so I’ll leave the room to the experts to answer this but don’t see which IP could be changing here. And I don’t see why the client cannot just do the same thing that what I’m doing when I’m just clicking “Stop” then “Start” so it works again. For now I have to manually do this every few hours to keep it working, so it looks like a bug.
I thinking because you are running a custom image something got taken out. Multi-Wan does support repeater set up, you could use that
No, I’m not using custom image, it’s 4.2.0 beta2
Here is what Multi-WAN looks like, only default settings, only one WAN source (repeater in my case):
Sorry I may have gotten it confused with another post
I thought you were referring to a custom firmware
The only strange thing I see is 8.8.4.4 is googles secondary DNS and usually 8.8.8.8(googles primary dns) is before it. That should not make a difference. But sense you did not make changes something is not loading right I am guessing.
With a fresh install openwrt has google 8.8.8.8 and 8.8.4.4. and then Cisco OpenDNS 208,67.222.222(primary) and 208.67.220.220(secondary) as the default DNS
Perhaps try changing(like I have done) to Cloudflare 1.1.1.1, 1.0.0.1 or Quad9 9.9.9.9 149.112.112.112
reverted to 3.214 via uboot or whatever its called the method via ethernet and upload a file, and its still poor speeds, I think my Flint must be broken now, or this paticular version of 3.214 has been modified since I had it installed and now, as speeds are the same as on 4.x
300 mbps download
full fat 750 mbps upload every time
it should be symmetrical
what is going on with this router
ethernet is 990 mbps up
990 down the line is fine
upload wifi is fine
only download wifi is terrible 
Can confirm I am experiencing similar issue to a lot of users. I created a post and the logs are here.
BIG PROBLEM with 4.1.0 Stable on FLINT.
This firmware leaks DNS after some time. In general after a day or two, the Wireguard connection turns to yellow in the VPN menu and when you check your DNS for leaks, it leaks all over the place.
DO NOT TRUST THIS FIRMWARE!
1 Like
So Why are you posting in a Firmware 4.2.x SNAPSHOT post and not a stable build post.
1 Like
Just installed a fresh copy of 4.2 compiled on 1/27 on an Opal and am seeing odd behavior from the modem manager. This is using an EC25-AF in a USB enclosure.
- After clicking auto setup, it will change to the connecting prompts, then return to auto setup/manual setup after about 5 seconds. About 10 to 15 seconds later, it will make a connection and display the IP information. On the 1/10 snapshot, I would click auto setup 2 to 5 times and it would eventually connect (instead of waiting 10 to 15 seconds).
It looks like modem manager needs more information messages during the connection process. It briefly flashed “sim not registered” during the 10/15 second wait (once), so apparently it is doing things behind the scenes. It is not displaying any information to the user during connecting and just looks like the modem hung-up. Manual setup still works like a charm on the 1st try.
-
The modem does not auto connect after a reboot using a prior connection of auto setup or manual connection. Clicking abort and either of the “setups” does connect fine to remedy though. I am only adding an APN on manual setup and changing the service to LTE. No changes are needed on auto setup.
-
Still seeing a random over-voltage message on 1 out of 3 reboots. Unplugging and replugging in the modem does not restore the modem. A reboot has to be performed. I do not see this symptom on 3.215 and did not see this on the 4.1.1 beta. Are too many components initializing at once on boot?
-
Using a cloned or manual MAC Address does not seem to be saving. It continues to display the default MAC after applying. I do see the edited MAC in glconfig, but the GL gui and Luci show the default MAC.
-
More of a feature request, but any chance of getting
AT+CGDCONT?added to the list of AT commands in the dropdown?
The modem stays connected for hours after it does connect and maintains the solid white light with no other problems.
Edit: The modem worked fine for several hours today, but this evening, I received over-voltage disconnects while connected. 4.2 is not usable so I’ll reinstall 3.215 and wait for the next round of snapshots/beta for 4.2.
Also, the reboot is timed for exactly how long it takes the Opal to get to 100% on the progress bar, so a page could not be displayed error is shown on the refresh. Adding 5 to 10+ seconds to that (or slowing the progress bar) should allow for seamless reboots. And why doesn’t the progress bar match the blue theme for 4.2?
[ 563.518910] dwc2 17000000.usb: Overcurrent change detected [ 563.648974] dwc2 17000000.usb: Not connected [ 563.653308] option1 ttyUSB3: usb_wwan_write: submit urb 0 failed: -19 [ 563.659826] dwc2 17000000.usb: Not connected [ 563.664125] option1 ttyUSB3: usb_wwan_write: submit urb 0 failed: -19 [ 563.758917] usb 1-1: USB disconnect, device number 2 [ 563.766827] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 [ 563.776760] option 1-1:1.0: device disconnected [ 563.784824] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1 [ 563.794978] option 1-1:1.1: device disconnected [ 563.803577] option1 ttyUSB2: GSM modem (1-port) converter now disconnected from ttyUSB2 [ 563.813316] option 1-1:1.2: device disconnected [ 563.822148] option1 ttyUSB3: GSM modem (1-port) converter now disconnected from ttyUSB3 [ 563.832127] option 1-1:1.3: device disconnected [ 563.841579] option 1-1:1.5: device disconnected
Specs for EC25-af
Supply Voltage Range 3.3–4.3 V, 3.8 V Typ.
Power Consumption (Typical)
10 μA @ Power off
1.0 mA @ Sleep, Typ.
23.3 mA @ Idle
USB 2.0 specs
In general, the specifications for a USB 1.0 and 2.0 standard downstream port, delivers up to 500 mA or 0.5A
Your out of power spec, unless your usb enclosure is powered which is not mentioned.
You might be doing damage by using it.
Thanks! I flashed back to 3.215 which has never had over-voltage issues on boot or during operation, with me usually having the USB enclosure plugged in 1st, then powering up.
Its just reporting my findings on the beta firmware. The configuration has worked perfectly, with solid connectivity for my use under the 3.x firmwares.
I installed the 4.1.1 beta for a day to test in December and did not see any symptoms either (other than connectivity). I have a Spitz with extroot on 3.215 that I don’t test with, so I can install the snapshots for a day on my Opal to test with no inconveniences. I do like the new UI in the 4.x firmwares though. Lots of nice touches.
Any idea when 4.2 will be released as stable and available for updating my AR750S-Ext (Slate)
3 Likes
Slate Plus previously using latest “stable” firmware 4.1.x…
Makes no sense that stable firmware uses snapshot of ddwrt.
UI not working - most pages at end of tree stuck and fail to return user control. Had to upgrade to beta to see if UI functional. Thankfully yes.
So am happy to be a beta tester out of need. Seems too much complexity of hardware and software models. Makes a single thread like this hard to interpret - everyone has different hardware.
Is there a map simplifying the hardware/software matrix??? Might help to know who is better off in beta than stable.
Please use stable ddwrt in stable firmware.
I am using GL-AX1800 Flint. My home ISP (BIGLOBE) offers IPv4 over IPv6 with MAP-E and I wanted to use it. So I made the necessary settings based on the following.
However, the above configuration does not seem to work in 4.2.0 (beta 2, snapshot 2023-02-04). every time the interface I created for map tries to start, the log repeats endlessly with the following error.
Tue Feb 7 02:30:00 2023 daemon.notice netifd: Interface ‘wan6map_’ is enabled
Tue Feb 7 02:30:00 2023 daemon.notice netifd: Interface ‘wan6map_’ is setting up now
Tue Feb 7 02:30:00 2023 daemon.notice netifd: Interface ‘wan6map_’ is now up
Tue Feb 7 02:30:00 2023 daemon.notice netifd: Interface ‘wan6map_’ has link connectivity
Tue Feb 7 02:30:00 2023 daemon.notice netifd: Interface ‘wan6map_’ is now down
Tue Feb 7 02:30:00 2023 daemon.notice netifd: Interface ‘wan6map_’ is disabled
Tue Feb 7 02:30:00 2023 daemon.notice netifd: Interface ‘wan6map_’ has link connectivity loss
Tue Feb 7 02:30:00 2023 daemon.notice netifd: Interface ‘wan6map’ is now down
Tue Feb 7 02:30:00 2023 daemon.notice netifd: Interface ‘wan6map’ is setting up now
Tue Feb 7 02:30:01 2023 daemon.notice netifd: wan6map (15407): Command failed: Unknown error
Rolling back to v4.1.0 release 6 (Stable) with similar configuration, IPv4 over IPv6 (MAP-E) generally works as intended. (However, I had to disable the PPPoE WAN because the gateway metric is ignored, but that is yet another issue.)
By the way: I am very happy that GL.iNet is selling such a fun product for Japan as well! Thank you so much and I hope you will continue to sell it in various regions 
One thing I know is that firmware 4.2 relay mode named as Passthrough, and in firmware 4.1 it’s native, of course, 4.2 is more accurate. So, maybe please try to use 4.2 Passthrough as a config basis,
I have set the IPv6 configuration item to Passthrough from the GL.iNet UI, but it does not seem to be enough to properly connect to IPv6 in the first place. To connect correctly, you need to change the WAN6 Device from LuCI to @wan->eth0 (same procedure and settings as before v4.1.0). After making the configuration change, the connection will be made correctly.
also, just to be sure, I tried the same procedure from the beginning based on Passthrough, but it still seems that the interface by “map” cannot be started correctly with the same error.
another issue is that it appears that unless I use LuCI to change the Country Code for 5Ghz Wireless to the correct one (in my case JP), I can’t get actual communication to work.
(Oddly enough, this problem also seems to be happening in 4.1.0 release 6, which was initialized by a rollback.)
1 Like
That maybe a bug, can you print the command output:
hexdump -C /dev/mtd8 |grep -e COUNTRY -e UTC -e test
00000050 66 69 72 73 74 74 65 73 74 ff ff ff ff ff ff ff |firsttest…|
00000060 73 65 63 6f 6e 64 74 65 73 74 ff ff ff ff ff ff |secondtest…|
I ran the command, but it did not output anything other than the above two lines containing “test”.
(note: this Flint has already been rolled back to v4.1.0 release 6 at the time this command was executed.)
Also, my Flint was purchased from GL.iNET on Amazon.co.jp, so it is definitely a unit shipped to Japan. however, I found some interesting details in the reviews.
To summarize and translate the relevant content, “Updating to FW 4.1.0 will cause the default to use a frequency band that is prohibited by law to be used in Japan. To fix this, you need to set the Country Code to JP from LuCI”
In my case, I had manually set it to JP and fixed channels from an earlier version, so it may have been overlooked until the initialization associated with the rollback restored the settings.
It appears that this bug continues to exist in current Firmware 4.2.0.
I have new GL-MT3000, it’s same to me.
I thought it was just in spec, not bug.
But sadly, on MT3000, there is no option to set country code in LuCI
---- edit ----
I found command-line settings below.
uci delete network.mt798111.txpower
uci set network.mt798111.country=JP
uci delete network.mt798112.txpower
uci set network.mt798112.country=JP
uci commit wireless
1 Like
On MT3000, AXT1800, country code is preconfigured.
So in Japan, the country code is JP already.
1 Like