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

[Norbytus]

Can't build on FreeBSD.

[DoumanAsh]

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

[DoumanAsh]

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

[Norbytus]

I can test on FreeBSD and Linux, if you need

[DoumanAsh]

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

[DoumanAsh]

@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.

[Norbytus]

I run tests and i have next problem

[DoumanAsh]

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.

[Norbytus]

I did it tommorow.

[DoumanAsh]

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

[ntninja]

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 😀

[DoumanAsh]

@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

[Norbytus]

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

[Norbytus]

And many people use fcntl for block stream in BSD

[ntninja]

@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)

[DoumanAsh]

@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.

[ntninja]

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. 🙂

[DoumanAsh]

@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 :)

[DoumanAsh]

@Norbytus ping

[Norbytus]

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.

[DoumanAsh]

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.