Erik Nordmark writes:
> > Unfortunately, I don't think we can rip out this misbegotten swill too
> > easily, as the open source PPP code depends on it. It'll require some
> > careful testing.
>
> What part depends on the kernel setting IFF_POINTOPOINT when it receives
> a SIOCS{,L}IFADDR on a non-IFF_POINTOPOINT interface?
>
> Looking at sppp source code it passes up a dl_info_ack which makes IP
> set IFF_POINTOPOINT (A zero length phys address makes IP do this.)
I was referring to the open source version, which is quite different
from the one in OpenSolaris today. (Particularly in the kernel
modules, which we had to rewrite substantially to pass ON muster.)
I went back to the external code and had another look. It does set
dl_addr_length and dl_sap_length both to 4, so it looks like this one
should "just work." That doesn't match what I thought I remembered
from testing, though.
Erik Nordmark writes:
> The offending code I was thinking of is this code in ip_if.c
> if ((ipif->ipif_flags & IPIF_POINTOPOINT) == 0) {
There are more offenses here than that. There's no way that
IFF_POINTOPOINT can be in ipif_flags. It has to be an ill_flags or
(better still) phyint_flags value because it's a property of the
underlying interface itself, not a per-logical-interface matter.
> I think that would return EINVAL or EADDRNOTAVAIL on other OSes.
4.4BSD returns EINVAL. Linux 2.6 seems to be happy with the ioctl,
but no clue what mischief the ioctl actually causes down below.
Erik Nordmark writes:
> Thus I think what is in dl_info_ack is sufficient to make this work AFAIU.
I think I agree ... I'd also want to see careful tests done, though.
It's ugly, and it's been there forever.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]
