WAN crash when on Whatsapp Videocall

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?

Maybe I misinterpreted your other comment about plug and play - but it seemed that you were under the impression that the drivers would be pre-installed on openwrt. When I described that plug and play only applies to the big os’s, you then quoted @frolic, which seemed unnecessary.

I think your time would be better spent not trying to "interpret" my post, or determining what is or isn't "necessary".

:thinking:
What a strange response.
:man_shrugging:

ARM... wanna test it in a x64 linux pc for us?

Yes of course i can test if it helps the community in any way.
I have a linux mint live cd on a thumb drive. Would that do?

One thing i would like to mention that I'm a rookie in linux, so if u ask me to do very complex things, u would have to give me appropriate instructions.

1 Like

(o crap... no idea if there is a client on linux)

disregard-request-apologies-too-much-hassle-or-needs-to-be-setup-as-the-router

assuming you disabled wifi+mobile internet when you tested on the phone and connected whatsapp running on the phone over the wired adapter

for a pc/notebook test you'd pretty much just plug the thing in and make sure wireless is off then run whatsapp then open video

gathering the kernel version of those OS's may also be of use:

admin > terminal > uname -a
(maybe 'super/windows-key + t' will open?)

no biggie... the fact you tested on the phone is a great indicator already... and i'm sure someone else will be able to test this sooner or later

basically from the (useful) info you've provided...

  • this bug is distinctly different than the majority of others linked
  • this bug is (tentatively) confirmed on ARM cpus and eliminating x64 OR newer kernels might help others who own these adapters