Hi @MarcoSch 

Thanks for posting in our business forum.

MarcoSch wrote

Hi  @Clive_A ,

 

attached is the full wireshark log for the affected time periods. All messages should be included. For me it is still strange that it only occurs with a version greater than 1.3.x. I have tried it with all 1.4.x versions. With each of these versions, the error occurs after 2 hours. With versions 1.3.x everything works as it should and there is no renewal after 2 hours. I have now the option to get an static ip. This should prevent the error from occurring again or? Thank you and best regards marco 
 

Will take a further look into the file.

Hi @MarcoSch 

Thanks for posting in our business forum.

MarcoSch wrote

Hi  @Clive_A, 

 

Many thanks for the analysis. Were there any adjustments regarding arp / juniper from 1.3.x to 1.4.x? Is it possible to disable the ip conflict check within the Omada controller software? With hardware version 1.3.x of the router this behavior does not seem to occur.

 

Many thanks and best regards Marco 

It is mainly because of the ARP and the reply from your ISP.

It responds to the ARP and announces that the IP address has been taken.

I don't think there is a way to fix it if the ISP replies IP conflict as the ARP broadcast is expected behavior. Removing this is not a good idea. DHCP that part works okay as it is a result of the ARP.

And your ISP quickly released the DHCP after the second dial and it gets the IP back. It looks like a problem on your ISP end and you can bring this information to them as the ARP reply comes from the ISP(?) device.

Hi @MarcoSch 

Thanks for posting in our business forum.

MarcoSch wrote

Hi  @Clive_A 

 

thanks for the explanation.

Means I would have to contact my isp to tell him that after a firmware update arp broadcasts are coming which have detected an ip conflict.

The isp will probably say that it has not changed anything and that there is a firmware error.

In my opinion, there must also have been a change within the firmware. With version 1.3.0 these arp broadcasts seem to have been ignored. Can you say why this only occurs from version 1.4.0? I am currently running version 1.3.0 and have no problems at all. As soon as I change to version 1.4.x the problems occur again.

Many thanks and regards marco

I don't deny this might be a new thing added to 1.4.X. But I am not a dev and have no access to the code.

If it does not occur on the 1.3.X and it ignores the ARP like what you speculated, if you have Wireshark and verified that, that's not an expected behavior.

So, the firmware iterates and updates the minor issues and optimizes the system. If this minor issue is optimized or added in the later firmware and it causes a problem in the system, this is not a fault in the system.

It matches how ARP and DHCP RFC. If you think this has to be removed, at least a proper reason should be provided. The product is not targeting only you but others with the WAN connection to be DHCP. 

It seems to be the ISP system optimization thing. Adding the ability to send ARP is a mechanism to avoid issues like the IP conflict as the Wireshark showed. And ARP got other use cases. I don't or our dev think we should change this due to cases like this.

There were similar reports like this but most are not followed up by the users. And we don't have other complaints regarding this.

If there is a new and strong piece of evidence indicating that it is the router problem, I am open for discussion.

P.S.

In the end, since I am writing this whole stuff, I am not sure if it is possible to set up the ACL to block ARP. I don't think ARP can be blocked by the ACL. ARP is OSI layer 2 based and it seems to be impossible to address this from the router.

It'd only be the way out to remove the ARP broadcast but that's not ideal and possible for larger network use cases.