Since I updated to Core 161, I have the problem that my USB ethernet adapter is causing problems.
22:54:45 kernel: ax88179_178a 2-3: 1.0 green0: unregister 'ax88179_178a' usb-0000: 00: 14.0-3, ASIX AX88179 USB 3.0 Gigabit Ethernet
22:54:45 kernel: xhci_hcd 0000: 00: 14.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or e p state.
22:54:45 kernel: usb 2-3: USB disconnect, device number 2
After the restart it works again for a few hours
Hi,
sorry for the late response on this.
Does upgrading to Core 162 make a difference here? It comes with a new kernel, which might change the behaviour - ideally solving the problem. 
Thanks, and best regards,
Peter Müller
Hi,
by the way: Since Core Update 162, I experience trouble with an Asix Electronics AX88772C USB-to-LAN adapter (but it worked fine with Core Update 161 and below).
Please refer to bug #12750 for details - perhaps your device is affected by this one as well.
Thanks, and best regards,
Peter Müller
Unfortunately I still have the problem with Core 162
Is this the sam Problem?
https://bugzilla.kernel.org/show_bug.cgi?id=202541#c176
Hi,
meanwhile, I get the impression we are dealing with two different problems:
Your case definitely sounds like the XHCI problem a patch is available for, and I believe shipping a kernel containing this patch should solve the issue.
In my case, there are no log messages in /var/log/bootlog apart from the usual ones. I only noticed the MAC and S/N of the adapter changed after rebooting into the new kernel, but that’s it.
Perhaps the aforementioned XHCI patch will solve this as well (collateral usage 
), but I won’t take that for granted. Also, in my problem seems to be related to the board, not to the USB-LAN-adapters - a device I know is working perfectly fine does not work on the affected machine either.
Thanks, and best regards,
Peter Müller
OK, how can i use the patch for ipfire?
Hi,
this is unfortunately not so easy, since patches to a kernel cannot be applied without recompilation (in theory, there is such a thing as kernel livepatching, but it comes with security downsides, I rarely saw it being used in production, and it probably wouldn’t work in this case).
So, you can either compile a custom version of IPFire with the patches in question included, or wait for the next Core Update to fix this (we’d really appreciate your testing feedback on it). Given the current situation at kernel 5.15.6, I’d favor something like an emergency Core Update, but have not yet received any comment on this proposal.
Sorry to disappoint, and best regards,
Peter Müller
OK, i will wait for the next Core Update.
Hi,
just for the records: This issue was raised at yesterday’s telephone conference as well - please refer to its log for details.
Thanks, and best regards,
Peter Müller
Peter
The telephone conference log links to Procedure regarding USB networking equipment issues with kernel 5.15 which indicates the ax88179_178a issue is resolved in 5.15.11 but 163 is using 5.15.6.
Can I infer from this that the ax88179 issue is not resolved in 163?
Currently still holding on 161 at home as I use a ax88179_178a for my red connection.
Thanks, Phil
Looks like you’ll have to wait for cu 164 which currently looks like on kernel 5.15.23
https://git.ipfire.org/?p=ipfire-2.x.git;a=shortlog;h=refs/heads/next
Hi,
indeed. Because we were unable to reproduce this with reportedly affected USB-LAN-adapters (we believe it is an issue related to the kernel’s handling of certain mainboard USB hubs), and there were no other reports other than yours and mine, it was decided to postpone this to Core Update 164.
Sorry to disappoint - Core Update 164 will be in testing soon, and it would be great if you could give it a try then to see if it finally resolves the issue. libusb was updated in it, too, solving another USB-related bug. Perhaps it is a combined issue…
Thanks, and best regards,
Peter Müller
Hi Peter
Currently planning to swap out the problematic ax88179 and replace it with something else so I can upgrade to 163. (I’ll also use this opportunity to confirm if the ax88179 causes problems with 163)
I’ve only got one ax88179 but will swap it into a test configuration when 164 beta is available.
Regards, Phil
I swapped the ax88179 with a RTL8153 I had as a spare and ran for 24 hours without problems.
I’ve now upgraded from 161 → 163, swapped back to the ax88179 and run for the last 24 hours without any problems.
BTW I’m running on an old Intel Wilson Canyon NUC Core i5-4520U, profile fireinfo.ipfire.org - Profile c860bf20f1f6b7a1cfc5ae468faef57f3fcb4d54
Hi,
Core Update 164 is now available for testing. Please give it a try, and kindly report back if it solves the issue, improves anything or - I hope it doesn’t - introduce another regression. 
Hm, this is odd to hear. On my affected system, swapping NICs did not accomplish anything… 
Thanks, and best regards,
Peter Müller
I ran into similar issues when upgrading from 161 to 163.
DHCP no longer worked on GREEN or BLUE.
These both have USB-Ethernet adapters.
Not looking for a solution here, but rather providing my notes here mainly as help if someone else comes across the same scenario.
(where gui is mentioned, it means the ipFire web admin configure screen)
a) home page indicated a upgrade from 161 to 163 was available. I clicked on it. Pakfire kept giving an error saying there was already a pakfire session running. I couldn’t exit. The cmd interface also appeared frozen, so after apout 10 minutes I powered off and did a restart.
b) after restart, I could not get a gui session. No DHCP reponse from GREEN. The led indicator on the unmanaged switch connected to GREEN iface was blinking constantly about 3 times per sec.
c) I cold restarted my 2 unmanaged switches; one for GREEN (Cisco SHO) and one for BLUE (DLink)
d) i reinstalled 163 from CD . Same situation. no DHCP, no access to gui.
e) I reinstalled older 161 from CD .
Same situation. No access to gui from GREEN. (no IP address given to client via DHCP)
f) I zero’s out the SD card i use for the ipFire (dd if=/dev/zero of=/dev/sdb), replaced the ‘USB to Ethernet’ adapter i use for the GREEN iface with a new adapter, and re-installed 163 from CD. GREEN was now working. Restored from previous backup. So either wiping the SD card, or a new USB to Ethernet device did the trick. Likely the latter, as you will see below the same thing was happening to the BLUE interface.
g) discovered that BLUE was acting same as GREEN previously. WiFi clients were not getting DHCP ip addressess, and the other unmanaged switch (DLink) was also showing the same rapid led blinking like I previously had on GREEN.
h) this time decided to wireShark capture what all the blinking was about, so I connected directly to the BLUE’s USB to Ethernet adapter iface (Manufact DLink). Turns out the BLUE iface, was constantly sending (per WireShark descript) PROTOCOL=‘MAC CTRL’, DEST=‘Spanning-tree-(for-bridges)_01’, INFO=‘Pause: pause_time: 0 quanta’, and INFO=‘Pause: pause_time: 65535 quanta’
i) from ipFire’s gui ‘Zone Configuration’ i disabled BLUE (was set to NATIVE), and rebooted ipfire. The USB to Ethernet (DLink) iface no longer showed active LED. Hoped here that after the reboot, and setting back to NATIVE, that this would reinitialize the port and/or adapter. It did not change anything.
j) another full reinstalled of 163 from CD. BLUE iface still with same USB to Ethernet. DHCP on BLUE has been disabled and re-enabled via gui. Still no DHCP response on BLUE, and the stream of ‘MAC CTRL’ packets continue.
k) Again, another full install of 163 from CD, but this time replaced the ‘USB to Ethernet’ adapter for BLUE with a newly purchased unit (like I did for GREEN earlier on to get it going). The backup restore not yet been done, but the BLUE DHCP has been enabled via the gui. SUCCESS !!! BLUE WiFi clients now get IP addr and can connect.
l) Did a restore from my 161 backup. Everything still works.
Two possibilities here.
1-) Either something overwrote or reconfigured the internal firmware of both ‘USB to Ethernet’ devices for GREEN and BLUE (different manufacturers) during the ipFire upgrade,
2-) or something within the Dell’s Intel-i7 motherboard remembered the device ID of the 2 USB devices which may have gotten corrupted during the hard power off after the pakfire issue, and set them to work a certain way (spanning tree).
However, mystery question remains as to why pakfire was already running when I clicked on the 161 → 163 upgrade notice at the bottom of the home screen, which created a conflict and error situation.
Hi,
thank you for the detailed post.
Some very cheap NICs, especially USB-to-LAN-adapters, do not seem to have a MAC address configured in their firmware. The packets you observed look like a faulty firmware indeed, emitting network packets without a source MAC.
Apparently, the Linux kernel we shipped in Core Update 163 contained a bug, so some of those NICs in conjunction with certain USB hubs were not initialised correctly (many other distributions reported this as well).
It is still interesting to see that you managed to get around this issue; I was unable to do so for the affected IPFire installation. Oh well…
Hm, I don’t think so, at least I doubt this would be the root cause of it.
That is an unrelated bug, being fixed in Core Update 164, where the Pakfire CGI has been massively improved.
By the way: Did upgrading to Core Update 164 (testing) changed or improved something in your setup?
Thanks, and best regards,
Peter Müller
The USB-LAN device that was on BLUE is a DLink DUB-E100.
It has a mac address stamped on it which corresponds to the mac used by ipFire 161. It also corresponds to the mac that wireshark was picking up.
If you want I can email you (don’t want it public) the wireshark capture file I took as ipFire was booting.
@pmueller - After further testing of the 2 affected USB->LAN devices, i found that the DLink device (used for BLUE) does use its correct mac address when sending ‘Spanning-Tree’ packets, whereas the one used on GREEN ( an AIX ‘AX88772’ ) device has 00:00:00:00:00:00 as mac addr, which confirms what you’ve been seeing (no mac allocated).
I also tested the 2 same devices on a fresh install of the 164 TEST iso, and I am getting the same results. So appears that the two devices have been permantly affected, as I also tried plugging the devices into another hardware (not ipFire) and was getting same results.
Note that the spanning-tree packets only begin to appear after about 2 minutes or so after boot.
I have not yet tried my 2 new replacement USB->LAN devices on the 164 TEST as I don’t want to risk having these also become defective just yet.
Worth noting maybe is that both the DLink and AIX devices are USB 2.0 10/100.
My new replacement devices presently used on my running ver 163 hardware are both USB 3.0 Gigabit devices, so maybe the kernel’s usb bug only affected older USB 2.0 devices ?
… typo … should actually read GREEN ( an ASIX ‘AX88772’ )