FreeLists / openbeosnetteam / [openbeosnetteam] Re: mbuf.h

["Philippe Houdoin" <philippe.houdoin@xxxxxxx>]

> > Solution to fix that issue need more consideration.
> 
> Why do we not fix it by finishing your new netstack together? ;)
> I would stall PPP until the netstack is usable. The current netstack 
> is not usable, either, so I can only help finishing one of the two 
netstacks to be able to finish and test PPP.

The current net stack is far usable than new_stack is, or will be in 
mid term.
 
> We have an alternative in our repository. May I help? What needs to 
> be done to get ethernet support?

Ethernet layer support is there. The new_stack ethernet layer module 
wrap any /dev/net/* R5-ethernet compliant driver and start to read from 
it, pushing any new packet of data up into stack... which fall flat 
shortly, as the stack don't have layers chaining assembly implemented 
yet. 

Loopback layer is there, too, but yet as no upper protocol is 
implemented nor chained to him, no packet can reach him currently.

This network layers assembly is the major step I should work on.
Maybe Nathan Whitehorn, if you're still lurking here as I hope you do, 
could you help us on 
this topic, even if we've already discussed it before here...

What I've in mind is that each packet handler (that could be packets 
producers, consumers or both) have a upper (input) handlers list and 
downer (output) handlers list. But I don't think yet on how to assemble 
them, possibly with what Nathan call a layer name "protocol/flavor". 
See previous posts here about this topic...

Another design point I've in mind is every stack addon should follow 
the same API, even if it don't implement all hooks.

> OTOH, I cannot test the ethernet interface because I do not have a 
> network (only PPPoE).
> Would loopback be sufficient? :)

If you use PPPoE, you have an ethernet device in your system, or I miss 
something?
Obviously, to test [new_]stack you need to disable it in BONE or 
net_server so that you can open it.
 
> IMHO, it will be unnecessary work to solve the bug. Let's get the new 
> netstack working.
> What is the new netstack's status?

It's far from being even ready to do such simple thing like a "ping".
Even ARP support is not there...

And it's "C" API, not C++. You all know why, I hope.
The new_stack is currently hosted bu an userland app called 
net_stack_server, that emulate kernel modules API, 
making debugging the stack easy. 

If you wan't to see how it's working, here a *ready-to-try* version:
http://philippe.houdoin.free.fr/phil/beos/openbeos/network_kit/
new_stack-20030928.zip

To try it, assuming you've at least one /dev/net/* device free to be 
used (disable it from Boneyard or net_server), run from Terminal:
$ cd /where/ever/you/expand/the/zipfile/new_stack
$ net_stack_server

This stack host app load then start it, which in turn load stack layers 
modules, a.k.a ethernet devices & loopback interfaces and an empty arp 
layer...

If you wait enough and have another machine or internet connected to 
your device (a ping runned from remote machine could help here to fire 
an ARP request over network), you should see some packets coming and 
dumped by the ethernet layer.
And that's pretty much all what's working/implemented today.

-Philippe



--
Fortune Cookie Says:

Real Programs don't use shared text.  Otherwise, how can they use
functions for scratch space after they are finished calling them?