James Carlson wrote: >Steven Stallion writes: > > >>I was afraid of that. >> >>I threw together a quick patch last night which simply diabled the >>command in ifconfig that sets a new destination address (which results >>in the POINTOPOINT flag being set on the interface); nothing fancy. >> >> > >There are two potential problems here. > >I consider the problem in ifconfig to be at worst a cosmetic problem, >and perhaps not even a problem at all: it allows the user to generate >an ioctl that by rights ought to fail. As a design matter, I don't >really see that as a problem worth fixing, unless it somehow doesn't >manage to handle the error returns correctly. > >The other problem is the kernel. It's _allowing_ you to do something >that's clearly wrong. There's no getting around that one -- broadcast >type interfaces simply do not have a configured "destination address" >and can never have one. Allowing the ioctl to "succeed" -- and worse >yet corrupting the interface state as a result -- is a clear-cut bug. > >
Why shouldn't I be able to do: # ifconfig bge0 1.2.3.4 5.6.7.8 up if the cable that from bge0 goes to bge0 on another box? That sure seems like "point-to-point" to me. >>Either way, what is the best method to proceed? I submitted a bug last >>night with a category of networking / ifconfig (there is a reference to >>this thread in the description). >> >> > >I don't think that's the right thing to fix. > > I agree. I think what needs fixing, in the first instance, is to allow ifconfig to reset IFF_POINTTOPOINT if it is setting the broadcast address or netmask. Darren _______________________________________________ networking-discuss mailing list [email protected]
