Skip to content

Linux: Refine connection status reporting. #1389

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.

Sign up for GitHub

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
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

Linux: Refine connection status reporting. #1389

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions CHANGES
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,8 @@ DayOfTheWeek, Month DD, YYYY / The Tcpdump Group
Fix a few device activation bugs.
Count and timestamp packets better.
Add kernel filtering, fix userland filtering.
Linux:
Refine connection status reporting.
DAG:
Always set PCAP_IF_CONNECTION_STATUS_NOT_APPLICABLE.
In dag_findalldevs() handle known errors better.
Expand Down
20 changes: 12 additions & 8 deletions pcap-linux.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,6 +103,10 @@
// Linux before 3.5
#define ARPHRD_IEEE802154_MONITOR 805
#endif
#ifndef ARPHRD_IP6GRE
// Linux before 3.7
#define ARPHRD_IP6GRE 823
#endif
#ifndef ARPHRD_NETLINK
// Linux before 3.11
#define ARPHRD_NETLINK 824
Expand Down Expand Up @@ -1828,17 +1832,22 @@ get_if_flags(const char *name, bpf_u_int32 *flags, char *errbuf)
switch (arptype) {

case ARPHRD_LOOPBACK:
case ARPHRD_CAN:
case ARPHRD_TUNNEL:
case ARPHRD_TUNNEL6:
case ARPHRD_SIT:
case ARPHRD_IPGRE:
case ARPHRD_IP6GRE:
/*
* These are types to which
* "connected" and "disconnected"
* don't apply, so don't bother
* asking about it.
*
Copy link
Member

Choose a reason for hiding this comment

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

Are there any Linux ARPHRD_ types that we're not explicitly handling, i.e. we're handling it by doing nothing in the (implicit) default case?

Copy link
Member Author

Choose a reason for hiding this comment

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

In this switch block? Yes, for example, ARPHRD_ETHER and ARPHRD_NETLINK (arguably, the latter may make sense in this case too, but I didn't test that). The default results in PCAP_IF_CONNECTION_STATUS_UNKNOWN.

* XXX - add other types?
*/
close(sock);
fclose(fh);
free(pathstr);
*flags |= PCAP_IF_CONNECTION_STATUS_NOT_APPLICABLE;
return 0;

case ARPHRD_IRDA:
Expand Down Expand Up @@ -1886,13 +1895,8 @@ get_if_flags(const char *name, bpf_u_int32 *flags, char *errbuf)
/*
* OK, this OS version or driver doesn't support
* asking for this information.
* XXX - distinguish between "this doesn't
Copy link
Member

Choose a reason for hiding this comment

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

What do EOPNOTSUPP and EINVAL indicate here? Does that make the distinction in question?

Copy link
Member Author

@infrastation infrastation Jul 23, 2025 •
edited
Loading

Choose a reason for hiding this comment

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

As far as the comment says it, one (not sure which one) means "ethtool is not supposed to work with this interface" and the other means "ethtool is supposed to work with this interface, but it could not". Perhaps the final version should split the comments into two cases, or do something else that would be more sensible than removing the comment.

AFAIR, the intent of this chunk is to have a more sensible relation between interfaces that have a notion of the connection status and interfaces that are in ethtool domain. As the pull request comment says, it turned out to be a can of worms bigger than expected, so this change is not safe for merging and should be reworked to some extent. Also this would need some testing on 2.6 kernels to see how much of the semantics holds.

Also bitwise OR with PCAP_IF_CONNECTION_STATUS_UNKNOWN is a no-op, as I see now.

* support ethtool at all because it's not
* that type of device" vs. "this doesn't
* support ethtool even though it's that
* type of device", and return "unknown".
*/
*flags |= PCAP_IF_CONNECTION_STATUS_NOT_APPLICABLE;
*flags |= PCAP_IF_CONNECTION_STATUS_UNKNOWN;
close(sock);
return 0;

Expand Down