My specific question is, are there limitations or restrictions in Micropython and/or Pico in regard to using static IP addresses?
I ask because I’ve recently had to two very different applications where the code would fail using static, but work fine using DHCP.
The first was getting a json file from currentuvindex.com. The code works fine when connected using DHCP but fails when connected with a static IP. At first I thought the issue was DNS related and so I tried different DNS servers, no luck. Maybe it was my router settings so I bypassed that by using my mobile as a wi-fi hotspot, same issue.
The second was testing some code for uMail as an SMTP client for sending emails using MicroPython. The email will not send when on a static IP.
def do_connect(ssid=secrets['ssid'],psk=secrets['password']): # Gets the info from the secrets.py
print("do_connect.py says do_connect is called")
wlan = network.WLAN(network.STA_IF) # Initialize the Wi-Fi interface.
wlan.active(True) # Activate the interface.
# Set a static IP configuration
static_ip = '192.168.0.61' # Desired IP address
subnet = '255.255.255.0' # Subnet mask
gateway = '192.168.0.1' # Gateway IP
dns = '8.8.8.8' # 8.8.8.8 is Google. 202.142.142.142 is Aussie Broadband's DNS.
wlan.ifconfig((static_ip, subnet, gateway, dns))
# Connect
wlan.connect(ssid, psk)
# print(wlan.isconnected()) # Check the connection status.
# Wait for connect or fail
wait = 10
while wait > 0:
if wlan.status() < 0 or wlan.status() >= 3:
break
wait -= 1
print('do_connect.py says waiting for connection...')
time.sleep(1)
# Handle connection error
if wlan.status() != 3:
raise RuntimeError('do_connect.py says wifi connection failed')
Hi.
What if you use your public facing IP address not your private IP?
Does it help?
Just a thought. I figure it’s the public IP that is static after all.
I’ve reserved IP addresses in the router for my Picos using their MAC addresses so I can work around this although its still a niggle I’d like to fix or have an answer for.
One thing I did find though is my use of Wi-fi extenders. I have two d-link extenders and the Picos connected to these. By default the extenders have DHCP set to Auto with a predetermined IP address range. So even though I’d reserved addresses in the router, these were outside the extender’s range. I turned DHCP OFF in the extenders and the Picos then acquired the addresses reserved in the router. The d-link documentation is very vague of this issue.
My preference/recommendation is to manage static addresses on the network device, single point of governance. Does not mean I wouldn’t be also trying to get the damn code to work.
Dual DHCP servers as a concept its not good nor bad in its own right.
The trick it to ensure they are
a) All have the same gateway/dns etc that you want them to use
b) dont have overlapping pools
c) ensure any fixed/static leases are on both.
If all your devices are on the one flat network/vlan, then there is no need to have more then one DHCP server outside of a backup, so turning them off should not cause any issues (if on one network/vlan).
DHCP 101
Client wakes up and connects to a new network
Cleint sends DHCP Discover.
Every DNS server on that vlan will respond
At this point its up to the client to pick “1” and then request an IP address from that dhcp server.
If the client already has an IP (same devices will cache when turned off, others wont) e.g. lease expires (or is >= 50% of the lease life)
Client will request to renew its IP from the same DHCP server it got it from.
So a device that is on 24/7 should be sticky to the one DHCP server. If that DHCP server does not respond, the client can drop back to the discover and start again.
the main thing to avoid if using 2 or more DHCP servers is lease overlap.
e.g. DHCP 1 and 2 are working and both have the same pool to hand out.
DHCP 1 issues 10.0.0.10 to Client A
Client A is turned Off, but the lease is still valid.
DHCP 1 has an issue and stops responding.
Client B requests and IP and DHCP 2 hands out 10.0.0.10
i.e. it does not know its been leased from DHCP1, nor does the ping test work as Client A is off and the final ARP check from Client B is ok as Client A is off.
Now client A is turned on and keeps using the IP as it was given, as the lease has not yet expired.
At this point you have 2 devices with the same IP cause all sorts of nice Layer 2 issues for you
From this thread I think the consensus is that its not so much that there’s limitation or restrictions, rather its more complex that one would think and it’s far simpler to reserve an address in the router (all you need is the MAC address)?
If it’s possible to let the router handle it then yes that’s always the best option has worked for me in the past in vanilla python.
If the code is meant to work from an arbitrary router then MAC address or the public address might be required.
Unless it’s gear such as a NAS (which hosts SANs etc) or a box that hosts a type 1 Hypervisor, etc, then it’s almost always best to let your router manage IPs. Configure a static IP on the router, ideally outside the DHCP range.
If the device changes, on the router, release the static IP for the old MAC address, and then set the IP of the new device to be the same. A reboot that power cycles the NIC is often needed for DHCP to flush properly, and then it’ll always be the same from then on.
There are lots of different things mixed together here.
I’d say find a simple Micropython ping implementation and test with that.
Get that to work first with dchp then later test with a static ip.
There may be a bug somewhere in Micropython but I doubt it. Static or dynamic IP assignment at the network level should make zero difference at the application level. Keep it simple and then add stuff one at a time.
Dave
