IEEE80211 Prism header dissecting problem ..

Discussion:

H.Jin Ko

2014-03-20 07:58:12 UTC

Hello List.

I dumped wireless packet using tcpdump (DLT_PRISM_HEADER) on linux
(mips) and opened it in wireshark (v1.10.6) on win7.
Wireshark say its encapsulation type is "IEEE 802.11 plus Prism II
monitor mode radio header (21)" but didn't dissect prism header.
Raw packet has 144 bytes of PRISM header and WLAN's frame control is
started at 0x90.
But wireshark dissected frame control at 0x00 without Prism header.

Prism(Prism capture header) is already checked in Enabled Protocols.
I want to see correct dissected Prism header.
Is there something that I missing?

Thanks in advance.

- H.Jin

$ file out.cap
out.cap: tcpdump capture file (big-endian) - version 2.4 (802.11 with
Prism header, capture length 65535)

<snip>
Frame 24: 394 bytes on wire (3152 bits), 394 bytes captured (3152 bits)
Encapsulation type: IEEE 802.11 plus Prism II monitor mode radio header (21)
Arrival Time: Jan 1, 2014 09:03:51.007932000 대한민국 표준시
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1388534631.007932000 seconds
[Time delta from previous captured frame: 0.076445000 seconds]
[Time delta from previous displayed frame: 0.076445000 seconds]
[Time since reference or first frame: 1.100408000 seconds]
Frame Number: 24
Frame Length: 394 bytes (3152 bits)
Capture Length: 394 bytes (3152 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: prism:wlan]
IEEE 802.11 Association Request, Flags: ........
Type/Subtype: Association Request (0x00)
Frame Control Field: 0x0000
.... ..00 = Version: 0
.... 00.. = Type: Management frame (0)
0000 .... = Subtype: 0
Flags: 0x00
.... ..00 = 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.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
.100 0100 0000 0000 = Duration: 17408 microseconds
Receiver address: 00:00:00:90:61:74 (00:00:00:90:61:74)
Destination address: 00:00:00:90:61:74 (00:00:00:90:61:74)
Transmitter address: 68:30:00:00:00:00 (68:30:00:00:00:00)
Source address: 68:30:00:00:00:00 (68:30:00:00:00:00)
BSS Id: 00:00:00:00:00:00 (00:00:00:00:00:00)
Fragment number: 0
Sequence number: 0

.......

0000 00 00 00 44 00 00 00 90 61 74 68 30 00 00 00 00 ...D....ath0....
0010 00 00 00 00 00 00 00 00 00 01 00 44 00 00 00 04 ...........D....
0020 ff ff bc 9f 00 02 00 44 00 00 00 04 0a ed 92 a3 .......D........
0030 00 03 00 44 00 00 00 04 00 00 00 99 00 04 00 44 ...D...........D
0040 00 00 00 04 00 00 00 1f 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 06 00 44 00 00 00 04 00 00 00 1f .......D........
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 44 ...............D
0070 00 00 00 04 00 00 00 0b 00 09 00 44 00 00 00 04 ...........D....
0080 00 00 00 00 00 0a 00 44 00 00 00 04 00 00 00 fa .......D........
0090 80 00 00 00 ff ff ff ff ff ff 20 e5 2a 06 d2 73 .......... .*..s
00a0 20 e5 2a 06 d2 73 f0 52 42 90 1a 69 8b 01 00 00 .*..s.RB..i....
00b0 64 00 11 00 00 0d 4e 45 54 47 45 41 52 5f 52 36 d.....NETGEAR_R6
00c0 33 30 30 01 08 8c 12 98 24 b0 48 60 6c 05 04 01 300.....$.H`l...
00d0 02 00 00 30 14 01 00 00 0f ac 04 01 00 00 0f ac ...0............
00e0 04 01 00 00 0f ac 02 0c 00 2d 1a ef 09 1b ff ff .........-......
00f0 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100 00 00 00 00 00 3d 16 99 0f 04 00 00 00 00 00 00 .....=..........
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 bf 0c b7 ................
0120 00 00 00 ea ff 00 00 ea ff 00 00 c0 05 00 97 00 ................
0130 00 00 dd 31 00 50 f2 04 10 4a 00 01 10 10 44 00 ...1.P...J....D.
0140 01 02 10 47 00 10 56 62 9f 41 f4 59 6f 3d b2 4e ...G..Vb.A.Yo=.N
0150 40 d4 9a 47 e7 6a 10 3c 00 01 03 10 49 00 06 00 @..G.j.<....I...
0160 37 2a 00 01 20 dd 09 00 10 18 02 01 00 1c 00 00 7*.. ...........
0170 dd 18 00 50 f2 02 01 01 88 00 03 a4 00 00 27 a4 ...P..........'.
0180 00 00 42 43 bc 00 62 32 66 00 ..BC..b2f.
</snip>
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-***@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-***@wi

Hadriel Kaplan

2014-03-20 15:37:25 UTC

Permalink

I think the Prism dissector is being called, but then it hands it to normal 802.11 instead. I don't know anything about Prism packets, but the wireshark code appears to expect the Prism message codes (either 0x00000044 for type 1, or 0x00000041 for type 2) to be in little-endian order on-the-wire, whereas your packet has it in network-order (ie, big-endian) on-the-wire.

Since the wireshark code doesn't think it's a Prism message, the Prism dissector just calls the normal 802.11 dissector instead. At least that's what a quick look at the code looks like is happening.

If the wireshark code is in error, and Prism message codes are in network-order on-the-wire, please submit a bug.

-hadriel

On Thursday, March 20, 2014 10:14 AM, H.Jin Ko <ymir.kr-***@public.gmane.org> wrote:

Hello List.

I dumped wireless packet using tcpdump (DLT_PRISM_HEADER) on linux
(mips) and opened it in wireshark (v1.10.6) on win7.
Wireshark say its encapsulation type is "IEEE 802.11 plus Prism II
monitor mode radio header (21)" but didn't dissect prism header.
Raw packet has 144 bytes of PRISM header and WLAN's frame control is
started at 0x90.
But wireshark dissected frame control at 0x00 without Prism header.

Prism(Prism capture header) is already checked in Enabled Protocols.
I want to see correct dissected Prism header.
Is there something that I missing?

Thanks in advance.

- H.Jin

$ file out.cap
out.cap: tcpdump capture file (big-endian) - version 2.4 (802.11 with
Prism header, capture length 65535)

<snip>
Frame 24: 394 bytes on wire (3152 bits), 394 bytes captured (3152 bits)
Â Â Encapsulation type: IEEE 802.11 plus Prism II monitor mode radio header (21)
Â Â Arrival Time: JanÂ 1, 2014 09:03:51.007932000 ëíë¯Œêµ íì€ì
Â Â [Time shift for this packet: 0.000000000 seconds]
Â Â Epoch Time: 1388534631.007932000 seconds
Â Â [Time delta from previous captured frame: 0.076445000 seconds]
Â Â [Time delta from previous displayed frame: 0.076445000 seconds]
Â Â [Time since reference or first frame: 1.100408000 seconds]
Â Â Frame Number: 24
Â Â Frame Length: 394 bytes (3152 bits)
Â Â Capture Length: 394 bytes (3152 bits)
Â Â [Frame is marked: False]
Â Â [Frame is ignored: False]
Â Â [Protocols in frame: prism:wlan]
IEEE 802.11 Association Request, Flags: ........
Â Â Type/Subtype: Association Request (0x00)
Â Â Frame Control Field: 0x0000
Â Â Â Â .... ..00 = Version: 0
Â Â Â Â .... 00.. = Type: Management frame (0)
Â Â Â Â 0000 .... = Subtype: 0
Â Â Â Â Flags: 0x00
Â Â Â Â Â Â .... ..00 = 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.. .... = Protected flag: Data is not protected
Â Â Â Â Â Â 0... .... = Order flag: Not strictly ordered
Â Â .100 0100 0000 0000 = Duration: 17408 microseconds
Â Â Receiver address: 00:00:00:90:61:74 (00:00:00:90:61:74)
Â Â Destination address: 00:00:00:90:61:74 (00:00:00:90:61:74)
Â Â Transmitter address: 68:30:00:00:00:00 (68:30:00:00:00:00)
Â Â Source address: 68:30:00:00:00:00 (68:30:00:00:00:00)
Â Â BSS Id: 00:00:00:00:00:00 (00:00:00:00:00:00)
Â Â Fragment number: 0
Â Â Sequence number: 0

.......

0000Â 00 00 00 44 00 00 00 90 61 74 68 30 00 00 00 00Â ...D....ath0....
0010Â 00 00 00 00 00 00 00 00 00 01 00 44 00 00 00 04Â ...........D....
0020Â ff ff bc 9f 00 02 00 44 00 00 00 04 0a ed 92 a3Â .......D........
0030Â 00 03 00 44 00 00 00 04 00 00 00 99 00 04 00 44Â ...D...........D
0040Â 00 00 00 04 00 00 00 1f 00 00 00 00 00 00 00 00Â ................
0050Â 00 00 00 00 00 06 00 44 00 00 00 04 00 00 00 1fÂ .......D........
0060Â 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 44Â ...............D
0070Â 00 00 00 04 00 00 00 0b 00 09 00 44 00 00 00 04Â ...........D....
0080Â 00 00 00 00 00 0a 00 44 00 00 00 04 00 00 00 faÂ .......D........
0090Â 80 00 00 00 ff ff ff ff ff ff 20 e5 2a 06 d2 73Â .......... .*..s
00a0Â 20 e5 2a 06 d2 73 f0 52 42 90 1a 69 8b 01 00 00Â Â .*..s.RB..i....
00b0Â 64 00 11 00 00 0d 4e 45 54 47 45 41 52 5f 52 36Â d.....NETGEAR_R6
00c0Â 33 30 30 01 08 8c 12 98 24 b0 48 60 6c 05 04 01Â 300.....$.H`l...
00d0Â 02 00 00 30 14 01 00 00 0f ac 04 01 00 00 0f acÂ ...0............
00e0Â 04 01 00 00 0f ac 02 0c 00 2d 1a ef 09 1b ff ffÂ .........-......
00f0Â ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00Â ................
0100Â 00 00 00 00 00 3d 16 99 0f 04 00 00 00 00 00 00Â .....=..........
0110Â 00 00 00 00 00 00 00 00 00 00 00 00 00 bf 0c b7Â ................
0120Â 00 00 00 ea ff 00 00 ea ff 00 00 c0 05 00 97 00Â ................
0130Â 00 00 dd 31 00 50 f2 04 10 4a 00 01 10 10 44 00Â ...1.P...J....D.
0140Â 01 02 10 47 00 10 56 62 9f 41 f4 59 6f 3d b2 4eÂ ...G..Vb.A.Yo=.N
0150Â 40 d4 9a 47 e7 6a 10 3c 00 01 03 10 49 00 06 00Â @..G.j.<....I...
0160Â 37 2a 00 01 20 dd 09 00 10 18 02 01 00 1c 00 00Â 7*.. ...........
0170Â dd 18 00 50 f2 02 01 01 88 00 03 a4 00 00 27 a4Â ...P..........'.
0180Â 00 00 42 43 bc 00 62 32 66 00Â Â Â Â Â Â Â Â Â Â ..BC..b2f.
</snip>
___________________________________________________________________________
Sent via:Â Â Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives:Â Â http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
Â Â Â Â Â Â mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

Guy Harris

2014-03-20 17:50:04 UTC

Permalink

Post by Hadriel Kaplan
I think the Prism dissector is being called, but then it hands it to normal 802.11 instead. I don't know anything about Prism packets, but the wireshark code appears to expect the Prism message codes (either 0x00000044 for type 1, or 0x00000041 for type 2) to be in little-endian order on-the-wire, whereas your packet has it in network-order (ie, big-endian) on-the-wire.

Actually, they're not "on-the-wire" at all - the Prism header is radio-level-information metadata generated by and written to the packet buffer by the driver.

So the byte order might depend on the driver and the CPU type; he said "mips" - there are both big-endian and little-endian MIPS systems, so perhaps

1) this was a big-endian MIPS system

and

2) the drivers put the Prism header in host byte order

in which case we need to have the Prism code support both byte orders.

(Yet another reason not to like Prism headers; radiotap:

http://www.radiotap.org

specifies little-endian byte order, so a non-buggy driver would write out the radiotap header in little-endian order *even when running on a big-endian machine*.)
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

Guy Harris

2014-03-21 01:58:28 UTC

Permalink

Post by Guy Harris
in which case we need to have the Prism code support both byte orders.

I've checked into the trunk a change that should handle that.

If your Windows system is 32-bit, please wait until a build with a higher number than 2057 shows up in

http://www.wireshark.org/download/automated/win32/

The installer will have a name like Wireshark-win32-1.11.3-2058-7b6f0475.exe, with the number after "1.11.3" being 2058 or greater and the item just before ".exe" being some random collection of 8 hex digits. You may have to wait for a while, however, as that buildbot is currently offline and not generating new builds.

If your Windows system is 64-bit, please wait until a build with a higher number than 2057 shows up in

http://www.wireshark.org/download/automated/win64/

The installer will have a name like Wireshark-win64-1.11.3-2058-7b6f0475.exe, with the number after "1.11.3" being 2058 or greater and the item just before ".exe" being some random collection of 8 hex digits.

These are development builds, so they may have a random collection of interesting new features and interesting new bugs, as well as interesting user interface changes. For Windows, they might offer a choice between versions using GTK+ (the old UI toolkit, which is the one current official releases use) and Qt (the new UI toolkit, which we want to use for 1.12). The Qt version might be nicer in some ways, but a number of UI features have not yet been implemented with Qt, so they will only be available in the GTK+ version.

Once you get the new version installed, please try reading the capture file with the new version, and let us know whether it works or not.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

H.Jin Ko

2014-03-21 02:33:09 UTC

Permalink

Thanks for update.
I installed Wireshark-win64-1.11.3-2058-7b6f0475.exe and saw correct
prism header and wlan frame.

Attached dissected prism header.

- H.Jin

<snip>
No. Time Source S.Port Destination
D.Port Protocol Length Info
2 0.007733 20:e5:2a:06:d2:73 ff:ff:ff:ff:ff:ff
802.11 394 Beacon frame, SN=1472, FN=0, Flags=........,
BI=100, SSID=NETGEAR_R6300
Frame 2: 394 bytes on wire (3152 bits), 394 bytes captured (3152 bits)
Encapsulation type: IEEE 802.11 plus Prism II monitor mode radio header (21)
Arrival Time: Jan 1, 2014 09:01:40.887805000 대한민국 표준시
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1388534500.887805000 seconds
[Time delta from previous captured frame: 0.007733000 seconds]
[Time delta from previous displayed frame: 0.007733000 seconds]
[Time since reference or first frame: 0.007733000 seconds]
Frame Number: 2
Frame Length: 394 bytes (3152 bits)
Capture Length: 394 bytes (3152 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: prism:wlan]
[Number of per-protocol-data: 3]
[IEEE 802.11 wireless LAN, key 1]
[IEEE 802.11 wireless LAN, key 1]
[IEEE 802.11 wireless LAN, key 1]
Prism capture header
Message Code: 0x00000044
Message Length: 144
Device Name: ath0
DID Host Time -49779
DID: Host Time (0x00010044)
Status: Supplied (0)
Length: 4
Host Time: 4294917517
DID Mac Time 69827346
DID: Mac Time (0x00020044)
Status: Supplied (0)
Length: 4
MAC timestamp (lower 32 bits): 69827346
DID Channel 153
DID: Channel (0x00030044)
Status: Supplied (0)
Length: 4
Channel: 153
DID RSSI 0x1e
DID: RSSI (0x00040044)
Status: Supplied (0)
Length: 4
RSSI: 30
DID Unknown 0
DID: Unknown (0x00000000)
Status: Supplied (0)
Length: 0
Unknown DID Field: 0x00000000 (0)
DID Signal 0x1e
DID: Signal (0x00060044)
Status: Supplied (0)
Length: 4
Signal: 30
DID Unknown 0
DID: Unknown (0x00000000)
Status: Supplied (0)
Length: 0
Unknown DID Field: 0x00000000 (0)
DID Rate 5.5 Mb/s
DID: Rate (0x00080044)
Status: Supplied (0)
Length: 4
Data rate (Mb/s): 5.5
DID Is Tx 0x0
DID: Is Tx (0x00090044)
Status: Supplied (0)
Length: 4
IsTX: Rx Packet (0x00000000)
DID Frame Length 250
DID: Frame Length (0x000a0044)
Status: Supplied (0)
Length: 4
Frame Length: 250
IEEE 802.11 Beacon frame, Flags: ........
Type/Subtype: Beacon frame (0x0008)
Frame Control Field: 0x8000
.... ..00 = Version: 0
.... 00.. = Type: Management frame (0)
1000 .... = Subtype: 8
Flags: 0x00
.... ..00 = 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.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
.000 0000 0000 0000 = Duration: 0 microseconds
.........

0000 00 00 00 44 00 00 00 90 61 74 68 30 00 00 00 00 ...D....ath0....
0010 00 00 00 00 00 00 00 00 00 01 00 44 00 00 00 04 ...........D....
0020 ff ff 3d 8d 00 02 00 44 00 00 00 04 04 29 7b 12 ..=....D.....){.
0030 00 03 00 44 00 00 00 04 00 00 00 99 00 04 00 44 ...D...........D
0040 00 00 00 04 00 00 00 1e 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 06 00 44 00 00 00 04 00 00 00 1e .......D........
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 44 ...............D
0070 00 00 00 04 00 00 00 0b 00 09 00 44 00 00 00 04 ...........D....
0080 00 00 00 00 00 0a 00 44 00 00 00 04 00 00 00 fa .......D........
0090 80 00 00 00 ff ff ff ff ff ff 20 e5 2a 06 d2 73 .......... .*..s
00a0 20 e5 2a 06 d2 73 00 5c 3a 10 54 db c8 01 00 00 .*..s.\:.T.....
00b0 64 00 11 00 00 0d 4e 45 54 47 45 41 52 5f 52 36 d.....NETGEAR_R6
00c0 33 30 30 01 08 8c 12 98 24 b0 48 60 6c 05 04 01 300.....$.H`l...
00d0 02 00 00 30 14 01 00 00 0f ac 04 01 00 00 0f ac ...0............
00e0 04 01 00 00 0f ac 02 0c 00 2d 1a ef 09 1b ff ff .........-......
00f0 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100 00 00 00 00 00 3d 16 99 0f 04 00 00 00 00 00 00 .....=..........
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 bf 0c b7 ................
0120 00 00 00 ea ff 00 00 ea ff 00 00 c0 05 00 97 00 ................
0130 00 00 dd 31 00 50 f2 04 10 4a 00 01 10 10 44 00 ...1.P...J....D.
0140 01 02 10 47 00 10 56 62 9f 41 f4 59 6f 3d b2 4e ...G..Vb.A.Yo=.N
0150 40 d4 9a 47 e7 6a 10 3c 00 01 03 10 49 00 06 00 @..G.j.<....I...
0160 37 2a 00 01 20 dd 09 00 10 18 02 01 00 1c 00 00 7*.. ...........
0170 dd 18 00 50 f2 02 01 01 88 00 03 a4 00 00 27 a4 ...P..........'.
0180 00 00 42 43 bc 00 62 32 66 00 ..BC..b2f.
</snip>

Post by Guy Harris

Post by Guy Harris
in which case we need to have the Prism code support both byte orders.

I've checked into the trunk a change that should handle that.
If your Windows system is 32-bit, please wait until a build with a higher number than 2057 shows up in
http://www.wireshark.org/download/automated/win32/
The installer will have a name like Wireshark-win32-1.11.3-2058-7b6f0475.exe, with the number after "1.11.3" being 2058 or greater and the item just before ".exe" being some random collection of 8 hex digits. You may have to wait for a while, however, as that buildbot is currently offline and not generating new builds.
If your Windows system is 64-bit, please wait until a build with a higher number than 2057 shows up in
http://www.wireshark.org/download/automated/win64/
The installer will have a name like Wireshark-win64-1.11.3-2058-7b6f0475.exe, with the number after "1.11.3" being 2058 or greater and the item just before ".exe" being some random collection of 8 hex digits.
These are development builds, so they may have a random collection of interesting new features and interesting new bugs, as well as interesting user interface changes. For Windows, they might offer a choice between versions using GTK+ (the old UI toolkit, which is the one current official releases use) and Qt (the new UI toolkit, which we want to use for 1.12). The Qt version might be nicer in some ways, but a number of UI features have not yet been implemented with Qt, so they will only be available in the GTK+ version.
Once you get the new version installed, please try reading the capture file with the new version, and let us know whether it works or not.

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-***@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@

Guy Harris

2014-03-21 04:36:14 UTC

Permalink

Post by H.Jin Ko
Thanks for update.
I installed Wireshark-win64-1.11.3-2058-7b6f0475.exe and saw correct
prism header

I've backported the changes to the 1.10 and 1.8 branches, so they should be in the next 1.10 release (for people with OSes that don't package Wireshark, or that do and, in the current version, supply 1.10) and 1.8 release (for people working at places where they have to get management approval for third-party software and they haven't gotten around to approving Wireshark 1.10 yet, and people running OSes where the version they're running supplies 1.8, but they're at least bothering to supply new dot-dot 1.8 releases).

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

H.Jin Ko

2014-03-21 02:19:21 UTC

Permalink

As you say, wlan driver wrote prism header with host byte order and it
runs on mips(big-endian) machine.
However prism dissector treated prism is little-endian (such like radiotap).
I need to fix driver or use custom dissector for this case.

Thanks for replay, Hadriel and Guy.
I really appreciate it.

- H.Jin

Post by Guy Harris

Actually, they're not "on-the-wire" at all - the Prism header is radio-level-information metadata generated by and written to the packet buffer by the driver.
So the byte order might depend on the driver and the CPU type; he said "mips" - there are both big-endian and little-endian MIPS systems, so perhaps
1) this was a big-endian MIPS system
and
2) the drivers put the Prism header in host byte order
in which case we need to have the Prism code support both byte orders.
http://www.radiotap.org
specifies little-endian byte order, so a non-buggy driver would write out the radiotap header in little-endian order *even when running on a big-endian machine*.)
___________________________________________________________________________
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users

___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe

Guy Harris

2014-03-21 02:31:11 UTC

Permalink

Post by H.Jin Ko
As you say, wlan driver wrote prism header with host byte order and it
runs on mips(big-endian) machine.
However prism dissector treated prism is little-endian (such like radiotap).
I need to fix driver or use custom dissector for this case.

Or, if your Windows machine is 64-bit, try

http://www.wireshark.org/download/automated/win64/Wireshark-win64-1.11.3-2058-g7b6f047.exe

As per my earlier message, this is a development build, so it may have a random collection of interesting new features and interesting new bugs, as well as interesting user interface changes. For Windows, the installer might offer a choice between a version using GTK+ (the old UI toolkit, which is the one current official releases use) and a version using Qt (the new UI toolkit, which we want to use for 1.12). The Qt version might be nicer in some ways, but a number of UI features have not yet been implemented with Qt, so they will only be available in the GTK+ version.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users-IZ8446WsY0/***@public.gmane.org>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request-IZ8446WsY0/***@public.gmane.org?subject=unsubscribe