Different download speeds - Ipfire behind modem, Ipfire via modem mode

So commenting that line out is telling IPFire’s dhcpcd to ignore the maximum MTU size that your ISP’s dhcpd server is sending to IPFire and just use 1500 by default.

Check what the MTU value gets set to when you have the modem in router mode and the line
option interface_mtu is not commented out. As your download speeds are ok when in router mode the MTU might be more like 1500 then.

If that is the case then it looks like your modem may have a fault when in bridge mode and your ISP’s dhcpd server is sending that the maximum MTU should be small, 576 or smaller. Alternatively their dhcpd server may be sending an incorrect MTU when the modem is in bridge mode.

It looks like you are getting closer to figuring out what the problem is.

1 Like

I did some minitests earlier (I wrote about It)

-swapping MAC addresses (RED GREEN) does not change anything - - Download about 220Mb/s
-laptop, connected “directly” via modem mode - Download is about 500Mb/s
-laptop, with MAC from RED ipfire (LocallyAdministredAddress)
connected “directly” via modem mode - Download is about 500Mb/s
-On the IPfire machine, I was running Linux Mint Xfce Usb Live, instead of IPfire - Download about 500Mb/s (connected “directly” via modem mode)
edit: -I set, IP address, gateway, mask, received from DHCP my ISP
to static, in setup IPfire - Download about 500Mb/s

“ip link show”
red0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000

In Setup → Networking → Address Settings → RED
“Force DHCP MTU” = 1500

First question:
why does IPfire ignore “Force DHCP MTU” = 1500 ?

You used the above with your minitest with the modem in bridged mode. I was asking what does that test give with the modem in router mode, when you don’t have
option interface_mtu commented out.

It looks to me that the 10-mtu dhcpcd-hook checks if the ISP has provided an MTU value. If yes then that is used and if no then the Force DHCP MTU value is used.

1 Like

next minitests via modem in router mode

1 obraz
red0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
green0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000

WebGUI Status–>Network (Other)->Routing table entries:
obraz

MTU on modem
obraz

2
obraz

red0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
green0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000

WebGUI Status–>Network (Other)->Routing table entries:
obraz

MTU on modem
obraz

OK, so in router mode there is no difference at all with or without option interface_mtu commented out but in bridged mode there is a huge difference.

If the ISP dhcp server is calculating the mtu value incorrectly then commenting out option interface_mtu should be fine and not give a problem.

If the ISP dhcp server is calculating the mtu correctly because there is some issue with the modem in bridged mode as opposed to router mode then commenting out option interface_mtu could be a problem because a higher MTU than the connection can use could result in packet loss or intermittent connection.

The above is just my view based on what I have searched and read and comparing it with your results. I am not an expert by any means on this topic

1 Like

next minitest
Xubuntu USB LIVE running instead of IPfire connect “direct” via modem mode

obraz

2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN mode DEFAULT group default qlen 1000

3: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1280 qdisc mq state UP mode DEFAULT group default qlen 1000

4: enp1s0f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000

Has anyone noticed yet that only IPfire has a problem with MTU? :wink:

Then if you believe it is a problem within IPFire, please raise a bug at IPFire bugzilla.

https://bugzilla.ipfire.org/

Your credentials from here will give you log in.

1 Like

There are many indications of this.

Next question:
Why can Xubuntu and others set a good MTU, but IPfire can’t?

Next question:
Which MTU is signaled by the DHCP server of your ISP?

I called my ISP support and was told that the dhcp server gives an MTU of 1500

Did you check this?
You can capture with tshark, for example.

If you could give the right Tshark command, I could try it

tshark isn’t necessary.
You could just do
tcpdump -i red0 portrange 67-68 -c 10 -w dhcpcd.cap
This captures 10 DHCP request/replies.
The resulting file dhcpcd.cap can be analysed with eg. Wireshark.

Thanks a lot for the hint.
I will try as soon as I can.

Welcome back.
Covid stopped me - “little bit” :mask:

I have 4 tcpdump files

  1. no hash, no MTU force
  2. with hash, no MTU force
  3. no hash, with MTU force
  4. with hash, with MTU force

( hash in the file
/var/ipfire/dhcpc/dhcpcd.conf

`# Respect the network MTU’
‘# option interface_mtu’)

MTU force - in Setup → Networking → Addresses → RED

What should I be looking for?

Same issue here with my ISP. As suggested it solved the issue adding the comment at startup in
/etc/sysconfig/firewall.local

sed -i ‘s/^option interface_mtu$/#option interface_mtu/’ /var/ipfire/dhcpc/dhcpcd.conf

My main issue with MTU was mostly to video streaming upwards in web conference and screen sharing and now is solved by commenting out that line.

Have you tried changing the “Force DHCP MTU” entry?

2 Likes

@IPTOm

If the question is to me no I have not tried that. I am also in core 167 so issue may still be around …

I am running a cable modem with no router future. … iPFire gets the ISP public IP.