Subject: Re: Interface specification in route(8)
To: None <email@example.com>
From: Lucio de Re <firstname.lastname@example.org>
Date: 02/23/1999 14:19:43
According to Ignatios Souvatzis:
> IP version 4 point to point links, be it PPP or SLIP, be it 4.3BSD or 4.4BSD
> derived systems, semantically do not create a network of their own.
Accepted, although, for example, my Novell MPR (which is admittedly
pretty ancient, but seems built to the most rigid standards) expects
the ppp link to be its own subnet - doesn't do unnumbered or any
> The kernel routes by looking wether the single remote address matches, when
> it finds an interface with the POINTTOPOINT bit on.
Does a point-to-point link get treated exceptionally, in this respect,
or is this merely a generalisation of existing kernel semantics?
> This is 99% of a real unnumbered interface: you can share the IP address of
> your Ethernet as your local address.
That really appealed to me, but then it is not clear from the
documentation that I need to specify a 255.255.255.255 mask because
otherwise pppd adopts not only the Ethernet address, but also the
netmask (I'll SEND-PR that, if I can find a way to fix it).
> I dont know exactly what happens when you ifconfig (or the ioctl pppd does)
> a POINTTOPOINT interface to a non-FFFFFFFF netmask. Apparently, it creates
> a routing table entry with that netmask, which lateron causes trouble. I've
> witnessed this all the time since I took over the PPP FAQ. Just dont do it.
Happens by itself, no cooperation from me :-) And it does break, as
you suggest, and it shouldn't be done. But it is probably OK for
numbered point-to-point links. I do use it in Cape Town, with slightly
ppp0 1500 <Link> 56200 3 65443 0 0
ppp0 1500 22.214.171.124 126.96.36.199 56200 3 65443 0 0
ppp1 576 <Link> 17343 4 16152 0 0
ppp1 576 188.8.131.52 184.108.40.206 17343 4 16152 0 0
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
inet 220.127.116.11 --> 18.104.22.168 netmask 0xfffffffc
ppp1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 576
inet 22.214.171.124 --> 126.96.36.199 netmask 0xfffffffc
both interfaces are intended to have their own subnet, I'm not sure
when the first one relinquished the 188.8.131.52 in favour of
184.108.40.206 within 220.127.116.11 (!?)). Here, the netmask is
explicitly set and the default result is positively evil (.139 is the
broadcast in .136/30)
Also, there's no guarantee that pppd will choose the "right" Ethernet
interface. We may be lucky in Cape Town that it wasn't ne1 or ne2 it
chose as its number, after being told (Ha! I think our ISP has changed
parameters) to use its own.
In fact, in the first instance, we do not specify or request the IP
numbers for the subnet, our ISP presumably specifies their end, whereas
in the past it specified both ends.
Instructive, indeed, but there are definitely defects that could be
eliminated for the sake of the principle of least surprise.
Also, while I'm asking, I did ask once how to make sure that ppp0 was
associated with a particular tty and ppp1 with another, and suggestions
were made that I distractedly lost. Is there an archive I can seek
these responses, or does someone have a simple answer to this?