Re: umodeswitch
On Fri, Apr 09, 2021 at 06:07:17PM +0200, Emmanuel Dreyfus wrote:
> port 10 addr 2: high speed, power 500 mA, config 1, Mobile
> Connect(0xab00), Mobile Connect(0x2001), rev 2.28(0x0228), serial
> 25052a63011b
I got it working by adding just this:
--- u3g.c.orig 2021-04-09 20:52:16.008519125 +0200
+++ u3g.c 2021-04-13 02:53:20.636012294 +0200
@@ -261,4 +262,5 @@
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DWM157 },
{ USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DWM157E },
+ { USB_VENDOR_DLINK, USB_PRODUCT_DLINK_DWM222 },
};
Of course thatr does not help with mode switch. Here is drvctl -ntl output:
(...)
usb1
uhub1
umass1
scsibus1
sd1
cd0
And usbdevs -dvf /dev/usb1
(...)
port 10 addr 2: high speed, power 500 mA, config 1, Mobile Connect(0xab00),
Mobile Connect(0x2001), rev 2.28(0x0228), serial 25052a63011b
umass1
Here is modeswitch without the umodeswitch driver:
# eject /dev/cd0d
And now usbdevs -dvf /dev/usb1 says
port 10 addr 3: high speed, power 500 mA, config 1, Mobile Connect(0x7e35),
Mobile Connect(0x2001), rev 2.28(0x0228), serial 0123456789ABCDEF
And drvctl -ntl
(...)
usb1
uhub1
u3g0
ucom0
u3g1
ucom1
u3g2
ucom2
u3g3
ucom3
u3g4
ucom4
umass1
scsibus1
sd1
And the modem works. I understand umodeswitch ejects sd1 while it should
eject cd0. But I have no clus about how to fix that.
--
Emmanuel Dreyfus
m...@netbsd.org
Re: umodeswitch
On Fri, Apr 09, 2021 at 06:07:17PM +0200, Emmanuel Dreyfus wrote: > port 10 addr 2: high speed, power 500 mA, config 1, Mobile > Connect(0xab00), Mobile Connect(0x2001), rev 2.28(0x0228), serial > 25052a63011b While I got some success with ZTE MF112, with the cold boot configuration problem left, (see other message in the thread), I can get no satisfaction with D-Link DWM-222. Looking at usb_modeswitch and FreeBSD code, it seems it is supposed to switch its product ID from ab00 to 7e12 on plain disk eject, there is no special handling compared to other devices. But even after umodeswitch removed the scsibus/sd devices, it gets stuck as ab00 as reported by usbdevs: port 10 addr 3: high speed, power 500 mA, config 1, Mobile Connect(0xab00), Mobile Connect(0x2001), rev 2.28(0x0228), serial 25052a63011b umodeswitch0 I got more information using usbutil: # usbctl -a 3 -f /dev/usb1 DEVICE addr 3 DEVICE descriptor: bLength=18 bDescriptorType=device(1) bcdUSB=2.01 bDeviceClass=0 bDeviceSubClass=0 bDeviceProtocol=0 bMaxPacketSize=64 idVendor=0x2001 idProduct=0xab00 bcdDevice=228 iManufacturer=1(Mobile Connect) iProduct=2(Mobile Connect) iSerialNumber=3(25052a63011b) bNumConfigurations=1 CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=32 bNumInterface=1 bConfigurationValue=1 iConfiguration=0() bmAttributes=80 bMaxPower=500 mA INTERFACE descriptor 0: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=2 bInterfaceClass=8 bInterfaceSubClass=6 bInterfaceProtocol=80 iInterface=4(Mass Storage) ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in bmAttributes=bulk wMaxPacketSize=512 bInterval=0 ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-out bmAttributes=bulk wMaxPacketSize=512 bInterval=1 current configuration 1 -- -- Emmanuel Dreyfus m...@netbsd.org
Re: umodeswitch
In article <1p7infd.zofefgbhxppgm%m...@netbsd.org>,
Emmanuel Dreyfus wrote:
>Emmanuel Dreyfus wrote:
>
>> I had some success with ZTE MF112 by just telling umass to not attach it
>> using umass_quirks (patch below). I got a frienly OK when telling it ATZ
>> on /dev/ttyU2 at 230400 bps. I need to add a SIM to perform further
>> testing.
>>
>> Is the approach sane?
>
>It is not. I got mislead by the fact that the device maintains state
>across reboots, and is only reset by a power cycle.
>
>Supporting ZTE MF112 only requires this change:
>
>--- u3g.c.orig
>+++ ./u3g.c
>@@ -253,4 +253,5 @@
>{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF628 },
>{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF820D },
>+ { USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF112 },
>
>/* 4G Systems */
>
>But it does not work out of the box. It needs two device scan for u3g to
>attach, either booting twice after a power cycle, or
>detaching/rescanning after a single boot from cold state (drvctl -d
>umodeswitch0 ; drvctl -a usbdevif -r uhub1).
>
>Once u3g attaches the device, it keep doing so across reboots, until the
>next power cycle.
>
>Any hint on how that could be fixed?
See FreeBSD's u3g.c driver. Perhaps we can accommodate sending the
initialization command in the umodeswitch.c driver?
christos
Re: umodeswitch
Emmanuel Dreyfus wrote:
> I had some success with ZTE MF112 by just telling umass to not attach it
> using umass_quirks (patch below). I got a frienly OK when telling it ATZ
> on /dev/ttyU2 at 230400 bps. I need to add a SIM to perform further
> testing.
>
> Is the approach sane?
It is not. I got mislead by the fact that the device maintains state
across reboots, and is only reset by a power cycle.
Supporting ZTE MF112 only requires this change:
--- u3g.c.orig
+++ ./u3g.c
@@ -253,4 +253,5 @@
{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF628 },
{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF820D },
+ { USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF112 },
/* 4G Systems */
But it does not work out of the box. It needs two device scan for u3g to
attach, either booting twice after a power cycle, or
detaching/rescanning after a single boot from cold state (drvctl -d
umodeswitch0 ; drvctl -a usbdevif -r uhub1).
Once u3g attaches the device, it keep doing so across reboots, until the
next power cycle.
Any hint on how that could be fixed?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
Re: umodeswitch
Emmanuel Dreyfus wrote:
> port 3 addr 4: high speed, self powered, config 1, ZTE WCDMA
> Technologies MSM(0
> x0117), ZTE,Incorporated(0x19d2), rev 0.00(0x), serial
> MF1900BYTD01
I had some success with ZTE MF112 by just telling umass to not attach it
using umass_quirks (patch below). I got a frienly OK when telling it ATZ
on /dev/ttyU2 at 230400 bps. I need to add a SIM to perform further
testing.
Is the approach sane?
--- u3g.c.orig 2021-04-09 20:52:16.008519125 +0200
+++ u3g.c 2021-04-11 03:15:54.050593540 +0200
@@ -251,8 +251,9 @@
{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF622 },
{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF626 },
{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF628 },
{ USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF820D },
+ { USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF112 },
/* 4G Systems */
{ USB_VENDOR_LONGCHEER, USB_PRODUCT_LONGCHEER_XSSTICK_P14 },
{ USB_VENDOR_LONGCHEER, USB_PRODUCT_LONGCHEER_XSSTICK_W14 },
--- umass_quirks.c.orig 2021-04-11 02:24:22.832597008 +0200
+++ umass_quirks.c 2021-04-11 03:16:45.624011222 +0200
@@ -342,8 +342,22 @@
PQUIRK_NOSYNCCACHE,
UMATCH_VENDOR_PRODUCT,
NULL, NULL
},
+
+ /*
+* ZTE MF112 3G modem advertises itself as umass, but the
+* storage is not functionnal and umodeswitch fails to change
+* personality, beaause it is already a 3G modem. Make sure
+* umass does not attach it.
+*/
+ { { USB_VENDOR_ZTE, USB_PRODUCT_ZTE_MF112 },
+ UMASS_WPROTO_UNSPEC, UMASS_CPROTO_UNSPEC,
+ 0,
+ 0,
+ UMATCH_NONE,
+ NULL, NULL
+ },
};
const struct umass_quirk *
umass_lookup(uint16_t vendor, uint16_t product)
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
Re: umodeswitch
Martin Husemann wrote:
> How did you add the ID?
Like in patch below. I also tried the same apporach as NOVATEL2 case in
umodeswitch_attach, with no better outcome.
I am a bit surprised for D-Link DWM222 since Linux's usb_modeswitch
supports it with no special handling.
--- umodeswitch.c.orig 2021-04-09 20:51:58.812087597 +0200
+++ umodeswitch.c 2021-04-09 17:57:17.853298685 +0200
@@ -420,8 +421,9 @@
break;
case USB_VENDOR_ZTE:
switch (uaa->uaa_product){
+ case USB_PRODUCT_ZTE_MF112:
case USB_PRODUCT_ZTE_INSTALLER:
case USB_PRODUCT_ZTE_MF820D_INSTALLER:
(void)u3g_bulk_ata_eject(uaa->uaa_device);
(void)u3g_bulk_scsi_eject(uaa->uaa_device);
@@ -439,8 +441,9 @@
case USB_VENDOR_DLINK:
switch (uaa->uaa_product) {
case USB_PRODUCT_DLINK_DWM157E_CD:
case USB_PRODUCT_DLINK_DWM157_CD:
+ case USB_PRODUCT_DLINK_DWM222_CD:
(void)u3g_bulk_ata_eject(uaa->uaa_device);
(void)u3g_bulk_scsi_eject(uaa->uaa_device);
return UMATCH_HIGHEST;
default:
> If it does not do that, either the command was wrong, or it does not
> like moving to configured state (see the NOVATEL2 case in umodeswitch_attach).
>
> Martin
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
Re: umodeswitch
On Fri, Apr 09, 2021 at 06:07:17PM +0200, Emmanuel Dreyfus wrote: > And as usual, they attach as umass devices instead of u3g. I added the > ids of the two devices in umodeswitch.c and now: > > umodeswitch0 at uhub1 port 3: Switching off umass mode > umodeswitch1 at uhub1 port 10: Switching off umass mode How did you add the ID? You have to make umodeswitch_match() send the proper command to the device, the device than handles the detach and reataches with proper personality. If it does not do that, either the command was wrong, or it does not like moving to configured state (see the NOVATEL2 case in umodeswitch_attach). Martin
umodeswitch
Hello I am trying to add support for two 3G/4G modems. They show in usbdevs -dv as: port 3 addr 4: high speed, self powered, config 1, ZTE WCDMA Technologies MSM(0 x0117), ZTE,Incorporated(0x19d2), rev 0.00(0x), serial MF1900BYTD01 port 10 addr 2: high speed, power 500 mA, config 1, Mobile Connect(0xab00), Mobile Connect(0x2001), rev 2.28(0x0228), serial 25052a63011b And as usual, they attach as umass devices instead of u3g. I added the ids of the two devices in umodeswitch.c and now: umodeswitch0 at uhub1 port 3: Switching off umass mode umodeswitch1 at uhub1 port 10: Switching off umass mode But they are not attached by u3g and remain attached by umodeswitch forever. I added a printf at the beginning of u3g_match() and they are not even tested for a match. What is the trick I miss here? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org
