Reinhard Speyerer <rs...@arcor.de> writes: > On Mon, Nov 30, 2015 at 10:53:35AM +0100, Bjørn Mork wrote: > >> hmm, "fixing" this seems simple enough: Just add the necessary code to >> net/ipv6/addrconf.c for handling ARPHRD_NONE devices. But I have two >> questions: >> >> 1) will random addresses be a problem? We might have to recreate the >> address every time the interface comes up, as we have nowhere to store >> it AFAICS. So the link-local address will change whenever you toggle >> the device down/up. > > This might invalidate some fundamental assumptions in the firmware about > the host environment. My suggestion would therefore be to avoid changing > the link-local address when changing the network interface up/down status.
Yes. That's definitely so unexpected that it's better not to implement it at all.. >> 2) what about other ARPHRD_NONE devices? This is currently 'tun', 'hso' >> and 'n_gsm'. Will a default IPv6 link local address be a problem for >> any of these? >> >> The only device type I know how to test is 'tun'. And to me it looks >> like an obvious winner there. Why shouldn't tun devices do SLAAC and >> support other IPv6 link local services by default? But I don't normally >> use such devices, so I know very little about real use cases... > > Since tun may have non-IP use cases and n_gsm is a line discipline AFAIK > we should probably not overload ARPHRD_NONE like this. I'm not sure that would be a problem, any more than using ethernet for non-IP is one. >> If we can't add such generic ARPHRD_NONE code, then the alternatives I >> can see are >> - defined an new ARPHRD_ type with about the same semantics, and add >> ipv6/addrconf code for it >> - do some driver hack - I believe it is possible to manually create an >> IPv6 device and assign an address from the driver. >> >> I don't like either. So I guess I will propose the ARPHRD_NONE code. >> > > Perhaps it might be possible to use raw IP mode with IPv6 without a > link-local address by using WDS status indications? It's definitely possible to use raw IP with IPv6 without a link local address. But I don't think it should be :) > The reason I used > the original ifconfig inet6 up implementation was that this was > required to trigger SLAAC according to ETSI/3GPP TS 27.060 for early > MC77xx firmware versions as WDSGetCurrentSettings did not return an > IPv6 prefix when WDSStartNetwork was finished. > > However at least current MC73xx firmware versions (and perhaps also > other "modern" QMI firmwares) now proactively perform an internal SLAAC > after a WDSStartNetwork and WDSGetCurrentSettings returns the same IPv6 > prefix as an ifconfig inet6 up with SLAAC in Ethernet mode would. If > mReconfigureRequired from the WDSPacketServiceStatusReport TLV 0x01 > would correctly indicate when the IPv6 prefix assigned from the > network has changed it might be possible to mirror the effect of SLAAC > for raw IP from user space. Yes, I know that the prefix could change - in theory. I have my doubts whether that would actually work in the real world. The status is about the same as for IPv6 renumbering elsewhere: All the necessary tools are there so you can make it work, but every user and device have made some bogus assuption that needs fixing first. I don't think we are any more guaranteed that renumbering will work with SLAAC than without. The chances are about the same. And I believe the good NM people will want to do SLAAC in userspace anyway. So the missing link local address might be a non-issue for NM? In any case, I got very helpful feedback from YOSHIFUJI Hideaki so I am considering implementing a random (but permanent) ifid allocation scheme after all. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
