usocket didn't find SO_BROADCAST

[chaopi]

I try using micropython with esp32 board to make a WOL server to wake up my PC. I found that I need codes like

Code: Select all

from socket import socket, AF_INET, SOCK_DGRAM, SOL_SOCKET,  SO_BROADCAST
# defind data, ip ...
sock = socket(AF_INET, SOCK_DGRAM)
sock.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)
sock.sendto(data, (ip, 9))
sock.close()

But I found that socket didn't constant SO_BROADCAST.
Is there any way to make WOL work micropython?

thanks all.

[dahult]

This is not a direct answer to Chaopi's question but additional info and a related request for help. The SO_BROADCAST option has not been in the socket library since at least 1.9.4. Even though most socket examples show setting the socket option for broadcasts, I have been able to send and receive broadcast packets since uPython version 1.9.4 on ESP8266's and ESP32's using the following code:

Sender:
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.sendto(msg, ('10.0.49.255', 1926))

Recvr:
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('10.0.49.255', 1926))
while True:
msg, addr = s.recvfrom(1024)
print(msg, addr)

[NOTE: The address ('10.0.49.255', 1926) are the broadcast IP address and PORT I am using for my network. Your values must be
changed to meet your network. The broadcast IP address is set up by your network configuration but the PORT can be any number
(typically > 1024) just needs to be the same for all senders and receiver(s).

I have been using the above code for well over a year without problem until I re-flashed the receiver with version 1.12. The sender code continues to work fine and works on ESP8266's and ESP32's with 1.12 but the receiver code has stopped working entirely. The s.recvfrom() sits in a wait-state and never returns anything. I know the broadcast packets are being sent out because the same receiver code does work on a Raspberry Pi running Debian/Buster (even without the s.setsockopt(SOL_SOCKET, SO_BROADCAST, 1)).

So my question to add to Chaopi's is why did my broadcast receiver stop working? I did try re-flashing the receiver back to 1.9.4 (esp8266-20180511-v1.9.4.bin) but the receiver still sits waiting on s.recvfrom().

Any ideas/help is appreciated.

Doug

[chaopi]

thank you.

[dahult]

Update on my post. The Recvr code I posted earlier does work on micropython 1.12 (both the Sndr and Recvr broadcast code work fine). At the same time I upgraded my esp32's and esp8266's to 1.12 I also I replaced my network eqpt with a Unify Dream Machine (router, switch & access point all in one). I had an old Apple Time Machine I connected up as an access-point and connected the esp8266 I have been using a the broadcast receiver to it and broadcast traffic is coming through fine.

I contacted support at Ubiquity because on top of getting no broadcast traffic coming through, my Ubiquity network has been dropping connections to my Raspberry Pi's. I told the support guy that I was losing connections and could not ssh into my clients. He asked what type of clients and when I told him they were Raspberry Pi's he immediately said they will not help with anything to do with Raspberry Pi's and tried to end the support call right there. When I told him that it was not only ssh problems by http problems and I couldn't even ping the clients even though they show up on the Ubiqity config manager as working fine with 100% wifi signal. After asking for some screen shots and config files he said that he could not fix this at Level 1 and was going to send it up to Level 2. That was yesterday and I'm not holding my breath.

If you are on this forum you probably have an interesting mix of devices on your network. If you do, don't buy any Ubiqity equipment. They seem to only want to support corporate networks where there is a lot of control (i.e., little variety) on the devices on their network.