No access via USB-C ethernet cable (Linux) - No DHCP reply and ASIX asix_rx_fixup() bad header length?!

[hachiman]

Hey everyone, 

as mentioned ASIX driver is not working on MacOS. I switched over to a (VirtualBox) Kali Linux guest. 

I have configured a USB filter to passthrough the ASIX NIC to the Linux machine, which works flawlessly. 

NIC with DHCP

First I setup eth1 with DHCP. nmcli shows that it is trying to receive an IP address, however it fails. 

Wireshark on eth1 also shows DHCP requests, yet no replies. 

NIC with fixed settings

Next I manually configured the IP settings. 

eth1 has been configured manually with 172.16.42.42, route seems to be all right.

I further removed the main NIC (virtually unplugged the cable) to make sure there are no other interferences. 

Still no access. 

What I see is an error message asix_rx_fixup() bad header length in dmesg.

Has anyone experience something similiar? 

Thanks! 

[chrizree]

I can't seem to recreate/reproduce your problem. But I'm not on Mac/Big Sur either so I don't have the same setup as you do. However, it works perfectly well for me to pass on the USB ASIX Ethernet NIC of the Mk7 to a VM guest in VirtualBox. As said, not Mac based for me but a Linux Lite installation in VirtualBox running on a host based on Lubuntu 20.04 LTS. Just disabled all network interfaces in VirtualBox for the VM guest. Then setting up a USB filter for the ASIX adapter (Mk7). It then boots up the VM with Mk7 access without any further configuration. DHCP working, SSH working as well as accessing the Mk7 web gui. My ASIX doesn't show up in the VM guest as eth0, eth1 or such, but with the interface name that you normally get when using the Mk7 (enx001337xxxxxx).

[hachiman]

Thanks for the input. Doesnt work, even though I did everything as you did. 

USB filter for the Linux VM, disable all other NICs on the Linux VM, boot, ASIX gets recognized as eth1 (which is somewhat different from your description of enx001337xxxxxx, but that shouldnt matter).

When I run Wireshark on the eth1 ASIX NIC I can see DHCP request but never any answers. 

When I configure it with a fixed IP of 172.16.42.42 and try to connect to 172.16.1.1 of the MK7, I see the correct route being setup and I see the corresponding ARP requests via Wireshark on eth1. But also, no reply. 

EDIT:

So apparently this is something with the MK7 (kinda glad I am not that stupid). 

I went into recovery mode to see if it changes. I have eth1 manually configured for 172.16.42.42 etc. and eth0 as my standard uplink for the virtual NAT network. 

Now when I open the browser and go to http://172.16.42.1 it immediately works and I am able to select the recovery firmware. Thats strange. 

 

EDIT 2: 

After FW recovery connect to 172.16.42.1:1471 or :80 fails again.... that is utterly frustrating. 

[Irukandji]

That Weird to happen. I don't know if @Darren Kitchen
Can look at it. The only two Macintosh's can't even run the latest version of macOS.. 

[hachiman]

7 minutes ago, Jtyle6 said:

That Weird to happen. I don't know if @Darren Kitchen
Can look at it. The only two Macintosh's can't even run the latest version of macOS.. 

Thanks @Jtyle6. 

I edited my post above. Super strange. The HTTP connection works when I put the MK7 in FW reset mode. After a successful reset and reboot (I assume based on the steady blue led light), it fails again. No reply on the eth1 NIC in my Linux box. 

So currently everything I try is inside a virtualized Linux machine, not on the MBP directly. However the error is quite similar.

There is no IP traffic, no DHCP, no matter whether I use my MBP (with the possibility of a flawed ASIX driver on Big Sur with 2019 MBP), or when I use the Linux machine. 

[chrizree]

In what way are you setting up USB filters in VirtualBox for the guest VM. Do you simply use what the host OS provides or are you setting up the filter all manually?

[hachiman]

I am using the automatic filter. However I dont see the problem there. 

As mentioned above, when I set the MK7 into recovery mode, it miraculously works. 

Recap: 

Set MK7 into recovery mode and follow instructions at https://docs.hak5.org/hc/en-us/articles/360055166053-Firmware-Recovery

Assign fixed IP settings for eth1 (which is the ASIX chipset) NIC, 172.16.42.42 with /24 subnet mask

Open browser and go to 172.16.42.1

Result:
It works and I can access the FW recovery website of the MK7

Analysis:

• The USB filter works, the ASIX chipset is correctly recognised by the Linux guest VM
• The driver in the Linux guest works, the NIC comes up, I can assign IP settings, I can ping the NIC at the assigned IP of 172.16.42.42
• This implies also that the USB passthrough at hypervisor level works
• The USB-C port works at the MBP
• The USB-C cable works
• The ASIX chipset works 

Problem: 

After recovery and reboot of the MK7, the same problem occurs as before. Even when I skip DHCP and keep the existing settings for the eth1 NIC, I dont get any answer from the MK7 itself. 

Wireshark shows nothing on eth1, except outgoing arp requests for 172.16.42.1

If I revert back to DHCP for eth1, it is stuck sending DHCP requests but never receives an answer. Also seen in Wireshark. 

[chrizree]

To rule the Mk7 out, it would be interesting to see how it behaves with another setup (for example like the one I used to try to recreate your issues), but you probably need an alternative computer for that.

[hachiman]

I just tried it again. I put the MK7 into recovery mode, it works. I can access its website at 172.16.42.1 flawlessly. 

Now I am resetting it again, without much hope. 

 

After several tests I can say that the MK7 is easily accessible when in recovery mode. 

Normal startup and the website at 172.16.42.1 doesnt work, with no traffic at L2 or L3 be seen within Wireshark. 

NIC setup stays the same and is not altered. 

 

I kept ping running while accessing the recovery website, works perfectly fine. I can watch ARP resolution, ICMP packets and HTTP packets via wireshark.

MK7 recovers and reboots in normal mode (with blue LED), ping dies, timeout, no ARP, only outgoing traffic in wireshark, nothing incoming anymore.

 

PS: 

If I use my iPad in parallel to connect to the WiFi of the MK7 -> this works. 

So it is not the MK7 in general. There must be something wrong on the USB-C ethernet end. Even though I have no idea what that might be. 

EDIT:
I would upload another screenshot, but apparently I used all my space here. 

[chrizree]

I have no further suggestions other than the already mentioned action that involves trying it all on an alternative computer with an alternative OS, or create a Hak5 support ticket.

[hachiman]

Appreciate it @chrizree

I think I have to open a ticket, or maybe @Darren Kitchenswings by this thread and has some other ideas. 

[jbeez]

I have the same exact experience hachiman.  I just recieved my mk7 this week.  I just went to set it up on my MBP with big sur and same experience.  Plugged it into my dell XPS w/ windows10 and the usb-c works fine.

I installed the driver in osx, I was checking tcpdump, same exact thing, it was requesting for an IP but never a response.

[jbeez]

Not sure that it matters, but I noticed on my MBP the asix driver sets the speed to 100baseTX, the ASIX interface is supposed to be a gigabit interface?

[hachiman]

Hey everyone, 

 

just a brief update from my end. Maybe someone else comes across this and my experience can be of any help. 

After multiple strange failures with Kali Linux (lsusb works, lsmod etc. as well, but no traffic, no ARP, no DHCP, no HTTP on the eth int of MK7, except when MK7 is in recovery mode, USB filter set in VirtualBox):

I tried it with a Win10 (also virt. guest on the same MBP on the same VirtualBox hypervisor) and all of a sudden it worked. 

Now I tried it with a fresh install of Parrot Sec and it works like a charm. 

I have no idea what this could be but it really bugs me out. 

So if you have a similar issue setting up WiFi Pineapple MKVII on Kali Linux, try a different OS.