Re: MC 7304 ipv4v6

[Bjørn Mork <bjorn mork no>]

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