ESP8266 Community Forum

- Tue May 12, 2015 5:23 pm #17271 Using SDK 1.0.1 I've registered a promiscuous mode callback to monitor traffic. For testing purposes I'm using simple java code on a laptop connected to the same WLAN as the ESP that simply sends UDP packets with increasing length:

Code: Select allimport java.io.IOException;
import java.net.DatagramPacket;
import java.net.DatagramSocket;
import java.net.InetAddress;
import java.net.UnknownHostException;

public class SendUdp
{
   public static void main (String[] args) {
      try {
         System.out.println("create socket");
         DatagramSocket socket = new DatagramSocket(8027);
         socket.setBroadcast(true);
         socket.connect(InetAddress.getByName("255.255.255.255"), 8027);
         byte[] buf = new byte[100];
         for (int i = 0; i < 100; i++) {
            System.out.println("sending " + i);
            DatagramPacket packet = new DatagramPacket(buf, i);
            socket.send(packet);
            Thread.sleep(10);
         }         
      } catch (Exception e) {
         e.printStackTrace();   
      }
   }
}


but all packets I receive have the length set to either 12 or 60. As the WLAN is WPA encrypted and the MAC header etc. come on top, I expected packet lengths somewhere between 70 and 170 bytes...

Code: Select allwifi_promiscuous_rx(uint8 *buf, uint16 len)

I understand that the promiscuous mode does not provide the full packet content but I expected the length to be accurate. The best "documentation" that provides insights into the format of the buffer provided to the callback is this: https://github.com/ly0/esp8266-smartlink/blob/master/network_80211.h which seems to be partly provided by Espressif - but it does not explain the 12 byte packets and does not provide any details about what the SDk makes available to the callback. When the java code is running, the number of 12 byte packets received by the ESP is dramatically higher so I suspect that these are kind of the stubs representing the UDP packets... Looking at the first 12 bytes of the buffer for these packets there is no pattern visible that could represent the real packet length .

Any further documentation is greatly welcome!!

- Tue May 12, 2015 6:38 pm #17273 Sorry for hijacking your topic, but I'm curious: is the whole wifi/packet processing done in hardware? If so, could the hardware not contain backdoors triggered by specially-crafted packets?

- Thu May 14, 2015 2:40 am #17350 It appears that bytes 5 and 6 of the 12 byte long buffers received by the promiscuous callback are reflecting the length of the original packet

Code: Select allplen = (buf[5] + (buf[6] << 8))

It would still be very helpful to e.g. get the struct definition of the 12 bytes to understand the surrounding data. It's obviously not the same as the RxConfig struct for the 60+ byte buffers.
And it would be very important to understand when/why packets are represented one or the other way (maybe by packet type/subtype/protocol/...).

- Sun May 24, 2015 6:06 am #18302 Found the 12 byte rx struct here: http://bbs.espressif.com/download/file.php?id=416