Re: MC 7304 ipv4v6

[Bjørn Mork <bjorn mork no>]

Reinhard Speyerer <rspmn arcor de> writes:

> This looks rather similar to the "Dualstack errors with MC7354" problem
> described here https://forum.sierrawireless.com/viewtopic.php?f=117&t=8295 .
>
> Apparently the qmi_wwan patch contained in the thread was not submitted
> as a Linux kernel patch so far.

Ouch, bad conscience hitting hard... Again.

The patch will probably solve the problem, but it makes all the header
fixup magic ten times worse. And at the time I was in doubt whether the
use case was really important enough to warrant a workaround as ugly as
this.  So I wanted to let it rest in the back of my head for a while,
before making up my mind. The only problem is that there is very littly
that will stick there... And I forgot all about it. Sorry

(Note that I'm definitely not criticizing the code - it's ugly because
this is an ugly problem. And as the thread shows, I failed to create the
simple solution I hoped for.)

Thanks for bringing this up again.  I guess we must do something about
it.  But..... given the current MC74xx development, I'm really tempted
to say 'use raw IP' in this case.  The thing is, it looks like we have
to support raw IP mode anyway. If so, then we might as well (ab)use it
as workaround for any such header problem instead of adding even more
specialized ugly header rewriting.

What do you think?  Is "dual-stack on MC7354" another candidate for raw
IP? If we are going to add it anyway, that is.

Anyone have any wishes for raw IP driver API/UI?  So far I've added
about 3 such APIs, and they are all different, non-standard, difficult
to understand and dissatisfying in all ways.  So I think it's best to
use a completely new method now ;)

Seriously, if anyone has a good idea then I'm all open for
proposals. The only requirements I have is that it should be runtime
configurable and it must be settable per netdev.  I.e., you should be
able to use both 802.3 and raw-ip qmi_wwan devices at the same time.

The current approach I use for testing (which I believe I have posted a
few years ago) is ethtool private driver flags.  That's at least a
standard API.  But I'm all open for sysfs too. Either way, user space
will have to know about this setting and what it's good for.  And sysfs
has the advantage that you don't need any tool to use it. The cdc_ncm
sysfs files slipped in without much trouble (although I don't know if
anyone are using them), so I guess we have a fair chance getting
something like qmi/linkprotocol or similar accepted too.


Bjørn