Wifi Software AP mode

Support
1

Lilygo TTBEAM 1.1 board used here.

I’ve set an SSID and a password, and turned on the software AP mode. Seems to work fine, once the board starts up and creates a self-signed cert as part of the process of rebooting.

My question is this:

Seems if I have TWO TBEAMs near enough to each other that when setting them to wifi AP mode, and giving each a different SSID, they wind up booting with different IP addresses. So - I’m assuming they “probe” the wifi to make sure the IP is open before assigning one to itself?

Normally, this wouldn’t cause an issue, but since the subnets are different (192.168.4.x vs 192.168.41.x), to use the web interface, you have to reconnect to each board instead of just using http://<ip_address>. Is it possible to ALSO set the IP for the software AP? If so, I haven’t stumbled into that one in the documentation.

2

What is the use case for two AP devices? One AP with other devices connected as clients is the more common setup and even that is an edge case. Actual WiFi use is usually limited to a single bridge device on most networks, not sure why you want everything on the WiFi.

3

Sorry … There’s currently no support for two devices, both acting as access points and having different IP addresses.

The IP address used by the built in AP is hard coded as 192.168.42.1 . Really don’t know how they’d be getting different addresses.

There’s no way to configure what you’ve suggested, but we’ll accept a PR if one is offered.

4

I don’t want everything on wifi. I’m experimenting.

5

well, I’ve set up two devices within range of each other (6 feet or so), and the first received an address of 192.168.4.1. The second, when configured gave an address of 192.168.42.1.

I’ve connected to wifi for both of them - separately - while both were active and running. So they got different IP addresses. I don’t know what the code has internally, but I can tell you I got two different IP addresses with both up at the same time.

Sorry - editing this - the second IP assigned was NOT 192.168.42.1 - but 192.168.42.2. I know those IPs were assigned, because I used the web interface to go to each of them after connecting to their AP, one at a time.

6

I wonder if the espressif sdk is doing that.

Either way, I think you’ve bumped into something we didn’t expect — that two devices will both be an AP with shared credentials.

Please file a bug in our tracker and we’ll add it to the list of things to be investigated.

7

I’ll put a bug report in - but not sure they are “shared credentials” - unless you mean different SSID (they both have different SSIDs), but do use the same PW to join the AP.

I believe the “heart” of this may be the use of the ‘arp’ command (not sure if this is embedded Linux), or using essentiall an ‘arp’ SDK. I’ve run into other products in the last few years using arp to provide a ‘non-DNS’ name to access the device through the client’s arp table. Unexpected side affects, etc. in those other products.

I’m ASSUMING arp or an arp protocol is being used, since the devices appear to have “probed” the network to come up with a different IP.

1 Like
8

I’ll try to do some more testing - but with all the other things I’ve got going I spend maybe 1/2 day a month “playing” with them. Keeps me off the streets at night :grin:

1 Like
9

good descriptions of a problem really helps with reproducing it.

thanks mate!

10

Oh how well I know! Been a developer now since my sophomore year of high school. 49 years ago…

I’ll see what I can do - with instructuons and “8x10 color glossies”

11

In triplicate & faxed.

12

Ok - fax broke down, but here’s what I’ve done so far

Both devices are LilyGo TTBEAM v1.1 devices
Flashed the firmware-1.2.59.d81c1c0 firmware to 2 units, then, I set the settings to “known” values.

  1. Started with a ‘meshtastic —set factory_reset true
  2. Reset the device via reset switch
  3. Ran a “settings” script:
# Radio channel settings
meshtastic --set region US								# set region to US
meshtastic --ch-set id 0 --ch-index 0					# set Channel id
meshtastic --ch-set name “mychannel" --ch-index 0	    # set channel name
meshtastic --ch-set psk default --ch-index 0            # set encryption to default   
meshtastic --ch-set tx_power 0 --ch-index 0				# max legal power for region

# set limit of hops to max of 7
meshtastic --set hop_limit 7

# 'rotate' display every 120 seconds
meshtastic --set auto_screen_carousel_secs 120

# GPS settings
meshtastic --set gps_update_interval 30					# GPS update interval
meshtastic --set location_share LocEnabled				# GPS Location enabled
meshtastic --set position_broadcast_secs 120			# broadcast interval to other units
meshtastic --set position_broadcast_smart true			# set smart broadcast
meshtastic --pos-fields POS_ALTITUDE POS_ALT_MSL POS_BATTERY POS_SATINVIEW   # set to get altitude, MSL, Battery % and how many sats in view

# WIFI settings
meshtastic --set wifi_ap_mode true
meshtastic --set wifi_password “somepw"	--set wifi_ssid "mesh_9c00"
reset the device via reset switch
  1. Device powered up, and got an ip of 192.168.4.1, let it create the self-signed cert, confirmed via attaching desktop via wifi to AP, and then running ‘arp -a’:
     <user>@iMac27 Meshtastic % arp -a
     ? (192.168.4.1) at 44:17:93:87:9c:1 on en1 ifscope [ethernet]
  1. Had to manually bring up the web page in a browser
  2. Tried to attach via browser to http://meshtastic.local - cannot attach.
  3. Tried to attach via browser to http://192.168.4.1/json/report, and got a report back, part of which is:

{
“wifi”: {
“rssi”: 0,
“ip”: “192.168.4.1”
},
}
Left this device powered on, then moved to 2nd device, and did:

  1. Started with a ‘meshtastic —set factory_reset true
  2. reset the device via reset switch
  3. Ran a “settings” script (same as above, just changed SSID, password left as 1st device)
  4. INTERESTINGLY, the first device became IP 192.168.42.1 - second device became 192.168.4.1 - then powered down both devices, powered them up again, one after the other - BOTH devices had an IP of 192.168.42.1 - and devices connected to each other via radio, and could be seen in the screen(s) that they were connected to each other.
  5. Only ONE AP visible via wifi - the second one. Connected via wifi to it, and an ‘arp -a’ only shows that second device. INTERESTINGLY, within a couple seconds of attaching the the AP - a webpage appears for the second device.

So, both devices are identical, on the same FW release, have been factory reset prior to setting any settings and the only setting difference is the wifi_ssid (different for each device). My intent in the script is to find the unit’s MAC address via ‘meshtastic --info’, by parsing the returned JSON, and having a table that has unique settings based on MACaddr and set them accordingly. The vast majority of settings will be identical between units - just a few differences here and there.

Why set up devices via wifi? Well, I guess I had hoped the web interface was actually ‘built out’ so I could have two devices, connect to their respective AP, and change settings without have to disconnect/reconnect the micro USB. On another thread, I had issues and found that it was loose power connections via USB, and breathing on a device would reset it (it was a headless device, so you couldn’t see anything, and until I got used to the flashing lights, I didn’t realize the unit was being reset so often). That was my hope, but found the web interface has virtually no settings available.

I don’t know if this constitutes a bug or not, as I’m not sure what the software should actually do at this point, but I’d certainly say that sometimes giving the device one IP address, then another, and sometimes both having the same IP is an issue.

Hopefully my steps are repeatable.

13

This is very detailed.

It’s on the list.

Thank you!

1 Like