Bjørn Mork <bj...@mork.no> writes: > 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. > > 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... > > 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.
Just FYI: I ended up with an automated random address, which will be stable for the lifetime of the interface. This has now been accepted into net-next, so SLAAC will be in place along with the qmi raw-ip support in v4.5. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
