ESP-NOW - receiving even if MAC address is not added to peer list

[volentiae]

Versions: MicroPython 1.22.1, Thonny 4.1.4, ESP32-WROOM-32D

I am running the small ESP-NOW examples found here: https://docs.micropython.org/en/latest/library/espnow.html on two different ESP32s.

However, the receiver receives messages from the transmitter. The peer address added to transmitter is NEITHER a broadcast address NOR the address of the receiver.

What am I doing wrong or have misunderstood?

TIA

[glenn20]

@volentiae - its a little hard to understand what you are doing here. One thing I have occasionally found useful is to double check just what peers the transmitter thinks have been registered by inserting print(e.get_peers()) before you start transmitting messages.

If you could post your code snippets it might help me understand what is happening. (Remember to follow the guidelines for posting code in https://github.com/orgs/micropython/discussions/9111).

[volentiae]

Sure, here is the sender code

import network, espnow, time

# A WLAN interface must be active to send()/recv()
station = network.WLAN(network.STA_IF)  # Or network.AP_IF
station.active(True)

esp_now = espnow.ESPNow()
esp_now.active(True)
peer = b'\xbb\xbb\xbb\xbb\xbb\xbb'   # MAC address of peer's wifi interface
esp_now.add_peer(peer)      # Must add_peer() before send()

esp_now.send(peer, "Starting...")
for i in range(10000):
    esp_now.send(peer, str(i), True)
    time.sleep(1)

It doesn't matter what MAC address is added for the peer, the messages are still received and displayed by the receiver.

Here is the receiver code

import network, espnow

# A WLAN interface must be active to send()/recv()
station = network.WLAN(network.STA_IF)
station.active(True)

esp_now = espnow.ESPNow()
esp_now.active(True)

while True:
    host, msg = esp_now.recv()
    if msg:             # msg == None if timeout in recv()
        print(host, msg)

It looks to me as if all transmissions are made using the broadcast address irrespective of the address added.
print(esp_now.get_peers()) returns empty.

[glenn20]

Thanks. When you say "empty", do you mean None or () or something else?

Did you add the print(esp_now.get_peers()) after esp_now.add_peer(peer) on the sender?

[glenn20]

One more thing to try... are messages still received if you change the mac address on the sender from b'\xbb\xbb\xbb\xbb\xbb\xbb' to b'\x01\x01\x01\x01\x01\x01'?

[glenn20]

Whoops - I mean b'\xfe\xfe\xfe\xfe\xfe\xfe'. I am guessing the problem MAY be due to a poor choice of example mac address by me in the docs. b'\xbb\xbb\xbb\xbb\xbb\xbb' happens to be a multicast mac address.

[volentiae]

The print(esp_now.get_peers()) was inserted in these places:

import network, espnow, time

# A WLAN interface must be active to send()/recv()
station = network.WLAN(network.STA_IF)  # Or network.AP_IF
station.active(True)

esp_now = espnow.ESPNow()
esp_now.active(True)
peer = b'\xbb\xbb\xbb\xbb\xbb\xbb'   # MAC address of peer's wifi interface
esp_now.add_peer(peer)      # Must add_peer() before send()
print(esp_now.get_peers())

esp_now.send(peer, "Starting...")
for i in range(10000):
    print(esp_now.get_peers())
    esp_now.send(peer, str(i), True)
    time.sleep(1)

The following MAC addresses have been tested
b'\xbb\xbb\xbb\xbb\xbb\xbb'
b'\xab\xcd\xef\x01\x23\x45'
b'\x01\x01\x01\x01\x01\x01'
b'\xA1\xB2\xC3\xD4\xE5\xF6'
and all are received and printed by the receiver
b'\xfe\xfe\xfe\xfe\xfe\xfe'
b'\xc8\xf0\x94\x4e\xb7\x58'
is not received

print(esp_now.get_peers()) vs the MAC address shows different results
b'\xbb\xbb\xbb\xbb\xbb\xbb'
The result is visible as ()
b'\xab\xcd\xef\x01\x23\x45'
The result is visible as ()
b'\xA1\xB2\xC3\xD4\xE5\xF6
The result is visible as ()
b'\x01\x01\x01\x01\x01\x01'
The result is visible as ()
b'\xfe\xfe\xfe\xfe\xfe\xfe'
((b'\xfe\xfe\xfe\xfe\xfe\xfe', b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 0, 0, False),)
b'\xc8\xf0\x94\x4e\xb7\x58'
((b'\xc8\xf0\x94N\xb7X', b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00', 0, 0, False),)

So some addresses can bypass the receiver's MAC address. Those MAC addresses that can bypass are more than the ones listed above I know from testing with a group of people. However, I cannot remember which ones.

[glenn20]

Yes, any mac address with the least significant bit of the left-most byte set is a multicast mac address. These are treated similarly to broadcast addresses by the underlying ESPNOW implementation - ie. they will not be returned by esp_now.get_peers() and they will be responded to by listening clients.

[volentiae]

Hmmm, OK. My understanding was that ESP-NOW does not offer Multicast, that is enabled by bit 0 of the MSB.

It is probably a good idea to change the example MAC address, currently BB:BB:BB:BB:BB:BB which is a Multicast, to one in the recommended ranges
00:00:5E:00:53:00 to 00:00:5E:00:53:FF
00:50:C2:00:00:00 to 00:50:C2:FF:FF:FF

Re esp_now.get_peers(): to me it sounds a bit weird, that Broadcast and Multicast don't respond in the same way as Unicast.

Question: Is there a way to see if the received frame is a Broadcast, Multicast or Unicast except adding an indicator to the message payload?

[glenn20]

Hmmm, OK. My understanding was that ESP-NOW does not offer Multicast, that is enabled by bit 0 of the MSB.

Yeah, the multicast capabilities of espnow are not well documented.

It is probably a good idea to change the example MAC address, currently BB:BB:BB:BB:BB:BB which is a Multicast, to one in the recommended ranges 00:00:5E:00:53:00 to 00:00:5E:00:53:FF 00:50:C2:00:00:00 to 00:50:C2:FF:FF:FF

Yes, the example was meant to be a dummy mac address that you should replace with your own device's mac address. I wasnt thinking about multicast when I wrote that. I'll think about submitting a PR to fix it.

Re esp_now.get_peers(): to me it sounds a bit weird, that Broadcast and Multicast don't respond in the same way as Unicast.

I think I understood why they did it that way some time in the past... but I have forgotten now 🤔 (see here).

Question: Is there a way to see if the received frame is a Broadcast, Multicast or Unicast except adding an indicator to the message payload?

Yes, espressif added a new field in the recv callback in v5.0 of the IDF which includes the destination address. Passing that through to the micropython api for every received message would have broken the existing api, consume another 6 bytes for each received message and would be of no interest in the great majority of cases. If there is a good case for adding it, I'd be happy to consider it. Of course, anyone can independently submit a PR to add it as well.

Personally, if I am sending a broadcast (or multicast) message to my devices, it is usually obvious from the messaging content/protocol (eg. time sync messages, service advertising, ota update availability, etc.).

[volentiae]

It seems as if this test can check if the address is not bypassing the receiver's MAC address

if len(esp_now.get_peers()) == 0:
    print("Dubious MAC address")

Except that is also becomes true for the broadcast address FF:FF:FF:FF:FF:FF. However, there must be an underlying issue somewhere I think.