Ask Your Question
0

Ethernet padding in 802.11 packets

asked 2020-11-20 08:32:44 +0000

Turtle gravatar image

As we know, the minimum payload of an Ethernet II frame is 46 bytes (or 42 bytes if 802.1Q tag is present). If the payload is less, padding bytes are added. When capturing on ethernet interface, Wireshark is usually able to dissect these bytes (filter eth.padding).

My question is about what happens to these padding bytes when this frame is sent as 802.11 frame? For example, a TCP ACK frame sniffed from wireless interface going from STA to DS (To DS: 1 From DS: 0) does not have these padding bytes. Whereas TCP ACK frame going from DS to STA (To DS: 0 From DS: 1) does show 6 bytes of padding. Even though Wireshark was not able to dissect them, I assume these last 6 zero bytes correspond to ethernet padding bytes (or if FCS is visible these 6 bytes come just before it).

I have noticed this behaviour from my own captures and, for example, from Wireshark sample capture Http.cap from https://wiki.wireshark.org/SampleCapt.... References from Http.cap are:

  • packet 9 going to DS (no padding bytes)
  • packet 13 going to STA (padding bytes visible)

Is this expected behaviour or somehow related to specific wireless NICs? I couldn't find any explanation for this from internet nor the 802.11 standard.

Not sure about the setup in sample capture Http.cap, but I will further clarify my test setup.

PC1 <-> Switch1 <-> AP ... Wireless client <-> Switch2 <-> PC2

When I capture on either Switch from a mirrored (SPAN) port, all the TCP ACK frames going to either direction have ethernet padding. Then when I capture on wireless interface with an external capture adapter, only packets going to wireless client do have these padding bytes intact. So it seems that the wireless client is able to strip these padding bytes when the Ethernet frame is translated to 802.11 frame. AP and Wireless client are both identical devices, only their operating modes differ.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2020-11-20 09:03:28 +0000

Guy Harris gravatar image

My question is about what happens to these padding bytes when this frame is sent as 802.11 frame?

If the frame originates from an 802.11 interface, there are no padding bytes.

I think the reason for Ethernet padding was, originally, to make sure that a packet, when transmitted, will, once it's completely transmitted, result in a signal along all of a maximum-length Ethernet cable, so that, while it's being transmitted, if any other station on that cable tries to transmit, it'll either detect the carrier for the packet the other station is transmitting (that's the CS - "carrier sense" part of "CSMA-CD") or detect a collision between the the packet the other station is transmitting and the packet it's trying to transmit (that's the CD - "collision detect" part of "CSMA-CD").

That's no longer necessary on full-duplex switched Ethernet, but it's still used.

It's also not used for 802.11.

I'd have to look at various 802 standards to see if they indicate what should happen to the padding in an Ethernet frame if the frame is bridged from Ethernet to 802.11. If it's routed at the IP layer from Ethernet to 802.11, the router will probably strip off the padding.

edit flag offensive delete link more

Comments

Thank you for the reply! In my test case, isn't it just the case where Ethernet frames are bridged from Ethernet to 802.11 since the original source of the packets are PC1 and PC2? Thus first they have to pass the Ethernet frames through switch.

One idea came to my mind: In my case the Wireless client is actually doing NAT/port forwarding to PC2. When I look at the address fields at the 802.11 MAC header, the Source address (wlan.sa) for a packet from Wireless client to AP is actually the MAC address of the wireless client (not PC2!). Whereas on the packet from AP to client the Source address is the MAC address of PC1.

So does that correspond to your comment that "if the frame originates from an 802.11 interface, there are no padding bytes" (despite the original source is PC2)?

Turtle gravatar imageTurtle ( 2020-11-20 12:54:44 +0000 )edit

Also, if @Guy Harris you are able to find anything from 802 standards or point me to relevant documents, it would be highly appreciated

Turtle gravatar imageTurtle ( 2020-11-23 08:04:46 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2020-11-20 08:32:44 +0000

Seen: 21 times

Last updated: Nov 20