-
Notifications
You must be signed in to change notification settings - Fork 54
templates: fix addrman patch #376
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
Conversation
|
Dang, that's a nice bugfix fren! Patch LGTM. We'll want to rebuild the images after this one. I'll kick them all off in a bit on my machine, and then merge if they all complete? |
|
Just realized I made a mistake as well will update.... |
|
Fixed my mistake and added an addrman unit test for reviewers |
|
added a test that pulls the new v27.0 image and checks addrman buckets. also had to bump lnd version: https://x.com/roasbeef/status/1781086945986404559 |
willcl-ark
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK fa0e383
tested locally, and it works nicely
The current addrman patch results in an addrman that buckets ipv4 address by 32 bits instead of 16. The issue is that in
NetGroupManager::GetGroup()we are dealing with IPv4 mapped to IPv6 addresses and so the 32 bits the function actually processes are the null prefix in the embedding scheme. This means all ipv4 addresses in warnet always end up in the same bucket :-PThe solution in this PR ensures that we process the last 32 bits of the embedded ipv6 structure which is where the actual ipv4 address really lives.
The issue is illustrated really well in the debugger while stopped in
GetGroup():