7354 modem woes
-
New to pfsense but not tinkering. I have a 7354 modem from a cradlepoint mc400 connected via usb. The device is recognized but does not appear as a device to assign.
I'm in a rural location with cellular as the only option. No wan is currently assigned & no hard-wired connection available. This is a fresh install of the latest version of pfsense.
Apologies in advance if I've missed something obvious. Any help is appreciated. -
You have a link to a description of that device? This?
https://source.sierrawireless.com/devices/mc-series/mc7354/How does it appear in the output of:
usbconfig dump_device_desc
Check in /dev for USB connected com ports which appear as cuaUx. The upper case U denoting USB connected.
Steve
-
Thanks so much for the reply. You have the device correct, however, it's connected through an MC400 modem for usb connectivity. https://cradlepoint.com/products/accessories/mc400
Here is the output of usbconfig:ugen3.2: <CradlePoint MC400> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (500mA)
bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0009 <HUB>
bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0002
bMaxPacketSize0 = 0x0040
idVendor = 0x237d
idProduct = 0x0400
bcdDevice = 0x3298
iManufacturer = 0x000a <CradlePoint>
iProduct = 0x000b <MC400>
iSerialNumber = 0x0000 <no string>
bNumConfigurations = 0x0001ugen3.4: <Sierra Wireless, Incorporated MC7354-CP> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
bLength = 0x0012
bDescriptorType = 0x0001
bcdUSB = 0x0200
bDeviceClass = 0x0000 <Probed by interface class>
bDeviceSubClass = 0x0000
bDeviceProtocol = 0x0000
bMaxPacketSize0 = 0x0040
idVendor = 0x1199
idProduct = 0x68c0
bcdDevice = 0x0006
iManufacturer = 0x0001 <Sierra Wireless, Incorporated>
iProduct = 0x0002 <MC7354-CP>
iSerialNumber = 0x0003 <retrieving string failed>
bNumConfigurations = 0x0001 -
Hmm, interesting. The modem is a USB device anyway so most of those external modem carriers are purely passive. That has a hub in it for some reason. Maybe it can switch the SIMs actively? You usually get only one slot.
This is concerning:
@rico1471 said in 7354 modem woes:
Sierra Wireless, Incorporated MC7354-CP
It looks like cradlepoint put their own firmware on the modem or in some other way modified it.
But it still has the same product ID:
https://github.com/pfsense/FreeBSD-src/blob/7b30cdd1e579d000fab264695818b2da01014a43/sys/dev/usb/usbdevs#L4105And that should be supported by u3g:
https://github.com/pfsense/FreeBSD-src/blob/7b30cdd1e579d000fab264695818b2da01014a43/sys/dev/usb/serial/u3g.c#L527So I expect to see some USB serial devices created that you can create a PPP link over. Check /dev. Check the boot log.
Of plug it in after booting and see what new entries are in the system log.Steve
-
@stephenw10 said in 7354 modem woes:
Hmm, interesting. The modem is a USB device anyway so most of those external modem carriers are purely passive. That has a hub in it for some reason. Maybe it can switch the SIMs actively? You usually get only one slot.
All my Cradlepoint devices do have two sim slots. Maybe a leftover in their firmware for this device.??.
-
The MC400 does indeed have 2 sim slots and I believe it does support active switching, although I have yet to utilize that function. Presently there is only 1 sim card in use.
Unfortunately, I won't have access to the machine again until tomorrow. Forgive my ignorance, but when you say "check in /dev" what sort of output should I be expecting? Run from the subject machine or logged in via the gui?
I will post the system log info tomorrow. Thank you again for the troubleshooting assistance.
-
On a box I have here with a Sierra em7305 in it:
[2.4.5-DEVELOPMENT][admin@3100.stevew.lan]/root: ls -ls /dev/cua* 0 crw-rw---- 1 uucp dialer 0x57 Nov 6 13:26 /dev/cuaU0.0 0 crw-rw---- 1 uucp dialer 0x58 Nov 6 13:26 /dev/cuaU0.0.init 0 crw-rw---- 1 uucp dialer 0x59 Nov 6 13:26 /dev/cuaU0.0.lock 0 crw-rw---- 1 uucp dialer 0x5d Nov 6 13:25 /dev/cuaU0.1 0 crw-rw---- 1 uucp dialer 0x5e Nov 6 13:26 /dev/cuaU0.1.init 0 crw-rw---- 1 uucp dialer 0x5f Nov 6 13:26 /dev/cuaU0.1.lock 0 crw-rw---- 1 uucp dialer 0x63 Nov 6 13:28 /dev/cuaU0.2 0 crw-rw---- 1 uucp dialer 0x64 Nov 6 13:26 /dev/cuaU0.2.init 0 crw-rw---- 1 uucp dialer 0x65 Nov 6 13:26 /dev/cuaU0.2.lock 0 crw-rw---- 1 uucp dialer 0x69 Nov 6 13:26 /dev/cuaU0.3 0 crw-rw---- 1 uucp dialer 0x6a Nov 6 13:26 /dev/cuaU0.3.init 0 crw-rw---- 1 uucp dialer 0x6b Nov 6 13:26 /dev/cuaU0.3.lock 0 crw-rw---- 1 uucp dialer 0x23 Nov 6 13:26 /dev/cuau0 0 crw-rw---- 1 uucp dialer 0x24 Nov 6 13:26 /dev/cuau0.init 0 crw-rw---- 1 uucp dialer 0x25 Nov 6 13:26 /dev/cuau0.lock 0 crw-rw---- 1 uucp dialer 0x29 Nov 6 13:26 /dev/cuau1 0 crw-rw---- 1 uucp dialer 0x2a Nov 6 13:26 /dev/cuau1.init 0 crw-rw---- 1 uucp dialer 0x2b Nov 6 13:26 /dev/cuau1.lock
You can see there are 4 cuaU ports that have been added. The two cuau ports are the normal system com1 and com2 serial ports.
You can also see that in the boot log:[2.4.5-DEVELOPMENT][admin@3100.stevew.lan]/root: cat /var/log/dmesg.boot | grep u3g u3g0 on uhub0 u3g0: <Sierra Wireless, Incorporated EM7305, class 0/0, rev 2.00/0.06, addr 2> on usbus0 u3g0: Found 4 ports.
Steve
-
The log:
Nov 9 00:44:39
kernelugen3.2: <CradlePoint MC400> at usbus3
Nov 9 00:44:39
kerneluhub8 on uhub3
Nov 9 00:44:39
kerneluhub8: <CradlePoint MC400, class 9/0, rev 2.00/32.98, addr 2> on usbus3
Nov 9 00:44:39
kerneluhub8: MTT enabled
Nov 9 00:44:40
kerneluhub8: 4 ports with 4 removable, self powered
Nov 9 00:44:51
kernelugen3.4: <Sierra Wireless, Incorporated MC7354-CP> at usbus3
The /dev mirrors the first 3 lines from your example except 0x4b 0x4c and 0x4d are in place of 0x57 0x58 and 0x59
-
So only entries with lower case
u
? And no u3g entries in the boot log or system log?Steve
-
Correct.
-
Then the modem is probably set to the wrong usb 'composition', it's not presenting any ppp interfaces. It's probably in comp 9, MBIM only.
That cannot be corrected from FreeBSD directly. It must be connected to something running a Linux flavour that can talk to it over mbim. Or probably from Windows also.
Compositions 6, 7 or 8 should present an AT port to connect across. See:
https://forum.netgate.com/post/758332Last time I hit this I used this script to change it from Ubuntu:
https://git.mork.no/wwan.git/tree/scripts/swi_setusbcomp.plLike
./swi_setusbcomp.pl --device=/dev/cdc-wdm0 --usbcomp=8
assuming it asspears as cdc-wdm0 in Linux.You could also try running from pfSense:
usbconfig -d ugen3.4 dump_all_config_desc
If it's in one of the 'combo' composition modes it will show multiple config indexes and we can choose a different one.
Steve
-
I will take a look at the post and script you provided. Here is the dump from pfSense:
ugen3.4: <Sierra Wireless, Incorporated MC7354-CP> at usbus3, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
Configuration index 0
bLength = 0x0009 bDescriptorType = 0x0002 wTotalLength = 0x005f bNumInterfaces = 0x0002 bConfigurationValue = 0x0001 iConfiguration = 0x0000 <no string> bmAttributes = 0x00e0 bMaxPower = 0x00fa Additional Descriptor bLength = 0x08 bDescriptorType = 0x0b bDescriptorSubType = 0x0c RAW dump: 0x00 | 0x08, 0x0b, 0x0c, 0x02, 0x02, 0x0e, 0x00, 0x00 Interface 0 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0000 bAlternateSetting = 0x0000 bNumEndpoints = 0x0001 bInterfaceClass = 0x0002 <Communication device> bInterfaceSubClass = 0x000e bInterfaceProtocol = 0x0000 iInterface = 0x0000 <no string> Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x00 RAW dump: 0x00 | 0x05, 0x24, 0x00, 0x10, 0x01 Additional Descriptor bLength = 0x05 bDescriptorType = 0x24 bDescriptorSubType = 0x06 RAW dump: 0x00 | 0x05, 0x24, 0x06, 0x0c, 0x0d Additional Descriptor bLength = 0x0c bDescriptorType = 0x24 bDescriptorSubType = 0x1b RAW dump: 0x00 | 0x0c, 0x24, 0x1b, 0x00, 0x01, 0x00, 0x10, 0x20, 0x08 | 0x80, 0xdc, 0x05, 0x20 Additional Descriptor bLength = 0x08 bDescriptorType = 0x24 bDescriptorSubType = 0x1c RAW dump: 0x00 | 0x08, 0x24, 0x1c, 0x00, 0x01, 0x40, 0xdc, 0x05 Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0082 <IN> bmAttributes = 0x0003 <INTERRUPT> wMaxPacketSize = 0x0040 bInterval = 0x0009 bRefresh = 0x0000 bSynchAddress = 0x0000 Interface 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x0000 bNumEndpoints = 0x0000 bInterfaceClass = 0x000a <CDC-data> bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0002 iInterface = 0x0000 <no string> Interface 1 Alt 1 bLength = 0x0009 bDescriptorType = 0x0004 bInterfaceNumber = 0x0001 bAlternateSetting = 0x0001 bNumEndpoints = 0x0002 bInterfaceClass = 0x000a <CDC-data> bInterfaceSubClass = 0x0000 bInterfaceProtocol = 0x0002 iInterface = 0x0000 <no string> Endpoint 0 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0081 <IN> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000 Endpoint 1 bLength = 0x0007 bDescriptorType = 0x0005 bEndpointAddress = 0x0001 <OUT> bmAttributes = 0x0002 <BULK> wMaxPacketSize = 0x0200 bInterval = 0x0000 bRefresh = 0x0000 bSynchAddress = 0x0000
-
Ok, with only one config index it will need to be changed in Linux.
That does assume CradlePoint haven't changed it in some way.Steve