I have a strange thing here since a couple of days (or since 4.1.3 upgrade?)
Even though I assign my openhabian a fix IP based on the MAC Adresse (Standard Asus router Feature) via dhcp it somehow changes the IP after same hours of running. How can that happen? The router hardware and setup is the same, nothing changed. So the port forwarding from outside fails for MQTt connections which is annoying.
Thanks for support.
Sounds strange, I have the same setup running since years without any troubles.
Have you possibly activated both, LAN and WLAN?
They have different MAC addresses.
But just guessing ā¦
Have you checked the Log of your router for DHCP renewal tasks?
I donāt think thatās an openHABian issue. I would also try to look into the router logs. Normally you see issues like this with mobile devices like smartphones which randomly change MAC adresses to spoof ad targeting. But an Raspberry Pi always uses the same MAC adress for Wifi and for LAN, so I donāt think the issue lies here - but in the way your router assigns IPs. Sounds a bit rude, but are you sure, the router configuration is as you stated: static dynamic IP configuring DHCP in the router? and you donāt have any other DHCP-server or service running in your network which could affect your pi?
Just to be clear since this is a little ambiguous as stated, it always uses the same MAC every time it connects, but the MAC for each networking device is different. WiFi and Ethernet have different MACs.
that is of course correct. But if OP didnāt mess with openHABianās installation, thereās only one NIC active. So my educated guess is indeed itās most likely a Router DHCP configuration issue.
I totally agree.
Thank you for the hint for checkin the dhcp log. It shows openhabian is struggling to get the IP address and when I looked at it it was just changing. But what is causing this?
Jun 27 20:02:13 kernel: [1299254.950635] br0: received packet on ath1 with own address as source address
Jun 27 20:02:16 dnsmasq-dhcp[940]: disabling DHCP static address 192.168.11.14 for 10m
Jun 27 20:02:16 dnsmasq-dhcp[940]: not using configured address 192.168.11.14 because it was previously declined
Jun 27 20:02:16 dnsmasq-dhcp[940]: disabling DHCP static address 192.168.11.14 for 10m
(10 more entries for same time slot)
Thatās not a Raspberry Pi, is it.
We donāt support running openHABian on hardware other than Raspis.
As you have setup the OS on those yourself it can be anything we cannot know so youāll have to figure out yourself I guess.
This is the standard openhabian image running on a PI4 the above shows the log of my Asus router which runs the dhcp server with the fixed ip assigned.
A client will send a ādhcpdeclineā response if for some reason it thinks there is another node on the network with that IP address. So for some reason your RPi thinks some other device as that IP ending in 14 already. Is there a device with that IP?
br0 is a network bridge device. Whatās it bridging? Did you set up a bridging interface? ath1 implies you have more than one wifi device on this machine (the numbering starts at 0). Are both trying to connect to the same wifi network? That would cause the problem as one wifi connection will see the otherās IP address as a duplicate. Or maybe there is a flakey connection between the wifi device and the rest of the RPi so that it disappears and then comes back as the next number and when it comes back it requests a new IP address and sees the old ath0 already has that address.
Iāve never set up openHABian with wireless devices so canāt say so for certain, but I doubt that this is a standard openHABian networking config. If for some reason you didnāt do this on purpose, your best bet may be to take a backup and start up a new openHABian. If you are using a USB wifi device try a different USB port or a different dongle. If itās the onboard wifi, you might have a broken RPi.
There is no such thing as a āstandardā one as openHABian constantly keeps evolving and it depends on when you have set it up and what you did since in terms of upgrading OS packages (OH is irrelevant here).
You really should be giving these details upfront itās not fun when we have to ask you for each and every of them.
Same for your networking setup, you have not explained that although your problems are unique and likely to be related to that.
As Rich suggested I, too, would install a FRESH openHABian.
That now would be a āstandardā one we at least know.
guys, Iām not sure, if you got the information from @Moerky:
the log he posted is from the router, so it does not refer to the Wifi NIC on the Pi.
That being said, Moerky:
and Iām with the others: try to export your current openHAB configuration, install a vanilla openHABian and import your configuration. Then try to reproduce - or perhaps itās gone.
But: I still think, thereās some kind of misconfiguration on your router and/or network. I know nothing about Asus router, but perhaps you can delete your DHCP lease and reassign a new one with a completely different IP? or look for a double entry with the MAC adress of the wifi NIC of your Pi?
or itās just simply you configured some network device with the same IP on the device that you plan to use with your Pi. Try to identify all your network devices and look for one with the same IP (192.168.11.14) as you try to distribute via DHCP.
I did get that info.
In the DHCP protocol, the router assigns an IP address to the client. However, if the client, the RPi in this case, thinks that some other client on the network already has that IP address, the client will reject the IP address. Thatās what this log line means:
Jun 27 20:02:16 dnsmasq-dhcp[940]: not using configured address 192.168.11.14 because it was previously declined
The client is telling the DHCP server āsorry, I know someone else has that address, give me a different oneā.
Couple that with the network device names reported on the RPi side (i.e. bro, ath1) the conclusion is the networking on the RPi is not a standard openHABian config.
I would not expect to see a bridge (br0) on a standard openHABian and I would expect the onboard WiFi device to be ath0, not ath1. Given that there is a network bridge present and two WiFi devices, I can really see how the RPi sees itās already assigned IP address on ath0 as taken when ath1 tries to connect.
Ok. Looks like for me, that the whole log excerpt is taken out of the router, so that br0 and ath1 actually means the bridge and Wifi stack of the ASUS.
Apart from that, my bet is also, thereās already a device on that IP address.
FWIW Asus routers are notorious for DHCP issues.
Assuming you do not have a misconfigured MAC address in your static file for your RPi and assuming you are not MAC spoofing on the RPI and assuming you have already rebooted the router or even dumped the configuration and reset and reloaded it you might consider as an alternate next best step other the what has already been suggested full reload of openhabian would be to fire up Wireshark and dump the traffic and filter on your dhcp response packets during the time all of this is happening at that 10 minute marks or what ever it reoccurs at. That should tell the whole story and eliminate all the what ifās
You could be right now I look at it again.
Thanks to (most of you) for being so supportive. I can confirm itās a pi4 connected via lan to the network and the log was the one of the router. WLAN is not connected on the pi. I only update openhabian to be on the latest stable release - thatās what it makes so strange. Also the router is about 2 years in this setup. Never had such a dhcp issue. I changed the IP to a free one Iāve never seen being used. Same result. After some minutes it changes it to a various other one.
Iām lacking time and motivation to reset either one or the other. But will give it a try with the router and then only making the dhcp reservation and port forwarding. Hope that helps.
What happens if you make it a static address on the pi and rely on dhcp?
I always statically assign my servers because they donāt change. I only use dhcp for laptops and phones etc that are mobile.
One other thing I thought about after I posted earlier are your system times correct and close to in sync between the Rpi and the router? Dhcp is somewhat time sensitive due to it tracking lease period so that is also something you may want to look at as well. Seems odd that your IP is releasing so quickly after it assigns. Normal default is 24 hours unless you have reduced the lease/renew time to a shorter interval
Current update: I did a full reset of my router and only configured the openhabian address and a few others. All other IPs stay the same except for openhabian even though I picked several āguaranteed freeā ones which were not taken before. Still same behaviour of changing the IP with the log entry in my Asus router log. Still happens after some hours.
Then I changed to a static IP updating /etc/dhcpcd.conf with
interface eth0
#static ip_address=192.168.11.114/24
#static routers=192.168.11.1
#static domain_name_servers=192.168.11.1
When rebooting I can access openhabian but after some minutes I can not reach it anymore.
The ASUS router reports a totally different IP which also can not be reached.
When I login to openhabian it says in the splash screen
but a ifconfig reports
openhabian@openhabian:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.11.114 netmask 255.255.255.0 broadcast 192.168.11.255
inet6 fe80::9233:e46:a7be:6008 prefixlen 64 scopeid 0x20
ether dc:a6:32:48:32:18 txqueuelen 1000 (Ethernet)
RX packets 43782 bytes 37795406 (36.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 31558 bytes 5349036 (5.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Any other suggestion than to reinstall everything?
a) I have quite a few scripts for backup routines and other stuff implemented apart from a video cam which monitors my water usage, an eBUS for my pump > I wouldnāt want to setup all this stuff again AND I havenāt changed anything there ā¦
b) I donāt find any DHCP issues for Asus routers apart from obtaining the IP from the ISP which is not my issue here. And I resented the router (see before)
c) I have various other IP addresses assigned manually in the router which all work fine.
Thanks again for your support. Iām quite desperate with this issueā¦