Opened 6 years ago

Last modified 2 months ago

#9624 assigned bug

AX88772B USB Ethernet. Read::MISMATCH of the frame length

Reported by: kallisti5 Owned by: nobody
Priority: normal Milestone: R1
Component: Drivers/Network/usb_asix Version: R1/Development
Keywords: MISMATCH Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

Asus USB Ethernet dongle using the usb_asix driver.

Get a large number of the following error paired with stalling network communications:

KERN: usb_asix:06.09.160:Read::MISMATCH of the frame length: hdr 153; received:154

hdr is always one less than received.

Attachments (1)

Change History (20)

comment:1 by kallisti5, 6 years ago

Summary: Asus USB Ethernet. Read::MISMATCH of the frame lengthAX88772B USB Ethernet. Read::MISMATCH of the frame length

comment:2 by kallisti5, 6 years ago

Looking at recent changes, hrev44805 may be to blame for this. (as I swear this usb dongle has worked in the past)

comment:3 by kallisti5, 6 years ago

Owner: changed from siarzhuk to kallisti5
Status: newassigned

#8238 may be related. testing some tweaks now.

comment:4 by korli, 6 years ago

Did you check without hrev44805 applied?

comment:5 by kallisti5, 6 years ago

Yeah, same result. My recent commit mostly cleared up the fact that the registers do different things on the A vs B models.

comment:6 by kallisti5, 6 years ago

I purchased another USB ethernet adaptor. (D-Link DUB-E100 rev.C1)

Turns out it is the same idential chipset :( After adding the USB ID, I encountered the exact same error.. so it definitley looks like AX88772B is broken in general and it wasn't a one-off issue.

comment:7 by siarzhuk, 6 years ago

Why just to not ignore this extra byte? Probably this is some kind of CRC - anyway as soon as the length in header is not more than actal received amount you should be on the safe side. ;-) Have you tried this? It is always good idea to run two tcpdumps on the Haiku and outside of it to investigate packets content.

PS: How is your adapters are looking like? Yes, there are always difficult to find corresponding hardware to buy - all is masked by this marketing names. :-\ On the same reason I have postponed #8238 - just had no such hw.

comment:8 by phoudoin, 6 years ago

Well, when compared to FreeBSD's if_axe.c/if_axeregs.h, it seems that each frame is 16bits aligned, which can explain these 153 vs 154 mismatches.

I'm also worried that the device is supposed to send frames in burst mode, but we only queue an USB bulk read for one frame max size (1536 or something). In such situation, if several small (think UDP) ethernet frames are really pending, the device will return *several* frames in one bulk read, but we only use the first one. It's clearly broken.

comment:9 by kallisti5, 6 years ago

I found a AX88772 device (D-Link DUB-E100 rev.B1) and am seeing the same errors.. The AX88772 does seem to have minimal functionality though compared to the AX88772B.

KERN: usb_asix:05.10.198:Read::MISMATCH of the frame length: hdr 359; received:360
KERN: usb error ehci -1: qtd (0x9885600) error: 0x00048d50
KERN: usb_asix:05.12.328:Read::Device status error:0x8000a01a
KERN: usb_asix:05.12.329:Read::Error: no place for TRXHeader:only 0 of 4 bytes.
KERN: usb_asix:05.12.339:Read::Error:TRX Header is invalid: len:0x3047; ilen:0x316
KERN: usb_asix:05.13.073:Read::MISMATCH of the frame length: hdr 105; received:106
KERN: usb_asix:05.13.253:Read::MISMATCH of the frame length: hdr 125; received:126
KERN: usb_asix:05.16.918:Read::MISMATCH of the frame length: hdr 243; received:244
KERN: usb_asix:05.21.200:Read::MISMATCH of the frame length: hdr 216; received:280
KERN: usb_asix:05.21.201:Read::MISMATCH of the frame length: hdr 92; received:156
KERN: usb_asix:05.25.975:Read::MISMATCH of the frame length: hdr 243; received:244
KERN: usb_asix:05.27.522:Read::MISMATCH of the frame length: hdr 153; received:154
KERN: usb_asix:05.27.524:Read::MISMATCH of the frame length: hdr 153; received:154
KERN: usb_asix:05.27.525:Read::MISMATCH of the frame length: hdr 153; received:312
KERN: usb_asix:05.36.926:Read::MISMATCH of the frame length: hdr 185; received:186
KERN: usb_asix:05.38.543:Read::MISMATCH of the frame length: hdr 243; received:244
KERN: usb_asix:05.39.619:Read::MISMATCH of the frame length: hdr 165; received:166
KERN: usb_asix:05.39.620:Read::MISMATCH of the frame length: hdr 165; received:166

comment:10 by phoudoin, 6 years ago

The MISMATCH errors are showing that either we've just facing 16bits alignment or, and it's here far worst, we've retrieved from USB controler more than a single frame but only consume the first one. And the reason is quite simple: our driver is clearly not Multi-Frame-Burst (MFB) mode aware... aka broken.

The three error at ~05.12.328 seems more related to an USB error condition, though.

Last edited 6 years ago by phoudoin (previous) (diff)

in reply to:  9 comment:11 by siarzhuk, 6 years ago

Replying to kallisti5:

I found a AX88772 device (D-Link DUB-E100 rev.B1) and am seeing the same errors.

Are you working on this problem ATM? I see some bids on ebay.de and itching to squeeze out of this whistle all of its possibilities. ;-)

comment:12 by phoudoin, 6 years ago

Owner: changed from kallisti5 to phoudoin
Status: assignedin-progress

I'm moving this ticket to my top backlog right now :-), having found back my old DUB-E100 revB1. Expect change in the next few days.

in reply to:  12 comment:13 by kallisti5, 6 years ago

Replying to phoudoin:

I'm moving this ticket to my top backlog right now :-), having found back my old DUB-E100 revB1. Expect change in the next few days.

Hows the backlog? :D

comment:14 by phoudoin, 6 years ago

Backlog is two months old, due to Real Life Issues(tm) I keep to always underestimate :\

One thing that held me too is the fact that I've to develop under VirtualBox (thanks to UEFI madness) and failed so far to find a way to expose that USB adapter from host to guest OS. So far, I've just started to change a bit the *Device classes hierarchy in order to split them between single-frame and multi-frame-burst devices, and I've a drafty (untested, see above why) MFB read support.

Last edited 6 years ago by phoudoin (previous) (diff)

comment:15 by korli, 6 years ago

It would seem that phoudoin is right, packets are 16bits aligned, the driver should probably expect this additional byte and keep it for processing in the next packet...

comment:16 by korli, 6 years ago

I guessed wrong, packets are 16 bits aligned, just padded. I adjusted the logging in hrev45900, the stalling communications should still remain though, I can't reproduce them here on Intel EHCI. FWIW I have the device ids: 0x0b95:0x7e2b.

comment:17 by siarzhuk, 4 years ago

JFYI: the datasheet for AX88772B can be goodled by name AX88772B_Datasheet_v104.pdf. My copy is 1120745 bytes big and was received directly from Asix support 4 years ago. It is looking fairly detailed.

comment:18 by phoudoin, 2 years ago

Owner: changed from phoudoin to nobody
Status: in-progressassigned

comment:19 by probono, 2 months ago

Getting

KERN: [33musb_asix:[0m31.23.576:Read::Error of queue_bulk_v request:0x80000000
KERN: PMA: bad value for allocate (41231686064 bytes)
KERN: usb error xhci 0: failed to allocate TRBs

The AX88772B based USB to Ethernet device does not get an IP address in Haiku (nightly build as of today).

Note: See TracTickets for help on using tickets.