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. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list