Getting martian source errors in kernel and dropping network

[dr_techno (Dave Mikeska)]

@phane

For now, I don’t see cascading martian source errors, just one set of them from my Xbox One since I did the factory reset. I’m hoping that the buggy firmware may have just had an issue before and doing the full reset may have resolved it.

it could be an effect of the xbox trying upnp. Which is something that needs to be refined everywhere including all manufactured routers. At least with this system you see any error that occurs.

[phane (James Redel)]

@dr_techno

It should be fine then because once the static entry is put in the router its going to keep it. Because there is a bug in their firmware because the 1st one in the chain has to get a static so the others link properly and when it does you will be able to use the dns name that goes back to the 1st one which it sounds like what you ended up with. On their OS, they suppose to show the static address of the first node here on the network screen but it doesn’t. I don’t think it has an ssh server to log into its version of Linux/BSD to actually look at how the net is set up. But working backwards seemed to solve the issue since the static address doesn’t go away when resetting it.

The IP is being automatically picked up through DHCP via IPFire. I have IPFire’s DHCP configured with fixed lease IP’s for each node of .2, .3, and .4. (These are outside the DHCP server’s range for dynamic leases). It was set up this way before the factory reset as well. I know that each node is getting the .2, .3, and .4 since when I point to those addresses with a web browser, they are automatically redirecting me to .2 (the main node). They also show up with those IP addresses in the Linksys app.

You’ll note in the screenshot above, that it even pulled the domain name (redel) from IP Fire’s DHCP. There is no way to set it up in Bridge Mode and bypass the DHCP client without updating to a custom firmware, AFAIK. It is, however, not running a DHCP server and wireless clients are getting their correct IP’s from IPFire (as they were before the reset).

[phane (James Redel)]

Issue is still seeming to happen, but less often. There are less martian source errors but the whole NIC still drops with the following errors showing up when it does:

22:20:04 	kernel: 	ax88179_178a 3-3:1.0 green0: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 5756 ms 

[dr_techno (Dave Mikeska)]

That particular error is usb port related, which normally either power management is accidentally turned on or there is an issue with a usb hub.

[phane (James Redel)]

It’s a built in USB port on an intel NUC that never had issues before. Power management in Linux is a deep dark hole of extensive documentation. Is there an easy way to check the power management setting for the USB port/hub/NIC and set it to not shut down to save power?

Edit: I found this page which had a way I’ll try that creates a file /etc/udev/rules.d/50-usb_power_save.rules and adds the following line to block any USB devices from power save mode:

ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="05c6", ATTR{idProduct}=="9205", ATTR{power/autosuspend}="-1"

Since the only USB device I have is the ethernet NIC, this would work for me if it’s not going to cause any other issues with IP Fire.

[dr_techno (Dave Mikeska)]

just add or make sure acpi=off is on the kernel boot line. If you have to add it, then you have to update grub.

[phane (James Redel)]

Still had this issue last night, twice within an hour after not having it for over a month. I’m trying Dave Mikeska’s idea of reinstalling from scratch only instead of manually replacing all the settings (of which I had several) I just did a backup and restored from that. I see some changes in the WUI and I’m running with no addons for now (not that I had many to begin with).

[phane (James Redel)]

Full reinstall with restoration of backed up settings didn’t resolve the issue. Still showing a device timeout on the AX88179 and total failure.

22:06:51 kernel: ax88179_178a 3-4:1.0 green0: NETDEV WATCHDOG: CPU: 0: transmit queue 0 timed out 5002 ms

As a final attempt before going nuclear on this, I swapped the two network devices so the AX88179 is my red and my Intel I218-V is my green. If the AX88179 still fails, it’s an issue with ACPI or USB. If the Intel fails this time, it’s a configuration problem.

[dr_techno (Dave Mikeska)]

The only problem I had with mine was a 100M link issue that I solved it by not using a usb hub. But since that was before the Kernel change and I don’t use them anymore. I will find my usb nic dongles and see if I can repeat your issue with mine.

I have noticed the chip manufacturer published a new Linux driver recently, but the Linux Main Kernel guys are going to be slow incorporating it.. Which is driver version 3.5. What we have in ipfire is driver version 3.4

[phane (James Redel)]

It has been almost two months since I reversed the adapters and I have had no issues. Still get the occasional martian source error, but only from certain clients that seem to have issues when only when they first turn on / wake. IP Fire has not had the AX88179 adapter fail once since swapping it to be the red adapter and the integrated Intel one as the green.

Still not sure why the same adapter would fail on the same USB port with the same controller when being used as the green interface but not when used as the red, but if it aint broke…

[pscar13 (Phil SCAR)]

Perhaps it’s a bandwidth issue; your WAN has a slower bandwidth than your LAN.

Or Qos.
Have you enabled QoS on Red?

[hvacguy (Shaun HVAC)]

Perhaps ping running on the WAN keeps it from going to sleep? Some sort of power saving mode.

[phane (James Redel)]

Perhaps it’s a bandwidth issue; your WAN has a slower bandwidth than your LAN.

Modem connection to the internet is 500 mbps but the link between the modem and the IP Fire box is still gigabit for red and gigabit to the switch for green.

Have you enabled QoS on Red?

No.

[bbitsch (Bernhard Bitsch)]

If your modem has a WAN speed of 500 mbps, the maximal speed of a connection <client in LAN> ↔ <endpoint somewhere in the WAN> is 500 mbps.
The speed of an internet path is determined by the slowest link.

[phane (James Redel)]

@bbitsch

If your modem has a WAN speed of 500 mbps, the maximal speed of a connection ↔ is 500 mbps.
The speed of an internet path is determined by the slowest link.

I don’t think you got the picture. This never was a bandwidth issue. It was an issue with the connection randomly and completely failing. It wasn’t the link between the modem and the provider or the modem and the IP Fire box that was failing, either. It was the adapter from the IP Fire box to the 16 port gigabit switch (that serves the rest of the house) that was failing, and it was failing completely and suddenly at random.

That connection was completely gigabit in both directions. It would only be when I was trying to connect to the internet beyond the IP Fire box that the effective speed would be less. I can use iPerf3 to the IP Fire box and get gigabit speeds all day long, before and after the swap.

Swapping it out so that failing adapter connected to the cable modem instead and the built-in Intel one connected to the switch instead made the problem go away (for whatever reason). This problem didn’t exist for several years prior to this. A recent IP Fire update triggered it, either through a driver / kernel update or something else.

[pscar13 (Phil SCAR)]

Indeed, the kernel version changed during the CU 190 upgrade.
But that doesn’t explain why your adapter works on Red and not on Green.
Have you updated to CU 196?

[phane (James Redel)]

Yes, all current with CU196. However, the adapter working now on red did not correspond to any CU. I swapped them immediately after a failure and brought it back up, it hasn’t failed since.