Arp ping packets fail to build correctly

[stryngs]

Brief description

When trying to build an Arp ping frame to inject using Monitor Mode I came across a strange bug where show2() completely changes the intent and layers are removed and unwanted layers added. This results in a malformed packet.

Scapy version

2.5.0rc2

Python version

3.10.6

Operating system

Linux 6.0.6

Additional environment information

No response

How to reproduce

import binascii
from scapy.all import *

rawHex = '000008000000000088020000FFFFFFFFFFFFAABBCCDDEEFF1122334455660000AAAA030000000806000108000604000170A6CC3010BAC0A864DB000000000000C0A864FE'

example = RadioTap(binascii.unhexlify(rawHex))
example.show()

Actual result

In [39]: example.show()
###[ RadioTap ]###
version = 0
pad = 0
len = 8
present =
notdecoded= ''
###[ 802.11 ]###
subtype = QoS Data
type = Data
proto = 0
FCfield = from-DS
ID = 0
addr1 = ff:ff:ff:ff:ff:ff (RA=DA)
addr2 = aa:bb:cc:dd:ee:ff (TA=BSSID)
addr3 = 11:22:33:44:55:66 (BSSID)
SC = 0
###[ 802.11 QoS ]###
A_MSDU_Present= 1
Ack_Policy= 1
EOSP = 0
TID = 10
TXOP = 170
###[ LLC ]###
dsap = 0x3
ssap = 0x0
ctrl = 0
###[ Raw ]###
load = '\x00\x08\x06\x00\x01\x08\x00\x06\x04\x00\x01p\xa6\xcc0\x10\xba\xc0\xa8d\xdb\x00\x00\x00\x00\x00\x00\xc0\xa8d\xfe'

Expected result

Something closer to:
In [40]: z.show()
###[ RadioTap ]###
version = 0
pad = 0
len = None
present = None
notdecoded= ''
###[ 802.11 ]###
subtype = QoS Data
type = Data
proto = 0
FCfield = from-DS
ID = 0
addr1 = ff:ff:ff:ff:ff:ff (RA=DA)
addr2 = aa:bb:cc:dd:ee:ff (TA=BSSID)
addr3 = 11:22:33:44:55:66 (SA)
SC = 0
###[ LLC ]###
dsap = 0xaa
ssap = 0xaa
ctrl = 3
###[ SNAP ]###
OUI = Officially Xerox, but 0:0:0:0:0:0 is more common (00:00:00)
code = ARP
###[ ARP ]###
hwtype = Ethernet (10Mb)
ptype = IPv4
hwlen = None
plen = None
op = who-has
hwsrc = 70:a6:cc:30:10:ba
psrc = 192.168.100.219
hwdst = 00:00:00:00:00:00
pdst = 192.168.100.254

Related resources

In the Expected result section above I obtained the z object by using sniff() while an nmap scan was running with -sP as the flag. I took the From-DS example that I wanted and attempted to recreate it.

If you would like to capture the same kind of packet sniff while in monitor mode when a -sP nmap scan is happening using Open Wifi. Sure enough when I take that pcap and then wireshark it, it shows as not malformed, just like I expect. However, if I run z.show2() the same error occurs.

[guedou]

Are you aware of this example working fine on a previous Scapy version?

[stryngs]

I am not, however I have never tried this on a previous version. Was using 2.4.5 and went to go file an issue and saw the 2.5 and so upgraded to rc2.

Typically I'd blame weirdness like this on something PEBKAC related but I can reproduce by sniffing nmap -sP and then trying to .show2() any of the captured frames which gives me the feeling it isn't the way in which I built the frame but some underlying bug with how those specific fields play together when being prepared.

[guedou]

Thanks. That explains why git bisect does not find a good commit. Unfortunately, I don't known 802.11 enough to provide a fix quickly.

[stryngs]

I'll do some debugging tonight and see what I can come up with. Thanks for looking into this!

[stryngs]

Through trial and error I believe it is the subtype field within Dot11() causing the issue

from scapy.all import *

f = RadioTap()\
       /Dot11(addr1 = 'ff:ff:ff:ff:ff:ff',
              addr2 = 'aa:bb:cc:dd:ee:ff',
              addr3 = '11:22:33:44:55:66',
              # subtype = 8,
              type = 2,
              FCfield = 2)\
       /LLC()\
       /SNAP(code = 2054)\
       /ARP(op = 1,
            hwdst = 'ff:ff:ff:ff:ff:ff',
            hwsrc = '11:22:33:44:55:66',
            pdst = '192.168.10.1',
            psrc = '192.168.10.100')

f.show()
f.show2()

[stryngs]

Confirmed @guedou the issue is the subtype. Funny enough though after it builds it uses the subtype of 8 and so by simply commenting that out the wanted effect is achieved!

[stryngs]

arping -i wlan0 -U -S 192.168.100.226 192.168.100.226

Listening to this with a 3rd party node I noticed tonight there were diffs in the To-DS and From-DS frames more so that I had realized previously:

The To-DS

[scapy.layers.dot11.RadioTap,
 scapy.layers.dot11.Dot11,
 scapy.layers.dot11.Dot11QoS,
 scapy.layers.l2.LLC,
 scapy.layers.l2.SNAP,
 scapy.layers.l2.ARP,
 scapy.packet.Padding]

The From-DS

[scapy.layers.dot11.RadioTap,
 scapy.layers.dot11.Dot11,
 scapy.layers.l2.LLC,
 scapy.layers.l2.SNAP,
 scapy.layers.l2.ARP,
 scapy.packet.Padding]

When testing I saw that you could build the To-DS from scratch and have it successfully work by using Dot11 and not giving a subtype and removing the Dot11QoS layer all together.

Closing this out.