On Wed, 2016-03-02 at 14:28 +0100, Yegor Yefremov wrote: > Hi Bjørn, > > On Wed, Mar 2, 2016 at 1:27 PM, Bjørn Mork <bj...@mork.no> wrote: > > > > Yegor Yefremov <yegorsli...@googlemail.com> writes: > > > > > > > > One of our customers came upon a Huawei MU609 card with IDs > > > 12d1:1506. > > > Below is lsusb -t output for this card: > > > > > > # lsusb -t > > > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, > > > 480M > > > |__ Port 1: Dev 2, If 0, Class=, Driver=usb-storage, 480M > > > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=musb-hdrc/1p, > > > 480M > > > |__ Port 1: Dev 2, If 0, Class=, Driver=hub/4p, 480M > > > |__ Port 1: Dev 3, If 0, Class=, Driver=ftdi_sio, 12M > > > |__ Port 2: Dev 4, If 0, Class=, Driver=usb-storage, 480M > > > |__ Port 3: Dev 8, If 0, Class=, Driver=option, 480M > > > |__ Port 3: Dev 8, If 1, Class=, Driver=option, 480M > > > |__ Port 3: Dev 8, If 2, Class=, Driver=option, 480M > > > |__ Port 3: Dev 8, If 3, Class=, Driver=option, 480M > > > |__ Port 3: Dev 8, If 4, Class=, Driver=option, 480M > > > > This is missing the interface class info, so it is impossible to > > say if > > that driver attachment is correct or no. > > > > > > > > So far mmcli couldn't detect this card as a modem. In this > > > document > > > [1] is stated, that this is an old version of MU609. What is the > > > difference between them? Does the old MU609 provide cdc_ether > > > interface? > > There is no direct relationship between device name, device ID and > > functions for Huawei devices. But they appear to maintain a strict > > class/subclass/protocol to function mapping. > > > > I cannot answer the questions based on the available information. > I don't have the card at hand, so will try to get "lsusb -v" info. > > > > > > > > > Btw. I have encountered problems [2] with the latest > > > usb_modeswitch_data version and bot MU609 new and ME909. Could > > > you > > > also take a look at it? > > I'm not sure I understand what the problem is. There isn't much > > information here. > Do you have one of these cards, so that you could try them with the > latest usb_modeswitch_data package > (http://www.draisberghof.de/usb_modeswitch/usb-modeswitch-data-201601 > 12.tar.bz2)? > > This package has following file since 20151101: > > usb_modeswitch.d/12d1:1573 > > with following content: > > # Huawei ME909u-521 > Configuration=1 > > Below - corresponding entry in the ChageLog file: > > 20151101: > Added devices: Huawei ME909u-521 [12d1:1573], Huawei E327s-150 > (Variant) > [12d1:1597], Huawei E3531s-2, E3131 (Variant) [12d1:15ce], Huawei > E3131 > (Variant) [12d1:15d0], Huawei E3531 (Variant) [12d1:15d2], > Novatel U620L > [1410:9020], Novatel U620L [1410:9022], ZTE MF820s, MF832s > [19d2:0198], > ZTE MF195E [19d2:1580]; some new target IDs added to existing > device > configs; small correction of Makefile to fix Debian bug #803603 > > Downgrading this package to the version before 20151101 solves the > problem, i.e. usb_modeswitch doesn't interfere with the modem and I > get all needed interfaces inclusive cdc_ether one and ModemManager is > also happy.
FWIW, both my Huawei E398 and E392 (which are supposed to be QMI-based devices) now only bind to 'option' and I get no QMI :( This is with a fairly recent usb_modeswitch. It seems that usb_modeswitch's driver force binding is buggy again. ISTR it waits a few seconds for the kernel driver to bind, and if that doesn't happen within the timeout it will force-bind 'option' to all ports. I replaced the string "option" and "option1" in /usr/sbin/usb_modeswitch_dispatcher with garbage and replugged my E398, and guess what? Everything works now! I am using 20151101 modeswitch data and usb_modeswitch 2.2.5, but even 2.3.0 doesn't fix this problem. Dan _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
