ESP01S + AT commands to enable incoming data from any local IP

Before asking my question i'll "briefly" describe what i'm trying to achieve.

I'm making some sort of domotics local network, in which there is a server, 3 to 4 tablets, and many sensors and actuators (like lights, PIR, temperature sensors, watering stations, window blinds, doorbells, etc...)

when you start up the devices they connect to the local server with a fixed IP (only the server has a fixed IP, the rest gets a dynamic one)
and those devices send an introductory packet to present their IP, MAC, task, name and if this device was already connected previously or not and to which slot it was allocated on the server.
after the intruduction is complete they disconnect from the server (close the TCP port) to allow other devices to do the same procedure because the ESP01S i'm using has a maximum number of server connections set to 4.

so at this point, after all the devices presented themselves, i connect one of the tablets to the server and i get a list of all the available devices with their respective IPs...

but here's the tricky part... now i want to send a data packet to a device from the list, so now i have his IP... and i know how to send the data from the tablet... but I just dont know the correct way to open a connection on the receiving device to which any IP can send data.

an alternative would be opening a permanent UDP connection on the receiving device with the server IP, and instead of sending data from the tablet to the device, you would have to send it to the server and then the server must redirect it to the right device trough a new UDP connection.

on another note, by testing some stuff, i found that if you open let's say and UDP connection with a random IP, you can get UDP data packets even from other IPs... but i don't believe this is the right way to go because of the unknown issues that may arise, example (ACTUAL OUTPUT):


device_1:
AT+CIFSR

+CIFSR:STAIP,"192.168.1.16"
+CIFSR:STAMAC,"50:02:91:da:5a:a8"

OK
AT+CIPSTART="UDP","192.168.1.15",8000,8001

CONNECT

OK
AT+CIPSEND=5

OK

busy s...

Recv 5 bytes

SEND OK


device_2:
AT+CIFSR

+CIFSR:STAIP,"192.168.1.15"
+CIFSR:STAMAC,"50:02:91:da:5b:4a"

OK
AT+CIPSTART="UDP","192.168.1.100",8001,8000

CONNECT

OK

+IPD,5:TEST


from the example above i opened an UPD connection with IP 192.168.1.100, but got data from IP 192.168.1.16... what is that about?

which version of the AT firmware?

AT+GMR

AT version:1.1.0.0(May 11 2016 18:09:56)
SDK version:1.5.4(baaeaebb)
compile time:May 20 2016 15:08:19
OK

yes. this is how UDP in AT works. for listening, the IP address is ignored. it is not intended to filter out messages.
you can use AT+CIPDINFO to get the senders IP address (at least in AT 1.7. I don't know about 1.1)

well my concern is not really finding from what IP my data comes from, it was more about enabling reception of incoming packets, so what i'm getting from your response is that i theoretically could open an UDP connection to my own IP (or the server IP for what it matters) and could possibly get an incoming UDP packet from any IP on the network?

the sender IP is not a concern because it is included in every trasmitted packet, because this system also provides anti intrusion protections (home security), and the IP with other parameters is used to calculate an encrypted data portion to check the command validity, so even if i send a packet from a correct IP, if i don't know how to calculate the security question, it is flagged as invalid.
plus if i fake the sender IP, the response will be sent to the IP I specified in the packet, not really to the sender, to avoid external data retrieval.

last question, if you know the answer, otherwise i'll need to test this:
since the router changes the IP every X minutes... will the UDP connection i set remain active, or will it close itself when an IP change occurs?
like just now i got these messages on every ESP module connected right now:

WIFI DISCONNECT
WIFI CONNECTED
WIFI GOT IP

i guess that it is the DHCP timeout?

in TCP/IP there is a listening port TCP or UDP. there is no filter. any device can connect to a web server and any device can send an UDP message to a listening port.
In TCP/IP stack implementations UDP doesn't start a listening port when sending a message, but the AT fw is not designed right in this matter. so you have to first start a 'connection' (which listens), before using CIPSEND.

the router shouldn't change the IP address

so my assumption was correct?
i just need to start listening to UDP incoming data by opening an UDP connection to any IP (because the AT software requires it, not because this is the norm)

and by router changing IPs i meant the IPs of the connected devices, not the router itself, isn't this called DHCP timeout? where an IP address remains "reserved" for a certain device for a certain amount of time saved on the router? and when that time passes I don't exactly know what happens other than the fact that if a device is disconnected, the next time it connects it gets a new IP address... but what about a device that is connected when the timeout happens?

when that happens i get the WIFI DISCONNECTED messages on all ESPs connected right now... but still the IPs dont change...
also i get the same messages on the server with fixed IP, but then again it stays with the correct fixed IP

DHCP lease expires but the device can/should request renewal of the lease time for the same IP.

in my WiFiEspAT library WiFiUDP.begin is implemented like:

uint8_t WiFiUDP::begin(uint16_t port) {
  if (linkId != NO_LINK) {
    stop();
  }
  linkId = EspAtDrv.connect("UDP", "0.0.0.0", port, this, port);
  listening = (linkId != NO_LINK);
  return listening;
}

and i guess that is the reason all the devices keep the same ip till i turn them off, but the what might be the WIFI DISCONNECTED / CONNECTED / GOT IP messages be? do they really lose connection momentarily or do they simply renew the DHCP lease? i'm asking this because it could cause some issues if it really disconnects randomly, because i could be pinging that device or sending a packet that would be lost i guess.

so it basically creates an UDP connection to IP 0.0.0.0, cool!

the disconnection maybe caused by a weak signal or not sufficient powering. it is not normal

I was thinking lately.... why use CIPSERVER which limits the TCP connected devices to 4, when i could use CIPDINFO to display the incoming IP of UDP messages from any source since opening an UDP connection listens to data incoming from any IP?

is there really any benefit on using CIPSERVER?

basically if I do this:

AT+CIPDINFO=1
AT+CIPMUX=1
AT+CIPSTART=0,"UDP","0,0,0,0",0,8001

I will start listening to incoming UDP packets on port 8001 from any IP, and the +IPD output will tell me the IP and port of the device that sent me the data.
and since I enabled CIPMUX i could simply do this to reply, again, to any device on the network:

+IPD,0,6,192.168.1.24,8000:TEST //incoming data
AT+CIPSTART=1,"UDP","192.168.1.24",8000 //open new UDP connection on link 1
//(without UDP local port, because i will not be receiving any data on this link, it is for transmission only)
AT+CIPSEND=1,6 //send data on link 1
>TEST\r\n
Recv 6 bytes
SEND OK
AT+CIPCLOSE=1

this way i will use only 2 connections out of the 4 maximum from CIPMUX for internal network communication, and i could use one more to fetch data online like time/date/weather, and the last one could be used for remote control over the internet.

instead if I use CIPSERVER i will need to try to connect multiple times if all 4 slots from CIPMUX are full because it will return a connection error... this could also be used as an attack to hinder communication between modules (if i connect to all 4 slots and remain idle or send garbage), which i would need to create defences for.

but here's another question... since my devices are powered up together, they will technically try to connect to the server (at startup) at the same time, will that cause any issues since they are all sending data to the same IP and PORT? or will the server get all separate entries correctly?

AT+CIPSERVER start a listening port for TCP. so it will create a TCP connection between the device initiating the connection and the device with the listening port.
A TCP connection has guarantied delivery of packets.
UDP is "send one packet and forget".

I get that UDP is less secure in terms of delivery, but since the whole network will work on an DATA + ACK schedule, i shouldn't worry about packet loss, i'm currently still developing it but the idea is this:

client: sends packet to server, with header indicating type of data
server: responds with a security question, which the client must answer otherwise the previous packet will be discarded
client: responds to security question, and if it is correct the previous packet will be parsed by the server
server: sends ACK and any response data that the client may have requested
client: if data was requested send ACK, otherwise it ends here

if at any of this steps the client or server takes too much time to respond, it will re-send the same packet a couple times more, if there is still no response, drop the communication.
also if the security question fails, it is up to the client to try again from the start.


forgot to add that both the ACK and security question/answer contain a checksum based on the incoming packet, so if the packet if corrupted the ACK/question/answer will be invalid and the packet discarded

even better i could open CIPSERVER on the client instead of the server and instead of opening an UDP connection from the server i could simply open a TCP one, the result is the same


edit:
but opening CIPSERVER on the client will again enable the possibility of the full CIPMUX slots and the incoming connection being refused, for which i will need once more to put measures against...

also will this be an issue?
I cannot try it right now because i'm still developing the server part of the network, and i have only one working client at the moment

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.