USB pluggable Gigabit ethernet adaptor stops functioning after tcpdumping ~100mb/sec of traffic


#1

Hi There,

I just bought two USB Pluggable Gigabit Ethernet adaptors - and unfortunately they don’t seem to be behaving too nicely in OS X Mountain Lion.

I installed the drivers early and rebooted as prompted by the automated email from amazon (nice) :o) - however - the adaptors *appear* to work fine initially, however when I use with network diagnostics tools (ntop, specifically, although I replicated it using tcpdump) - to look at high throughputs of data, the adaptor stops working. I have to reset the interface in order to allow throughput again.

I need to sniff traffic of around 100mb, but it seems to stop functioning… can you assist?

Thanks,

Adam.


#2

Hi Adam-

Thanks for posting with your issue, I’ll be happy to help!

Since we have both a USB 2.0 and a USB 3.0 gigabit adapter now, for starters if you could please clarify which one you have this will help. The 2.0 is grey, the 3.0 is black.

Also, are you seeing this issue on both adapters? If so, I’ll want to try and duplicate it if it’s something we can reproduce on standard tools like ntop/tcpdump, so any further details you can share about the trigger conditions would be helpful to see if we can duplicate or if this might be something system specific.

Best wishes-

Jeff Everett
Plugable Technologies


#3

Heya Jeff,

Thanks for the speedy reply! I have the USB 2.0 one I believe. System Profiler sees it as an AX88178 on the USB High-Speed bus (max Speed 480Mb/sec).

I’ve switched the adapters around and they both seem to do it - so I am able to replicate on both. I’ve captured multiple tcpdump’s but they’re too big to wade through to spot anything obvious.

I’ve done some playing this evening and I’ve managed to find it only seems to reproduce this issue when I span one particular vlan. That vlan carries PPPoE traffic between my ISP router and my PPPoE terminator… not sure if this traffic makes any difference somehow…

I’ll do some more research tomorrow tomorrow to find if this really is it or if its something else i’m missing… for now, its bed time :o)

Thanks,

Adam.


#4

Ok, wee bit of an update - its not the PPPoE thing, it happens with/without that, the timings just appear random, and sometimes i have to wait aaaages for it to stall so debugging this is a bit of a nightmare.

I’ve currently got it mirroring one port, and i’m looking at that - its so far been running for about 5 hours (longest) - so I think this is ‘reliable’. I’ll leave it for a full 24 hours before increasing to the next port… then the next, and so on. This could take a while to replicate with the smallest amount of data…

(I’ve tried mirroring just the first 5 ports, and then the last 15 - but both these break it) - tried doing each individual vlan, but these all break it… It does appear to break faster if i’m snooping that PPPoE traffic (which contains raw public internet stuff)… but that’s the only common thing i’ve noticed so far!


#5

Hi Adam-

Thanks for the additional details!

I can’t say any of this triggered a solution that we can suggest: it sounds like the adapter might just be getting overloaded trying to look at a lot of data that it wouldn’t in a “normal” configuration.

From the 5 hours comment I’m guessing you may be OK, but let us know if you’ve found a scenario that is consistently failing out and we can look into it.

Best wishes-

Jeff Everett
Plugable Technologies


#6