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