SFT1200 VPN DNS issue on the v4.7.2

Technical Support for Routers
1

I did an upgrade to 4.7.2 over the weekend on an SFT1200.

The upgrade worked OK, but I found DNS stopped working, so I reloaded the current release and restored from backup.

I have an always on Wireguard connection and while the routing was fine, checked using traceroute for a target IP address, DNS would not resolve.

The only clue I found was that there was an extra entry for the DNS servers which was populated with the SFT1200's LAN IP address. I tried various DNS server configurations but was unable to get to one where DNS worked. Hence the roll-back.

1 Like
2

Hi,

Here creates the new thread for troubleshot this issue.

Is the VPN Client connection normal?
The VPN server is from a VPN service provider or a self-built server?

Is the ping <IP> normal, and the ping <domain name> is abnormal?

Screenshot the GL GUI > Network > DNS to check.

4

The VPN connection is configured in what is normally considered to be a Road Warrior configuration.

All aspects of the configuration looked to be running normally apart from the DNS. But that's not to say I tested the functionality of all aspects of the router. I just focused on the DNS issue.

I don't use any public VPN services. All the Wireguard services are running on OPNsense firewalls that I have full control of. The far-end for this one being in the USA. The VPN servers have been running for about 5 years and there were no DNS issues with 4.3.21 prior to the upgrade or after 4.3.21 had been re-installed.

When running traceroute (mtr) to an <IP> address timings were as expected.

ping <domain name> did not work because DNS would not resolve.

Additionally when watching the far-end firewall logs, DNS requests from the router were not seen.

I'll try and do this when I'm back from Europe, around the end of next week.

5

Is this profile of SFT1200 available when imported and used on the WireGuard client on your computer?

This issue has not been reproduced yet. If it does not work, we may ask you provide a remote desktop to check for the issue.

6

I'll try and do a clean install of 4.7.2 and re-test over the weekend.
I might not manage this as I'm currently preparing to be in the US next week.

7

Also please test the profile on the computer WireGuard APP, to see if the VPN tunnel works.

No problem, please contact me at that time when you available to remote check.

8

The traceroute showed that the traffic was routed correctly over the VPN.

10

If available, please PM to share the VPN profile with me.

If not, please PM to share me the issue syslog.

12

Hi,
New member and owner of Opal SFT1200!
Came across this post from another thread discussing the Opal and MSC cruises.

I, as OP, attempted to install 4.7.2 Beta and found myself in the same situation, no DNS when connecting via WireGuard or OpenVPN for the clients connected to the router.

I SSH'd into the router and perform a quick ping/traceroute/nslookup while I was connected to the VPN and it worked great directly from the router. Hosts that are only available via VPN responded to DNS resolution as well as ping, no issues.

When looking at the system log I came across an entry that stated:
daemon.crit dnsmasq[14743]: extraneous parameter at line 6 of /etc/dnsmasq.conf.vpn
this was followed by: dnsmasq failed to start

Reverting back to 4.3.24 and, just like OP, reloading from backup, fixed the situation and the VPN is up and running again.
Is there anything that I can provide while testing this to try and help troubleshoot this issue?

13

It seems the vpn scripts are also wrong in addition to the tx scripts in the beta firmware. Either that or they got completely overhauled because on the stable version there is no dnsmasq.conf.vpn -- only a dnsmasq.conf.

Line 6 of the .vpn script in the beta firmware:

enable-ubus=dnsmasq.vpn

The man page says the following:

Enable dnsmasq UBus interface. It sends notifications via UBus on DHCPACK and DHCPRELEASE events. Furthermore it offers metrics and allows configuration of Linux connection track mark based filtering. When DNS query filtering based on Linux connection track marks is enabled UBus notifications are generated for each resolved or filtered DNS query. Requires that dnsmasq has been built with UBus support. If the service name is given, dnsmasq provides service at that namespace, rather than the default which is **dnsmasq**

It seems that the option is not recognized in the dnsmasq version the Opal runs.

$ ls stable/etc/dnsmasq.*
stable/etc/dnsmasq.conf

Only 1 config for dnsmasq in the stable.

$ ls beta/etc/dnsmasq.*
beta/etc/dnsmasq.conf  beta/etc/dnsmasq.conf.mptun  beta/etc/dnsmasq.conf.vpn

A bunch more in the beta. Either they have overhauled it or like with the tx power init script used the wronf config files for our little Opal.

14

We're using dnsmasq version 2.80 from 2018 on the Opal and overriding the default ubus service name wasn't added until 2020.

So unless the Gl-Inet team back ported that option they are trying to use an option that does not exist in the version on the Opal. The joys of severely outdated software.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=d162bee356586ccddccb50fd665c4a5556ce1147

Option really does not exist:

root@GL-SFT1200:~# dnsmasq --enable-ubus=hello
dnsmasq: bad command line options: try --help

It accepts the command only without the service name change:

root@GL-SFT1200:~# dnsmasq --enable-ubus
dnsmasq: failed to create listening socket for port 53: Address in use
2 Likes
15

Interesting. Out of curiosity I just checked their download site again and the Beta FW has been removed from it.
I'm guessing the GL-Inet team is aware of these issues.

16

Beta FW is back. With different make: openwrt-sft1200-4.7.2-0308-1741428334

17

Would you expect it to be called 4.7.2.1 or something similar?

1 Like
18 
Tue Mar 11 14:32:34 2025 kern.err usbmuxd[6320]: [1] Another instance is already running (pid 4769). exiting.
Tue Mar 11 14:32:34 2025 kern.err usbmuxd[6335]: [1] Another instance is already running (pid 4769). exiting.
Tue Mar 11 14:32:36 2025 kern.err usbmuxd[6738]: [1] Another instance is already running (pid 4769). exiting.
19

installed it's called beta2.

checking at present, is the vpn dns issue on OpenVPN or Wireguard?

Yes still broken on OpenVPN on 4.7.2, I downgrade to 4.3.24 and the VPN DNS works correctly.

This is annoying.

20

Lets call it 7.4.2.1
Opened the box again, and installed it.
Just that little convenient test stream: https://www.waveform.com/tools/bufferbloat

A very quick test learns ...

  • TX power is OK now (-30dBm received on short distance). TXPower setting in GUI is responsive.
  • 40MHz bandwidth is correct (but his might come from my earlier LUCI settings)
  • no scan/connection to DFS channels
  • AMPDU still breaks. This is not a wifi 802.11 n or ac device. It cannot handle that mode, as those wifi modes have up to 64 MPDU in one A-MPDU transmission.

Log claims MSDU not MPDU (typo ?)

Tue Mar 11 19:57:03 2025 kern.warn kernel: [ 585.975126] lmac[1] Error, msdu index reach maximum limit, 31
Tue Mar 11 19:57:03 2025 kern.warn kernel: [ 585.980967] lmac[1] Error, buffer is not uploaded to host buffer completely

Back in the box, this is not a good travel router for now, with that wifi driver. (only 31 MPDU are accepted, hopefully there is at least retransmit of the rest of the A-MPDU?)

Maybe I'll do some more tests, like with previous versions (eg country code), and see how bad the performance drops while using repeater. It may be sub-optimal but repeating the missed part of an A-MPDU might eventually give enough performance for a travelrouter. Have to find the config file with the "ampdu_max_cnt" configuration in this version. SFT1200 2.4 GHz Repeater Disconnects - #61 by bpwl1

2 Likes
21

We are aware of the issue and have updated the VPN DNS codes.

It will be merged and released in the next version.

Affected models: B3000, SFT1200.

22

Thank you, any news on the WiFi driver issues?

23

4.7.2.1 beta: Giving up again. 5GHz sometimes good for work (40Mbps), sometimes images do not load. 2.4GHz dramatic again as we have seen so many times before. (probably still needs wifi legacy mode).