beacon handle.

[israellot]

A quick review of what I've done. It's not much but maybe it's a starting point.
My goal was to discover the signature of this function reported in the symbols : ppTxPkt . It appears to me to be the central point for all packets sent over the air, regardless of ap association. Would be a key piece for making a open source 802.11 implementation.

I took this function as a starting point: ieee80211_send_probereq , on most FreeBSD branches it has the same signature ( here's an example https://github.com/freebsd/freebsd/blob ... 1_output.c ) :

Code: Select all

ieee80211_send_probereq(struct ieee80211_node *ni,
   const uint8_t sa[IEEE80211_ADDR_LEN],
   const uint8_t da[IEEE80211_ADDR_LEN],
   const uint8_t bssid[IEEE80211_ADDR_LEN],
   const uint8_t *ssid, size_t ssidlen)

The only unknown is the ieee80211_node argument. It turns out the ESP has a basic config struct at the address _irom0_text_start+0xc, it appears everywhere on the disassembled code.
Looking at the function eagle_lwip_getif,

Code: Select all

40213200 <eagle_lwip_getif>:
40213200:       f38341          l32r    a4, 4021000c <_irom0_text_start+0xc>
40213203:       62cc            bnez.n  a2, 4021320d <eagle_lwip_getif+0xd>
40213205:       4428            l32i.n  a2, a4, 16
40213207:       32dc            bnez.n  a2, 4021321e <eagle_lwip_getif+0x1e>
40213209:       020c            movi.n  a2, 0
4021320b:       f00d            ret.n
4021320d:       0b1266          bnei    a2, 1, 4021321c <eagle_lwip_getif+0x1c>
40213210:       5428            l32i.n  a2, a4, 20
40213212:       228c            beqz.n  a2, 40213218 <eagle_lwip_getif+0x18>
40213214:       0228            l32i.n  a2, a2, 0
40213216:       f00d            ret.n
40213218:       020c            movi.n  a2, 0
4021321a:       f00d            ret.n
4021321c:       f00d            ret.n
4021321e:       0228            l32i.n  a2, a2, 0
40213220:       f00d            ret.n

it became clear the ROM has two ieee80211_node structures, one for the soft ap, the other for the station client. One is on offset 16 from the main config struct, the other on offset 20.
Guessing the signature was easy :

Code: Select all

 struct ieee80211_node * eagle_lwip_getif(int id);

Passing 1 returns a pointer to the access pointer node, 0 for the station ap.
Using this pointer as first argument on the ieee80211_send_probereq function allows me to successfully inject a probe request packet.

A second step would be writing a function in C that replicates the ieee80211_send_probereq,
basically creating a management frame using ieee80211_getmgtframe, configuring it and finally outputting the frame via ieee80211_mgmt_output which internally calls ieee80211_raw_output which in my opinion is replaced by ppTxPkt in ESP, so maybe the signature is similar. But I didn't go down that road so much. Help would be appreciated.

[jimchu]

Hi Israellot,

Is it possible for you to send us your example for packet injection?

[danielcbit]

I'm too would be interested in this example of packet injection.

IF ESP released the complete WiFi stack code it would be awesome! But their reluctance in doing so tells me that maybe some problem about license might be occurring.

There are also other protocols that could be implemented that would be very much beneficial to propelling the use and sell of ESP8266, like for example the WiFi Aware specification (http://www.wi-fi.org/discover-wi-fi/wi-fi-aware)

[ESP_Alen]

Your opinion is correct.
I just would like to add that I want the data to the beacon packet.
Slave node can verify this with additional data. And, it is possible to perform more additional features.
And the confirmation of the received beacon packet is to use sniffer function.
So I need a ESP API function of adding tag information in the beacon packet.
It is possible?

We have release mesh demo on github, please clone current code about mesh:
https://github.com/espressif/ESP8266_MESH_DEMO