[openbeosnetteam] Re: general or PPP ideas

AAAAAAH! Outlook Express crashed two times when I tried to reply to this
mail. :(
So, here is a short answer:
You must tell the IP module which ip address it should use, so you need some
kind of settings!
I do not want to use _files_. I want to use the structures. Just the
Nathan's attributes idea and adapt it to settings for modules. IP would use
the structure to save nameservers and the ip-address and the netmask.
I do not want to use settings to save protocol ids! It's like ppp.conf. Look
at it and you know what I mean. But: it is not the file that I want to use,
but just the structure. I need some way to structure my connection settings
(which compressions, authentication method, ip settings, etc.). The Dial-Up
preflet or the dialer application will pass that structure to the PPP
module. The PPP module will know which authentication method to use and
which protocols to support. Maybe you want to use IPX for one of your
connections, so you must edit the settings file (the format in which Dial-Up
saves connections, like bone.conf or any other connection representation).
The preflet does not know how to handle IPX because it does not know the
needed settings like IPX ID (or something similar to an IP address).

I do not have any code at the moment because I want to design all add-on
APIs on paper first. They must work together correctly.
Do you think I should split up the authenticators in authenticator protocols
and user-password-DBs? I do not want to hard-code things like using the
users DB for authentication. Or is this okay for you? It would be difficult
to add support for LDAP, for example.

I will soon be ready with the general concept. Then I will start to make the
API and after that I will start coding the real PPP module.

Waldemar

----- Original Message -----
From: "Philippe Houdoin" <philippe.houdoin@xxxxxxx>
To: <openbeosnetteam@xxxxxxxxxxxxx>
Sent: Saturday, April 26, 2003 12:43 AM
Subject: [openbeosnetteam] Re: general or PPP ideas


> Hi,
>
> >AFAIK, each used protocol (IP, IPX, etc.) must be specified and
> configured
> >for each link (Ethernet, PPP).
>
> Configured? What do you mean?
>
> > How is this done at the moment?
>
> There's no specification of which protocol should be used by a link or
> not.
> Stack loads all protocols presents at startup, and each one, at init
> time, register itself
> against the stack as handling one or more specific protocol id/stack *
> level* pair for a specific
> *domain*.
>
> Example:
> src/add-ons/kernel/network/protocols/ipv4/ipv4.c:ipv4_module_init():
>
> add_domaine(NULL, AF_INET);
> add_protocol(&my_proto, AF_INET);
>
> my_proto point to a struct:
>
> struct protosw my_proto = {
> "IPv4", // protocol name
> NET_IPV4_MODULE_NAME,  // module path/name
> 0, // protocol type (SOCK_DGRAM, SOCK_STREAM, or 0 = n/a)
> NULL,  // domain list
> IPPROTO_IP, // protocol number
> 0,  // protocol flags
> NET_LAYER2,  // protocol layer level
>
> // follow protocol callbacks...
> };
>
> The layer levels here are known as DoD (aka pre-OSI, or TCP/IP, layers)
> :
>
> NET_LAYER4, Application Layer = OSI Application to Session Layers (raw)
> NET_LAYER3, Service Provider Layer = OSI Transport Layer (udp, tcp)
> NET_LAYER2, Internet Layer =  OSI Network Layer (ipv4, icmp)
> NET_LAYER1, Access Layer =  OSI Link and Physical Layers (ethernet,
> loopback, serial_ppp?)
>
> Current stack dynamicly build a protocols linked list.
> Each protocol can to get whole domain's protocols for what layer he
> want; upper on reception, down(er?) on transmission.
>
> > So, there is
> >no possibility to add a protocol by just adding the driver.
>
> That how current stack protocols module (or driver, if you want) do it!
>
> > It must be configured for each device.
>
> No.
>
> > This means that we need a good configuration
> >scheme.
> >I think that it would be cool to use a structure to describe a
> connection
> >(at least for PPP).
>
> By connection, you mean the protocols stack for one opened endpoint?
> Like BONE's bone.conf?
>
> I'm like Axel here, I really don't like external configuration when it
> don't offer you value-added.
> Protocols should discover each other themselves, by asking at runtime
> who is here, something like that.
> On reception, the upper protocol to pass packet to may even be select
> by stack's core, not on each
> protocol own schema:
>
> 1) ethernet get a new packet, check his integrity, extract the
> demuplexing "id"
> (let's say 0x8000 (ipv4) here), remove ethernet specific from packet
> and handle it to stack "core", telling "hey, here a 0x8000 packet, and
> don't ask me what's a 0x8000 packet as I don't care" :-)
> 2) stack "core" find which protocol(s) knows about 0x8000 packet kind
> at this stack layer level (network, aka NET_LAYER2 in DoD model): ipv4,
> but a peeper/sniffer protocol could too!.
> 3) He handle him (or them, if multiples) the packet
> 4) ipv4 extract the demuplexing "id" (let's say 0x06 (tcp) here),
> remove specifics, and handle it back...
> 5) stack "core" find which protocol(s) etc etc...
>
> On output, that's harder. TCP protocol require the sub-protocol being
> ipv4 or ipv6, and ip protocols can handle the packet to any link.
> Currently, it's hardcoded: udp.c:upd_output() explicitly call the layer
> 2 (Internet layer) IPPROTO_IP protocol handler. It's ipv4, obvioulsy.
> Same for our tcp protocol module.
> And same for raw protocol module, which BTW only support IP!
>
> >The structure describes which modules should be loaded and it defines
> >substructures to configure each module. This is useful especially for
> our
> >modular design (like I want to implement it for PPP).
> >The syntax should be the same as for driver settings. The settings
> code
> >could be reused and with our new OBOS implementation we can even save
> them
> >to disk or modify them easily.
>
> I don't agree about settings file when unnecessary, but
> Axel wrote already driver_settings API for OBOS:
> src/kernel/core/driver_settings.c
>
> >What do you think? At least, PPP should use this system.
>
> Dialup profiles are required for PPP link negociation, that's right.
> But for PPP sub-protocols, it would be better if they can rely on some
> registering mechanism against the main PPP module (their caller).
>
> >But, refering to the idea of using attributes for protocols/interfaces
> this
> >is a possible implementation. IPCP would add the nameservers to the
> dynamic
> >settings structure of the IP module, for example. This is similar to
> what we
> >discussed.
>
> Modifying a global settings file can't be enought, you'll have the
> stack to detect this modification.
> By notification or by pooling (bad!).
> However, if it's a dynamic, aka non-permanent setting, why storing it
> in permanent storage?
> Why not just telling the new DHCP-obtained IP address of a link by
> calling the stack control main function (ioctl()!) ?
>
> For DNS, as current implementation in our libnet.so is a BSD-like, I
> guess it's just a matter of adding/modifying to the /etc/resolv.conf.
> It's not much BeOS-ish, but maybe we could postpone for a better
> solution, no?
>
> >If you do not want to use this scheme for the whole netstack may I use
> this,
> >please? :))
>
> If you want, start with this schema.
> We always could make it better/clever afterward. If needed.
>
> BTW, do you have already some proof-of-concept code to show us?
>
> -Philippe
>
> --
> Fortune Cookie Says:
>
> "Hey!  Who took the cork off my lunch??!"
> -- W. C. Fields
>
>
>

Other related posts: