RadioTap Dummy Channel vs. Frequency confusion

[bannsec]

Brief description

RadioTap layer seems to confuse what the Frequency is vs. what the Channel is.

Environment

• scapy===git-archive.deve44bd373f
• 3.6
• Ubuntu 18.04

How to reproduce

• Simply capture 802.11 traffic and check out the "Channel" field.

Actual result

• Channel values such as 2452

Expected result

• The actual channel, such as channel 9 in the above example.
• A separate field called "Frequency" that would contain 2452 from above.

Related resources

[gpotter2]

Hi & thanks for the report
Could you please share a pcap or a packet as bytes/hex so that we can reproduce ?

We recently did several overhauls to RadioTap, it could have broken something.

Thanks !

[bannsec]

Sure. Attached
example.zip

[gpotter2]

That's not correct. In reality, there is only 1 channel field (and a tags one), which stores the frequency of the channel. Scapy does not interpret, thus unlike wireshark, it does not create "fake" fields to add extra informations.

When you see "channel 9", what happens in reality is that Wireshark matches the frequency using the following table:

This is technically not a bug. We could however potentially edit the Channel field to display the channel number between parenthesis (using LEShortEnumField), it that's any clearer. Feel free to submit a PR

[bannsec]

Yep, definitely aware of the frequency vs channel (thus the title and description of this ticket). However, Scapy is indeed either mis-representing the data or improperly parsing it.

RadioTap Defines the channel field here: https://www.radiotap.org/fields/Channel.html

Note, it is explicit that the channel field is comprised of two subfields:

• frequency <-- this is what scapy defines as "Channel"
• flags

Correspondingly, scapy exposes a "Channel" field in the radiotap layer, which appears to actually be the frequency subfield. It further exposes "ChannelFlags" and "ChannelFrequency" which appear to not actually get populated. In this way, the "Channel" field in scapy is incorrect, since it does not include flags as defined by radiotap.

To truly not interpret the underlying information, the Channel field in radiotap layer would be 4 bytes and include the flags.

Note that radiotap does a better job at avoiding some of the confusion since it explicitly calls this frequency, since 802.11 defines channel as frequency bands.

[gpotter2]

I see your point.
Currently:

• we use ChannelFrequency for XChannel.freq https://www.radiotap.org/fields/XChannel
• we use Channel for the real channel frequency, because that's what wireshark used to do before switching to channel.freq
  

We could change the names, but that would break already existing code :/ the issue here is about the naming convention. The parsing is correct

[bannsec]

Hmm.. Would it break functionality to also add the frequency to ChannelFrequency variable that doesn't seem to get populated?

…

On Mon, Apr 8, 2019 at 3:41 PM Gabriel ***@***.***> wrote: I see your point. Currently: - we use ChannelFrequency for XChannel.freq https://www.radiotap.org/fields/XChannel - we use Channel for the real channel frequency, because that's what wireshark used to do before switching to channel.freq [image: 6B9924D9-D802-4E22-A4B7-67108F2B449B] <https://user-images.githubusercontent.com/10530980/55751887-0257d800-5a47-11e9-9cbd-2b36b639eafd.jpeg> We could change the names, but that would break already existing code :/ — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1979 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHR34Pq6BjE2OAJfHWXLNAO_xDx6RrRcks5ve5t1gaJpZM4cgOSb> .

[gpotter2]

It's normal that it doesn't get populated: ChannelFrequency is used for XChannel

[bannsec]

Indeed. Just attempting to identify a way to make the attributes in your tool less misleading. Imho the proper answer from both a pythonic and following standards approach would be to change channel into a class object that exposes the two sub properties. Thus channel.frequency could be used. And for the concern about breaking things already written for the current way, simply override pythons duck typing for the class.

…

On Fri, Apr 12, 2019, 9:35 AM Gabriel ***@***.***> wrote: It's normal that it doesn't get populated: ChannelFrequency is used for XChannel ! I literally said that above — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1979 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHR34PPGpOC-sPFjinAezL8N4LM_l7viks5vgIuPgaJpZM4cgOSb> .

[gpotter2]

2a1cf29 (#1983) should resolve the issue 😄 Feel free to have a look