Zte-mf730m 42Mbps 3G howto and request for further assistance

PhilipG

Using pfsense 2.1.3 (and 2.2 snapshots a while back) I have managed to cobble together a partially working 3g wan config with this DC-HSDPA 42Mbps dongle.
My discovery is that to change this 42Mbps dongle issued by 3 (at least in the UK) to a usable if_cdce mode (ie ue0) from the useless storage mode one simply has to execute the following:-

usbconfig dump_all_config_desc
usbconfig dump_all_config_desc
usbconfig dump_all_config_desc

ie a simple usb dump command 3 times in a row.
That little number took me a massive amount of time to stumble across. No amount of usb_modeswitching gave any joy. I have started a thread at usb_modeswitch for an alternative but the above works reliable as far as switching the device in pfsense and in FreeBSD 10 and has the very attractive aspect of needing no additional software.

So to automate the execution of the above otherwise harmless (hopefully) commands I did the following:-
ssh into pfsense

if using the nano variant of pfsense one must first:- /etc/rc.conf_mount_rw
then

cat << EOF > /usr/local/sbin/zte-mf730m-switch
#!/bin/sh
usbconfig dump_all_config_desc
usbconfig dump_all_config_desc
usbconfig dump_all_config_desc
sleep 10
EOF

chmod a+x /usr/local/sbin/zte-mf730m-switch

cat << EOF > /usr/local/etc/devd/zte-mf730m.conf
notify 100 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "ATTACH";
match "vendor" "0x19d2";
match "product" "0x1420";
action "/usr/local/sbin/zte-mf730m-switch";
};
EOF

and if using nano variant a return to read only root with:- /etc/rc.conf_mount_ro

Then a:-

/etc/rc.d/devd restart

to enable the new devd rule.

My remaining problem is that during boot or plugin of the device there is a 6 minute delay with the following terminal output:-

run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Retrying command
.
..repeating
.
run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Error 5, Retries exhausted

and then a normal boot continues if we are in deed booting.

The plugin 6 minute pause can be avoided by first adding the following USB quirks:-

usbconfig add_dev_quirk_vplh 0x19d2 0x1420 0xf0f7 0xf0f7 UQ_MSC_NO_GETMAXLUN
usbconfig add_dev_quirk_vplh 0x19d2 0x1420 0xf0f7 0xf0f7 UQ_MSC_NO_INQUIRY

But there will still be a 6 minute hang on power up with the device plugged in which I don't know how to get around.
This is the case in pfsense 2.1.3 and 2.2 (although when I last tried with 2.2 it was missing if_cdce.ko and if_cdce.ko.symbols (not sure if needed) but copying them from FreeBSD10 worked)
https://forum.pfsense.org/index.php?topic=74664.msg409078#msg409078

Does anyone know how I can add the above usb quirks to pfsense or can we have them added to the kernel on the next release.
I believe they have to be added to some quirks kernel file and a kernel recompilation later and we are done.

The above arrangement is still a little flaky but with a 6 minute wait at the trial of anything involving a reboot it is incredibly frustrating to try anything out so that is why I offer my findings so far; and request help with adding the quirks to the kernel.

As is stands occasionally during boot the ue0 interface is not found but without these quirks added to the kernel some how it is an inhumane task to approach.

It would be great if we could support this dongle as it looks to be so close.
Thanks for any help anyone can provide.

tom_o

<bump>did you get any further with this?</bump>

dawsmac

I am having the same problem… If this card was supported would enable a very good UK 4G solution as this is a very popular stick... :)

has anyone made any progress on this ?

Cheers

Rich