EmonPi not respecting DHCP-assigned IPs

Orionn · 2019-01-26T20:50:51.322Z

My wifi to my EmonPi has always been patchy, and sometimes instead of getting the correct IP (192.168.1.222, which is assigned by the dd-wrt router), it gets a different IP from the DHCP pool (e.g. 192.168.1.100). It doesn’t come up in the list on the router (Status>LAN or Status>Wireless).

So to overcome the patchy wifi into the meter box, I just installed powerline adapters and am now connecting over the LAN/eth0 port, and I’m getting the exact same thing. I’ve got the MAC address listed in the dd-wrt router to assign 192.168.1.222 to the eth0 port (and .223 to the wifi), but for some reason it keeps getting 192.168.1.109 on eth0.

I tried setting the wlan IP statically, but emoncms didn’t load properly (I can’t remember the exact error message).
/etc/network/interfaces looks like this:

# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet manual
   wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
iface wlan0 inet dhcp

# GSM 3G Hi_Link USB modem
allow-hotplug eth1
iface eth1 inet dhcp

ifconfig -a looks like this:

eth0      Link encap:Ethernet  HWaddr b8:27:eb:55:70:1e
          inet addr:192.168.1.109  Bcast:192.168.1.255  Mask:255.255.255.0
      inet6 addr: fe80::ba27:ebff:fe55:701e/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:8625 errors:0 dropped:0 overruns:0 frame:0
      TX packets:2039 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:608923 (594.6 KiB)  TX bytes:495945 (484.3 KiB)

lo        Link encap:Local Loopback
      inet addr:127.0.0.1  Mask:255.0.0.0
      inet6 addr: ::1/128 Scope:Host
      UP LOOPBACK RUNNING  MTU:65536  Metric:1
      RX packets:209442 errors:0 dropped:0 overruns:0 frame:0
      TX packets:209442 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1
      RX bytes:96972068 (92.4 MiB)  TX bytes:96972068 (92.4 MiB)

wlan0     Link encap:Ethernet  HWaddr b8:27:eb:00:25:4b
      inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0
      inet6 addr: fe80::79c:8bce:5d2:f4b3/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:425 errors:0 dropped:0 overruns:0 frame:0
      TX packets:42 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:56993 (55.6 KiB)  TX bytes:9820 (9.5 KiB)'

DHCP assignments on my dd-wrt router look like this:

dhcp%20pool732×147 4.8 KB

Oh, and everything else on my network obeys the DHCP assignments, it’s just the emonpi that plays up.

Bill.Thomson · 2019-01-26T21:04:43.959Z

Silly question… Have you disabled the DHCP server inside dd-wrt?

e.g.

image1026×868 41.5 KB

Disabled here - - - - - - - - - - - - - ^

Is there another DHCP server on your LAN?

borpin · 2019-01-26T23:36:08.244Z

Couple of thoughts…

Do you see the correct mac address assigned to the wrong IP in the DHCP server?
Have you tried rebooting the router/DHCP server with the EmonPi off network.
Is IPv6 enabled?
What version of the SDCard are you running (Jessie or Stretch)?

Try increasing the lease time of these 2 and, if you can, expire the lease of the IPs causing the problem, ideally with the EmonPi off network.

I’d want to disable the WiFi if it is not being used but I do not know how to do that.

Orionn · 2019-01-27T01:30:08.763Z

OK, facepalm. I was about to explain how my DHCP server isn’t actually the gateway, but then I checked the gateway and I had left it’s DHCP server on. So the gateway was assigning the IP to the EmonPi. I turned off the DHCP server on the gateway, and now everything’s working fine.

That explains why the EmonPi would sometimes get the right IP, and sometimes not. But it doesn’t explain why the 15-20 other devices that come and go always have the right IP. Oh well, the problem’s solved, best not to fall down a rabbit hole.

Thanks for your help, Bill & Brian.