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 
you say...

> I dont know why a ppp should _ever_ have a netmask (other than
> 255.255.255.255).
> 
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 192.96.32.131 netmask 255.255.255.255
changed netstat -in from 
ppp0  1500  192.168.30.16 192.168.30.22        15382     0    15201     0     0
to
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 :-)

++L