Closed pjsg closed 3 years ago
Thanks for the improvements!
Hi Philip,
I commented out the ip_id you added as it was causing timing violations. See build/hermeslite.sta.rpt for the timing reports. I think this was independent from the DHCP changes you made.
73,
Steve kf7o
Ah -- I need to learn more about timing reports. Thanks for doing that....
On Wed, Dec 2, 2020 at 11:49 PM Steve Haynal notifications@github.com wrote:
Hi Philip,
I commented out the ip_id you added as it was causing timing violations. See build/hermeslite.sta.rpt for the timing reports. I think this was independent from the DHCP changes you made.
73,
Steve kf7o
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/softerhardware/Hermes-Lite2/pull/149#issuecomment-737663519, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALQLTLJEZ4TWLPX5PQPHXLSS4KFDANCNFSM4UJ2DBCA .
This fixes a problem where the dhcp client filled out the client_addr field when the HL did not respond to that address, By leaving it blank, the DHCP server is forced to return the DHCP message by Mac address. Then it turned out that the HL would respond to a ping that was sent to an address it didn't have. This was a problem as the DHCP server can verify that nobody has an IP before handing it out (by sending a ping and seeing if it gets a response). This test only failed if the arp cache on the dhcp server had not timed out.
I also noticed that the IP packet did not have the DF bit set (Dont Fragment), so I fixed that. I also added an IP ID to the IP header which increments by one for every packet sent. The idea here is to be able to see if I could track down where my occasional lost packet was going (i.e. in particular, whether the HL thought that it had sent it).
These changes work in my environment, unplugging, replugging cables etc.