FreeBSD: Cannot compile due to unresolved import of: AF_NETLINK, AF_PACKET and accept4

Question

FreeBSD: Cannot compile due to unresolved import of: AF_NETLINK, AF_PACKET and accept4

Norbytus opened this issue 7 years ago · comments

Can't build on FreeBSD.

Douman · Answer 1 · Thu Apr 06 2017 01:55:05 GMT+0800 (China Standard Time)

Thanks for reproting.
As i don't have FreeBSD it is difficult for me to verify unix part of code.

It seems there is no AF_NETLINK & AF_PACEKT, but i find it strange that you do not have access to accept4 on freebsd as it should be available https://doc.rust-lang.org/libc/x86_64-unknown-freebsd/libc/fn.accept4.html

Most possibly AF_NETLINK & AF_PACKET will need be linux only flags and for accept4 i need to check libc version

Douman · Answer 2 · Thu Apr 06 2017 02:01:43 GMT+0800 (China Standard Time)

Ok accept4 has been added recently to libc rust-lang/libc#546
When next version of libc will be out i'll pin my crate to it and for unresolved constants i'll make fix later on

Alexsander · Answer 3 · Thu Apr 06 2017 02:17:01 GMT+0800 (China Standard Time)

I can test on FreeBSD and Linux, if you need

Douman · Answer 4 · Thu Apr 06 2017 14:07:26 GMT+0800 (China Standard Time)

Just for reference missing flags are fixed in #4
accept4 waits for new version of libc

Douman · Answer 5 · Sun Apr 30 2017 15:03:44 GMT+0800 (China Standard Time)

@Norbytus Could you please check that you can build with new libc 0.2.22
I also uploaded 0.2.1 version that bumped minimum required libc to this version.

Alexsander · Answer 6 · Mon May 01 2017 02:32:07 GMT+0800 (China Standard Time)

I run tests and i have next problem

Douman · Answer 7 · Mon May 01 2017 02:49:01 GMT+0800 (China Standard Time)

Are these failing tests persistently failing?

I will need to investigate what's wrong with tests then.
It is especially strange to see error here https://github.com/DoumanAsh/lazy-socket.rs/blob/master/tests/socket.rs#L338 - maybe BSD implementation differs somehow from linux and we do not set non-blocking flag properly.

Alexsander · Answer 8 · Mon May 01 2017 03:00:29 GMT+0800 (China Standard Time)

I did it tommorow.

Douman · Answer 9 · Mon May 01 2017 14:41:32 GMT+0800 (China Standard Time)

@Alexander255 ping. I would appreciate some help with BSD sockets :)

Erin Yuki Schlarb · Answer 10 · Tue May 02 2017 05:53:28 GMT+0800 (China Standard Time)

Doing a quick read over socket_select_connect it would appear as if FreeBSD does not consider a non-blocking connect to a localhost TCP address and asynchronous operation and therefor immediately returns a success value. We currently assume, however, that a non-blocking connect will always return EINPROGRESS.

It would be very useful to have a strace target/debug/deps/socket-9a271bcd0abf4f86 to confirm that that's indeed what's happening.

For the second error I believe @DoumanAsh has already fixed the problem in the mean time 😀

Douman · Answer 11 · Tue May 02 2017 12:21:22 GMT+0800 (China Standard Time)

@Alexander255 That's what i suspected... Still i'm not sure should we have test that is trying to connect to some remote host instead

Alexsander · Answer 12 · Tue May 02 2017 18:37:32 GMT+0800 (China Standard Time)

I add Norbytus@7c7f4d3 options for reuse addres and port, and run ktrace(strace) i get some time it's good some no.

Alexsander · Answer 13 · Wed May 03 2017 16:36:58 GMT+0800 (China Standard Time)

And many people use fcntl for block stream in BSD

Erin Yuki Schlarb · Answer 14 · Wed May 03 2017 18:22:17 GMT+0800 (China Standard Time)

@DoumanAsh: I guess we could connect 8.8.8.8:53 or something. The test should print out a large warning on startup that its outcome depends on external servers and an active network connection, so that an appropriate "error message" (stdout output) is visible if the test fails.

@Norbytus: It's weird that adding SO_REUSEADDR would change anything in this case, but either way doing that is not a fix.
With "It would be very useful to have a strace target/debug/deps/socket-9a271bcd0abf4f86", I actually meant it would be useful to have the relevant strace/ktrace output. I have just assumed that something like strace (with somewhat different output) exists on all unices (even MSYS has a very lightweight implementation of this). So what I actually meant was:

Please run ktrace target/debug/deps/socket-9a271bcd0abf4f86 to get debugging information of the test (don't use RUST_BACKTRACE environment variable through)
Run kdump -dH to parse the generated trace file
Look for the relevant CALL connect(…) line that tries to connect to 127.0.0.1:60006 and check whether it returns a success value or an EINPROGRESS error (or copy the relevant lines)

Douman · Answer 15 · Wed May 03 2017 18:40:44 GMT+0800 (China Standard Time)

@Alexander255 four 8 is google DNS, right? Hm... well connecting to google DNS seems to be more or less reliable. So i suppose we can go with it.

Erin Yuki Schlarb · Answer 16 · Wed May 03 2017 18:48:53 GMT+0800 (China Standard Time)

I'm not particularity happy about the choice either, but how many probably-reliable guaranteed-static-IPv4 TCP services do you know? Suggesting Google DNS was pretty much by default and is technically an abuse of their service. 🙂

Douman · Answer 17 · Wed May 03 2017 18:50:07 GMT+0800 (China Standard Time)

@Norbytus I pushed update to use google DNS could you please try it out?

@Alexander255 Yeah, i understand. I just asked cuz i saw port 53 :)

Douman · Answer 18 · Sat May 13 2017 03:57:20 GMT+0800 (China Standard Time)

@Norbytus ping

Alexsander · Answer 19 · Sat May 13 2017 06:04:32 GMT+0800 (China Standard Time)

I'm sorry. Only today had senn message from @DoumanAsh. So did pull. And it's ok. But time at time has error, but now on tcp and tcp6 test.

Douman · Answer 20 · Sat May 13 2017 14:07:30 GMT+0800 (China Standard Time)

No problem. I think it is just github mentions are case sensitive and that's why you didn't see.
For tcp/tcp6 errors i think it is just how it is now. They are not exactly stable.

Anyway good that now it works on FreeBSD.