On Mon, Nov 30, 2015 at 10:53:35AM +0100, Bjørn Mork wrote: > Bjørn Mork <bj...@mork.no> writes: > > Reinhard Speyerer <rs...@arcor.de> writes: > > > >> On Sat, Nov 28, 2015 at 10:58:17PM +0100, Thomas Schäfer wrote: > >>> [...] > >>> I would be very happy if somebody tells me the steps for testing with PDP- > >>> context IPv4v6. > >> > >> Not sure whether this also applies to qmi-cli as I used a different > >> QMI client (which leaves network interface initialization to the > >> application) for a short dualstack test with Linux kernel 3.12.x and a > >> MC7304 but for me IPv6 only worked when explicitly assigning a > >> link-local address with e.g. > >> # ifconfig wwan<n> inet6 add fe80::1:2:3:4/64 up > >> when the network interface was set to raw IP mode instead of simply using > >> # ifconfig wwan<n> inet6 up > >> as no router solicitations were sent out otherwise. > > > > That's a very good point indeed! I didn't think of the possibility of > > supporting SLAAC over raw-ip interfaces. I only did manual address > > config on IPv6 too. Thanks for verifying that the modem replies to RS > > over raw-ip. > > > > I'll see if I can figure out what it takes to automatically assign a > > link local address for these interfaces. I guess that should be done in > > any case for proper IPv6 support > > 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. > > 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. > > 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? 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. Regards, Reinhard _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list