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
BIOCSRTIMEOUT: Invalid argument #54
Comments
Here is MacPorts build file I'm using -- looks very standard:
and the patchfile is very standard too - same one used on homebrew.
|
* Set the buffer size to 64k, i.e. big enough to hold a jumbo frame * Set the packet buffer timeout (read timeout) to 1ms as -1 was illegal on some platforms. (see tracebox/tracebox#54). Signed-off-by: Olivier Tilmans <olivier.tilmans@uclouvain.be>
Signed-off-by: Olivier Tilmans <olivier.tilmans@uclouvain.be>
Hi @kencu, Thanks for the report! All 3 crashes are related to the way the libcrafter library which is used by tracebox sets the bpf filters on its raw socket and the associated timers (i.e., it was using an illegal value). Additionally, your first test exhibited the issue reported in #49: |
thank you - I'll test this out and see if it works as expected. |
It builds correctly, and I no longer get the Abort Trap 6 error. Thanks! At this moment, I'm not certain if the output I'm seeing is what is expected. For example
|
This corrects the corrected output from #54 Signed-off-by: Olivier Tilmans <olivier.tilmans@uclouvain.be>
This output is indeed unexpected as instead of displaying the ttl distance it displays the ascii interpretation of the ttl ... (hence the whole set of characters ...). 098cd08 should fix that display issue (note that it was fine for i.e. the json output or the lua api). As tracebox never stops while traceroute does, it likely means that tracebox fails to infer that it reached the target host, which could stem from 3 different reasons:
I cannot reproduce that here, could you record a trace when doing your test ? i.e. Detecting (i) should be straightforward from the trace, (ii) should not matter in this case (i.e. tracebox currently listens on too many interfaces, not the reverse), (iii) can be inferred from the trace, i.e., there was an (ICMP) reply seen by tcpdump but libcrafter filtered it out. Could you try the revision 2b3bb42 and run tracebox with a In short,
Thanks! |
OK. For some reason I had to manually bring up the loopback interface with this: |
Thanks for the trace. However, it looks like I wrote incorrect tcpdump filters (i.e. these should have been
Was traceroute working before you brought the interface up ? Having to bring it up in the first place sounds odd. Could try to compare what you see in tcpdump when running a traceroute vs running tracebox ? (i.e. without filtering on the interface or the packet types). If tracebox does receive ICMP replies, i'd be interested to get another capture of these (i.e. to get the source IP as well as the values of the various ICMP fields and payload). Did you try tracebox towards external hosts ? |
Compiling release 0.4.2 using what appears to be very standard settings on MacPorts I am getting this error on 10.13 and also on 10.6:
Does this give you any ideas what might be up?
The text was updated successfully, but these errors were encountered: