[openbeosnetteam] Re: PPP: dial-on-demand

> > For those who did not understand:
> > This is just a joke (see the smileys). ;)
>
> I guess that not *only* a joke, right?

Of course not *only*. :)
But the question about my stupidity was not serious. ;)
It is important that it worked and enforced someone to answer this mail. ;))

Thank you for your reply.

> > Hi,
> > before I implement something that would never work with our stack,
> > could
> > you please help me with some (basic?) BSD stuff?
>
> Part of the problem in answering your question is nobody knows here
> that much
> BSD stack internals.
> Me included.

Well, it seems that I have to suggest a new netstack again. :)
Nathan had a good idea for the netstack. Why do we not build upon that idea?
I did look at your netstack very much, but it is written C, not C++, which
is a pitty. ;)
With Nathan's netstack I had the impression that it would be easy to use.

> A second part of the problem, and that may be only my opinion here, is
> we (I?) want to
> build a network stack the BeOS philosophy way. That is:
> - modular
> - dynamic (loading and unloading) of components/addons/protocols/
> whatever
> - light and clean architecture/design
> - clever code
> - easiest to maintain and understand as possible
>
> For me, BSD code fall far away in some points here, and the current
> stack code, mostly inspired if not ported (mbuf anyone!?) is
> hard to maintain, fix and expand for this same reason: before, one need
> to become familiar with many BSD stack design concepts.

That is very very true. Therefore we should try to make a C++ netstack.
I hear some people cry "no, some will not like C++", but maintaining,
understanding and reading the code is far easier than with any C stack.
Nathan's netstack can be much cleaner than any C stack, IMHO.
Putting everything into small objects and assigning good names and using
inheritance would result in a powerful stack.

One reason for C++ is that C looks more cryptic than C++.

> Being POSIX/BSD sockets API don't means using BSD stack design, just
> that we should support
> as much as possible of *public* BSD network API:
> - sockets API
> - BINDeries API
> - network-related POSIX includes files, where they should be and what
> they should containt
> - some most expected network command line tools, like route, ping,
> traceroute, ifconfig, etc...

Agreed.

> > I plan to implement dial-on-demand the following way:
> > When an interface registers itself to the ppp_interface_manager it
> > gets an
> > ifnet structure assigned.
> > The if_flags are set to IFF_UP | IFF_POINTTOPOINT.
> > This happens will all interfaces regardless whether dial-on-demand is
> > set
> > or not.
>
> Make sense.
>
> I know that current stack design allow to *register* an (or multiple)
> interface(s)  only at module load time, and not after.
> That's a flaw, and PPP (virtuall) interfaces requires this feature.
> However, I don't see the need for a separate ppp_interface_manager, a
> "ppp" module loaded by the core stack should be enough,
> if it support dynamic interface registration.
>
> BTW, my pet new_stack project, located under current/src/tests/kits/net
> /new_stack/* support this.
>
> I don't know if

The ppp_interface_manager module actually is that "ppp" module you talked
about with the difference that it has some extensions like a "kill" thread
to delete unused interfaces. It will also have get_interface and
put_interface so that it does not delete an interface that is in use by some
driver/module or a userland app and it will feature a "live-query-like"
method to be notified when interfaces are added/deleted.

> > The following is only done with dial-on-demand interfaces:
> >
> > 1) The IP Control Protocol adds itself as the default route and uses
> > an
> > undefined class A dst address (?10.0.0.1 + if_unit?) and an undefined
> > class A interface address (?10.127.0.1 + if_unit?).
>
> Okay, time I look at this IPCP chapter in TCP/IP Illustrated.
> :-)

I think you will only find it in the RFCs 1332 and 1877 as they are
PPP-specific and that book merely has a very short ppp summary.

> > BTW, do we have a function
> > that returns the netmask of some ip-address?
>
> You mean, compute the netmask from any ip-address?
> I'm not sure, no.
> Maybe in ifconfig.c...[checking...], no.
>
> Okay, what we have is these macros in current/headers/posix/netinet/
> in.h:
>
> IN_CLASS[A|B|C|D] for testing ip address class;
> IN_CLASS[A|B|C|D]_NET for class ip net address.
>

That should work. Thanks.

> If "Is ok" = succeed to set new interface dst address, yes it do that:
> curent/src/add-ons/kernel/network/core/in.c:in_control(), line 308:
>
> -----8<-----------------
> case SIOCSIFDSTADDR:
> if ((ifp->if_flags & IFF_POINTOPOINT) == 0)
> return EINVAL;
> oldaddr = ia->ia_dstaddr;
> ia->ia_dstaddr = *(struct sockaddr_in*)&ifr->ifr_dstaddr;
> /* update the interface if required */
> if (ifp->ioctl) {
> error = ifp->ioctl(ifp, SIOCSIFDSTADDR, (caddr_t) ia);
> if (error) {
> ia->ia_dstaddr = oldaddr;
> return error;
> }
> }
> /* change the routing info if it's been set */
> if (ia->ia_flags & IFA_ROUTE) {
> ia->ia_ifa.ifa_dstaddr = (struct sockaddr*)&oldaddr;
> rtinit(&(ia->ia_ifa), RTM_DELETE, RTF_HOST);
> ia->ia_ifa.ifa_dstaddr = (struct sockaddr*)&ia->ia_dstaddr;
> rtinit(&(ia->ia_ifa), RTM_ADD, RTF_HOST|RTF_UP);
> }
> break;
> -----8<-----------------

Thanks.

> > Which ioctl should bring the interface up? SIOCSIFFLAGS or
> > SIOCSIFADDR or
> > both?
>
> According to current stack code, I'll say SIOCSIFADDR, but it will make
> sense to
> to handle correctly a SIOCSIFFLAGS with IFF_UP set for a PPP interface.
>
> > How do I prevent changing the interface's ip?
>
> Hum, really don't know. Except by rejecting SIOCSIFADDR in your PPP
> interface ioctl() hook...

So, if I want to set the address I must set it before the ioctl and then
call ioctl so that the netstack stuff also works correctly?
The ioctl would then just return B_OK if they are equal (which pretends that
we changed the IP).

> > Do I have to add an ifaddr for each protocol?
>
> No. Each interface stores his own addresses in an global ifnet_addrs
> list, for all domains.

I do not understand this.
How are the ifaddrs added to the ifnet? It must somehow know which addresses
it supports.

> > 3) A Down() (or whatever might cause it) will bring us back to 1)
>
> Or a timeout. Each packet received or sent should reset this timeout.

I will implement it.

> > Do you think this will work?
>
> I'm far to fully understand both all these points and the current stack
> internals to "think" it will work.
> I just *feel* it *may* work...
> :-\

That is a start, at least. ;)

> BTW, did you give a look at first draft ppp & serial_ppp code that was
> included in the old net_kit backup
> http://philippe.houdoin.free.fr/phil/beos/openbeos/network_kit/
> obos_net_kit-20020822.zip ?

Yes, but I must admit I do not like it. :)
The C interface looks too complicated and ugly. This does not mean the code
is bad, but I do not like reading C.
Sometimes it helps a little bit to look at that code, but I prefer the
bigger pppd implementations for BSD/Linux, though they are full of
statically compiled-in stuff so that the code is very blown-up.

Waldemar

Other related posts: