[LEDE-DEV] Broken hotplug of USB 3G modems (packages wwan and uqmi vs. netifd) — advice needed

[Ivan Shapovalov]

On 2018-01-15 at 06:17 +0300, Ivan Shapovalov wrote:
> Hello,
> 
> I've noticed a bug in LEDE's handling of USB 3G modems using QMI
> protocol (at least), which leads to broken hotplug. It's actually
> been
> present for quite long (since BB or CC). I've tracked down the root
> cause but I'm unsure where (as in which project's bugtracker) would
> be
> the best place to report it or how would be the best way to fix it
> (see
> below for the actual question).
> 
> The problem is that QMI proto handler clashes with netifd proper over
> the interface's "device" property. QMI proto handler uses "device" to
> specify the cdc-wdmN device node path[1], e. g.:
> 
> root at router:~# cat /etc/config/network
> 
> <...>
> config interface 'wan'
>         option proto 'qmi'
>         option device '/dev/cdc-wdm0'
>         option apn 'internet.megafon.ru'
>         option auth 'none'
> 
> [1]: https://wiki.openwrt.org/doc/uci/network#protocol_qmi_usb_modems
> _using_qmi_protocol
> 
> At the same time, netifd clobbers "device" in the UCI state files in
> runtime, setting it at least from the following places:
> 
> /etc/hotplug/iface/00_netstate.sh[2]
> 
> [2]: https://github.com/lede-project/source/blob/master/package/netwo
> rk/config/netifd/files/etc/hotplug.d/iface/00-netstate#L4
> [3]: https://github.com/lede-project/source/blob/master/package/netwo
> rk/config/netifd/files/lib/network/config.sh#L46
> 
> The QMI proto handler reads UCI configs directly, so it isn't
> affected
> by this clobbering. However, the wwan's hotplug handler reads UCI via
> config_load/config_get and thus reads the clobbered value and is thus
> broken.
> 
> The most easy way to fix this would be to read UCI configs directly
> in
> the hotplug handler, thus ignoring state. However, this property name
> clash feels dirty and I'd like to fix this properly.
> 
> Felix, what is the "device" property used for in netifd? Why is it
> needed? Could you please explain what you meant by "further remapping
> issues" in 477c3c4[4] and especially which "legacy scripts" you were
> talking about in bffa830[5]?
> 
> [4]: https://github.com/lede-project/source/commit/477c3c40156cca124b
> ec0520a733f455d0085914
> [5]: https://github.com/lede-project/source/commit/bffa830f13d610bce0
> d9357c35759dec099a9ea5
> 
> Cheers,

Ping? Anyone? Or do I need to send an actual patch to solicit some
attention?

-- 
Ivan Shapovalov / intelfx /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/lede-dev/attachments/20180122/cac500bd/attachment-0001.sig>