WAN crash when on Whatsapp Videocall

I am new to this forum so please bear with me if I have posted in wrong place.

I'm running openwrt 21.02.1 on Raspberry Pi 3 and a Asus Tuf AX5400 as AP.
My problem is every time i do a video-call via whatsapp, within 10 ~ 20 sec the internet stops working.
(Voice calls work ok though. Video calls on Google Meet or other apps work perfect.) After the WAN has stopped working, I can access Luci or ssh over LAN or Wifi. I have to do a manual reboot to make WAN work again. This however doesn't happen when both devices making whatsapp video call are on the same home network. Except this, everything is working perfect.
I've tried using snapshot, 19.07.8, 21.02.0, etc but face exact same problem. I am using a clean install without any additional packages.
Here is the log i captured yesterday when the problem happened.
Can anyone help me fix this weird problem?

BusyBox v1.33.1 (2021-10-24 09:01:35 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 21.02.1, r16325-88151b8303
 -----------------------------------------------------
root@OpenWrt:~# logread -f
Sun Dec 19 23:08:56 2021 daemon.info dnsmasq-dhcp[1831]: DHCPREQUEST(br-lan) 192.168.1.176 30:ae:a4:27:d3:d4
Sun Dec 19 23:08:56 2021 daemon.info dnsmasq-dhcp[1831]: DHCPACK(br-lan) 192.168.1.176 30:ae:a4:27:d3:d4
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8803.882852] ------------[ cut here ]------------
Sun Dec 19 23:13:51 2021 kern.info kernel: [ 8803.890225] NETDEV WATCHDOG: eth1 (ax88179_178a): transmit queue 0 timed out
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8803.900194] WARNING: CPU: 1 PID: 0 at net/sched/sch_generic.c:473 0xffffffc010604938
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8803.913027] Modules linked in: pppoe ppp_async iptable_nat brcmfmac xt_state xt_nat xt_conntrack xt_REDIRECT xt_MASQUERADE xt_FLOWOFFLOAD xt_CT pppox ppp_generic nf_nat nf_flow_table_hw nf_flow_table nf_conntrack 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 snd_bcm2835(C) hid evdev nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 tun 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
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.008968] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G         C        5.4.154 #0
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.021953] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.030616] pstate: 60400005 (nZCv daif +PAN -UAO)
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.038198] pc : 0xffffffc010604938
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.044388] lr : 0xffffffc010604938
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.050453] sp : ffffffc01000bdd0
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.056289] x29: ffffffc01000bdd0 x28: 00000000000000e0
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.064101] x27: 0000000000000140 x26: 00000000ffffffff
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.071835] x25: 0000000000000000 x24: 0000000000000000
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.079464] x23: 0000000000000001 x22: ffffff80357a9000
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.086995] x21: ffffff80357a9480 x20: ffffffc0108f6000
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.094437] x19: 0000000000000000 x18: 0000000000000000
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.101805] x17: 0000000000000000 x16: ffffffc011509dd8
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.109075] x15: 0000000000000020 x14: 0000000000000a40
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.116243] x13: 0000000000000000 x12: 0000000000000001
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.123293] x11: 00000000ffffffff x10: ffffff8035e66710
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.130254] x9 : ffffff8035e66710 x8 : 0000000000000001
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.137145] x7 : 0000000000000008 x6 : 0000000000000001
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.143936] x5 : ffffffc0103a46f0 x4 : 0000000000000002
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.150629] x3 : 0000000000000000 x2 : 0000000000000004
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.157252] x1 : 0000000000000004 x0 : 0000000000000040
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.163786] Call trace:
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.167372]  0xffffffc010604938
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.171611]  0xffffffc010111d90
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.175798]  0xffffffc0101125b0
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.179986]  0xffffffc0100813f4
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.184158]  0xffffffc0100a72ec
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.188296]  0xffffffc0100f7a3c
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.192395]  0xffffffc010081018
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.196480]  0xffffffc010082df0
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.200542]  0xffffffc0100864c8
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.204566]  0xffffffc0100d4a44
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.208539]  0xffffffc0100d4c3c
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.212480]  0xffffffc010095038
Sun Dec 19 23:13:51 2021 kern.warn kernel: [ 8804.216398] ---[ end trace a782cc9594947a90 ]---
Sun Dec 19 23:13:56 2021 daemon.info dnsmasq-dhcp[1831]: DHCPREQUEST(br-lan) 192.168.1.176 30:ae:a4:27:d3:d4
Sun Dec 19 23:13:56 2021 daemon.info dnsmasq-dhcp[1831]: DHCPACK(br-lan) 192.168.1.176 30:ae:a4:27:d3:d4
^Croot@OpenWrt:~#

ax88179, take a number .... Internet connection gone after performing speed tests - #10 by moeller0

1 Like

NETDEV WATCHDOG ax88179_178a

timing is kinda weird...

20201212-2031 2.3.636 r15199-5d2b577a53 5.4.82-1-9c8ae92a

that's way, way, way long ago... however... 19.x should be immune... very interesting... seems to maybe finger rpi firmware (plays a role)?
(think I saw some recent patches about this)

yeah... here we go (not sure if applies to rpi3 (asked) - 19.07.4 seems to be before the fallout and as your bootloader runs from sd? could be worth testing that ~ beware has known stale code so don't run it permanantly)...

click the first referenced link in the PR... references the asix dongle...

XHCI_VLI_TRB_CACHE_BUG @ popcornmix


update: word is your error is unrelated to the above... apologies


did find these loosely related comments somewhat amusing tho'

timg236

############# post 1
I think this should be raised as a Linux issue. Once the kernel is loaded the network interface is reset before starting the kernel. There is no shared network state between the firmware and the kernel.

############# final post
Resolved in pieeprom-2020-06-15
1 Like

What happens, when you insert a 100Mbps switch between Rpi and AP?
Is it still overloading the connection?

I guess its not a power issue. I'm using a 5V 4Amp powersupply. I have done 10 speed tests back to back but no problems. I have also stress tested it by
downloading 20GB file multiple times but still no problem. This problem only arises when using whatsapp video call when one device is outside home network.

Thanks for the reply. I am a bit confused how to implement your solution. Can you be a little more specific? I am quite new to this.

I dont have a switch to test. However I have tested with the inbuilt wifi of the RPi and still the same problem. Everything works except whatsapp video call.

Could still be a RPi usb port power issue, but yes, it doesn't seem to fail in the same way as in the other threads.

Yes it may be. But why does it only happen when starting a WP video call? if it would have been a usb port power issue it should happen all the time, right? I have continuously used this setup for 5 days non stop but no problem. The moment i start WP video call it goes mad. Isnt this very strange?

Can you change the eth0 speed with ethtool instead?

E.g.:

ethtool -s eth0 speed 100 duplex full autoneg off

Could be a Kernel / power management of the ethernet chip issue.

Thanks for suggesting. But bad news is it didnt help. Same thing continues.

I'm totally confused and out of options as of now... You guys have any idea what might be wrong?

Do you have another rpi board that you can try out? I am not sure whether the ethernet chip is ok.

I have a RPi Zero W but I think it wont be of any use.
I tried to swap the Asix Ethernet adapter as LAN and inbuilt Lan of RPi as WAN. Things were exactly same still. Only difference is earlier WP videocall would crash within 10 ~ 30 seconds but this time it lasted exactly around 9.50mins everytime and then LAN crashed.
From this I can infer that the Asix ethernet adapter is the culprit.
The only thing that is bugging me is that why everything works except WP videocalls? This is very strange behaviour.
I think I would get another usb to ethernet adapter with Atheros chip. Do you think this will work?
Or would you recommend something else? And which driver should i select for it?

EDIT:
I attached the Asix Ethernet adapter to my Redmi K20 Pro android phone and it worked well till I made a WP videocall and it crashed within 20 seconds. This again proves the Asix ethernet adapter is buggy. What is causing this WP videocall bug is beyond my understanding.

TP-Link UE300.

Thanks for recommending. I will get the UE300 then.
It says it uses RTL8153 chip. Do I need to install additional package or is it plug and play?

you'll probably need kmod-usb-net-rtl8152.

Ok. Big thanks everyone. You guys really helped me a lot :innocent:

1 Like

TP-Link says it's plug and play.

For the big operating systems (MacOS, Linux, Windows) which can bundle pretty much any/all drivers for these type things without concern about running out of storage space.

OpenWrt and other embedded systems are much more space/resource limited and thus do not include extra drivers beyond the ones required to enable the hardware onto which openwrt is installed.

Then I guess this would be the option...

Right. Which is why @frollic had provided the guidance on which driver package to install

What's your point?