Recovery after electrical storm took out WAN adapter

This applies to my pi4 router running 24.x (recently upgraded to latest stable). We had an electrical storm the other night and I woke to my LAN having no internet access. A bit of troubleshooting revealed that that my WAN port (asix 88772a usb-to-ethernet adapter) on the pi4 was not working properly (flapping, as I think it’s called), likely due to a nearby lightning strike. Another machine on my LAN had also had its adapter compromised, though the cable modem, a second wired client, and the LAN port of the pi4 had suffered to ill effects.

I’ve confirmed by the way that the usb port on the pi4 to which the asix adapter was connected is functional since I was able to mount a usb flash drive there and read/copy files to/from that drive. So I’m pretty certain the asix adapter itself is the only damaged component on the pi4. And when it’s connected I do see in dmesg output that it continuously comes up and goes down.

Anyway I decided that the most painless way to restore my network would be to buy a replacement usb-to-ethernet adapter that uses the same chip as the original one. To that end, I located a ugreen usb-to-ethernet adapter that uses a slightly different revision of the hardware, the 88772e (“e” as opposed to “a”) chip and plugged it into the usb port (I’ve tried 3 of 4 usb ports, btw).

While usbcore reports that an asix device is getting registered, no ethX device file seems to be getting assigned to it. So this has not been the drop-in replacement I’d hoped it would be. I can’t assign a new WAN interface because, obviously, there is no device file representing the hoped-for drop-in replacement interface.

So I’m looking for suggestions for things to try. Any pointers will be much appreciated.

BTW this is a brand new usb-to-ethernet adapter, taken out of the package just yesterday. So it should not be suspect in any way. Additionally, while I was trying to discover its mac address I plugged it into my laptop and it did get assigned a device file (eth1) there. That said, I didn’t test its network functionality beyond that.

Do you have a vacant port on a multi-port device to re-purpose as new WAN?
Are you sure provider's boxes are not knocked out?

I had a back-up router that I put in place as soon as I realized the WAN port adapter could not be easily diagnosed/restored. So the internet has been working pretty much fine using it. Thanks for suggesting that.

I think I’ve found the crucial clue. And it has to do with what I guess should be called false advertising. Though the replacement adapter I bought was advertised as using the 88772e chip, when I plug it into my Arch laptop and run lsusb I get output indicating it is actually the ax88179 gigabit adapter chip. So I wound up getting a 1gb adapter rather than the 10/100 one I ordered, and for under 10 USD, something about which I’d otherwise be happy. But since it uses a different module than the one I have on this system and since I now have no internet access from the router (WAN port down), it presents an additional PITA since I now have to figure out how to get the RIGHT module onto the router.

1 Like

Download the kmod-usb-net-asix-ax88179 package onto your computer and then copy it over via scp to your pi. From there you can install it and the adapter should spring to life.

That’s what I thought of doing, psherman. But AI has been advising me that it’s not that simple and that I need to get internet access. Or set up a temporary package repo on my laptop (from which I can connect to the pi4) or on a usb drive. I’ll be very glad if it really is as simple as you say.

Skip that, you can add modules also via firmware-selector and do full upgrade.

Thanks for offering that advice, brada4. Finding and downloading the module doesn’t present much of a problem. But I’m unclear about the installation part. By “firmware selector” are you referring to System > Backup/Flash firmware in the Luci interface? I mean, bearing in mind I can’t get internet access ATM due to WAN port absence.

For simple packages like drivers, there are often no additional dependencies so it should just work.

You can build a custom image with your driver pre-installed.

Nope, you install apk/ipk using SSH.

sysupgrade file from firmware-selectro.openwrt.org has to be used as any pther sysupgrade-compatible file.

Ok. Yeah I’ve used firmware selector before to build a custom image. But it’s been a few years. So it sounds like from what you’re saying that I could scp over the kmod to the router, then just do opkg install /path/to/module, right? Thanks

1 Like

Yes, exactly.

Yeah, that got the module installed. Thanks. However the ethX device file is still not being associated with the device that is now evidently being recognized by the system. Not quite sure how to proceed from here. Perhaps some other helper module is needed? Further tips will be appreciated.

Try removing eth1, restart, then re-add eth1.

There’s no eth1 currently listed on the system. At least ip addr doesn’t show one. Nor can I find eth1 in the Luci interface. It used to show up when the 88772a adapter was plugged in (and flapping after the electrical storm). But once I removed the device physically, eth1 disappeared from the system. eth1 is, as you seem to have understood, supposed to be the WAN port. I must be on about my 20th reboot and the last few have been without the problem adaptor connected.

Ok... then just try adding eth1. Does that work?

Thanks for the suggestion. When you speak of adding eth1, do you mean adding by, for example, editing /etc/config/network and creating for it a stanza there? I can’t find any evidence in dmesg output that the kernel sees any ethX on the system other than eth0, so I can’t see how that could help. Then again I’m far from having expertise in these matters and could very well be mistaken in that assumption.

Yes, you can simply create a new stanza with eth1 as the interface. Or, for that matter, you could add it to the existing br-lan (if you're using that for your lan interface), and if it works, it would operate just like the built-in ethernet port on your lan.

I did create in /etc/config/network an additional config device stanza that contains the line option name ‘eth1’ (I also tried eth2 and eth99 just for kicks) but that made no difference as far as ip addr output shows: I still see the only lo, eth0, phy0-ap0, and br-lan in that output, even after a reboot. I think I’m using br-lan for my LAN interface, yes. So I’ll start looking into that. Thanks for your continued input.

I’m still unable to get this new usb-to-ethernet adapter to work, even now that the correct kernel module is loading, due to the fact that it is not being assigned an ethX device file by the system. Honestly the results I’m seeing so far are very strange and a bit beyond my limited technical comprehension: the adapter does now, according to dmesg output, get a numerical designation of 1-1.2 (or 1-1.4, depending on which usb port it’s plugged into) and that output also shows that, despite it using the ax88179 module, it is nonetheless being somehow identified to the system as “Product: AX88772E”.

Meantime, since it seems like having WAN access could make the restoration process a whole lot less of a hassle, I’ve been exploring other options for getting some kind of alternate temporary WAN port. To that end I located in my junk pile yesterday a tl-wn822n (ver. 1.1) usb-to-wifi adapter which, as I’ve understood, should be pretty compatible with openwrt due to its ath9k wifi chip. I managed to locate kmod files for the adapter at the releases repo for my openwrt release (same repo where I found the kmod-usb-net-asix-ax88179 that I just managed to install - https://downloads.openwrt.org/releases/24.10.4/targets/bcm27xx/bcm2711/kmods/6.6.110-1-5642ee3ae5a6da3ce336f51cf968083c/). But when I copied them over to my rpi4 router and tried to opkg install them I hit a roadblock: despite them being in the same repo where I got the other kmod I just installed, it appears they were compiled against a different kernel source than the one on my rpi4 router and so will not install. The problem kmods have the kernel designation 6.6.110.6.12.52-r1 in their title, while the one that installed without issues has the kernel designation 6.6.110-r1 in its title. Because of the mismatch, opkg refuses to install them (incompatible with the architectures configured). So I’m now hitting a dead end on this potential workaround.

I’d just like to ask in wrapping up this post whether this kernel mismatch for kmods in a repository for a particular openwrt release is a common issue? In that particular repo, though most kmods have the 6.6.110-r1 kernel designator in their titles, there are something like 3 or 4 other kernel designators such as 6.6.110.6.12.52-r1 to be found among about a quarter of the files I see there.

I got internet access by associating via wifi with a nearby router. Managed to install those ath9k modules/firmware that way. But still no joy. Somehow the system is refusing the create/bind device files for either of these usb-to-ethrnet/wifi devices. For some reason that is beyond my current comprehension.