Re: MC 7304 ipv4v6

[Dan Williams <dcbw redhat com>]

On Tue, 2015-11-24 at 22:51 +0100, Bjørn Mork wrote:
> 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.

My vote would be sysfs, with values "raw-ip" or "802.3" that you can
read and write to the file.  At least then they are human-readable. 
 It's also easier to use from scripts than parsing ethtool output.

Dan