[openbeosnetteam] Re: libbind.so status

> Hi,
> libbind.so works now as far as I can see. 

Great (and huge) job.

> Our UDP module did not set the address family for the sockaddr passed 
> to recvfrom(). 
> Our old BIND seems to not care about that value. :)

Eh eh, newer code even help find and fix old dormant bug!

> Unfortunately, there are more problems to solve:
> 
> Ping resolved the host name correctly, but then it tries to send an 
> IP packet with most values set to zero (version and header length are 
both zero, for example, although they should be 4 and 5, respectively).

Is it a new bug?
We never saw this behavior before, right?

> I'd bet we have some places in our source that use immediate values 
> instead of constants and after I changed our headers to be more BONE-
like (for example: our shutdown() constants were different from ours) 
they are wrong, too. The route bin command used shutdown(sock, 0), 
although it should have been shutdown(sock, SHUTDOWN_RECV).

Well, in fact in POSIX sys/socket.h standard, it should be SHUT_RD, not 
SHUTDOWN_RECV:
http://www.opengroup.org/onlinepubs/007904975/basedefs/sys/
socket.h.html
 
> Mozilla wants to set SO_NONBLOCK on the HTTP socket. It does not work 
> because we do not have support for it. :(
> Any volunteers to add this sockopt? No, don't count on me until PPP 
> is finished and documented (which is not too soon ;).
> The BSD netstack could help us here (since we have a BSD port).

But SO_NONBLOCK is a BeOS R5-specific socket option when 
SO_BINDTODEVICE is a BONE-specific one...
Anyway, there is a real mess on non blocking mode support in the stack, 
that right.
Several confusion between file descriptor FIONBIO ioctl() opcode, BeOS 
specifig B_SET_[NON_]BLOCKING_IO opcode and SO_NONBLOCK...

> Let's make our netstack a complete BONE replacement until Waltercon 
> (stability does not matter, only functionality-wise).

Again... what!?
When is WalterCon already? In June, right?

There's still several BONE features missing, like DHCP, BoneYard, 
libpcap support, and boot network configuration...
And... there is some choice to make before.
I know I'm not enough active, but we didn't even discuss about the best 
way to bring both R5 and BONE compatibility, I was expecting we could 
find a cleaner way than duplicating code.
Anyway...

> Every time I put such a cool task up you run away like Philippe. ;) 

Eh eh, they've learn from the best... runner away.
Sorry, can't resist.

> Philippe, where are you? I thought you have time now. 

I thought too. But in fact I only have one or two hour max per day, not 
very enough to dive deep in code.
I forgot how time consuming/wasting can be job. It's even worse when 
they're not paid.

I understand you can feel a loonely coder. But, as in the past, every 
time one is highly productive, the others can follow him, even if they 
would have find time to try.

> This team needs some more active people who test and fix.
> And are we not still waiting for a working BNetEndpoint (but it is 
> not a high-priority task)?

Indeed. I don't know if Scott is still lurking there and have found his 
never comitted NetEndpoint.{cpp|h} files somewhere on his disk.
Scott?

- Philippe

--
Fortune Cookie Says:

"It's men like him that give the Y chromosome a bad name."

Other related posts: