Error in system log: daemon uhttpd vuci: accepted login for admin from <ip>

Dear Teltonika Experts,

I can connect from my PC to my RUTX11 via ssh without problems.

However, after I (fruitlessly) tried to log in from my PC to my RUTX11’s WebGUI, I got the below error message from the RUTX11’s system log:

daemon uhttpd vuci: accepted login for admin from 192.168.178.67

My PC’s IP 192.168.178.67 is in a different IP range than the RUTX11 (192.168.11.1), but that usually is not a problem (due to WireGuard VPN, see below), and connection via ssh works.

Usually, logging in works flawlessly (as I have WireGuard setup and running between my RUTX11 and my gateway router [a Fritzbox 7490], to which also my PC is connected), but this time, the “Loading…” spinner keeps on going, I cannot log in to the WebGUI, and I got the aforementioned message.

The RUTX11 (in my motorhome) IP range/subnet mask is: 192.168.11.x/255.255.255.0

It is connected to my Fritzbox (FB) 7490 with WireGuard as VPN via WiFi (when in home’s WiFi range), else via public WiFi or mobile (GSM/LTE).

The FB7490 (internet gateway at home) IP range/subnet mask is: 192.168.178.x/255.255.255.0

My questions are:

  1. Why is the system log message shown as error but reads “accepted login”?
  2. How can I find out why the login does not work? (as written above: usually, it does, even across the 2 different IP ranges)
  3. How do logins via WebGUI and via ssh differ (if at all) in respect to network routes? I ask, because I don’t understand why login via WebGUI doesn’t work but via ssh does work.

Hopefully, my post & questions are not too complicated. If not well described, please let me know, so I can try to amend my question.

Thanks for sharing your thoughts and best regards
7wells

Hello,

The issue sounds like it could be related to the MTU size.
I’ll ask you to log into the CLI of the device, and run the following commands:

uci set network.[tunnel_name].mtu='1300'
uci commit network
/etc/init.d/network restart

Replace the [tunnel_name] with the name of the WireGuard instance on the RUTX11. After restarting the network, the connection will be lost, but it will recover soon.
Keep in mind, that this MTU only applies to the WireGuard tunnel, if you are experiencing issues even outside the WireGuard tunnel, MTU can be lowered on the mobile interface by navigating to Network → Interfaces → General, editing the mob1s1a1 interface, and in the advanced options setting the Override MTU option to 1300.
Let me know if this helps!

Best regards,

1 Like

What’s the [tunnel_name]? With uci show network, I get this (some data redacted):

network.loopback=interface
network.loopback.device='lo'
network.loopback.proto='static'
network.loopback.ipaddr='127.0.0.1'
network.loopback.netmask='255.0.0.0'
network.loopback.metric='0'
network.globals=globals
network.globals.ula_prefix='xxxx:xxxx:xxxx::/48'
network.br_lan=device
network.br_lan.name='br-lan'
network.br_lan.type='bridge'
network.br_lan.ports='eth0'
network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.netmask='255.255.255.0'
network.lan.metric='1'
network.lan.ip6assign='60'
network.lan.delegate='1'
network.lan.force_link='1'
network.lan.stp='0'
network.lan.ipaddr='192.168.11.1'
network.lan.peerdns='0'
network.lan.gateway='192.168.178.1'
network.lan.dns='192.168.178.21'
network.@switch[0]=switch
network.@switch[0].name='switch0'
network.@switch[0].reset='1'
network.@switch[0].enable_vlan='1'
network.@switch_vlan[0]=switch_vlan
network.@switch_vlan[0].device='switch0'
network.@switch_vlan[0].vlan='1'
network.@switch_vlan[0].vid='1'
network.@switch_vlan[0].ports='2 3 4 0'
network.@switch_vlan[1]=switch_vlan
network.@switch_vlan[1].device='switch0'
network.@switch_vlan[1].vlan='2'
network.@switch_vlan[1].vid='2'
network.@switch_vlan[1].ports='5 0'
network.Gateway-WiFi-SSID=interface
network.Gateway-WiFi-SSID.proto='dhcp'
network.Gateway-WiFi-SSID.defaultroute='1'
network.Gateway-WiFi-SSID.delegate='1'
network.Gateway-WiFi-SSID.force_link='0'
network.Gateway-WiFi-SSID.metric='2'
network.FB7490=interface
network.FB7490.proto='wireguard'
network.FB7490.listen_port='xxxxx'
network.FB7490.private_key='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
network.FB7490.public_key='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
network.FB7490.disabled='0'
network.FB7490.dns='192.168.178.1'
network.FB7490.addresses='192.168.11.0/24'
network.FB7490.metric='3'
network.RUTX11=wireguard_FB7490
network.RUTX11.endpoint_port='xxxxx'
network.RUTX11.description='RUTX11'
network.RUTX11.preshared_key='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
network.RUTX11.public_key='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
network.RUTX11.persistent_keepalive='25'
network.RUTX11.route_allowed_ips='1'
network.RUTX11.endpoint_host='xxxxxxxxxxxxxxxx.myfritz.net'
network.RUTX11.allowed_ips='192.168.178.0/24'
network.mob1s1a1=interface
network.mob1s1a1.proto='wwan'
network.mob1s1a1.modem='3-1'
network.mob1s1a1.sim='1'
network.mob1s1a1.dhcpv6='0'
network.mob1s1a1.pdptype='ip'
network.mob1s1a1.method='nat'
network.mob1s1a1.auth='none'
network.mob1s1a1.auto_apn='1'
network.mob1s1a1.pdp='1'
network.mob1s1a1.apn='internet'
network.mob1s1a1.pref_apn='582'
network.mob1s1a1.metric='3'
network.mob1s2a1=interface
network.mob1s2a1.proto='wwan'
network.mob1s2a1.modem='3-1'
network.mob1s2a1.sim='2'
network.mob1s2a1.dhcpv6='0'
network.mob1s2a1.pdptype='ip'
network.mob1s2a1.method='nat'
network.mob1s2a1.auth='none'
network.mob1s2a1.auto_apn='1'
network.mob1s2a1.pdp='1'
network.mob1s2a1.apn='internet'
network.mob1s2a1.metric='4'
network.mob1s2a1.pref_apn='582'
network.wan=interface
network.wan.device='eth1'
network.wan.proto='dhcp'
network.wan.disabled='1'
network.wan.metric='5'
network.wan6=interface
network.wan6.device='eth1'
network.wan6.proto='dhcpv6'
network.wan6.disabled='1'
network.wan6.metric='6'

Thanks for your help!

@Daumantas Can you please completely delete my previous, deleted post? Sorry for the inconvenience and thanks a lot!

Hello,

Deleted the comment.
The tunnel names of your WireGuard instances are RUTX11 and FB7490.

1 Like

Before I change the MTU, shouldn’t I be able to check the currently set MTU with uci get network [tunnel_name].mtu? It does not work, though:

root@rutx11:~# uci get network.FB7490.mtu
uci: Entry not found
root@rutx11:~# uci get network.RUTX11.mtu
uci: Entry not found

Thanks for your patience and support!

OT:
It would be great if users could delete their previous post versions via the version history.

It should be uci show network.RUTX11, and one of the options will be MTU.

Only the moderators and the OP can see the edit history, other users cannot.

Best regards,

1 Like

Well, mtu is not shown for either:

root@rutx11:~# uci show network.RUTX11
network.RUTX11=wireguard_FB7490
network.RUTX11.endpoint_port='xxxxx'
network.RUTX11.description='RUTX11'
network.RUTX11.preshared_key='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
network.RUTX11.public_key='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
network.RUTX11.persistent_keepalive='25'
network.RUTX11.route_allowed_ips='1'
network.RUTX11.endpoint_host='xxxxxxxxxxxxxxxx.myfritz.net'
network.RUTX11.allowed_ips='192.168.178.0/24'

Or for:

root@rutx11:~# uci show network.FB7490
network.FB7490=interface
network.FB7490.proto='wireguard'
network.FB7490.listen_port='xxxxx'
network.FB7490.private_key='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
network.FB7490.public_key='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
network.FB7490.disabled='0'
network.FB7490.dns='192.168.178.1'
network.FB7490.addresses='192.168.11.0/24'
network.FB7490.metric='3'

Besides, if I understand it correctly, the tunnel in question in my case would be FB7490 (not RUTX11), right?

However, I can see the mtu like this:

root@rutx11:~# ip a | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
4: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
6: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN group default qlen 1000
7: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN group default qlen 1000
8: erspan0@NONE: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default qlen 1000
9: ip6gre0@NONE: <NOARP> mtu 1448 qdisc noop state DOWN group default qlen 1000
10: miireg: <> mtu 0 qdisc noop state DOWN group default qlen 1000
14: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
15: FB7490: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
21: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
22: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
23: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP group default qlen 1000
24: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000

For FB7490, the mtu is set to 1420, it seems. Shall I now lower it to 1300 with this:

uci set network.RUTX11.mtu='1300'

Or with this?

uci set network.FB7490.mtu='1300'

Sorry that I am still unsure about it. I don’t fully understand which of the 2 (tunnel) names is the one for which I should reduce the mtu.


PS:

Good to know - and thank you! :slight_smile:

Sorry, missed that RUTX11 is the peer name. Indeed, it should be lowered like the quoted command. Don’t forget to commit and restart the network.
If the command still does nothing, try running

uci add network.FB7490.mtu='1300'

Good, this is what I did:

root@rutx11:~# ip a | grep FB7490
15: FB7490: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 192.168.11.0/24 brd 192.168.11.255 scope global FB7490
root@rutx11:~# uci set network.FB7490.mtu='1300'
root@rutx11:~# uci commit network
root@rutx11:~# /etc/init.d/network restart
{
        "state": "OK"
}
root@rutx11:~# ip a | grep FB7490
26: FB7490: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1300 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 192.168.11.0/24 brd 192.168.11.255 scope global FB7490

The "state": "OK" message came after a few seconds, and I didn’t even have to re-login via ssh (connection was not interrupted). The new mtu of 1300 seems to stick.

However, the login via WebGUI still does not work, i.e. the “Loading…” spinner keeps turning, and the system log shows the same error as before.

__
PS:
I just rebooted the RUTX11, will check the value of the mtu for the FB7490 WireGuard tunnel andsee if the WebGUI login then works…

After a RUTX11 reboot I still cannot login via WebGUI.

Alternatively, I connected my mobile phone via WiFi to my RUTX11, and I can see from the system log that the phone got a lease (192.168.11.81). However, WebGUI login also does not work on that phone. The syslog does not show any complaints (or other messages) after the lease message, but the WebGUI shows (in red):

The device is unreachable. Please check the connection and try again.

Interestingly, ssh from my mobile phone to my RUTX11 works! So it’s always the WebGUI login that fails - both from PC (192.168.178.67, different IP range than the RUTX11) and from phone (192.168.11.81, i.e. same IP range as the RUTX11).

Have you tried lowering the MTU on the mobile interface?

I cannot login to the WebGUI, so how would I do that?

Apart from that, if you mean by “mobile interface” the mob1s1a1 (or No. 2, as I have 2 SIM cards inserted), why would it matter if login from phone and from PC does not work? (both connected to the RUTX11 via WiFi - and the RUTX11 connected to the internet via WiFi to my FB7490)

Sorry for my many questions. I’m just trying to sort things out. :wink:

By the way, I do have a (10-years) RMS license. Maybe I shall try using that to access Network → Interfaces → General. But still, for what? For mob1s1a1 or/and for something else?

You’re right, sorry, it misunderstood how you were connecting.
In this case, I’d simply recommend resetting the device to factory default settings. I understand that this is not the ideal solution, but since we are on a public forum, I’m not able to acquire any more information that might help me troubleshoot the issue further. If you have some complex configurations, you could take a backup of them via RMS, and try reuploading it after the reset. However, if it’s and issue with the configuration, the WebUI will become unreachable again.

Best regards,

1 Like

I don’t know how this happened, but all SIM indicator LEDs were already flashing on my RUTX11 when I went over and checked it.

Now I have done a factory reset and will start from scratch (better than loading previous settings, I guess).

Sorry that in the end we couldn’t find out the reason for my described problem, but I consider it “resolved” by factory reset.

I might add more info here if deemed relevant.

Thank you very much for your very kind and swift support. I have again learnt a lot. :grinning:

1 Like

This topic was automatically closed after 15 days. New replies are no longer allowed.