nhrp: add cisco-authentication password support#14788
nhrp: add cisco-authentication password support#147881337kerberos wants to merge 1 commit intoFRRouting:masterfrom
cisco-authentication password support#14788Conversation
ton31337
left a comment
There was a problem hiding this comment.
Missing documentation, some contributing guidelines, and styling issues yet.
|
general remark: apply 'git clang-format HEAD^' and squash the proposed changes. |
|
@louberger can you take a look at this? |
eebc70a to
aaf720c
Compare
eeae138 to
282a6e5
Compare
|
The latest update:
The internal testing by my team has shown issues when connecting with Cisco Spoke; keep PR as a draft until addressed |
Implemented: - handling 8 char long password, aka Cisco style. - minimal error inidication routine - test case, password change affects conection Signed-off-by: Volodymyr Huti <[email protected]>
282a6e5 to
41b4a29
Compare
|
@ton31337 @pguibert6WIND is anything else needed to tmerge this PR ? |
|
It won't be reviewed until it's marked as a draft. |
|
@volodymyrhuti I also have an interest in seeing this committed. I tested your PR against a Cisco router as spoke and found/fixed a few issues. (see attached file). Wireshark is still complaining. I'm wondering if its because the packet causing the error indication does not include the extensions when copying the packet that caused the indication. Wireshark just recursively parses the included original packet, so the checksum and length would be incorrect. Issues I found/fixed:
Happy to discuss, let me know if you have any questions. |
Taking over this development from FRRouting#14788 This commit addresses 4 issues found in the previous PR 1) FRR would accept messages from a spoke without authentication when FRR NHRP had auth configured. 2) The error indication was not being sent in network byte order 3) The debug print in nhrp_connection_authorized was not correctly printing the received password 4) The addresses portion of the mandatory part of the error indication was invalid on the wire (confirmed in wireshark) Signed-off-by: Dave LeRoy <[email protected]>
|
I have coordinated with @volodymyrhuti and he has agreed to let me carry this work forward. I am closing this PR and taking up the work in #16172 |
|
Replaced by #16172 |
Taking over this development from FRRouting#14788 This commit addresses 4 issues found in the previous PR 1) FRR would accept messages from a spoke without authentication when FRR NHRP had auth configured. 2) The error indication was not being sent in network byte order 3) The debug print in nhrp_connection_authorized was not correctly printing the received password 4) The addresses portion of the mandatory part of the error indication was invalid on the wire (confirmed in wireshark) Signed-off-by: Dave LeRoy <[email protected]>
Taking over this development from FRRouting#14788 This commit addresses 4 issues found in the previous PR 1) FRR would accept messages from a spoke without authentication when FRR NHRP had auth configured. 2) The error indication was not being sent in network byte order 3) The debug print in nhrp_connection_authorized was not correctly printing the received password 4) The addresses portion of the mandatory part of the error indication was invalid on the wire (confirmed in wireshark) Signed-off-by: Dave LeRoy <[email protected]>
Taking over this development from FRRouting#14788 This commit addresses 4 issues found in the previous PR 1) FRR would accept messages from a spoke without authentication when FRR NHRP had auth configured. 2) The error indication was not being sent in network byte order 3) The debug print in nhrp_connection_authorized was not correctly printing the received password 4) The addresses portion of the mandatory part of the error indication was invalid on the wire (confirmed in wireshark) Signed-off-by: Dave LeRoy <[email protected]> Co-authored-by: Volodymyr Huti <[email protected]>
Taking over this development from FRRouting#14788 This commit addresses 4 issues found in the previous PR 1) FRR would accept messages from a spoke without authentication when FRR NHRP had auth configured. 2) The error indication was not being sent in network byte order 3) The debug print in nhrp_connection_authorized was not correctly printing the received password 4) The addresses portion of the mandatory part of the error indication was invalid on the wire (confirmed in wireshark) Signed-off-by: Dave LeRoy <[email protected]> Co-authored-by: Volodymyr Huti <[email protected]>
Taking over this development from FRRouting#14788 This commit addresses 4 issues found in the previous PR 1) FRR would accept messages from a spoke without authentication when FRR NHRP had auth configured. 2) The error indication was not being sent in network byte order 3) The debug print in nhrp_connection_authorized was not correctly printing the received password 4) The addresses portion of the mandatory part of the error indication was invalid on the wire (confirmed in wireshark) Signed-off-by: Dave LeRoy <[email protected]> Co-authored-by: Volodymyr Huti <[email protected]>
Taking over this development from FRRouting#14788 This commit addresses 4 issues found in the previous PR 1) FRR would accept messages from a spoke without authentication when FRR NHRP had auth configured. 2) The error indication was not being sent in network byte order 3) The debug print in nhrp_connection_authorized was not correctly printing the received password 4) The addresses portion of the mandatory part of the error indication was invalid on the wire (confirmed in wireshark) Signed-off-by: Dave LeRoy <[email protected]> Co-authored-by: Volodymyr Huti <[email protected]>
Taking over this development from FRRouting#14788 This commit addresses 4 issues found in the previous PR 1) FRR would accept messages from a spoke without authentication when FRR NHRP had auth configured. 2) The error indication was not being sent in network byte order 3) The debug print in nhrp_connection_authorized was not correctly printing the received password 4) The addresses portion of the mandatory part of the error indication was invalid on the wire (confirmed in wireshark) Signed-off-by: Dave LeRoy <[email protected]> Co-authored-by: Volodymyr Huti <[email protected]>
Implemented:
Implemented in the context - https://vyos.dev/T2326