esp32: espnow improvements

[Laczen]

Summary

The PR proposes improvements to espnow pktradio, it separates the rx from the tx and simplifies the addressing used by espnow for sixlowpan. It also enables future expansion for ciphered data exchange.

Changes:

1. Separate TX from RX,
2. Modify addressing to allow only 2 byte node address.
3. Allow modifying the node address by modifying the ipv6 address (the ipv6 address has a direct relation with the node address)
4. Introduce the option to add a 4 byte random number to the mac header as a preparation for ciphered data exchange.
5. Introduce a FCB (frame control byte) as a replacement for the INFO field in the mac header.
6. Update esp32-devkitc:espnow config to reflect address size change and add telnet.
7. Update the documentation to reflect address size changes and addition of how to do a telnet session over espnow.

Impact

As the introduction of espnow is fairly recent it should have a large impact on users, the setup of espnow nodes is simplified.

Testing

All changes were validated on esp32-devkitc using the espnow config.

[Laczen]

@tmedicci, fyi.

[tmedicci]

Hi @Laczen , thanks for submitting it!

I have no comments regarding the code. The changes are welcomed! But I've found two possible bugs:

1. If I start the client device before the server, the server device halts:
   On client device:

nsh> ifup wpan0
ifup wpan0...OK
nsh> udpclient fe80::ff:fe00:a

On server device:

nsh> ifconfig wpan0 inet6 fe80::ff:fe00:a
nsh> ifup wpan0
ifup wpan0...OK
nsh> 
nsh> (device is halted here, not accepting further commands)

2. Wi-Fi coexistence: as soon as I connect to an AP, the server stops receiving the UDP packets:
   On server device:

nsh> ifconfig wpan0 inet6 fe80::ff:fe00:a
nsh> ifup wpan0
ifup wpan0...OK
nsh> udpserver &
udpserver [6:100]

On client device:

nsh> ifup wpan0
ifup wpan0...OK
nsh> udpclient fe80::ff:fe00:a
client: 0. Sending 96 bytes
client: 0. Sent 96 bytes

Again, on server device, the device stops receiving the UDP packets after connected to the AP. The udpserver is still running. Please note that I rearranged the log output to improve readability:

nsh> server: 0. Receiving up 1024 bytes
server: 0. Received 96 bytes from fe80:0000:0000:0000:0000:00ff:fe00:feff port 5472
server: 1. Receiving up 1024 bytes
server: 1. Received 96 bytes from fe80:0000:0000:0000:0000:00ff:fe00:feff port 5472
server: 2. Receiving up 1024 bytes
server: 2. Received 96 bytes from fe80:0000:0000:0000:0000:00ff:fe00:feff port 5472
server: 3. Receiving up 1024 bytes
server: 3. Received 96 bytes from fe80:0000:0000:0000:0000:00ff:fe00:feff port 5472
server: 4. Receiving up 1024 bytes
server: 4. Received 96 bytes from fe80:0000:0000:0000:0000:00ff:fe00:feff port 5472
server: 5. Receiving up 1024 bytes
server: 5. Received 96 bytes from fe80:0000:0000:0000:0000:00ff:fe00:feff port 5472
server: 6. Receiving up 1024 bytes
server: 6. Received 96 bytes from fe80:0000:0000:0000:0000:00ff:fe00:feff port 5472
server: 7. Receiving up 1024 bytes
server: 7. Received 96 bytes from fe80:0000:0000:0000:0000:00ff:fe00:feff port 5472
server: 8. Receiving up 1024 bytes
server: 8. Received 96 bytes from fe80:0000:0000:0000:0000:00ff:fe00:feff port 5472
server: 9. Receiving up 1024 bytes
server: 9. Received 96 bytes from fe80:0000:0000:0000:0000:00ff:fe00:feff port 5472
server: 10. Receiving up 1024 bytes
nsh> wapi psk wlan0 mypasswd 3
nsh> wapi essid wlan0 myssid 1
nsh> renew wlan0
nsh> ps
  PID GROUP PRI POLICY   TYPE    NPX STATE    EVENT     SIGMASK            STACK COMMAND
    0     0   0 FIFO     Kthread   - Ready              0000000000000000 0003056 Idle_Task
    1     0 100 RR       Kthread   - Waiting  Semaphore 0000000000000000 0004024 lpwork 0x3ffc0db8 0x3ffc0de8
    2     2 100 RR       Task      - Running            0000000000000000 0003024 nsh_main
    3     0 223 RR       Kthread   - Waiting  Semaphore 0000000000000000 0001992 rt_timer
    4     0 253 RR       Kthread   - Waiting  MQ empty  0000000000000000 0006624 wifi
    5     5 100 RR       Task      - Waiting  Semaphore 0000000000000000 0004056 telnetd
    6     6 100 RR       Task      - Waiting  Semaphore 0000000000000000 0004040 udpserver

[Laczen]

Hi @tmedicci thanks for your remarks,

Regarding item 1: I think the udpclient & server test program are meant to be started when the link is up and there might be an init problem when data is already coming in when the program is started. I have not verified how good they are.

Regarding item 2: The same as above, but on top of this: if the ap is using a different wifi channel than the espnow channel, the espnow channel will change on the server and the connection will be lost. Espnow can only coexist with wifi when the same wifi channel is used. BTW I am trying to be able to setup espnow without the wlan0 interface, but this seems to be not so straight forward.