Hi EB,
Somehow communication back and forth to you is not working 100% ok. We
don't seem to understand what exactly you want from us and you don't
seem to understand what we want from you to be able to help you.
> It would mean a lot to me if someone could look over the packet information
> I posted some days ago at the request of Joerg Mayer, Andrew Hood, Sake
> Blok, and Guy Harris.
We asked you to provide us with capture files in raw data format so that
we are able to load the data into wireshark. Up till now you have provided
us with screendumps and text output. Analysing these images or text is
much harder than analysing the actual packets which a raw data file
would provide. Guy has helped you in detail on how to save the data
in raw format:
"The best thing to do, as noted by Sake, is to save the packets as raw
data to a file. Use File -> Save As; that would let you select which
packets to save (for example, clicking the "Displayed" button and
choosing "Selected packet only" would save the currently-selected packet)."
If you want us to be able to help you, it works best if you are able
to provide the information in a form that we can work with more
easily.
> As a newb, I would appreciate your input on what you believe is happening in
> the captures I posted. Thank you.
As far as I can tell, Guy made a big effort in looking at the screen
captures you have provided and gave you his insight in what the
LLC packets look like to him:
"The packet you give as an example in Capture 2 appears to be, well,
mangled. There appears to be an extra byte with the value hex 02
between the 802.3 header and the 802.2 LLC header. I suspect that
packet is an IP packet (with a SNAP header), and would dissect as such
without that extra byte in there. Unfortunately, Wireshark has no way
of knowing that extra byte is there.
The packet in Capture 1 appears to be similarly mangled, but it doesn't
appear to be an IP packet. Unfortunately, I can't find anything about
an 802.2 DSAP or SSAP value of 52/53, so I don't know what type of
packet it is.
I infer from the references to WinDump that this is on Windows. Windows
drivers for 802.11 adapters don't do a very good job of supplying
packets to applications doing packet capture; there's not much of
anything that WinPcap or Wireshark can do about that."
Is that not the information you are looking for? If not, could you
please ask a specific question? Just asking us to analyse the
capture files you have made is not exactly the purpose of this
list as we are all quite busy with our day-to-day work. The list
is used to ask about specific bits that you might need help
with. Questions just like the one that started this discussion.
Please note that this list is just a community of people helping
each other in their spare time. It is not a commercial support
forum where one might expect answers to be given all the time and
in a timely manner.
As for the "[TCP Dup ACK xxx]" and "[TCP Out-Of-Order]" mesages that
you are seeing in "Capture_misc", they are caused (for the greater part)
by having the same packets in the capture twice. Once between
AppleCom_a8:2e:92 (00:11:24:a8:2e:92) and ComartSy_fe:0f:1f (00:0d:52:fe:0f:1f)
and once between
ComartSy_fe:0f:1f (00:0d:52:fe:0f:1f) and D-Link_14:f0:88 (00:13:46:14:f0:88)
Wireshark does it's analysis of the TCP sequence numbers at the TCP
layer. It assumes that all packets between two IP-address/port combinations
belong to the same TCP stream. It does not check whether the Ethernet
addresses are the same. This is useful because in many situations
the Ethernet addresses are different for the different directions in
the TCP stream.
I hope this helps,
Cheers,
Sake
