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.
-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
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
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
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
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.