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
IPv4 routing table is missing entries for additional addresses on the loopback interface #4201
Comments
gpotter2
added a commit
to gpotter2/scapy
that referenced
this issue
Apr 14, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
Merged
gpotter2
added a commit
to gpotter2/scapy
that referenced
this issue
Apr 14, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
gpotter2
added a commit
to gpotter2/scapy
that referenced
this issue
Apr 14, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
gpotter2
added a commit
to gpotter2/scapy
that referenced
this issue
Apr 19, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
gpotter2
added a commit
to gpotter2/scapy
that referenced
this issue
Apr 20, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
gpotter2
added a commit
to gpotter2/scapy
that referenced
this issue
Apr 20, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
evverx
pushed a commit
to evverx/scapy
that referenced
this issue
Apr 20, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
evverx
pushed a commit
to evverx/scapy
that referenced
this issue
Apr 20, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
gpotter2
added a commit
to gpotter2/scapy
that referenced
this issue
Apr 20, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
gpotter2
added a commit
to gpotter2/scapy
that referenced
this issue
Apr 20, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
This should be fixed in #4352. Feel free to try it out |
evverx
pushed a commit
to evverx/scapy
that referenced
this issue
Apr 21, 2024
This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes secdev#4201
gpotter2
added a commit
that referenced
this issue
Apr 28, 2024
* Rewrite arch/linux: interfaces/routes loading This rewrites much of the arch/linux code, in order to use a RTNETLINK socket instead of reading /proc/net/XXX. Among those: - the read_routes(6) functions - the linux interfaces provider - arch/linux util functions This adds support for multiple IPv4 addresses to interfaces, among with a generally much better handling of routes. fixes #4201 * Apply guedou suggestions * Restrain routes to RT_TABLE_LOCAL and RT_TABLE_MAIN
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Brief description
Scapy IPv4 routing table is missing additional addresses configured on the
lo
interface.Scapy version
2.5.0
Python version
3.11.2
Operating system
Debian bookworm 12.2 running kernel 6.1.52-1
Additional environment information
No response
How to reproduce
Given the following IPv4 and IPv6 addresses assigned to
lo
:scapy provides an IPv6 routing table that includes
2620:0:863:ed1a::3/128
:But the IPv4 route table is missing
198.35.26.98/32
:In fact, if we compare scapy IPv4 route table against the kernel local routing table, quite some entries seem to be missing:
Actual result
No response
Expected result
No response
Related resources
No response
The text was updated successfully, but these errors were encountered: