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

[Andy Lawman <ALawman@xxxxxxxxxxx>]

I'm afraid I can't help with questions
1 & 2, but I think 3 is straightforward:

The header length in IPv4 is a 4 bit
quantity in units of 4 bytes. 5 yields 20 - the length of an IPv4 header
with no options specified. So that's 20 bytes from the start of the IPv4
header (0x45) to the end of it. Immediately after this is the IP payload
of 64 bytes (84-20) - an ICMP message in this case. This is an echo reply
with 56 bytes of data (64-8) which you labeled the Ethernet payload. This
isn't anything to do with the Ethernet protocol, but is ICMP echo data
that's being echoed back - the echo request/reply protocol requires that
any data sent on the echo request is copied in to the echo reply. This
is exactly how Wireshark decoded the packet.   

Andy.

Bill Fassler <bill.fassler@xxxxxxxxx>

To	Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
cc
bcc
Subject	Re: [Wireshark-dev] ethernet over USB

Bill Fassler <bill.fassler@xxxxxxxxx>

Please respond to : Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>

Sent by: wireshark-dev-bounces@xxxxxxxxxxxxx  
01/02/2008 18:15

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

IMPORTANT - CONFIDENTIALITY NOTICE - This e-mail is intended only for the use of the addressee/s above.  It may contain information which is privileged, confidential or otherwise protected from disclosure under applicable laws.  If the reader of this transmission is not the intended recipient, you are hereby notified that any dissemination, printing, distribution, copying, disclosure or the taking of any action in reliance on the contents of this information is strictly prohibited.  If you have received this transmission in error, please immediately notify us by reply e-mail or using the address below and delete the message and any attachments from your system.

Amadeus Services Ltd, World Business Centre 3, 1208 Newall Road, Hounslow, Middlesex, TW6 2TA, Registered number 4040059