Hello !
I see a strange phenomenon at an access point regularly, I wonder if someone could explain to me what is going on....
First it goes like this:
Fri Feb 18 09:52:33 2022 daemon.info dnsmasq-dhcp[26051]: DHCPDISCOVER(eth0.16) 78:45:58:48:c5:bc
Fri Feb 18 09:52:33 2022 daemon.info dnsmasq-dhcp[26051]: DHCPOFFER(eth0.16) 192.168.1.13 78:45:58:48:c5:bc
This for about 50 lines. This is understandable, somehow the response from the AP is either not arriving, or it's not responding. I don't know why, but I know what's going on. But then the following lines come:
Fri Feb 18 09:52:33 2022 daemon.info dnsmasq-dhcp[26051]: DHCPDISCOVER(eth0.16) 78:45:58:48:c5:bc
Fri Feb 18 09:52:33 2022 daemon.info dnsmasq-dhcp[26051]: DHCPOFFER(eth0.16) 192.168.1.13 78:45:58:48:c5:bc
Fri Feb 18 09:52:33 2022 daemon.info dnsmasq-dhcp[26051]: DHCPREQUEST(eth0.16) 192.168.1.13 78:45:58:48:c5:bc
Fri Feb 18 09:52:33 2022 daemon.info dnsmasq-dhcp[26051]: DHCPACK(eth0.16) 192.168.1.13 78:45:58:48:c5:bc AP3-neu
Fri Feb 18 09:52:33 2022 daemon.info dnsmasq-dhcp[26051]: DHCPDISCOVER(eth0.16) 78:45:58:48:c5:bc
Fri Feb 18 09:52:33 2022 daemon.info dnsmasq-dhcp[26051]: DHCPOFFER(eth0.16) 192.168.1.13 78:45:58:48:c5:bc
Fri Feb 18 09:52:33 2022 daemon.info dnsmasq-dhcp[26051]: DHCPREQUEST(eth0.16) 192.168.1.13 78:45:58:48:c5:bc
Fri Feb 18 09:52:33 2022 daemon.info dnsmasq-dhcp[26051]: DHCPACK(eth0.16) 192.168.1.13 78:45:58:48:c5:bc AP3-neu
This goes about 300 lines, or perhaps more. I have to scroll a lot till I see something else. I don't understand this at all, because the assignment of the IP address is completed. Why does that have to do it again and again ? Note that around this time, ping-monitor says that it's not accessible, and I have a program to restart the device that connects the router with the AP. But I thought that if the AP is not accessible at all, the router won't be offering an IP address ? I think rather that inaccessibility through ping and this weird DHCP phenomenon are caused by something else....
My setting is
Router (OpenWRT)--switch--VDSL converter (master)--telephone line---vdsl converter (slave)--ethernet cable---AP3.
This VDSL converter crashes every once in a while, so I just set a relay (with raspberry pi) so that it will be restarted when the AP3 is not pingable for some time. It was doing it around this time, so I am not sure what is caused by what.
I would appreciate if someone could tell me what's going on....
I'm not sure if it's certified to work, but this vdsl2 converter is no longer sold (planet vc201-A), I think it's because it crashes regularly. It's been in use here for about 7 years. I have Unifi firmware now, but till a year ago, an old UAP with custom ware of Openwrt was in use. (installed by a wifi service provider hotsplots)
Now I looked at the log again, my AP1 is the same model, and is connected to the router through ethernet cable, and doing the same thing !!
One thing I did with this AP is, I restarted around 15:40. DHCP lease time is 12 hours, I looked at 03:54, it wasn't doing this. So I suppose, it happens at the first lease-renewal after a restart. (I have static lease for the APs set on the router, and APs are DHCP clients.)
It doesn't seem to take more than 1 second, so it's not so bad, but strange...
I guess the best you can do it capture packets at the side of the APs to verify if they indeed receive the Offers and the ACKs. From OpenWrt side it looks correct, it is replying to all the Discoveries or Requests it gets.
It's probably that the time on the AP is not correct and it thinks the lease is expired as soon as it gets the lease. Once the clock gets set then it stops doing this.
The time on the APs are set automatically by NTP servers, and they are listed as 0.ubnt.pool.ntp.org
and 0 varies through 3.
That's the default on the controller, so I would assume that the time is set correctly....
O, I see, APs need some time getting the right time, and before they set their time correct after booting, DHCP offer etc from the router come, and they throw them away.
This means, in all, there is nothing wrong going on, then?
Well, it's possible. I mean, the fact that it only happens at first boot seems to indicate something special about first boot, and one thing could be that the time is wrong.