[openbeosnetteam] Re: Interfaces

On 7/12/06, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote: 
> > There is no ppp net_device loaded when I use PPPoE. Even though
> > there
> > exists such a device, I have no idea when it comes into play.
> Well, that's strange because above the device layer PPP is the same
> protocol. If the PPP module is not loaded then the PPPoE module must
> contain a copy of the complete PPP stack...

I didn't say that there are no PPP modules loaded - but there is no (in
BONE terms) PPP interface loaded (interfaces/bone_ppp). The rest is
there.
BTW do you have any idea what "pppd" is for in BONE? It also doesn't
seem to be of any use. I can start it only if there is a PPP logical
interface, and then it periodically dumps some junk to the terminal.


I guess that it is needed for serial modems. The whole connection
phase ("chat") is normally (BSD, Linux, BeOS) handled in a separate
application that loads a connection script (those "chat" scripts). But
this is just a guess.

> I'm not sure you understood my concern. Did you ever try RASPPPOE on
> Windows? It requires the NIC to have an IP address. This is a similar
> problem. When I try to send a packet through an unconfigured
> interface
> the ethernet module just rejects the packet. The problem is that I
> can't mark PPPoE as an active protocol independently of IPv4. I can
> only bring the whole device up/down. Our new netstack should make
> this
> more independent.

I'm still unsure I get what you're saying.
You can just create the PPP interface and leave it down (unconfigured).
If you then try to send (or receive) some data through it, it would
need to automatically "up" itself instead of rejecting the request.
There is an IFF_AUTOUP flag in BONE that I would guess is thought for
exactly that usage.


I was talking about the ethernet interface, not the PPP interface. As
long as the ethernet interface is down I can't send any packets. As
long as the ethernet interface is unconfigured (no IP) it's down.
Thus, I can't send PPPoE packets over ethernet interfaces that don't
have an IP address, so I have to assign some address like
"192.168.0.1" just to be able to use PPPoE over that ethernet
interface.

> And why did you specifically talk about AF_INET? That depends on the
> protocol modules that are used for the PPP interface. I think I've

You specifically talked about IPv4 missing, and that would be in
AF_INET.


Ah, understood. :)

> overmodularized the PPP stack...is there any point in having it
> modular, at all?

Dunno, probably not too much ;-)
It makes sense to separate PPP from PPPoE, so that you could have
serial PPP as well, but beyond that, I don't know.


Well, the device code is already separated from the interface code.
I think I'll make the whole PPP stack monolithic when I find the time
to do it. That will save a few lines of code and get rid of the
static-lib mess in the kernel.

> BTW, you once wanted PPP to create a net_device for every interface
> even if it's not connected (instead of creating them on-demand). Is
> this what you plan for the new netstack? The way you talk about PPPoE
> gives me this impression. Well, the advantage could be that you don't
> need a special pppconfig command because ifconfig could issue the
> up/down actions.

Still, there is no net_device anywhere to be seen. But if you want to
use PPP you sure have to create an interface for it (either through
ifconfig or a dedicated application). Also in the auto dial case.


The way I imagined it would be to use node-monitoring to watch the
interface configuration files. If a new file is created the respective
net_device is automatically created, too. Deleting or changing the
configuration file results in the net_device being deleted/updated.
The default PPP interface (if there is one) is in connect-on-demand
mode. You can bring an interface up/down manually using ifconfig. PPP
interfaces would behave like ethernet interfaces, so applications
don't need special API code for handling PPP interfaces.

> How will protocols register themselves with the net_device? One party
> (protocol or, preferrably, the device) has to know the link-layer
> type
> IDs for the respective protocol (IPv4, IPv6, PPPoE). For example,
> ethernet has different packet type IDs than PPP and other devices.
> Will protocol IDs be hard-coded in the device or will it be possible
> to add new handlers by supplying the device's protocol type ID?

I am not sure what you mean. Are you asking how the received packets
are dispatched to the correct protocol?


Yes. :)

Bye,
Waldemar Kornewald

Other related posts: