Bjørn Mork writes:
> Bjørn Mork writes:
>> Reinhard Speyerer 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 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 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