ChuckMash

Looks like this is already supported anywhere you would be setting an IP, just set the domain instead. https://github.com/knolleary/pubsubclient/blob/master/src/PubSubClient.cpp#L118-L127 https://github.com/knolleary/pubsubclient/blob/master/src/PubSubClient.cpp#L715-L719

Yep, looks like keepalive 0 is not correctly respected. Try changing the following line https://github.com/knolleary/pubsubclient/blob/2d228f2f862a95846c65a8518c79f48dfc8f188c/src/PubSubClient.cpp#L373 to ``` if (((t - lastInActivity > this->keepAlive*1000UL) || (t - lastOutActivity > this->keepAlive*1000UL)) &&...

Receiving encrypted ESP-NOW messages is now supported, but sending is not yet. Possibly related to needing AAD/MIC calculation. AAD/MIC may also benefit validating received encrypted messages.

If the issue is the 8 byte MIC validation, it is made worse by the failing the validation check of received messages. ```python def callback(from_mac, to_mac, msg): packet = espnow.packet...

Compiled ESP-IDF from source with modified debug and ccmp.c to track through AAD and MIC. Unable to see output of DEBUG statements in ccmp.c.

List of potentially helpful links found so far. This comment will be updated * https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_now.html#security * https://github.com/espressif/esp-idf/blob/master/components/wpa_supplicant/src/crypto/ccmp.c * https://en.wikipedia.org/wiki/CCMP_(cryptography) * https://praneethwifi.in/2020/05/02/ctr-with-cbc-mac-protocol-ccmp-aes-ccmp/ * https://stackoverflow.com/questions/70814579/need-assistance-aes-ccm-decryption-of-an-802-11-payload-using-python-pycryptodom * https://github.com/espressif/esp-idf/blob/master/components/wpa_supplicant/src/crypto/aes-ccm.c#L179 * https://mrncciew.com/2014/08/19/cwsp-ccmp-encryption-method/ * https://github.com/stryngs/pyDot11/blob/main/SRC/pyDot11/pyDot11/lib/ccmp.py *...

I'm not sure, scapy is at the heart of everything, so I'm tempted to say the source of the issue is there. Using another computer, or interface, does wireshark pick...

Can you check with scapy version 2.5.0? This yields an error for me ``` raise Scapy_Exception("Unsupported address family (%i) for interface [%s]" % (addrfamily, iff)) # noqa: E501 scapy.error.Scapy_Exception: Unsupported...

Ah, The issue for me with this is after my interface is put into monitor mode, the previous error occurs. If I skip prep.sh then it works correctly, but then...

I have not tested the effects of data rates on latency. Is this with broadcast or unicast address? If unicast, latency spikes may be related to the underlying layer2 retransmission...