RUTX09 MTU problem

Hello
I have some question about ip fragmentation
In RUT950 i have no problem but in RUTX09 it is som trouble with MTU over mobile with passthrough and bridge mode

in a rutx09 fw 7.04.5
ping -l 1432 -f 8.8.8.8 thru rutx09 i get anser
ping -l 1433 -f 8.8.8.8 i get timeout
ping -l 1473 -f 8.8.8.8 i get the fragmentation flag
i can not ping with bigger loads than 1432

if i run command
uqmi –d /dev/cdcwdm0 –get-current-settings
mtu 1460

it fels some mixup with mss 1460 and mtu 1500 on rutx09

if i try it on rut955 fw 7.04.5 i never got timeout it works fine with fragmentation
ping -l 1472 -f 8.8.8.8 thru rutx09 i get anser
ping -l 1473 -f 8.8.8.8 i get the fragmentation flag
i can ping with bigger loads without timeout.

if i run command
uqmi –d /dev/cdcwdm0 –get-current-settings
mtu 1500

is it some differens in these rutos?

regards Kent

Hello,

Apologies for a late response. In RutOS 7.5, dynamic MTU was added, so the mobile interface will use the MTU provided by the network (unless specified otherwise).
Since these devices use different modems, it could be that the max MTU size is determined differently. Could you check if the same behavior is present on 7.5?

Best regards,

Hello
yes it is the same in version 7.05 on rut950 it works fine, but in rutx09 it is the same trouble.
I have also updated the modem EG06-E to version EG06ELAR04A20M4G

from system log in rutx09 i get this
daemon.notice netifd: mob1s1a1 (4058): Setting dynamic MTU: 1460 on qmimux0
daemon.notice netifd: Interface ‘mob1s1a1’ is now up
daemon.notice netifd: Network device ‘wwan0’ link is up
daemon.notice netifd: mob1s1a1 (4058): {
daemon.notice netifd: mob1s1a1 (4058): “pdp-type”: “ipv4”,
daemon.notice netifd: mob1s1a1 (4058): “ip-family”: “ipv4”,
daemon.notice netifd: mob1s1a1 (4058): “mtu”: 1460,
daemon.notice netifd: mob1s1a1 (4058): “ipv4”: {
daemon.notice netifd: mob1s1a1 (4058): “ip”: “x.x.x.x”,
daemon.notice netifd: mob1s1a1 (4058): “dns1”: “x.x.x.x”,
daemon.notice netifd: mob1s1a1 (4058): “dns2”: “x.x.x.x”,
daemon.notice netifd: mob1s1a1 (4058): “gateway”: “x.x.x.x”,
daemon.notice netifd: mob1s1a1 (4058): “subnet”: “x.x.x.x”
daemon.notice netifd: mob1s1a1 (4058): },
daemon.notice netifd: mob1s1a1 (4058): “ipv6”: {
daemon.notice netifd: mob1s1a1 (4058):
daemon.notice netifd: mob1s1a1 (4058): },
daemon.notice netifd: mob1s1a1 (4058): “domain-names”: {
daemon.notice netifd: mob1s1a1 (4058):
daemon.notice netifd: mob1s1a1 (4058): }
daemon.notice netifd: mob1s1a1 (4058): }

If I change Override MTU in
Network → wan->Interface mob1s1a1 Advance Settings

I get this from system log
daemon.notice netifd: mob1s1a1 (3397): Notifying WebUI that operator (1460) and configuration MTU (1500) differs
daemon.notice netifd: mob1s1a1 (3397): Setting up qmimux0
daemon.notice netifd: mob1s1a1 (3397): Setting configured MTU: 1500 on qmimux0
daemon.notice netifd: Interface ‘mob1s1a1’ is now up
daemon.notice netifd: Network device ‘wwan0’ link is up
daemon.notice netifd: mob1s1a1 (3397): {
daemon.notice netifd: mob1s1a1 (3397): “pdp-type”: “ipv4”,
daemon.notice netifd: mob1s1a1 (3397): “ip-family”: “ipv4”,
daemon.notice netifd: mob1s1a1 (3397): “mtu”: 1460,
daemon.notice netifd: mob1s1a1 (3397): “ipv4”: {
daemon.notice netifd: mob1s1a1 (3397): “ip”: “x.x.x.x”,
daemon.notice netifd: mob1s1a1 (3397): “dns1”: “x.x.x.x”,
daemon.notice netifd: mob1s1a1 (3397): “dns2”: “x.x.x.x”,
daemon.notice netifd: mob1s1a1 (3397): “gateway”: “x.x.x.x”,
daemon.notice netifd: mob1s1a1 (3397): “subnet”: “x.x.x.x”
daemon.notice netifd: mob1s1a1 (3397): },
daemon.notice netifd: mob1s1a1 (3397): “ipv6”: {
daemon.notice netifd: mob1s1a1 (3397):
daemon.notice netifd: mob1s1a1 (3397): },
daemon.notice netifd: mob1s1a1 (3397): “domain-names”: {
daemon.notice netifd: mob1s1a1 (3397):
daemon.notice netifd: mob1s1a1 (3397): }
daemon.notice netifd: mob1s1a1 (3397): }

It is the same mobile operatorn on rutx09 and rut950.
Has mtu 1460 anything to do with voice over IP is it possible to turn voip off?
Is it possible to change < “mtu”: 1460> in any config file?

regards Kent

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