SoftAP and DHCP

[Michael Jacobsen]

Hi,

Really need the SoftAP-mode and therefore also the DHCP functions. I see that 'libudhcp' is removed due to licensing issues.

Any alternatives?

/michael

[Angus Gratton]

On Tue, Sep 08, 2015 at 03:23:43AM -0700, Michael Jacobsen wrote:
> Really need the SoftAP-mode and therefore also the DHCP functions. I see
> that 'libudhcp' is removed due to licensing issues.

Hi Michael,

I have written[*] a basic dhcpserver implementation that I'm testing. It's not 100% RFC compliant but it works for basic usage (in my case it's intended just to provide enough functionality to connect to the ESP and communicate SSID details so the ESP can become a client).

I haven't posted that yet but I'll do it in the next day or so, if you'd like to test it then that would be great. :)


Angus

[*] I _really_ didn't want to write my own dhcpserver implementation but I couldn't find any that were suitable and were licensed appropriately. If anyone knows of one then I'll happily switch to it instead!

[Michael Jacobsen]

Hi Angus,

I'll be happy to test it. Sounds like we are working on the same idea:

1) Enable AP mode and DHCP.

2) Client connect to it.

3) Client connect to "micro" web server on the ESP where SSID/key can be entered.

4) The ESP then connects to that SSID (and web server is stopped)

About right? :-)

I also have another method: Use TI's SimpleLink app (IOS/Android) to send ssid/key. Got it working so far as the ESP can receive and decode the data sent by the SimpleLink app. But I don't know what a TI CC3000 transmits right after it has connected, so the SimpleLink app don't get to know whether or not the ESP successfully connected or not :-(

/michael

[Angus Gratton]

I've put the DHCP server support (and AP example) into a PR:
https://github.com/SuperHouse/esp-open-rtos/pull/46

Comments and testers very welcome, more details in the PR.

On Tue, Sep 08, 2015 at 04:14:04PM -0700, Michael Jacobsen wrote:
> I'll be happy to test it. Sounds like we are working on the same idea:
> 1) Enable AP mode and DHCP.
> 2) Client connect to it.
> 3) Client connect to "micro" web server on the ESP where SSID/key can be
> entered.
> 4) The ESP then connects to that SSID (and web server is stopped)
>
> About right? :-)

Yes, that's what I'm working towards as well.

I've started adding web server support via GNU libmicrohttpd[1]. It looks promising, although I'm not sure how resource-heavy yet (I think it's usually used on larger devices with a *nix OS, not RTOS microcontrollers.) Will keep you posted about how that goes.

> I also have another method: Use TI's SimpleLink app (IOS/Android) to send
> ssid/key. Got it working so far as the ESP can receive and decode the data
> sent by the SimpleLink app. But I don't know what a TI CC3000 transmits
> right after it has connected, so the SimpleLink app don't get to know
> whether or not the ESP successfully connected or not :-(

Nice work! AFAIK the SimpleLink protocol itself isn't patent protected or anything, so I think(?) we could merge support for this if you wanted to contribute it. I noticed that Espressif have it in recent versions of their SDK. Would be a nice feature to offer. :)


Angus

[1] https://www.gnu.org/software/libmicrohttpd/

[Michael Jacobsen]

Hi Angus,

Been testing your DHCP Server 'against' an iPhone with IOS9. This is what happens:

dhcpserver_task(): start

add 1

aid 1

station: e0:b5:2d:41:c3:31 join, AID = 1

handle_dhcp_request(): lease addr 172.16.0.2 assigned to MAC e0:b5:2d:41:c3:31

handle_dhcp_request(): expires = 360000

handle_dhcp_request(): lease addr 172.16.0.2 assigned to MAC e0:b5:2d:41:c3:31

handle_dhcp_request(): expires = 360000

handle_dhcp_request(): lease addr 172.16.0.2 assigned to MAC e0:b5:2d:41:c3:31

handle_dhcp_request(): expires = 360000

max connection!

station: e0:b5:2d:41:c3:31 join, AID = 1

handle_dhcp_request(): lease addr 172.16.0.2 assigned to MAC e0:b5:2d:41:c3:31

handle_dhcp_request(): expires = 360000

max connection!

max connection!

station: e0:b5:2d:41:c3:31 join, AID = 1

handle_dhcp_request(): lease addr 172.16.0.2 assigned to MAC e0:b5:2d:41:c3:31

handle_dhcp_request(): expires = 360000

max connection!

max connection!

max connection!

max connection!

max connection!

station: e0:b5:2d:41:c3:31 leave, AID = 1

rm match

At the second-last line, the phone gives up :-(

struct sdk_softap_config ap_config;

    

memset(ap_config.ssid,     0, sizeof(ap_config.ssid));

memset(ap_config.password, 0, sizeof(ap_config.password));

strcpy((char*)ap_config.ssid, WIFI_AP_NAME);

ap_config.ssid_len        = strlen(WIFI_AP_NAME);

ap_config.authmode        = AUTH_OPEN;

ap_config.ssid_hidden     = 0;

ap_config.max_connection  = 3;

ap_config.channel         = 7;

ap_config.beacon_interval = 100;

...and

ip_addr_t first_client_ip;

IP4_ADDR(&first_client_ip, 172, 16, 0, 2);

dhcpserver_start(&first_client_ip, 4);

Thoughts? Maybe IOS need some more DHCP options to be happy?

/michael

[Angus Gratton]

On Thu, Sep 24, 2015 at 01:01:25PM -0700, Michael Jacobsen wrote:
> Been testing your DHCP Server 'against' an iPhone with IOS9. This is what
> happens:
>

> *snip*

Hi Michael,

What I find with Android is that it connects but then a few seconds later it disconnects, after it fails to find a route to the internet. Is that possibly what's happening here as well?

I think the solution for most purposes is to behave like a captive portal, but I haven't gotten as far as implementing that yet...


Angus

[Michael Jacobsen]

Hi Angus,

Could very well be that. Added nameserver and router to the options that are sent back to the requester. Looks a bit better, but the client still leaves the network.

Also tried from my iMac (which has a cabled ethernet as it's primary connection). Looks a bit better.

"captive portal" - then there would also need to run a DNS server on the ESP, right?

I was hoping that mDNS broadcasts would be enough. Oh Well.

/michael

[pol delgado martín]

Hi,
I was too programming an AP mode and i observed what you both noticed with dhcps, the client disconnects. 
Is there any solution?

Pol

[pol delgado martín]

We can't use udhcp due to license incompatibilities. 
I have been searching, and i'm almost sure that you already know, but esp-lwip implemented a dhcp server with sdk like calls.

https://github.com/kadamski/esp-lwip/blob/esp8266-1.4.1/espressif/dhcpserver.c

Can we use this? Is it tested ?

[Angus Gratton]

On Thu, Apr 28, 2016 at 07:17:39AM -0700, pol delgado martín wrote:
> We can't use udhcp due to license incompatibilities.
> I have been searching, and i'm almost sure that you already know, but
> esp-lwip implemented a dhcp server with sdk like calls.
> https://github.com/kadamski/esp-lwip/blob/esp8266-1.4.1/espressif/dhcpserver.c
> Can we use this? Is it tested ?

Hi Pol,

I hadn't noticed that one, but there is a basic dhcpserver in esp-open-rtos now. I wrote it last year, but it took a while to get merged in:

https://github.com/SuperHouse/esp-open-rtos/tree/master/extras/dhcpserver

And an example:

https://github.com/SuperHouse/esp-open-rtos/tree/master/examples/access_point

It's pretty bare bones, but it works. If you find shortcomings then please open issues on the repo and/or send patches. :)


Angus

[pol delgado martín]

Hi Angus,
I know ! iyou did a great job, even if it's bare bones.

The problem is that when i connect with the mobile i get the IP, but after a couple of seconds or so the mobile disconnects.
I will keep searching, why it fails, alternatives,  improvements, hope i will find something useful

[Angus Gratton]

On Fri, Apr 29, 2016 at 12:49:59AM -0700, pol delgado martín wrote:
> Hi Angus,
> I know ! iyou did a great job, even if it's bare bones.
> The problem is that when i connect with the mobile i get the IP, but after
> a couple of seconds or so the mobile disconnects.
> I will keep searching, why it fails, alternatives, improvements, hope i
> will find something useful

Oh, sorry. This is what I get for not reading all the emails to the list.

Is there any chance you can get a packet capture (pcapng for Wireshark) from the phone? (I think the only way is via a rooted Android phone, but there might be other ways.)


Angus

[pol delgado martín]

Sure!
It seems that dhcp is working fine and android disconnects because it receives no response for it's DNS requests ? 

I attach the capture,

[pol delgado martín]

PS: i have an electhronic product with wifi embedded so you can control it from an android app (SJCAM4000), it acts as an AP (without internet access) it configures itself as the gateway, and it comes with no captive portal. The only service available is a web directory in 192.168.0.254 (so you can navigate the devices folders and images).

Android connects to it reliably, i thought i maybe see a hint of why android disconnects with esp, i can't see the differences but i attach here the capture since it may be useful to more skilled ones.

El martes, 8 de septiembre de 2015, 12:23:43 (UTC+2), Michael Jacobsen escribió:

[pol delgado martín]

El martes, 8 de septiembre de 2015, 12:23:43 (UTC+2), Michael Jacobsen escribió:

[pol delgado martín]

PS2: after watching closesly i have seen some differences, in the succesful negotiation dhcp also sends this options:

• Router : set to self (esp) ip.
• Broadcast adress
• DNS: set  to any.

I modified your dhcp server implementation so it also sends this options ( only 6 lines, so it was easy). The client still disconnects, here i attach the capture with the dhcps mod.

Also... sorry for the spam

[pol delgado martín]

Ok, after some research...

About dhcp:

• dhcp is working fine!
  The dhcp handshake completes succesfully. It can be seen in the captures i attached.
  It also can be observed connecting with a client and trying for example ifconfig.
  Furthermore before it disconects you can even talk for example to the telnet server in the access_point example (see captures attached).
• Adding router and dns options to dhcp improves the situation, but it is not the solution, not even a dirty fix,  seconds of difference still not usable, at least in my case, almost for sure the issue is not on dhcp options (see next point)
  
  
• I tried to disable the dhcp server and manually configure the client. I telneted succesfully, but after a few time, same issue, the client disconnected without even using DHCP!

It is possible to get a stable connection without internet (in fact in my captures both devices dumps look almost identical : succesful dhcp hs, no dns queries are resolved, some tcp connections missed and icmpv6 messages missed too) , taking this into account and If i'm getting things right it is not the client's issue.

As for the captive portal i'm betting it will not solve the problem, as i said i get reliable connection without it in other no internet AP devices, so not needed for sure.
We must trace "max connection!" message, it seems that something weird is happening at the esp at this moment, maybe then the data link layer packets are not handled?

Any hints for getting more info about it? Thougts? 

El martes, 8 de septiembre de 2015, 12:23:43 (UTC+2), Michael Jacobsen escribió:

[Angus Gratton]

3Hi pol & others,

I looked into this again today, and I think it's been happening for me as well the entire time - I just hadn't noticed it. Sorry!

10 seconds after a client connects to the ESP in SoftAP mode, the AP disassociates it for inactivity (regardless of whether it was active or not). Some of my devices were transparently re-associating without me noticing, but not all of mine were (and some, like my Android phone, actually seem to get stuck where the device thinks it's still associated even though it isn't.)

The short/quick answer is that you can work around this by replacing the SDK's internal hostap timeout function. It's hacky (and it means clients will never get booted for inactivity), but you can do it by adding this code to your program:

void sdk_hostap_handle_timer(void *cnx_node)
{
}

... full explanation of what I think the behaviour around the bug is:

* In libnet80211/ieee80211_hostap.o when hostap_input() sees packets from a new station, it calls a static function which adds the station to the internal connection table - via cnx_node_alloc() - and sets up a timer to call hostap_handle_timer() every 10 seconds (repeating). The argument passed to hostap_handle_timer() is the cnx_node structure that was just allocated.

* hostap_input is also supposed to look up each incoming packet's sender(?) in the internal connection table (cnx_node_search()), and if it finds a matching entry it writes the current count of hardware timer FRC2 to offset 0x108 in the allocated 'cnx_node' structure. This is a "last seen" timestamp.

* Every ten seconds the hostap_handle_timer() function compares the current FRC2 timer count to the stored timestamp, and if they're too far apart (ie no wifi frame received recently) then it sends a disassociation frame to the idle client and removes it using cnx_node_leave().

* cnx_node_leave() itself checks some internal state and prints the "max connection!" message each time it removes an "idle" client. (Unclear if this is a bug itself, or a symptom of the bug.)


... the bug happens because the "last frame receiver" timer value is never written to FRC2 offset 0x108 in hostap_input, this value is always zero so even an active client is disconnected after 10 seconds.

I don't know what causes that buggy behaviour. The bug could be in hostap_input, or maybe the "cnx node" is never properly registered.

I've opened an issue on the mailing list to track this:
https://github.com/SuperHouse/esp-open-rtos/issues/140


Angus

On Tue, May 03, 2016 at 07:27:56AM -0700, pol delgado martín wrote:
> Ok, after some research...
>
> About dhcp:
>

> - dhcp is working fine!

> The dhcp handshake completes succesfully. It can be seen in the captures
> i attached.
> It also can be observed connecting with a client and trying for example
> ifconfig.
> Furthermore before it disconects you can even talk for example to the
> telnet server in the access_point example (see captures attached).

> - Adding router and dns options to dhcp improves the situation, but it

> is not the solution, not even a dirty fix, seconds of difference still not
> usable, at least in my case, almost for sure the issue is not on dhcp
> options (see next point)
>

> - I tried to disable the dhcp server and manually configure the client.

> I telneted succesfully, but after a few time, same issue, the client
> disconnected without even using DHCP!
>
> It is possible to get a stable connection without internet (in fact in my
> captures both devices dumps look almost identical : succesful dhcp hs, no
> dns queries are resolved, some tcp connections missed and icmpv6 messages
> missed too) , taking this into account and If i'm getting things right it
> is not the client's issue.
> As for the captive portal i'm betting it will not solve the problem, as i
> said i get reliable connection without it in other no internet AP devices,
> so not needed for sure.
> We must trace "max connection!" message, it seems that something weird is
> happening at the esp at this moment, maybe then the data link layer packets
> are not handled?
> Any hints for getting more info about it? Thougts?
>
>
> El martes, 8 de septiembre de 2015, 12:23:43 (UTC+2), Michael Jacobsen
> escribió:
> >
> > Hi,
> >
> > Really need the SoftAP-mode and therefore also the DHCP functions. I see
> > that 'libudhcp' is removed due to licensing issues.
> >
> > Any alternatives?
> >
> > /michael
> >
>

> --
> You received this message because you are subscribed to the Google Groups "esp-open-rtos mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to esp-open-rto...@googlegroups.com.
> To post to this group, send email to esp-op...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/esp-open-rtos/5b8beee2-cb9d-49ad-bfa0-1fccdd8dd63b%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[pol delgado martín]

Hi!
It works now! i wish i could help... i tried to reverse engineer without success the firmware to trace the max connection message.

For start learning esp internals and reverse engineer the best place is foogod's site isn't it ?
Nice job here! 

El martes, 8 de septiembre de 2015, 12:23:43 (UTC+2), Michael Jacobsen escribió: