I'm trying to resolve a consistent issue that I have where a Teams call with someone will completely kill my external traffic connection through the firewall within about 30 seconds to 2 minutes on the call. I cannot reproduce this if I just do a Teams call with no other participants, it has to be one where I'm connecting with an external party.
I read something about someone tying this to something IPv6 related, so I disabled IPv6 on OpenWRT this morning but still had the same issue. I don't see anything noteworthy in the openwrt system log or kernel log. In fact, there were no actual errors in the system log when this happened this morning and I can't actually understand the time stamps in the kernel log, but based on some of the activity in the kernel log, I have sense of where something should've shown up there and there's nothing.
If there are logs from a cli which I should look at, that would be great as well.
I know someone on Reddit was complaining of the same thing and they never found a solution, but it doesn't seem to be widespread, so I'm not seeing much else about it. Any thoughts or suggestions would be greatly appreciated since it really affects my ability to work from home. Thanks!
I just had another call it happened again. I was able to capture this out of the system log and kernel log at the same time, in case this is helpful additional information:
Syslog
Sat Aug 6 09:58:22 2022 kern.warn kernel: [ 2251.059499] ------------[ cut here ]------------
Sat Aug 6 09:58:22 2022 kern.warn kernel: [ 2251.064149] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:473 0xc072567c
Sat Aug 6 09:58:23 2022 kern.info kernel: [ 2251.071255] NETDEV WATCHDOG: eth1 (ax88179_178a): transmit queue 0 timed out
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.071264] Modules linked in: rtl8192cu rtl8192c_common rtl_usb pppoe ppp_async iptable_nat brcmfmac xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT rtlwifi pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG usbhid slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables hid_generic crc_ccitt compat brcmutil ax88179_178a asix snd_bcm2835(C) hid evdev nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 snd_rawmidi snd_seq_device snd_pcm_oss snd_pcm_dmaengine snd_pcm snd_timer snd_mixer_oss snd_hwdep snd_compress snd soundcore nls_utf8 vfat fat nls_iso8859_1 nls_cp437
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.144035] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G WC 5.4.188 #0
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.151435] Hardware name: BCM2711
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.154842] Function entered at [<c020fee4>] from [<c020b308>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.160677] Function entered at [<c020b308>] from [<c0835538>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.166512] Function entered at [<c0835538>] from [<c021eca8>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.172346] Function entered at [<c021eca8>] from [<c021ed48>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.178179] Function entered at [<c021ed48>] from [<c072567c>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.184013] Function entered at [<c072567c>] from [<c0283a44>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.189847] Function entered at [<c0283a44>] from [<c0283f84>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.195679] Function entered at [<c0283f84>] from [<c0202958>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.201512] Function entered at [<c0202958>] from [<c0223ac0>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.207346] Function entered at [<c0223ac0>] from [<c026c720>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.213180] Function entered at [<c026c720>] from [<c04ed4b4>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.219014] Function entered at [<c04ed4b4>] from [<c0202238>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.224847] Exception stack(0xc0c01f28 to 0xc0c01f70)
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.229901] 1f20: 00000000 0046f9f0 eff83574 c0216020 ffffe000 c0c04e70
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.238085] 1f40: c0c04eb0 00000001 00000000 c0a49030 c0c0d348 00000000 c0c04f20 c0c01f78
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.246266] 1f60: c0208a5c c0208a60 60000013 ffffffff
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.251318] Function entered at [<c0202238>] from [<c0208a60>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.257151] Function entered at [<c0208a60>] from [<c0248e5c>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.262984] Function entered at [<c0248e5c>] from [<c0249190>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.268817] Function entered at [<c0249190>] from [<c0a00e24>]
Sat Aug 6 09:58:23 2022 kern.warn kernel: [ 2251.274803] ---[ end trace f2fed7bde8130a39 ]---
Kernel Log
[ 2251.071255] NETDEV WATCHDOG: eth1 (ax88179_178a): transmit queue 0 timed out
[ 2251.071264] Modules linked in: rtl8192cu rtl8192c_common rtl_usb pppoe ppp_async iptable_nat brcmfmac xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT rtlwifi pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack mac80211 ipt_REJECT cfg80211 xt_time xt_tcpudp xt_multiport xt_mark xt_mac xt_limit xt_comment xt_TCPMSS xt_LOG usbhid slhc nf_reject_ipv4 nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_filter ip_tables hid_generic crc_ccitt compat brcmutil ax88179_178a asix snd_bcm2835(C) hid evdev nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 snd_rawmidi snd_seq_device snd_pcm_oss snd_pcm_dmaengine snd_pcm snd_timer snd_mixer_oss snd_hwdep snd_compress snd soundcore nls_utf8 vfat fat nls_iso8859_1 nls_cp437
[ 2251.144035] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G WC 5.4.188 #0
[ 2251.151435] Hardware name: BCM2711
[ 2251.154842] Function entered at [<c020fee4>] from [<c020b308>]
[ 2251.160677] Function entered at [<c020b308>] from [<c0835538>]
[ 2251.166512] Function entered at [<c0835538>] from [<c021eca8>]
[ 2251.172346] Function entered at [<c021eca8>] from [<c021ed48>]
[ 2251.178179] Function entered at [<c021ed48>] from [<c072567c>]
[ 2251.184013] Function entered at [<c072567c>] from [<c0283a44>]
[ 2251.189847] Function entered at [<c0283a44>] from [<c0283f84>]
[ 2251.195679] Function entered at [<c0283f84>] from [<c0202958>]
[ 2251.201512] Function entered at [<c0202958>] from [<c0223ac0>]
[ 2251.207346] Function entered at [<c0223ac0>] from [<c026c720>]
[ 2251.213180] Function entered at [<c026c720>] from [<c04ed4b4>]
[ 2251.219014] Function entered at [<c04ed4b4>] from [<c0202238>]
[ 2251.224847] Exception stack(0xc0c01f28 to 0xc0c01f70)
[ 2251.229901] 1f20: 00000000 0046f9f0 eff83574 c0216020 ffffe000 c0c04e70
[ 2251.238085] 1f40: c0c04eb0 00000001 00000000 c0a49030 c0c0d348 00000000 c0c04f20 c0c01f78
[ 2251.246266] 1f60: c0208a5c c0208a60 60000013 ffffffff
[ 2251.251318] Function entered at [<c0202238>] from [<c0208a60>]
[ 2251.257151] Function entered at [<c0208a60>] from [<c0248e5c>]
[ 2251.262984] Function entered at [<c0248e5c>] from [<c0249190>]
[ 2251.268817] Function entered at [<c0249190>] from [<c0a00e24>]
[ 2251.274803] ---[ end trace f2fed7bde8130a39 ]---
I suspect there is an issue in the ax88179 driver that is being used in this version.
My EA3500 worked flawlessly under v19 and started having this issue the day I upgraded to v21.
After searching ax88179 I see there are a few posts about raspberry pi 4s going unresponsive. Same hardware "ax88179".
I also have a pi4 that was giving me problems and I've made some dirty restart script if the Network interface becomes unresponsive. Based on your logs it looks like openwrt has a watchdog service that will re-initialise when it becomes unresponsive.
I'm hoping someone smarter than us can come along and understand what is happening.
It might be worth trying a nightly build if they are available.
The axis (USB to ethernet?) adapters are not ideal under Linux/OpenWrt. People report better/more robust performance with realtek adapters like tp-link's ue-300.
ax is as far as I can tell an identifier for asix electronics corporation devices, so IMHO probably an USB3 to ethernet controller. And as I mentioned there are reports of these not working all that well with Linux/OpenWrt.
The USB to Eth adapter I'm having issues with is a UGREEN gigabit USB to eth adapter that's running the ax88179 chipset.
I can confirm, I don't have any issue with the RPi onboard ethernet port. I purchased a TP Link UE300 that has the RTL chipset and can confirm that without any other changes to the RPi or firewall, except the addition of the rtl8152 kmod package and tying the new WAN interface into the existing WAN rules, the new interface seems to be working flawlessly. I just did another Teams call a few minutes ago without any issues and did a test call last night without issues, both of which would've been a problem before.
Is there any value in trying to help the OpenWRT team run down the issue with the ax88179 chipset or do we just take it that those adapters aren't compatible with OpenWRT?
I honestly can not answer this, I am not a developer myself so all I tried was to report what I learned about USB3 gigabit ethernet dongles here in the forum. The problem I would guess does not only affect OpenWrt but probably also Linux upstream, so OpenWrt developers might not be the best audience to report issues to.
In case it's helpful, I took @rockjob suggestion and submitted a bug ticket to the devs. The workaround, wouldn't call it a solution, is to switch to a more compatible dongle for the RPi. The TP Link UE300 with the RTL8153 chipset using the rtl8152 kmod package, has been working flawlessly since I made that switch, for anyone hunting the forums down the road, for this issue and wanting a workaround. Cheers!