Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 12 Jul 1998 12:18:02 +0200 (CEST)
From:      Malte Lance <malte@webmore.com>
To:        Martin Husemann <martin@rumolt.teuto.de>
Cc:        hohmuth@innocent.com, freebsd-isdn@FreeBSD.ORG, hm@hcs.de
Subject:   Re: fallback-IP-addr for dyn. dials. Is there any use for it ?
Message-ID:  <XFMail.980712121802.malte@webmore.com>
In-Reply-To: <199807120904.LAA02855@rumolt.teuto.de>

next in thread | previous in thread | raw e-mail | index | archive | help

On 12-Jul-98 Martin Husemann wrote:
> Uhh, sorry,
> 
>> I found it just annoying to add this 0.0.0.0-"trigger-rule" into my
>> firewall-file and i did not for sure knew what implications such a rule
>> would have. And i found it much neater to just add "dynlip" to the
>> 'spppcontrol'-call instead of configuring the sppp-device with a magic
>> 0.0.0.0 number. Yes, 0.0.0.0 is magical for routing and that's ok, but
>> why config a device with 0.0.0.0 ???
> 
> Have to admit I'm still running this other software on that router (where
> I can assign any address and get dynamic ip address assignement on both
> sides of the link) :-(

Hä ???

> Yes, you are right. The 0.0.0.0 and 0.0.0.1 hack are realy ugly hacks
> and have to go. I talked to Gary about this right after they came in
> and he basically agreed, but wanted to keep our sppp as close as possible 
> to the standard sppp in the FreeBSD tree.

Hm ... there is not much in the standard-sppp to conform to. The code is
just a basic ground for
- attaching and detaching the devices (sppp_attach, sppp_detach)
- input and output via lower-layer (sppp_input, sppp_output)
- input, output and work-functionality for cp (sppp_lcp_input, sppp_cp_send)
- ioctl-handling (sppp_ioctl)

Joerg Wunsch made a major rewrite of this code and did a good job as he
mostly injected new functionality (and mainly not changed the existing
code).
The problem i saw in the standard-sppp-code is, that the code is missing
basic low-level features like
1. routing (no routing-code at all)
2. buffering of outgoing packets with a temporary wrong IP-addr (no code at all)
3. aliasing (no code at all)

Explanation of 2.:
Assume i configured my sppp-device with 0.0.0.0 for dynamic local IP-addr
assignment and dynamic dial-out. Then i set a default-route via
"-interface isppp0". When an outbound packet arrives, it will be sent via
sppp. When the connection is down at that time, the Open-function of lcp
is called and the dial-out is started, while the outbound-packet is enqueued
with the src-IP-addr of 0.0.0.0 and therefor there will be no response for
that packet. This case is acceptable for DNS-queries, since named boosts
several packets in short periods out. But for HTTP-queries, where the timeout-
value is rather high, it is extrem annoying for some user when there is no
fast response (even no "something unreachable"). Sometimes, the timeout is
that long, that sppp closes the connection in the meantime (that's the worst
case).

Correct code for routing would have the side-effect of stopping the natd-whining
on this list.
If the sppp-development is taken serious, routing and aliasing MUST be there.
Rewriting of src-IP-addr for dynamiclly assigned local IP-addr'es may be a
bonus.

My personal suggestion would be to port user-ppp or kernel-ppp to work with
i4b and inject the cisco and other parts of standard-sppp into this code,
since the question of inventing the wheel several times always stands.

Malte.

> 
> The flag in sppcontrol is the right way to go. We need "we-have-dynamic-ip"
> and "they-have-dynamic-ip" flags.
> 
> So now: let's either break our incompatibility with the standard sppp even
> more or move the standard sppp to a clean solution (or do the former right
> now and the later as soon as possible).
> 
> 
> Martin
> 

----------------------------------
E-Mail: Malte Lance <malte@webmore.com>
Date: 12-Jul-98
Time: 11:36:18
----------------------------------

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isdn" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980712121802.malte>