[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6045

--- Comment #9 from Tyson Key <tyson.key@xxxxxxxxx> 2011-07-01 08:50:52 PDT ---
Having spent some more time looking a trace from last night, I'm slightly
stumped.

For example:

No.     Time           Source                Destination           Protocol
Resource   Length Info
  14381 4358.602424000 host                  7.4                   AFP         
       148    FPLogin request

Frame 14381: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits)
    Arrival Time: Jul  1, 2011 01:10:44.923337000 BST
    Epoch Time: 1309479044.923337000 seconds
    [Time delta from previous captured frame: 0.001285000 seconds]
    [Time delta from previous displayed frame: 1.048024000 seconds]
    [Time since reference or first frame: 4358.602424000 seconds]
    Frame Number: 14381
    Frame Length: 148 bytes (1184 bits)
    Capture Length: 148 bytes (1184 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: usb:usbmux:tcp:dsi:afp]
    [Coloring Rule Name: TCP]
    [Coloring Rule String: tcp]
USB URB
    URB id: 0x00000000f6118800
    URB type: URB_SUBMIT ('S')
    URB transfer type: URB_BULK (0x03)
    Endpoint: 0x04, Direction: OUT
        0... .... = Direction: OUT (0)
        .000 0100 = Endpoint value: 4
    Device: 7
    URB bus id: 1
    Device setup request: not relevant ('-')
    Data: present (0)
    URB sec: 1309479044
    URB usec: 923337
    URB status: Operation now in progress (-EINPROGRESS) (-115)
    URB length [bytes]: 84
    Data length [bytes]: 84
    [Response in: 14382]
    [bInterfaceClass: VENDOR_SPECIFIC (0xff)]
Apple USBMUX
    Tag: 0
    Message Type: TCP Packet (6)
    Protocol Version: 0
    Packet Length: 84
Transmission Control Protocol, Src Port: ni-ftp (47), Dst Port: afpovertcp
(548), Seq: 1, Ack: 1, Len: 56
    Source port: ni-ftp (47)
    Destination port: afpovertcp (548)
    [Stream index: 789]
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 57    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x10 (ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgement: Set
        .... .... 0... = Push: Not set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
    Window size value: 512
    [Calculated window size: 512]
    [Window size scaling factor: -1 (unknown)]
    Checksum: 0x0000 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    [PDU Size: 22]
    [PDU Size: 34]
Data Stream Interface
    Flags: Request (0x00)
    Command: OpenSession (4)
    Request ID: 1
    Data offset: 0
    Length: 6 bytes
    Reserved: 0x00000000
    Open Session
        Option: Attention quantum (1)
        Length: 4
        Quantum: 1024
Data Stream Interface
    Flags: Request (0x00)
    Command: Command (2)
    Request ID: 2
    Data offset: 0
    Length: 18 bytes
    Reserved: 0x00000000
Apple Filing Protocol
    Command: FPLogin (18)
    AFP Version: AFP3.1
    UAM: DHX2
    User: root

0000  00 88 11 f6 00 00 00 00 53 03 04 07 01 00 2d 00   ........S.....-.
0010  84 10 0d 4e 00 00 00 00 c9 16 0e 00 8d ff ff ff   ...N............
0020  54 00 00 00 54 00 00 00 00 00 00 00 00 00 00 00   T...T...........
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
0040  00 00 00 06 00 00 00 54 00 2f 02 24 00 00 00 01   .......T./.$....
0050  00 00 00 01 50 10 02 00 00 00 00 00 00 04 00 01   ....P...........
0060  00 00 00 00 00 00 00 06 00 00 00 00 01 04 00 00   ................
0070  04 00 00 02 00 02 00 00 00 00 00 00 00 12 00 00   ................
0080  00 00 12 06 41 46 50 33 2e 31 04 44 48 58 32 04   ....AFP3.1.DHX2.
0090  72 6f 6f 74                                       root

We've only got 8 "real"/"from the wire" bytes (and 1 extra byte demarcating the
TCP header/part of the payload length) to play with, before the TCP header
immediately begins:

0000   00 00 00 06 00 00 00 54 00 2f 02 24 00 00 00 01  .......T./.$....
0010   00 00 00 01 50 10 02 00 00 00 00 00 00 04 00 01  ....P...........
0020   00 00 00 00 00 00 00 06 00 00 00 00 01 04 00 00  ................
0030   04 00 00 02 00 02 00 00 00 00 00 00 00 12 00 00  ................
0040   00 00 12 06 41 46 50 33 2e 31 04 44 48 58 32 04  ....AFP3.1.DHX2.
0050   72 6f 6f 74                                      root

I'm probably interpreting things incorrectly - but if you were to treat those 8
(9?) bytes as four 4-byte clusters, you'd either fall into the TCP header and
print garbage, or receive incorrect results for certain fields...

Of course, endianness issues don't help matters, either.

Any thoughts?

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.