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

Add proxy support to the neighbor functions #149

Merged
merged 1 commit into from
Aug 23, 2016

Conversation

CtrlZvi
Copy link
Contributor

@CtrlZvi CtrlZvi commented Jul 10, 2016

  • Don't require a MAC address for a neighbor proxy
  • Include proxies in the list of neighbors

Signed-off-by: Zvi "CtrlZvi" Effron viz+GitHub@flippedperspective.com

}
}

// TODO: seems not working because of cache
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably should fix this todo before merging

@vishvananda
Copy link
Owner

Thanks for adding this. One other thought. The iproute2 package allows you to list proxies separately. I'm wondering if we really want to include proxies by default or if it should be two separate commands? NeighList and NeighProxyList. Thoughts?

@CtrlZvi
Copy link
Contributor Author

CtrlZvi commented Jul 21, 2016

I actually was thinking the same thing after I submitted the PR. Plus, no chance of breaking someone's current user cases. I'll make the changes and update the PR.

- Don't require a MAC address for a neighbor proxy
- Include proxies in the list of neighbors

Signed-off-by: Zvi "CtrlZvi" Effron <viz+GitHub@flippedperspective.com>
@vishvananda vishvananda merged commit d710fba into vishvananda:master Aug 23, 2016
@CtrlZvi CtrlZvi deleted the neighbor_proxy branch August 24, 2016 23:22
borkmann added a commit to cilium/netlink that referenced this pull request Oct 29, 2021
The condition to demand a lladdress for neigh.Flags != NTF_PROXY is just
buggy, since there are various other flags such as NTF_USE, NTF_EXT_MANAGED,
etc where this is not required. Besides, the kernel handles this internally
anyway if it demands a NDA_LLADDR attribute. Simply get rid of the NTF_PROXY
flag/condition since it's wrong.

Fixes: d710fba ("Add proxy support to the neighbor functions (vishvananda#149)")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
vishvananda pushed a commit that referenced this pull request Nov 1, 2021
The condition to demand a lladdress for neigh.Flags != NTF_PROXY is just
buggy, since there are various other flags such as NTF_USE, NTF_EXT_MANAGED,
etc where this is not required. Besides, the kernel handles this internally
anyway if it demands a NDA_LLADDR attribute. Simply get rid of the NTF_PROXY
flag/condition since it's wrong.

Fixes: d710fba ("Add proxy support to the neighbor functions (#149)")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
byteocean pushed a commit to byteocean/netlink that referenced this pull request Nov 3, 2021
The condition to demand a lladdress for neigh.Flags != NTF_PROXY is just
buggy, since there are various other flags such as NTF_USE, NTF_EXT_MANAGED,
etc where this is not required. Besides, the kernel handles this internally
anyway if it demands a NDA_LLADDR attribute. Simply get rid of the NTF_PROXY
flag/condition since it's wrong.

Fixes: d710fba ("Add proxy support to the neighbor functions (vishvananda#149)")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
cyberys pushed a commit to cyberys/netlink that referenced this pull request Apr 5, 2022
The condition to demand a lladdress for neigh.Flags != NTF_PROXY is just
buggy, since there are various other flags such as NTF_USE, NTF_EXT_MANAGED,
etc where this is not required. Besides, the kernel handles this internally
anyway if it demands a NDA_LLADDR attribute. Simply get rid of the NTF_PROXY
flag/condition since it's wrong.

Fixes: d710fba ("Add proxy support to the neighbor functions (vishvananda#149)")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
cjmakes pushed a commit to cjmakes/netlink that referenced this pull request Jun 29, 2022
The condition to demand a lladdress for neigh.Flags != NTF_PROXY is just
buggy, since there are various other flags such as NTF_USE, NTF_EXT_MANAGED,
etc where this is not required. Besides, the kernel handles this internally
anyway if it demands a NDA_LLADDR attribute. Simply get rid of the NTF_PROXY
flag/condition since it's wrong.

Fixes: d710fba ("Add proxy support to the neighbor functions (vishvananda#149)")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
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

Successfully merging this pull request may close these issues.

2 participants