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

DRAFT: Support both "igrp" and "eigrp" in filters. #1428

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

guyharris
Copy link
Member

Use our own header to define IPPROTO_ values, rather than leaving them up to the OS for which we're building.

Always use IP protocol 9 for "igrp", and use IP protocol 88 for "eigrp". 9 is assigned to "any private Internet gateway protocol", and is mainly used for Cisco's IGRP. 88 is for Cisco's EIGRP, which is not compatible on-the-wire with IGRP.

FreeBSD, DragonFly BSD and macOS define IPPROTO_IGRP as 88, rather than as 9, and their libpcaps use IP protocol 88 for "igrp". Everybody else uses IP protocol 9 for "igrp".

@guyharris
Copy link
Member Author

This is one way to deal with the "igrp"/"eigrp" issues that b33f396 works around.

It makes libpcap's filter compiler, when compiled in FreeBSD, DragonFly BSD, or macOS work differently for a filter igrp than do the FreeBSD, DragonFly BSD, and macOS libpcap filter compilers do - they translate igrp as a test for IP protocol 88, not IP protocol 9. All other systems will translate igrp as a test for IP protocol 9.

@infrastation
Copy link
Member

This is one of five (so far!) inconsistencies that would require changing the meaning of some keywords or removing/adding keywords to be solved properly. Before making any changes I had in mind to:

  1. Post a detailed account of these issues on the list.
  2. Document the imperfections thoroughly in libpcap 1.11.x.
  3. Suggest addressing all issues at once in libpcap 2.0.0, so the users have to verify their filters only once and after an advance warning.

For this particular problem a potential solution could be replacing "eigrp" with the standard protocol names ("igp" for 9 and "eigrp" for 88).

@guyharris
Copy link
Member Author

For this particular problem a potential solution could be replacing "eigrp" with the standard protocol names ("igp" for 9 and "eigrp" for 88).

Is there a standard protocol named "IGP" (Interior Gateway Protocol), or is that a name for a type of protocol, as per https://en.wikipedia.org/wiki/Interior_gateway_protocol?

@guyharris
Copy link
Member Author

This is one of five (so far!) inconsistencies that would require changing the meaning of some keywords or removing/adding keywords to be solved properly.

What are the other four?

@infrastation
Copy link
Member

"igp" appears in Linux and FreeBSD /etc/protocols, which likely comes from the registry. Let me post a write-up to the list.

Use our own header to define IPPROTO_ values, rather than leaving them
up to the OS for which we're building.

Always use IP protocol 9 for "igrp", and use IP protocol 88 for "eigrp".
9 is assigned to "any private Internet gateway protocol", and is mainly
used for Cisco's IGRP.  88 is for Cisco's EIGRP, which is not compatible
on-the-wire with IGRP.

FreeBSD, DragonFly BSD and macOS define IPPROTO_IGRP as 88, rather than
as 9, and their libpcaps use IP protocol 88 for "igrp".  Everybody else
uses IP protocol 9 for "igrp".
@guyharris
Copy link
Member Author

"igp" appears in Linux and FreeBSD /etc/protocols, which likely comes from the registry.

So it's "pigp" without the "p".

@guyharris guyharris changed the title Support both "igrp" and "eigrp" in filters. DRAFT: Support both "igrp" and "eigrp" in filters. Jan 7, 2025
@infrastation
Copy link
Member

Let me suggest documenting this better (the change log, the backward compatibility section of the man page) and waiting a bit until it is clear which other related changes go along.

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

Successfully merging this pull request may close these issues.

None yet

2 participants