-
Notifications
You must be signed in to change notification settings - Fork 257
libnet_init(LIBNET_LINK, <null>): <no error message>
on some macs
#105
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
Comments
Interesting, I hadn't even considered testing on macOS until now. libnet could most definitely be the root cause for this. |
You meant MacBook Pro with touchbar. |
@i0ntempest You're more than welcome to give it a go. There are some samples in the libnet tree that should be easy enough to get started with. One using |
I got a error message that is shown "libnet_open_raw4(): SOCK_RAW allocation failed: Operation not permitted", so I try running in root, it's expected |
@ThomasHabets I see this was closed in your project, would you mind sharing what the conclusion/workaround was? |
I wish I documented it at the time, but I think this may be ThomasHabets/arping@3cad228. Basically sometimes we need to open something, just to call e.g. This appears to be a failure of libnet to (quoting the manpage) My workaround is simply to manually find My theory is that given Maybe the right fix is for libnet to continue searching? |
Aha, thanks! Yeah we should probably add fallback handling, looking for something named Just waded through the three (3!) implementations of Again, thank you so much for the quick reply! |
So, I've looked into this in detail now. Wanted to make sure before I disclosed my conclusions.
So, your workaround, @ThomasHabets, with a second pass looking for We could of course change the semantics, but I'm afraid that might break quite a few use-cases out there. And if we change the semantics I'd also like to see better support for IPv6-only interfaces as well. Hence, I'm putting this task on hold for now. |
Well, there's possibly one other way. For the cases where we are asked to search (second argument is My understanding of the Mac problem here is that we're just "unlucky" that the first scanned interface, and that we would have succeeded if we'd just continued scanning when opening the T2 interface fails. That should be safe, right? Same semantics. The three other avoid/skips yeah I don't think we can do anything about. |
OK, so here's how it works, pseudo code: libnet_init()
{
dev = libnet_select_device(dev)
if (libnet_open_link(dev))
return fail;
return ok;
}
libnet_select_device()
{
if (dev == NULL) {
num = libnet_ifaddrlist(&list);
if (num >= 1)
dev = strdup(list[0].dev);
free(list);
}
return dev;
}
libnet_ifaddrlist(list)
{
ioctl(fd, SIOCGIFCONF, &ifc);
return processing(ifc, list)
} As you can see, the list of interfaces is discarded in Both the Footnotes |
I was thinking something like:
|
Yes, that's another way to do it. A few of things that don't feel right:
I actually considered this approach when I wrote my previous reply, but chose not to include it since it's not just a good solution to this problem. Something similar though, where |
It doesn't have to be a public API, but yeah that's a good point about stability.
But actually doing that instead of pseudocode may not be as simple. |
The interface names are all |
@i0ntempest it's fine not knowing C, I was just curious if you knew the exact interface name, or type, that was the culprit here. I know the ethernet/wifi names are The output from |
I've attached the
|
Whoah, that's a lot of interfaces! 😮 Thank you! How do you know en7 is the T2 interface? It doesn't seem to have any distinguishing markings, really just looks like any kind of interface. In fact, en7 would never be considered by libnet as the code looks now, because it ignores interfaces that don't have an IPv4 address. Good point also about actual modern Macs, I guess the best approach after all is to go with something similar to what @ThomasHabets wrote. |
Physical interfaces+thunderbolt interfaces+thunderbolt bridge+virtual interfaces and you get that.
That is the problem. Apparently the only way is looking at
|
Thanks, this will be very useful! I guess we'd need, at least, a very rudimentary xml parser if we go down the blacklisting route. |
Just a thought... how about blacklisting ACPI paths or VID/PID pairs? Both should be pretty stable and are unlikely to change. But both would require gathering info from people and hardcoding those stuff in though. |
Yeah there are many opportunities here, but they rather quickly shoot way above what libnet was intended for. But it would make for a good "plugin" or user-provided list of interfaces, somehow. That way the user can user whatever mechanism they want to steer libnet in the right direction. |
Went to the local Apple Store a few days ago - confirmed that MacBooks with Apple Silicone and touch bar do not have the iBridge interface |
Amazing, thank you for taking the time to look into this! <3 |
See ThomasHabets/arping#36
I don't have a mac, but I suspect this could be a libnet issue picking a special system interface as if it's a normal network interface, when given
NULL
as ifname.Possibly only reproducible on Mac Pro with a touchbar.
The text was updated successfully, but these errors were encountered: