On Fri, Nov 24, 2017 at 07:25:19PM +0100, Bjørn Mork wrote: > Reinhard Speyerer <rs...@arcor.de> writes: > > > before posting this problem report > > https://developer.gemalto.com/threads/ipv6dualstack-problems-pls8-e-revision-03017 > > in the Gemalto developer forum I tested the qmi_wwan/cdc_ether changes > > you suggested above and apart from having two working QMI interfaces > > the IPv6/dualstack problems observed with AT^SWWAN/cdc_ether were > > also gone when using WDSStartNetworkInterface and the QMI interface in > > raw IP mode instead. > > Right. I did not know about the "carrier off" issue. But messed up > ethernet headers is a well known problem with all these Qualcomm based > modems. Switching them to raw IP mode is often the only way to make them > work consistently. > > Having seen this problem with multiple vendors, where some even have > borrowed our workarounds for their own out-of-tree drivers, makes me > pretty sure that it isn't easily fixable. It's a Qualcomm bug, and I > guess no one is allowed to even look at the code. Much less change it. > Which makes sense given the mess it must be... > > > Unfortunately Gemalto does no seems to be willing to provide an > > alternative USB composition which includes QMI interfaces for the > > PLS8. Therefore applying the above changes to qmi_wwan/cdc_ether might > > make the PLS8 network interfaces stop working when Gemalto decides to > > replace their f_rmnet gadget in CDCECM mode with a f_ecm gadget when > > releasing a firmware update. > > I don't think this is necessarily a problem. Only the QMI control > channel will stop working should this happen. The qmi_wwan driver will > provide the same network device support as cdc_ether, using CDC ECM > framing. > > And to be honest, such a redesign of the modem application for a mature > product is very unlikely, isn't it? Why would Gemalto want to do all > that extra work, taking the risks involved? For what possible purpose? > This is probably the reason they don't want to mess with alternative USB > compositions either. > > In any case, I think it is worth adding this device to qmi_wwan if it > works with current firmwares and you, or anyone else, finds it useful. > And it does sound like that based on the IPv6 issues you mention.. > > But I'll leave the decision to you or anyone else with such a device.
Hi Bjørn, given that the PLS8 USB PID 0x0061 is also used by firmware version 02.x which has been relased quite some time ago I'm afraid switching it from cdc_ether to qmi_wwan in the mainline Linux kernel now might break too many existing/working setups even if only for the changed interface name. Since Gemalto also seems to have moved away from supporting USB compositions with a QMI interface with newer firmware versions in general they might as well reserve the right to reject problem reports submitted to them when not using their AT^SWWAN/CDCECM setup. Therefore I will not submit patches which switch PLS8 with USB PID 0x0061 from the cdc_ether to the qmi_wwan driver. If there are other PLS8 users who don't share my concerns: please feel free to submit the patches yourself. Let's hope that Gemalto is able to fix the AT^SWWAN/CDCECM-specific IPv6/dualstack problems in their forthcoming PLS8 firmware version 04.x or provides an alternative USB composition if the effort for fixing the bugs would be too high. Regards, Reinhard