Re: MC 7304 ipv4v6

Reinhard Speyerer <rspmn 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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]