ESP8266 Developer Zone

Re: beacon handle.

2016-03-04T11:54:46+08:00

nice72 wrote:
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

Statistics: Posted by Guest — Fri Mar 04, 2016 11:54 am

Re: beacon handle.

2016-02-02T02:22:43+08:00

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)

Statistics: Posted by danielcbit — Tue Feb 02, 2016 2:22 am

Re: beacon handle.

2015-07-28T06:18:56+08:00

Hi Israellot,

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

Statistics: Posted by jimchu — Tue Jul 28, 2015 6:18 am

Re: beacon handle.

2015-06-09T04:01:34+08:00

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:

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:

40213200 :
40213200:       f38341          l32r    a4, 4021000c <_irom0_text_start+0xc>
40213203:       62cc            bnez.n  a2, 4021320d 
40213205:       4428            l32i.n  a2, a4, 16
40213207:       32dc            bnez.n  a2, 4021321e 
40213209:       020c            movi.n  a2, 0
4021320b:       f00d            ret.n
4021320d:       0b1266          bnei    a2, 1, 4021321c 
40213210:       5428            l32i.n  a2, a4, 20
40213212:       228c            beqz.n  a2, 40213218 
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:

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.

Statistics: Posted by israellot — Tue Jun 09, 2015 4:01 am

Re: beacon handle.

2015-05-28T08:19:20+08:00

israellot wrote:
I managed to send probe requests with arbitrary data.

This feature is of great value for ultra low power IoT as it can reduce the "on" time significantly thus reducing the power budget.
@israellot, can you post information of how this was achieved?

Statistics: Posted by eyal — Thu May 28, 2015 8:19 am

Re: beacon handle.

2015-04-30T02:56:01+08:00

@israellot

Can you post any information about how you add data to the beacon? I am also interested in this feature.

Statistics: Posted by Anki — Thu Apr 30, 2015 2:56 am

Re: beacon handle.

2015-04-25T05:50:03+08:00

I managed to send probe requests with arbitrary data.

Statistics: Posted by israellot — Sat Apr 25, 2015 5:50 am

Re: beacon handle.

2015-04-25T00:39:00+08:00

I believe it is
I'm working on reverse engineer the ESP libraries to gain access to wifi functions not exposed in the SDK.
I will let you know if I get any result.

Statistics: Posted by israellot — Sat Apr 25, 2015 12:39 am

Re: beacon handle.

2015-04-24T22:05:33+08:00

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?

Statistics: Posted by nice72 — Fri Apr 24, 2015 10:05 pm

Re: beacon handle.

2015-04-24T20:14:23+08:00

But what if we work with only probe requests and responses?
We would be still 802.11 compliant and could broadcast data multi-to-multi node. That's what I'm talking.
A protocol would need to be written on top of it but could work, no association required.

Statistics: Posted by israellot — Fri Apr 24, 2015 8:14 pm

Re: beacon handle.

2015-04-24T07:39:49+08:00

Hi !!

As you know, mesh is required to support the multi to multi node.

However, a wireless LAN solutions of esp8266 can not fully support it.

Frenkly speaking, In order to support a single to multi node, I chose a multi tree node method.

Is this a question you want answered ?

Thanks
Peter

PS : The status of the child node that can be found on the console log of the top-level node.

11800> wsts

========WLAN COMMON===================
----wlan mode........3
1 : station mode
2 : softap mode
3 : station + softap mode
----channal..........1
----phy mode.........3
1 : 11b - softAP, station
2 : 11g - softAP, station
3 : 11n - station
----sta mac..........[18:fe:34:9d:b5:c4]
----ap mac..........[1a:fe:34:9d:b5:c4]
========STATION=======================
----status...........5
0 : idle
1 : connecting
2 : wrong password
3 : no ap found
4 : connect fail
5 : got ip
----ssid............[iot_hub]
----passwd..........[]
----auto connection..0
----dhcp client......1
---------ip..........172.017.123.046
nm..........255.255.254.000
gw..........172.017.123.254
========AP============================
----ssid............[dvmesh_1]
----password........[13579ertyta]
----channel..........1
----authmode.........0
0 - open
1 - wep
2 - wpa_psk
3 - wpa2_psk
4 - wpa_wpa2_psk
----hidden...........0
0 - announced
1 - hidden
----maxcon...........4
max : 4
----bintv............100ms
100~60000ms
----dhcp server......1
---------ip..........010.010.001.001
nm..........255.255.255.000
gw..........010.010.001.001
----wifi station
[00] 010.010.001.002 18:fe:34:9d:b5:bf
[01] 010.010.001.003 18:fe:34:9d:b5:c2
[02] 010.010.001.004 18:fe:34:9d:b5:c1
[03] 010.010.001.005 18:fe:34:9d:b5:bb
========MESH==========================
----state............[CON_MQTT__]
----hop..............1
----udp..............(tx:48)(txfree:48)(txerr:0)(tout:0)
----fifo.............(perr:0)
----up/down pkt......(up:0)(down:0)
----bad bssid
empty
----up dev...........06:08:52:1f:87:c0
----dev pool
no devid ip tout hop echo
000 18:fe:34:9d:b5:bf 010.010.001.002 00 01 12/12
001 18:fe:34:9d:b5:c2 010.010.001.003 00 01 12/12
002 18:fe:34:9d:b5:c1 010.010.001.004 00 01 12/12
003 18:fe:34:9d:b5:bc 010.010.001.003 00 02 12/12
004 18:fe:34:9d:b5:bb 010.010.001.005 00 01 12/12
005 18:fe:34:9d:b5:bd 010.010.001.005 00 02 12/12

11800>

Statistics: Posted by nice72 — Fri Apr 24, 2015 7:39 am

Re: beacon handle.

2015-04-23T20:47:53+08:00

By the way, what's your approach to mesh os esp8266 nice72?

Statistics: Posted by israellot — Thu Apr 23, 2015 8:47 pm

Re: beacon handle.

2015-04-23T20:42:32+08:00

Similar to what I requested on viewtopic.php?f=7&t=371
Please Espressif, allow us to mesh!

Statistics: Posted by israellot — Thu Apr 23, 2015 8:42 pm

beacon handle.

2015-04-23T19:25:04+08:00

Dear Sir,

I am developing a mesh system using esp8266.

Although implementation of most of the functions, there are some limitations.

Due to the limitations of memory, our esp8266 system can support only six client.

We know, all systems that limit the number of supported client.

For the construction of a faster mesh system, I have one request.

I hope to handle 802.11's tx and rx beacon packet.

If esp8266 can add user defined tag information and interpret the packet,
I'll able to handle quickly and easily in the our mesh system.

Please, I hope that my request is allowed.

Thanks,
Peter

Statistics: Posted by nice72 — Thu Apr 23, 2015 7:25 pm