Wireshark · Wireshark-dev: Re: [Wireshark-dev] ethernet over USB

["ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>]

Hi.

I think you are comparing apples to oranges here.

SnoopyPro is a USB capture tool and it captures the various layers of
the USB protocol.
When used for EthernetOverUSB several layers above the USB layer  is
where you will find Ethernet frames.

So   with SnoopyPro you are capturing USB frames.


With wireshark on Linux you were capturing not USB frames  but rather
the Ethernet frames running on the virtual link layer provided by USB.


Your stack looks like this :

IP
Ethernet
Upper USB layer
Lower USB layer

With snoopy you captures tiny frames in the Lower USB layer and with
Wireshark you captured packets all the way up in the Ethernet layer.
thats why there is no real relation between what Wireshark saw on
linux and what snoopy saw on windows.   Two different layers.


To get something similar to what snoopy captured from your linux box
you must make it capture traffic on a much lower layer.


To be able to capture the USB layer on linux you need a new version of
TCPdump (download and install the latest tcpdump/libpcap svc version)
and also recompile your linux kernel so that it provides a pcap-like
interface to the USB layer.

http://wiki.wireshark.org/CaptureSetup/USB?highlight=%28usb%29

describes what you need to do to capture the usb frames on linux.


Since libpcap now has an encapsulation type for USB frames   which
usbmon in linux uses to write wireshark compatible pcap files,  you
may want to ping the snoopypro people and ask them if they can make
usbsnoopy compatible with libpcap and write libpcap files.



2008/2/2 Bill Fassler <bill.fassler@xxxxxxxxx>:
> Just in case someone is as interested as me, I meant to attach these files:
>
>
>
> Bill Fassler <bill.fassler@xxxxxxxxx> wrote:
>
>  Well I found a packet to packet correlation between the two sniffers and
> then I tried to hand dissect the snoopypro packet based on what I could
> learn from the Wireshark Capture.
>
> I have a couple questions, I understand this might be outside the normal
> scope of things here, so if nobody knows or doesn't want to spend the time
> looking at this I'll certainly understand.
>
> I am trying to understand as much through "reverse engineering" before I
> resort
> to the "protocol standard".  I like to try to do this because on rare
> occasions you
> run into proprietary protocols and you can't get your hands on any
> "standard".
>
> 1) What is the traffic inbetween real ethernet packets.  Hearbeat packets as
> Tyson seems to suggest or something more perplexing?
>
> 2) What is in the Ethernet header/wrapper where it seems there are only
> a few relevant bytes of data and many many empty (0x00 bytes)
>
> 3) How did I screw up on the byte size of my hand dissection? (highlighted
> below)
>
> The development team and the helpful users here have helped and saved me
> much time in the past, so I thought I would toss this over the fence:
>
> Here is the raw USB capture for this packet (according to SnoopyPro)
>
> 010000008e000000240000006200000000000000000000000000000000000000000000000000000000000000ae936c17012456da9ca1b3f30800450000542bdf400080014b75c0a80103c0a801010000b2c4760000016d070000177500000000000000ec560000000000080000000800000000000000caa65000c8eb5600c4eb5600405151000300000003000000
>
>
> ****************************************************************************************************************
> Raw Ethernet captured by snoopypro and hand dissected
> *****************************************************************************************************************
> I am trying to understand this USB wrapper/header which seems to be the same
> for every packet with just a few exceptions:
>
> 010000008e000000240000006200000000000000000000000000000000000000000000000000000000000000
>
> Destination:
> ae936c170124
> Source:
> 56da9ca1b3f3
> Traffic ID (Ethernet):
> 0800
> Version:
> 4
> Header Length: |
> 5                     |
>                        | <== I lost continuity here.  Wireshark claims 20
> bytes, but I
>                        | <== couldn't see how that was obtained. (seems like
> more to
>                       |  <== me when I count them manually)
> 0000               |
> Total Length:
> 54 (84)
> Identification:
> 2bdf
> Flags:
> 4
> Fragment offset:
> 000
> Time to live:
> 80 (128)
> Protocol IMCP:
> 01
> Header Checksum:
> 4b75
> Source:
> c0a80103
> Destination:
> c0a80101
> Type:
> 00 (Ping Reply)
> Code:
> 00
> Internet Control Message protocol checksum:
> b2c4
> Identifier:
> 7600
> Sequence Numer:
> 0001
>
> Ethernet payload:
> 6d070000177500000000000000ec560000000000080000000800000000000000caa65000c8eb5600c4eb5600405151000300000003000000
>
>
> **********************************************************************************************
> Dissected Wireshark capture of same packet
> *********************************************************************************************
>   No.     Time        Source                Destination           Protocol
> Info
>       7 12.412641   192.168.1.3           192.168.1.1           ICMP
> Echo (ping) reply
>
> Frame 7 (98 bytes on wire, 98 bytes captured)
>     Arrival Time: Jan 31, 2008 17:09:28.729364000
>     [Time delta from previous captured frame: 0.000057000 seconds]
>     [Time delta from previous displayed frame: 0.000057000 seconds]
>     [Time since reference or first frame: 12.412641000 seconds]
>     Frame Number: 7
>     Frame Length: 98 bytes
>     Capture Length: 98 bytes
>     [Frame is marked: False]
>     [Protocols in frame: eth:ip:icmp:data]
>     [Coloring Rule Name: ICMP]
>     [Coloring Rule String: icmp]
> Ethernet II, Src: 56:da:9c:a1:b3:f3 (56:da:9c:a1:b3:f3), Dst:
> ae:93:6c:17:01:24 (ae:93:6c:17:01:24)
>     Destination: ae:93:6c:17:01:24 (ae:93:6c:17:01:24)
>         Address: ae:93:6c:17:01:24 (ae:93:6c:17:01:24)
>         .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>         .... ..1. .... .... .... .... = LG bit: Locally administered address
> (this is NOT the factory default)
>     Source: 56:da:9c:a1:b3:f3 (56:da:9c:a1:b3:f3)
>         Address: 56:da:9c:a1:b3:f3 (56:da:9c:a1:b3:f3)
>         .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
>         .... ..1. .... .... .... .... = LG bit: Locally administered address
> (this is NOT the factory default)
>     Type: IP (0x0800)
> Internet Protocol, Src: 192.168.1.3 (192.168.1.3), Dst: 192.168.1.1
> (192.168.1.1)
>     Version: 4
>     Header length: 20 bytes
>     Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
>         0000 00.. = Differentiated Services Codepoint: Default (0x00)
>         .... ..0. = ECN-Capable Transport (ECT): 0
>         .... ...0 = ECN-CE: 0
>     Total Length: 84
>     Identification: 0x2bdf (11231)
>     Flags: 0x04 (Don't Fragment)
>         0... = Reserved bit: Not set
>         .1.. = Don't fragment: Set
>         ..0. = More fragments: Not set
>     Fragment offset: 0
>     Time to live: 128
>     Protocol: ICMP (0x01)
>     Header checksum: 0x4b75 [correct]
>         [Good: True]
>         [Bad : False]
>     Source: 192.168.1.3 (192.168.1.3)
>     Destination: 192.168.1.1 (192.168.1.1)
> Internet Control Message Protocol
>     Type: 0 (Echo (ping) reply)
>     Code: 0 ()
>     Checksum: 0xb2c4 [correct]
>     Identifier: 0x7600
>     Sequence number: 1 (0x0001)
>     Data (56 bytes)
>
> 0000  6d 07 00 00 17 75 00 00 00 00 00 00 00 ec 56 00   m....u........V.
> 0010  00 00 00 00 08 00 00 00 08 00 00 00 00 00 00 00   ................
> 0020  ca a6 50 00 c8 eb 56 00 c4 eb 56 00 40 51 51 00   ..P...V...V.@QQ.
> 0030  03 00 00 00 03 00 00 00                           ........
>
>
> Bill Fassler <bill.fassler@xxxxxxxxx> wrote:
>  Tyson,
>
> Thanks I'll check that out.  I also had the idea that perhaps I could export
> both capture logs into ASCII text and then use a perl script or something to
> try and identify two corresponding packets the raw USB packet that snoopypro
> has which matches the clean ethernet only packet(s) that Wireshark captured.
> I boiled the Wireshark capture down to six packets, ARP broadcast, ARP
> response, PING request PING response (x2).
>
> The snoopypro log during this period has closer to 200 packet captures.  I
> suppose I could just sit down with a magnifying class and in the time I have
> taken trying to find the sensible easy solution I could have by brute force
> found them manually (maybe).
>
> Bill
>
> Tyson Key <tyson.key@xxxxxxxxx> wrote:
>  Hi, assuming that you're referring to USB Communications Device Class, or
> ATM-over-USB devices (e.g. some consumer ADSL routers), everything gets sent
> as a generic URB_BULK(?) transmission, if I remember correctly, which
> Wireshark can't currently analyze. I'm not sure myself why it constantly
> sends a flow of data, even when both computers aren't using the link
> (presumably heartbeat traffic?). Assuming that Linux doesn't use some weird
> custom header, the USB Forum specifications might be of use.
>
> Hope that helps.
>
> On Jan 31, 2008 10:57 PM, Bill Fassler <bill.fassler@xxxxxxxxx> wrote:
> > Hey guys, I have been trying to understand ethernet over USB.  I have
> ethernet over USB working on an embedded development board running a
> blackfin DSP and uClinux.  I have everthing configured and can network with
> either linux or windows.  I am trying to understand the protocol and packet
> headers, wrappers and such.
> >
> > In an attempt to understand things I installed snoopypro and upgraded my
> Wireshark to 99.7, then I ping the windows box and it responds and I capture
> the traffic using both sniffers (yours and snoopypro).  I can not yet
> however, find a packet for packet correlation.  The sequence numbers are
> different.  I suppose that is because Wireshark sequence numbers are soley
> based on the Ethernet traffic (ARP and PING), when snoopypro picks up the
> higher layer and the sequence numbers reflect that.
> >
> > I tried to limit the traffic to just one ping.  Figuring that should be
> easy.  It wasn't since apparently the linux ethernet over USB driver sends
> stuff out almost constantly regardless of whether there is ethernet traffic.
> >
> > Any hoooo... you guys are the experts here.  I imagine I am making a
> simple task difficult.  How can I understand the ethernet over USB packet
> better?  I am thinking about writing a non-linux based version of this......
> and don't understand it enough to even start just yet..
> >
> > Bill Fassler
> >
> >
> > ________________________________
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
> now.
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
> >
>
>
>  _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>  ________________________________
> Never miss a thing. Make Yahoo your homepage.
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>  ________________________________
> Never miss a thing. Make Yahoo your homepage.
> _______________________________________________
>
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>
>
>
>  ________________________________
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
> now.
> _______________________________________________
>  Wireshark-dev mailing list
>  Wireshark-dev@xxxxxxxxxxxxx
>  http://www.wireshark.org/mailman/listinfo/wireshark-dev
>
>