On Mon, 2013-02-25 at 16:42 +0100, Aleksander Morgado wrote: > > On a side note, a user just reported an issue with a MC8790V (see the > > trailing 'V' there), log attached. In this case, the issue is not about > > using the APP1 port for PPP; the issue is that there is no non-APP port > > shown, so we don't specify any port being 'primary', and we end up > > choosing an incorrect one. > > > > So, with: > > > > ttyUSB3 --> APP1 > > ttyUSB4 --> APP2 > > ttyUSB5 --> APP3 > > > > We end up getting: > > > > tty/ttyUSB4 primary > > tty/ttyUSB3 secondary > > tty/ttyUSB4 data > > > > And ttyUSB4 doesn't like being the primary port here. Possibly ttyUSB3 > > should be the one treated as primary? > > Well, after some tests, seems that the exposed APP ports in this device > are like in any other Sierra device, with a limited AT command set, so > we cannot use them as primary port... Now I wonder if lacking a proper > primary AT port is a firmware/device bug or if they really did it on > purpose (e.g. so that only CnS can be used).
That may well be the case. There are some firmware commands to control port configuration, but those are can be *very* harmful and we should never be touching them in MM as we risk bricking the device, just like I did to my first UMG1831 with AT^U2DIAG. I think we're screwed here unless we add CnS support, and we don't have docs for that since it's proprietary. THe only other thing I can think of is that maybe it's a driver bug, but if the we have TTYs for all the USB interfaces shown in lsusb, then that's not the problem. Dan _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
