On Sat, Apr 13, 2002 at 11:45:13AM -0700, Guy Harris wrote:
> "Follow TCP stream" doesn't use the TCP reassembly code, if that's what
> you mean by "is this needed for something like follow TCP stream".
>
> However, fragmented 802.11 frames could probably be reassembled by code
> similar to the IP fragment reassembly code in "packet-ip.c".
No, I just meant that the fragments would have to be reassembled to
get full TCP stream (i.e., the parts from other than first
fragments). I considered IP reassembly and it would seem to be
suitable also for 802.11 fragments. However, this was the part that I
do not know in Ethereal and someone else can probably do the changes
with much less effort.
> Do you have a capture with fragmented frames in it? If so, I might be
> able to look at adding fragmentation support (although I can't say
> *when* I'd be able to look at it).
I attached a dump (only data frames included) of a ping request that
is fragmented into three 802.11 frames (512 byte fragmentation
threshold) and a reply to that ping with all data in one frame.
On Sat, Apr 13, 2002 at 01:23:33PM -0700, Guy Harris wrote:
> However, I have a capture somebody sent where there are 802.11 frames
> that have a non-zero fragment number field, have the "More fragments"
> flag not set, and that appear to contain LLC frames with a SNAP header,
> an OUI of 0x0000f8 (which is some Cisco OUI), and a PID of 0x0800 (the
> Ethernet type for IP), and which appear to contain IP datagrams.
That does not sound like a proper 802.11 frame that would be really
sent in the air.. IEEE 802.11 specifies that fragment number is always
zero for the first fragment.
> In this particular case, the old code dissected the packet as a TCP ACK;
> the new code just reports it as a fragment.
>
> Could it be that this is a *reassembled* frame (reassembled by the
> 802.11 card or by the driver), and that, for whatever reason, the
> reassembly code supplied, for example, the fragment number of the *last*
> fragment, rather than 0, i.e. the fragment number of the *first*
> fragment?
Yes, that is apparently the case. I sniffed the packets from the air
using a separate sniffer host, but indeed, at least some cards give
non-zero fragment number on the reassembled frame that is passed to
the host. I confirmed this with Prism2 cards. This is a bit odd, since
Intersil documentation claims that the header data of a reassembled
frame would match with _the first_ fragment of the packet, not the
last..
Anyway, yes, it does happen and the fragment part of my patch was not
that good for this kind of cases. It should be changed to show
fragments only if a frame with the same sequence number has been
received from the same remote station just (well, okay, in relatively
short period of time) before the packet with non-zero fragment number.
If you take a look at assembling the fragments, that should also fix
this since the code would need to follow fragments more thoroughly.
--
Jouni Malinen PGP id EFC895FA
Attachment:
80211.fragment.dump
Description: Binary data