Re: [Wireshark-users] WLAN APC file and RSSI
Well, I went through the wiretap library code and saw that while it's aware of the dBm tag (it has it's own switch case), it just doesn't read it. Very funny indeed. I'll see about uploading a capture file. Date: Tue, 22 Jan 2008 17:26:44 -0800 From: [EMAIL PROTECTED] To: wireshark-users@wireshark.org Subject: Re: [Wireshark-users] WLAN APC file and RSSI It looks like the dBm tag isn't supported in Wireshark. Do you have a capture file you can send to the list or upload to the wiki? Avi Berkovich wrote: First, thanks for the link. As for the dBm value, it is present in the capture file (stored right after the percentage value in the packet header). Date: Tue, 22 Jan 2008 09:34:55 -0800 From: [EMAIL PROTECTED] To: wireshark-users@wireshark.org Subject: Re: [Wireshark-users] WLAN APC file and RSSI Avi Berkovich wrote: Hello, Wireshark doesn't display the RSSI value in dBm, only in percent. This happens with APC files captured with Airopeek. Is this a limitation? Are you sure the dBm values are present in the capture file? According to http://www.wildpackets.com/elements/whitepapers/Converting_Signal_Strength.pdf, WildPackets prefers to use percentage values. ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users Express yourself instantly with MSN Messenger! MSN Messenger http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/ ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] WLAN APC file and RSSI
Avi Berkovich wrote: Well, I went through the wiretap library code and saw that while it's aware of the dBm tag (it has it's own switch case), it just doesn't read it. The problem is that, for 802.11 radio information other than in libpcap files (where the radio information appears in the packet data as a header preceding the 802.11 header), it's presented to the 802.11 dissector as a pseudo-header. That pseudo-header was originally introduced for the file format used by AiroPeek before *Peek switched to the new file format (the old file format is handled by wiretap/etherpeek.c, because the code to handle it was first added to handle files from EtherPeek; the new file format is handled by wiretap/airopeek9.c, because the code to handle it was first added to handle files from a later version of AiroPeek (the URL mentioned in airopeek9.c says 2.0.1)). The older versions of AiroPeek had a fixed-length radio header, with a 1-byte data rate value in 500Kb/s units, a 1-byte channel value with a channel number and a 1-byte signal level value as a percentage. Those were the only values put into the pseudo-header; some other file formats also use it. The newer versions of EtherPeek, AiroPeek, and presumably OmniPeek, have a variable-length TLV-based pseudo-header, with tags for both signal and noise as a percentage and as a dBm value, as well as other tags (including one mysterious one seen in an EtherPeek capture). The current pseudo-header has no provision for most of those values, so most of them are ignored. There are a couple of ways to handle this: 1) have a new pseudo-header that can handle all the radio pseudo-information found in capture files - including in the Prism, AVS, and radiotap headers in libpcap - and funnel all radio information through that. 2) have some mechanism for supplying the raw new-style *Peek TLV header and have a dissector for it - and perhaps even use that for the old-style *Peek header, CommView header, etc.. 1) has the advantage that all the code that knows about particular forms of radio information is in Wiretap, and no dissectors or taps need know those details. 2) has the advantages that: 1) we could have an option in the 802.11 dissector to have it either just display the extracted radio information (just the values) or display a dissection of the raw header - the former is probably what most users want (they don't care about the gory details of how a radiotap, AVS, or Prism header encodes that information), and the latter would be useful if you're debugging a driver generating a radiotap or AVS header or are trying to reverse-engineer a radio header); 2) there's no loss of information from transforming the header to a pseudo-header, so if you save packets from a capture the radio information will be saved as is. You *would* need multiple radio-information dissectors, but those could, at least, build a pseudo-header to hand to taps, so the taps would be independent of the capture file you're reading. ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] WLAN APC file and RSSI
On Jan 23, 2008, at 1:15 PM, Guy Harris wrote: The newer versions of EtherPeek, AiroPeek, and presumably OmniPeek, have a variable-length TLV-based pseudo-header, with tags for both signal and noise as a percentage and as a dBm value, as well as other tags (including one mysterious one seen in an EtherPeek capture). The current pseudo-header has no provision for most of those values, so most of them are ignored. ...as was, in fact, noted in the comment in front of airopeekv9_process_header(): * XXX - we should supply the additional radio information; * the pseudo-header should probably be supplied in a fashion * similar to the new BSD radio header, so that the 802.11 * dissector can determine which, if any, information items * are present. 2) has the advantages that: 1) we could have an option in the 802.11 dissector to have it either just display the extracted radio information (just the values) or display a dissection of the raw header - the former is probably what most users want (they don't care about the gory details of how a radiotap, AVS, or Prism header encodes that information), and the latter would be useful if you're debugging a driver generating a radiotap or AVS header or are trying to reverse-engineer a radio header); 2) there's no loss of information from transforming the header to a pseudo-header, so if you save packets from a capture the radio information will be saved as is. ...although Wiretap has to parse the new-style *Peek TLV header *anyway*, as the packet length and slice length (captured length) are part of that header. It might be that going with a new-style pseudo-header is good enough - yes, if we use that for libpcap, it would mean that you can't just use Wireshark to debug your wireless adapter driver if it's generating a mangled radiotap/AVS/Prism header, but I'm not sure whether that's worth worrying about. There is some risk of loss of information if we don't handle some particular attribute in a particular capture file format, but it might be that the right way to fix that is to add said support if we run into such a capture file. (Another alternative is to supply both the raw radio information *and* the parsed radio information as pseudo-headers, have different WTAP_ENCAP types for different forms of raw radio information, and supply both forms of radio information when writing a capture; that way 1) you'd still have the raw radio information for those users who want to see it and 2) at least when writing out packets in the format of the file from which they're read, we can just pass the raw radio information through, and not lose any information.) ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] WLAN APC file and RSSI
First, thanks for the link. As for the dBm value, it is present in the capture file (stored right after the percentage value in the packet header). Date: Tue, 22 Jan 2008 09:34:55 -0800 From: [EMAIL PROTECTED] To: wireshark-users@wireshark.org Subject: Re: [Wireshark-users] WLAN APC file and RSSI Avi Berkovich wrote: Hello, Wireshark doesn't display the RSSI value in dBm, only in percent. This happens with APC files captured with Airopeek. Is this a limitation? Are you sure the dBm values are present in the capture file? According to http://www.wildpackets.com/elements/whitepapers/Converting_Signal_Strength.pdf, WildPackets prefers to use percentage values. ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] WLAN APC file and RSSI
Avi Berkovich wrote: Hello, Wireshark doesn't display the RSSI value in dBm, only in percent. This happens with APC files captured with Airopeek. Is this a limitation? Are you sure the dBm values are present in the capture file? According to http://www.wildpackets.com/elements/whitepapers/Converting_Signal_Strength.pdf, WildPackets prefers to use percentage values. ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] WLAN APC file and RSSI
It looks like the dBm tag isn't supported in Wireshark. Do you have a capture file you can send to the list or upload to the wiki? Avi Berkovich wrote: First, thanks for the link. As for the dBm value, it is present in the capture file (stored right after the percentage value in the packet header). Date: Tue, 22 Jan 2008 09:34:55 -0800 From: [EMAIL PROTECTED] To: wireshark-users@wireshark.org Subject: Re: [Wireshark-users] WLAN APC file and RSSI Avi Berkovich wrote: Hello, Wireshark doesn't display the RSSI value in dBm, only in percent. This happens with APC files captured with Airopeek. Is this a limitation? Are you sure the dBm values are present in the capture file? According to http://www.wildpackets.com/elements/whitepapers/Converting_Signal_Strength.pdf, WildPackets prefers to use percentage values. ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users Express yourself instantly with MSN Messenger! MSN Messenger http://clk.atdmt.com/AVE/go/onm00200471ave/direct/01/ ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
