Re: MC 7304 ipv4v6

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"
described here .

Apparently the qmi_wwan patch contained in the thread was not
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
fixup magic ten times worse. And at the time I was in doubt whether
use case was really important enough to warrant a workaround as ugly
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
that will stick there... And I forgot all about it. Sorry

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

Thanks for bringing this up again.  I guess we must do something
it.  But..... given the current MC74xx development, I'm really
to say 'use raw IP' in this case.  The thing is, it looks like we
to support raw IP mode anyway. If so, then we might as well (ab)use
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
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,
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
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
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.


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