[openbeosnetteam] Re: mbuf.h
- From: "Philippe Houdoin" <philippe.houdoin@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sun, 28 Sep 2003 14:01:09 GMT
> > 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?
Other related posts:
