On Tue, 2015-11-24 at 22:51 +0100, Bjørn Mork wrote: > Reinhard Speyerer <rs...@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 _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
