GNOME Bugzilla – Bug 633465
iPhone eth is not recognised as mobile broadband
Last modified: 2020-11-12 14:31:50 UTC
kernel 2.6.36-1.fc15.x86_64 NetworkManager-0.8.1-9.git20100831.fc14.x86_64 With the new kernel, ipheth is now included in the kernel. When plugging in an iPhone, NetworkManager will try to automatically connect to it. NetworkManager shouldn't try to connect automatically to the broadband network (I can imagine people like me having problems, and not noticing it, ending up with a slow internet, and a high phone bill).
We don't actually detect that these are mobile broadband devices because they look just like ethernet. This is worse for phones that provide CDC-Ethernet interfaces too, but for some of those the best we can do is detect that the same USB device provides an ether + serial interface and treat it as a mobile broadband device. Other drivers we'd have to special-case would be ipheth and rndis stuff.
Maybe those devices should be tagged by udev?
Possibly, but I think we should actually end up special-casing ipheth devices. They are "wwan" devices, and the traditional tag for them is the "wwan" devtype in the kernel driver. But the devtype thing is only for devices that require further setup (like AT commands on a serial port) before the eth device is able to be used, which isn't the case for the iphone. I also used to have a SonyEricsson phone that had the same behavior via cdc-ether. But what behavior should we have for these devices? Should NM just not autoconnect them and leave it to the user to check the box if they want autoconnect? Should we tag them as "wwan" in the D-Bus interface so that the UI can do something intelligent with that? I think both of those are probably the right things to do.
Any plan to do this?
*** Bug 678818 has been marked as a duplicate of this bug. ***
This also relates to bug #554538, which probably "solves" this bug until it is fixed. The problem here is what should happen. Some people might prefer that the network connection is set up automatically when the phone is connected, if you always connect the phone to use it as a modem. Other people connect the phone to the PC to charge it, transfer files, photos etc. and never use it as a modem. Maybe we also need to list the devices in the NM config and let each of them have an autoconnection flag, or let you specify which devices should autoconnect in the list of mobile broadband connections. The most user friendly would probably to ask the user when a new device (or device type?) is connected if it should be used for internet connection.
In comment #6, i meant to refer to bug #667488.
Yes, it is related to bug 667488. But discussion about what should be moved there. This bug report should track the fact that iphone eth is not distinguished from ordinary eth. Changing summary.
A workaround for this bug is maybe to specify for the configured ethernet connections to restrict it to the ordinary ethernet interface so that it is not used for the phone ethernet connections.
This bug report now refers only to the missing detection that iphone ethernet is not ordinary ethernet.
Exactly, thus if the configured local ethernet connection is set up in the settings to be restricted to e.g. "eth0", this should be a workaround for this bug, since the phone would appear as "eth1" or "wwan0". I think this no longer applies to newer Android versions, as they require you to explicitly enable USB thetering after connecting it to a computer before it start acting as a modem.
Name-based workaround are actually the very last resort.
NM bugzilla reorganization... sorry for the bug spam.
bugzilla.gnome.org is being shut down in favor of a GitLab instance. We are closing all old bug reports and feature requests in GNOME Bugzilla which have not seen updates for a long time. If you still use NetworkManager and if you still see this bug / want this feature in a recent and supported version of NetworkManager, then please feel free to report it at https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/ Thank you for creating this report and we are sorry it could not be implemented (workforce and time is unfortunately limited).