Many packets are appeared on the wireless link ( in a layer 2 sense
) but, not every packet is handled by the network driver.
The driver only handles the packets in/out from upper layers. it means
that other protocol laid just above MAC layer will
call the driver to send them. However, those packets only
relating
to layer 2 is not from upper layer is not visible to driver,
such as RTS/CTS .
Maybe there is a way to let driver handle RTS/CTS also, but it is
depend
on How the MAC controller chip is designed.
I believe some manufactureer will make this operation "automatic",
or controlled by firmware, leaving no room to a "driver"'s
interference.
Thus, the driver program only handles packets from upper
layer,
such as IP packet.
The driver is sitting down between the upper layer and the chip
(hardware). The chip will generate a "correct" MAC format.
Thus, the driver also have no idea about how the final MAC packets
will be in what form of!
If I send a UDP packet with a payload of 40 bytes, how long the
packet will be when it arrivis the
driver of transmitting station (not in air!).?
The answer is 82,
So if a UDP of x, the lenth would be x+42. (this rule is observed by
experiment!)
I believe in the 42 bytes, 8 would be UDP header, 20 would be IP
header, and 8 is LLC overhead (link layer control)
so, the remaining 6 bytes must be the destination MAC address.
No. Because not only the IP layer will call the driver to send
payloads,
there is another protocol would
querying the WLAN, such as ARQ messages.
Thus, the applicaton can only control and predict its own flow
to the driver, but does not know the behavior of
that protocol.
Thus, in the packet flow to the driver, you can see some "60 bytes
length" packets occuring 'randomly". Those
packets are not generated by my socket application.
When the application is starting, the first packet present in the
driver is not the one you sent in the application, but
a length "60" packet. only when this packet is righteously acked, your
paclet will be transmitted followingly.