DHCP request for unknown address: 0.0.0.0

binderth · December 26, 2017, 7:27pm

this one appears in openhab.log every 4mins or so:

<<REBOOT>>
2017-12-26 20:10:02.823 [INFO ] [ternal.dhcp.DHCPPacketListenerServer] - DHCP request packet listener online
2017-12-26 20:13:59.201 [INFO ] [work.internal.dhcp.DHCPListenService] - DHCP request for unknown address: 0.0.0.0
2017-12-26 20:17:40.132 [INFO ] [work.internal.dhcp.DHCPListenService] - DHCP request for unknown address: 0.0.0.0
2017-12-26 20:23:58.376 [INFO ] [work.internal.dhcp.DHCPListenService] - DHCP request for unknown address: 0.0.0.0
2017-12-26 20:27:40.364 [INFO ] [work.internal.dhcp.DHCPListenService] - DHCP request for unknown address: 0.0.0.0

I’m not sure, from which binding this comes, but I suspect network binding…
Strange thing: this one didn’t come up, since I today forced another update von tha already running OH2 (sudo apt-get install --reinstall openhab2).

i use networkbinding for presence like this - of course no 0.0.0.0 device somewhere…:

Thing network:pingdevice:handy-andrea 		[ hostname="192.168.xx.xx", retry=3, timeout=5000, refresh_interval=60000, allowSystemPings="true", allowDHCPlisten="true" ]
Thing network:pingdevice:handy-thomas 		[ hostname="192.168.xx.xx", retry=3, timeout=5000, refresh_interval=60000, allowSystemPings="true", allowDHCPlisten="true" ]
Thing network:pingdevice:handy-sarah 		[ hostname="192.168.xx.xx", retry=3, timeout=5000, refresh_interval=60000, allowSystemPings="true", allowDHCPlisten="true" ]
Thing network:pingdevice:handy-david	 	[ hostname="192.168.xx.xx", retry=3, timeout=5000, refresh_interval=60000, allowSystemPings="true", allowDHCPlisten="true" ]

Thing network:pingdevice:TV-Samsung	 	[ hostname="192.168.xx.xx", retry=3, timeout=5000, refresh_interval=60000, allowSystemPings="true", allowDHCPlisten="true" ]
Thing network:pingdevice:TV-Sony		[ hostname="192.168.xx.xx", retry=3, timeout=5000, refresh_interval=60000, allowSystemPings="true", allowDHCPlisten="true" ]
Thing network:pingdevice:TV-Onkyo	 	[ hostname="192.168.xx.xx", retry=3, timeout=5000, refresh_interval=60000, allowSystemPings="true", allowDHCPlisten="true" ]
Thing network:pingdevice:TV-WiiU		[ hostname="192.168.xx.xx", retry=3, timeout=5000, refresh_interval=60000, allowSystemPings="true", allowDHCPlisten="true" ]

rlkoshak · December 27, 2017, 7:41pm

That’s the one.

So, 0.0.0.0 is a non-routable address and it can have different meanings based on the context. When a device is not connected to a network, some devices will assign themselves the address 0.0.0.0. Some software and hardware like routers of those that work with multiple networks will use 0.0.0.0 to address all the connected networks.

In this case, I suspect what is happening is you have one or more devices on your network that is having difficulty joining your network. When the network first comes up it will send out a request to the DHCP server and since it doesn’t have an address yet it is using 0.0.0.0 in that request.

cgeo · January 10, 2018, 7:58pm

Rich is right. A device will use the address 0.0.0.0 only when it is coming up online with no ip address and it needs to send a broadcast on the network so that the dhcp will give it an ip address. So before it gets an ip address it will use the address 0.0.0.0

I have the same and I investigated a bit to see what exactly causes this.
I have my own DHCP server and a wireshark capture reveals this

I have a foscam camera with a static ip address and for some reason the DHCP sends a NAK for every renewal request. I am assuming that there is something specific with that camera because none of the other devices on my network have such an issue. Maybe it should not request a renewal every 10 mins or so. But as far as I can see it is only cosmetic because the camera still keeps its ip address.

I am assuming that if you find your device and you give it a static ip address you will no longer see those messages. It must be something new because the camera is online for months and this only started recently. Maybe something changed in the latest version of the binding

binderth · January 10, 2018, 8:20pm

could you Point me to a wireshark howto, to find out from which MAC-Adress those requests come from? Opening wireshark is a bit overwhelming for the first time!

cgeo · January 10, 2018, 8:26pm

Easy

You click on the packet you want to analyse. In the pane just below the packet capture you get all the details of the selected packet

You can already see the mac address in the Ethernet II section (marked in yellow). You can also expand it so that you can see more info.

Let me know if this does not make sense to you

edit: if you want to filter only the dhcp packets you can put in the filter section the string bootp so that you only see dhcp packets

binderth · January 10, 2018, 10:00pm

Thanks. I’ll try!

binderth · January 12, 2018, 9:06am

I know, it’s not OH2 related, but as you seem to know your stuff!

I’m pretty much surprised to see this:

This one is my Samsung S8 asking for my Fritz.box!

and this one:

This one is my openHAB2 asking for some random(?) IP-address (192.168.xx.54 isn’t registered in my DHCP-Server at the time).
later my OH2 asks two times within milliseconds about the IP of my Nintendo WiiU (not online at that time) - only this time it is the same IP-address, but a complete different FQDN:

(all of this entries will have the entry in the log:

2018-01-12 09:53:48.332 [INFO ] [work.internal.dhcp.DHCPListenService] - DHCP request for unknown address: 0.0.0.0

PS. lastly I got those strange entries (not sure, which of them resulted into the 0.0.0.0 entry:

Is my FritzBox not configured?

cgeo · January 12, 2018, 9:21pm

First of all in order to match the timestamps you will need to go to Wireshark --> View --> Time Display Format --> Time of day. This way you will have the exact time the packet is intercepted on your wireshark PC.

Now your screenshots are not displaying DHCP messages but arp requests. I doubt these are related to the log for DHCP.

In short what is an arp request ? In this case, your samsung or your openhab have received a packet with a destination ip address that they need to route in the local network. In order to route it in the local network they need to map that ip address to an ethernet address (which is the mac address). Normally they have an arp table that associates a local ip address with the mac address. If the packet has a destination for which they do not have a corresponding mac address they will send a broadcast to your subnet (broadcast is always sent to 255.255.255.255 asking for the mac address that corresponds to the destination ip address). That is an arp request and that’s what your screenshots are about
Normally you should have an arp reply with the destination mac address so that the packet can be routed.

But as I said you should be looking for DHCP messages. To make it easier for you, you can filter on the bootp messages

binderth · January 13, 2018, 7:38pm

Thanks for helping me here. I do have loads of thos arp requests - even my Laptop sends those frequently (and redundantly - I think Windows 10 at least should have an arp table?)…
not all of those result in those

2018-01-13 20:17:21.167 [INFO ] [work.internal.dhcp.DHCPListenService] - DHCP request for unknown address: 0.0.0.0

just that ones:

remember: this is my openHAB2 server asking - but not from his “normal” FDQN, but from this JmDNS-IP-2 (?)

just for information, the MAC-Address is the same as the eth0:

[20:20:57] openhabian@openHAB2:/$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.xxx.10  netmask 255.255.255.0  broadcast 192.168.xx.255
        inet6 xxxx::xxxx:xxxx:xxxx:xxxx prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:c7:f6  txqueuelen 1000  (Ethernet)
        RX packets 21243559  bytes 2861206447 (2.6 GiB)
        RX errors 0  dropped 5  overruns 0  frame 0
        TX packets 20823551  bytes 2766175719 (2.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Lokale Schleife)
        RX packets 4408398  bytes 312533634 (298.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4408398  bytes 312533634 (298.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

binderth · January 13, 2018, 7:45pm

just to illustrate - is this normal? repeatedly and identical broadcasts from my openHAB-server to an IPaddress, which isn’t really live? (at least not in my fritz.box DHCP)

cgeo · January 15, 2018, 5:33pm

the fact that you have many arp packets is not necessarily bad.
What makes you think this is due to a problem ?

As for the logs about DHCP listen, I checked the network binding and indeed there is a new feature

https://docs.openhab.org/addons/bindings/network/readme.html

Regards,
Christos

binderth · January 15, 2018, 7:57pm

Hmm. I thought, having a ARP Table locally as cache would be efficient… Sometimes the Source asks within msecs on the same IP. But hey, if that’s the way it goes - I’m fine!

on another side: I thoroughly went through my configuration and must admit, the same IP-adresses, which seem to cause the INFOs are IP-addresses which changed, because of new mobiles…
But: even some pingdevices like my Onkyo Receiver (…53) are regularly online - but are still caught on the INFOs…

still strange, but ok, I can live with it.

cgeo · January 15, 2018, 10:07pm

I could not find anything for windows 10 but it seems that the cache life of the arc table is a few minutes. So I assume that you will see a lot of requests from time to time as a windows client tries to rebuilt some of its entries. Same for any other OS but I dont know the timers exactly

It also depends on the size of your network. Lots of devices, lots of arp requests.

As for the dhcp, the ip addresses that the DHCP server assigns have a lease time after which the clients need to renew them. They typically get the same ip address but they need to send the dhcp request again. This request will also be captured by the network binding