6

The issue

After installing Fedora 30 (KDE) on my laptop my router would crash shortly after I connected to it. This happened both when I connected through wired Ethernet and Wi-Fi. Fortunately, the router logs gave a clue as to why this was happening. I would get warnings like this:

kern.err kernel: [ 116.293427] ipq806x-gmac-dwmac 37200000.ethernet eth0: len 1675 larger than size (1536)

Followed by:

daemon.warn dnsmasq[2721]: reducing DNS packet size for nameserver 92.220.228.70 to 1280

For the first message I found a post on the OpenWrt forum with other people experiencing the same issue. It turns out that a bug in the switch driver causes the kernel to panic whenever it receives packets larger than the default MTU (1500), aka "jumbo frames".

Nobody else in that thread got the second warning, but I assume it's relevant in my case.

When I was using Fedora 29 I never experienced this, and all other devices on the network connect without any issues. So some bug must have been introduced in Fedora 30.

What I have observed

I have tried a couple of things to see if I can connect to the router without causing the warnings and crash. I'll list them below.

Wi-Fi, with NetworkManager enabled

Able to connect, but results in warnings and crash. ifconfig outputs an MTU of 1500.

Wi-Fi, with NetworkManager enabled and MTU set to 1500 in KDE System Settings

Able to connect, but results in warnings and crash. ifconfig outputs an MTU of 1500.

Wi-Fi, with NetworkManager disabled and connecting manually

$ sudo wpa_supplicant -B -iwlp18s0 -cwpa.conf -Dnl80211

$ sudo dhclient wlp18s0

Works fine! Results in no warnings and no crash. ifconfig outputs an MTU of 1500.

Wired Ethernet, with NetworkManager enabled

Able to connect, but results in warnings and crash. ifconfig outputs an MTU of 1500.

Wired Ethernet, with NetworkManager enabled and MTU set to 1500 in KDE System Settings

Able to connect, but results in warnings and crash. ifconfig outputs an MTU of 1500.

Wired Ethernet, with NetworkManager disabled and connecting manually

I just plug the cable into the port and run the following command:

$ sudo dhclient enp19s0

Works fine! Results in no warnings and no crash. ifconfig outputs an MTU of 1500.

Finding the cause

I want to find the cause for this bug so I can report it upstream, and would really appreciate if someone more experienced with debugging could help me out.

  • @sourcejedi Yes, I mean when it receives frames larger than 1536 bytes. I did try to set the MTU manually to 1500 under system settings in KDE, but it appears that the setting is being ignored since the router still receives jumbo frames. I suspect this has something to do with network manager; connecting to my wireless network manually with wpa_supplicant works just fine. – Dolan May 12 '19 at 8:45
  • If you want my experienced suggestion, you should not take the OpenWrt crash messages for granted - there's clearly some bug, so its not certain that the message about exceeding the MTU is not also a bug :-). I have edited your question to match your comment. Feel free to re-edit if I have mis-understood you. – sourcejedi May 12 '19 at 9:23
  • @sourcejedi Ok, so then it makes sense to check whether the MTU gets set above 1500. It seems like just a few jumbo frames get transmitted, and I would have to get lucky to catch the MTU set to above 1500 with for example: ip addr show | grep wlp18s0. When I ran that command I always got MTU 1500 back. Do you have any suggestions for how I can do that? – Dolan May 12 '19 at 12:42
  • I would be surprised if something is yanking the MTU setting up and down. Anyway, if it's not a kernel bug, I think you should be able to capture the outgoing packets using Wireshark on your laptop, and sort by frame size. You might have to make sure you capture on "all interfaces", because if you try to capture on an interface that is "down", it probably won't let you. I.e. this should let you mostly rule out a bug in NetworkManager . – sourcejedi May 12 '19 at 12:50
  • I'm not seeing any frames that exceed the maximum frame size of 1518 bytes, but I did see a handful of fragmented frames. Is that something that might be interesting? They originated from the router with my laptop as destination. – Dolan May 13 '19 at 8:34
1

I suggested Dolan run Wireshark on the laptop, to look for the large packets. Wireshark showed the laptop received fragmented IP packets. (It did not show the laptop transmitting any jumbo frames). If you reassembled the fragmented packets, they would be larger than 1500 bytes. Perhaps the fragmented packets triggered bad behaviour in the router's network driver.

The IP packets in question were DNS results. The DNS result types were related to DNSSec: DNSKEY and RRSIG. The DNSSec-related requests and responses were sent immediately before NetworkManager's captive portal test (HTTP request for http://fedoraproject.org/static/hotspot.txt). DNSSec responses are expected to be larger than 1500 bytes.

So my best guess for the difference between the Fedora 29 and Fedora 30 installs, is something about the DNS requests from NetworkManager.


EDIT: Dolan said they had not specifically enabled DNSSec on their Fedora 30 install. Since then, I have upgraded my own laptop to Fedora 30. I tried running the same test, and I do not see any DNS request or response with these types - only the A / AAAA types for IPv4 / IPv6 addresses. This is what I originally expected, since the list of changes announced for Fedora 30 does not include anything about DNSSec.

I understand if you specifically enabled systemd-resolved, then it would try to use DNSSec. But a default install of Fedora 30 does not enable systemd-resolved.


Dolan then said they had been looking for a straightforward workaround for the Fedora 30 laptop, but felt they have spent enough time on this issue and might try using a different distribution (maybe an older stable release) on their laptop :-).

0

I had the exact same symptoms, after days of investigation it turned out to be a known DoSS virus, as described here:

https://superuser.com/questions/863997/ddos-virus-infection-as-a-unix-service-on-a-debian-8-vm-webserver

I've removed it by following the instructions in the top post, now all is good. Here's my original post: Fedora 30 Workstation breaking wifi router

  • Question says "Wired Ethernet, with NetworkManager enabled - Able to connect, but results in warnings and crash." If you have a similar-looking problem which only happens on Wi-Fi, and does not happen on wired ethernet, then you should list which aspects of your problem are the same, and which are different or not confirmed. If you're not seeing some very specific similarities, you should definitely open a new question instead. If this is the identical problem but only a partial solution, then please mention explicitly that your answer does not solve the problem on wired Ethernet. Thanks. – sourcejedi Jul 31 '19 at 15:46
  • Ah, I see you've already written a specific question. Be aware your answer here might be deleted. – sourcejedi Jul 31 '19 at 15:56
  • You mentioned the timing on your problem is different for Ethernet v.s. Wi-Fi. However, in this question we found what was causing the problem, and we are pretty certain it would have the same sort of timing for Ethernet as it does for Wi-Fi. I will see if I can tidy this thread up so that specific detail is a little clearer. – sourcejedi Jul 31 '19 at 16:11
  • I am not convinced you found the cause of the problem. I don't think it's MTU packet size, not in my case at least as I have confirmed. I believe both our problems are one and the same, either related to Intel network chip (not sure what card Dolan has, but if Intel then that would make sense), or, very likely related to TCP buffer Recv-Q packets which can be observed using netstat. – Max Jul 31 '19 at 17:07
  • But if it is related to the wireless chipset and driver settings, then why would using wpasupplicant and dhclient directly fix the problem? (NetworkManager uses wpa_supplicant as well). – sourcejedi Jul 31 '19 at 17:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.