Subject: Re: Interface specification in route(8)
To: Ignatios Souvatzis <firstname.lastname@example.org>
From: Lucio de Re <email@example.com>
Date: 02/23/1999 13:27:13
According to Ignatios Souvatzis:
> Uhm, he _did_ number it, and he assigned it exactly the same numbers as to
> the ne1.
That's pppd's default behaviour, and it sounded cool to me. But, as
> I dont know why a ppp should _ever_ have a netmask (other than
I'll dig through the sources, you _do_ have a point, but it seems to
contradict the default behaviour. I think the two are irreconcilable.
I guess we'll have to consider permitting unnumbered links, no matter
how complex the implementation, to disambiguate in situations such as
this. At worst, we'll need to forbid the current behaviour where pppd
assumes the first existing interface address as its own.
> Once people remove it, most of their problems go away.
I hadn't thought of that (or, more precisely, to set the netmask on
that interface to 255.255.255.255. Let me see if I can try it...
Well, I'll be damned:
ifconfig ppp0 netmask 255.255.255.255
did nothing, but
ifconfig ppp0 192.168.30.22 22.214.171.124 netmask 255.255.255.255
changed netstat -in from
ppp0 1500 192.168.30.16 192.168.30.22 15382 0 15201 0 0
ppp0 1500 192.168.30.22 192.168.30.22 15711 0 15529 0 0
which is desirable, and, adding the default route now understandably
uses the _only_ interface that can reach the gateway.
I'm impressed, although I think the entire problem hinges around some
very loose implementation of underspecified standards. I would prefer
some discipline being applied here :-)