Ethereal-users: Re: [Ethereal-users] Malformed packets
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: PoWah Wong <wong_powah@xxxxxxxx>
Date: Thu, 1 Dec 2005 19:27:04 -0500 (EST)
All my 802.11 captured packets have "Malformed packets" at the end.
After reading Jaap Keuter's reply, I still don't know how to fix this problem?
I captured the packets by
#tethereal -i ath0 -c 10000 -w /tmp/sniff.capture
#tethereal -V -r /tmp/sniff.capture > /tmp/sniff.capture.txt
# tethereal -v
tethereal 0.10.10
Compiled with GLib 2.4.8, with libpcap 0.8.3, with libz 1.2.1.2,
without libpcre, with Net-SNMP 5.1.1, without ADNS.
NOTE: this build doesn't support the "matches" operator for Ethereal filter
syntax.
Running with libpcap version 0.8.3 on Linux 2.6.10-1.771_FC2.
Some frames are as follows:
Frame 314 (184 bytes on wire, 184 bytes captured)
Arrival Time: Dec 1, 2005 16:18:10.260824000
Time delta from previous packet: 0.003247000 seconds
Time since reference or first frame: 3.570238000 seconds
Frame Number: 314
Packet Length: 184 bytes
Capture Length: 184 bytes
Protocols in frame: prism:wlan
Prism Monitoring Header
Message Code: 68
Message Length: 144
Device: ath0
Host Time: 0x7c16cd1b (DID 0x10044, Status 0x0, Length 0x4)
MAC Time: 0x150f25ea (DID 0x20044, Status 0x0, Length 0x4)
Channel: 0x38 (DID 0x30044, Status 0x0, Length 0x4)
RSSI: 0x0 (DID 0x40044, Status 0x0, Length 0x4)
SQ: 0x0 (DID 0x0, Status 0x0, Length 0x0)
Signal: 0x3a (DID 0x60044, Status 0x0, Length 0x4)
Noise: 0x0 (DID 0x0, Status 0x0, Length 0x0)
Data Rate: 6.0 Mb/s
IsTX: 0x0 (DID 0x90044, Status 0x0, Length 0x4)
Frame Length: 0x28 (DID 0xa0044, Status 0x0, Length 0x4)
IEEE 802.11
Type/Subtype: Probe Request (4)
Frame Control: 0x0040 (Normal)
Version: 0
Type: Management frame (0)
Subtype: 4
Flags: 0x0
DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x00)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = WEP flag: WEP is disabled
0... .... = Order flag: Not strictly ordered
Duration: 0
Destination address: ff:ff:ff:ff:ff:ff (Broadcast)
Source address: 00:f0:00:06:ba:c0 (00:f0:00:06:ba:c0)
BSS Id: ff:ff:ff:ff:ff:ff (Broadcast)
Fragment number: 0
Sequence number: 0
IEEE 802.11 wireless LAN management frame
Tagged parameters (16 bytes)
Tag Number: 0 (SSID parameter set)
Tag length: 0
Tag interpretation:
Tag Number: 1 (Supported Rates)
Tag length: 8
Tag interpretation: Supported rates: 6.0(B) 9.0 12.0(B) 18.0 24.0(B) 36.0 48.0 54.0 [Mbit/sec]
Tag Number: 73 (Reserved tag number)
Tag length: 21
[Malformed Packet: IEEE 802.11]
------------------------------------------------------------------------------------------------------------------
After reading Jaap Keuter's reply, I still don't know how to fix this problem?
I captured the packets by
#tethereal -i ath0 -c 10000 -w /tmp/sniff.capture
#tethereal -V -r /tmp/sniff.capture > /tmp/sniff.capture.txt
# tethereal -v
tethereal 0.10.10
Compiled with GLib 2.4.8, with libpcap 0.8.3, with libz 1.2.1.2,
without libpcre, with Net-SNMP 5.1.1, without ADNS.
NOTE: this build doesn't support the "matches" operator for Ethereal filter
syntax.
Running with libpcap version 0.8.3 on Linux 2.6.10-1.771_FC2.
Some frames are as follows:
Frame 314 (184 bytes on wire, 184 bytes captured)
Arrival Time: Dec 1, 2005 16:18:10.260824000
Time delta from previous packet: 0.003247000 seconds
Time since reference or first frame: 3.570238000 seconds
Frame Number: 314
Packet Length: 184 bytes
Capture Length: 184 bytes
Protocols in frame: prism:wlan
Prism Monitoring Header
Message Code: 68
Message Length: 144
Device: ath0
Host Time: 0x7c16cd1b (DID 0x10044, Status 0x0, Length 0x4)
MAC Time: 0x150f25ea (DID 0x20044, Status 0x0, Length 0x4)
Channel: 0x38 (DID 0x30044, Status 0x0, Length 0x4)
RSSI: 0x0 (DID 0x40044, Status 0x0, Length 0x4)
SQ: 0x0 (DID 0x0, Status 0x0, Length 0x0)
Signal: 0x3a (DID 0x60044, Status 0x0, Length 0x4)
Noise: 0x0 (DID 0x0, Status 0x0, Length 0x0)
Data Rate: 6.0 Mb/s
IsTX: 0x0 (DID 0x90044, Status 0x0, Length 0x4)
Frame Length: 0x28 (DID 0xa0044, Status 0x0, Length 0x4)
IEEE 802.11
Type/Subtype: Probe Request (4)
Frame Control: 0x0040 (Normal)
Version: 0
Type: Management frame (0)
Subtype: 4
Flags: 0x0
DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x00)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = WEP flag: WEP is disabled
0... .... = Order flag: Not strictly ordered
Duration: 0
Destination address: ff:ff:ff:ff:ff:ff (Broadcast)
Source address: 00:f0:00:06:ba:c0 (00:f0:00:06:ba:c0)
BSS Id: ff:ff:ff:ff:ff:ff (Broadcast)
Fragment number: 0
Sequence number: 0
IEEE 802.11 wireless LAN management frame
Tagged parameters (16 bytes)
Tag Number: 0 (SSID parameter set)
Tag length: 0
Tag interpretation:
Tag Number: 1 (Supported Rates)
Tag length: 8
Tag interpretation: Supported rates: 6.0(B) 9.0 12.0(B) 18.0 24.0(B) 36.0 48.0 54.0 [Mbit/sec]
Tag Number: 73 (Reserved tag number)
Tag length: 21
[Malformed Packet: IEEE 802.11]
------------------------------------------------------------------------------------------------------------------
- Subject: Re: [Ethereal-users] Malformed packets
- From: Jaap Keuter <jaap.keuter@xxxxxxxxx>
- Date: Fri, 25 Nov 2005 16:16:11 +0100 (CET)
On Fri, 25 Nov 2005, Asensio Pradas Parra wrote:
> Dear Sirs:
> What does "Malformed packet" mean?.
>
> May you help me?....Thanks
>
Hi,
Malformed packet means that the dissector can't work out the contents of
the packet any further. This can have various reasons:
* The chosen dissector is wrong for this packet
* The packet is longer that a single frame and not reassembled
* There is a bug in the dissector
* (dare I say it?) The packet is wrong
Any of these is possible. You'll have to look into the specific situation
to determine what it is. You could disable the dissector by disabling the
protocol on the Analyzer menu and check how Ethereal displays the packet
then. You could (if it's TCP) enable reassembly for TCP and the specific
dissector (if possible) in the Edit|Preferences menu. You could check the
packet contents yourself by reading the packet bytes and comparing it to
the protocol specification. This could reveil a dissector bug. Or you
could find out that the packet is indeed wrong.
Have fun,
Jaap
Find your next car at Yahoo! Canada Autos
- Follow-Ups:
- Re: [Ethereal-users] Malformed packets
- From: Guy Harris
- Re: [Ethereal-users] Malformed packets
- Prev by Date: [Ethereal-users] Problem with shared libraries.
- Next by Date: [Ethereal-users] Re: UDP-Lite in Ethereal?
- Previous by thread: Re: [Ethereal-users] Problem with shared libraries.
- Next by thread: Re: [Ethereal-users] Malformed packets
- Index(es):