Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong Ethernet II destination MAC address. #426

Open
ColinDexter opened this issue May 21, 2022 · 6 comments
Open

Wrong Ethernet II destination MAC address. #426

ColinDexter opened this issue May 21, 2022 · 6 comments

Comments

@ColinDexter
Copy link

If I switch to another network (without turning off the Arduino and ENC28J60) I do get the new IP data from the DHCP. But when I request a website, the destination MAC address of the old DNS server remains in the Ethernet II package instead of the MAC of new DNS server. (verified with Wireshark.)

I can't find where this is set. Apparently this does not reset / set properly when reconnecting to the other network .

@globalcitizen
Copy link
Contributor

This issue is requesting a new feature - automatic ARP cache invalidation when link status changes. It should not be hard to implement however it will take more code and since few people have requested it disabling by default may be a good idea.

@ColinDexter
Copy link
Author

Okay, thanks. Only I have no idea how I can do an "automatic ARP cache invalidation". Hopefully this feature can be added in the future.

@globalcitizen
Copy link
Contributor

For the moment, you could for example reinitialize the library if a ping fails, which should have the intended effect.

@ColinDexter
Copy link
Author

I already do an ENC28J60::initialize on a disconnect but that doesn't solve the problem.

@globalcitizen
Copy link
Contributor

You could try:

  • Reset the whole device (soft reset function like: void(* soft_reset) (void) = 0; ... soft_reset();)
  • Manually alter the ARP cache

Ultimately if you are unable to reset the ARP cache or resolve via reset I don't think you will get far with this solution as it is not really polished in so far as usability for those sorts of edge use cases and is not receiving a lot of development effort anymore. If you really need rapid plug-and-play between networks without skipping a beat you may be best served by looking toward alternate stacks or hardware.

@ColinDexter
Copy link
Author

Sorry, I can program a bit, but this is going to be a little above my level.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants