[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: ip-{up,down} scripts



>> "RL" == Remi Lefebvre <remi@master.debian.org> writes:

>> What about modem users with static IP adresses? They will also be
>> treated as "local". If you want to control the action in ip-up.d
>> scripts, the script can check if the remote ip is one to act on.

RL> The local address on a private network must be one of the private
RL> domain which is one of 10.0.0.0-10.255.255.255 ;
RL> 172.16.0.0-172.31.255.255 ; 192.168.0.0-192.168.255.255 as stated
RL> in the NET-3 HOWTO. If you use a modem with a static IP, this IP
RL> will most likely _not_ be in these ranges as they are reserved for
RL> local networks.

There are enough ISP's that assign these private IPs, so you can only
get out using their proxy.

But me and you, we are speaking about rather uncommon cases in
general.

Like: A laptop, connecting to the LAN at different access points via
serial cable and getting a non-private IP, as this LAN operates with
"real" IPs. Is this a local connect or not?

How about putting your code snipplet into /usr/doc/ppp with a nice
explanation? So someone interested in incorperation this functionality
can add it. Also try to make it less expensive (combineing the two
shell spawns into one or such).

Better yet, make use of the ipparam option of pppd. give the option
"ipparam internet" on modem connects and "ipparam lan" on local
connects. Then you can use case in the scripts, as this option is
saved as PPP_IPPARAM.

I also believe only the package maintainer can not make a valid
decision if his script should run in the "local" case. You mentioned
crony. But it have no difficulties to think of a case where someone
connecting with a serial cable can reach the ntp server without
problems, as the LAN has a gateway to the internet. So a user has to
edit the scripts in any case to accomondate to his specific means. And
the better case is, if he can assume that all scripts are run on every
connection (principle of least surprise). So there are no guesses
needed about how a maintainer thinks a package should behave on
"local" connects.

As I said, with the ipparam option, there is no problem distinguishing 
the connections.

Ciao,
	Martin


Reply to: