7354 modem woes

rico1471

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.

stephenw10

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

rico1471

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 = 0x0001

ugen3.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

stephenw10

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#L4105

And that should be supported by u3g:
https://github.com/pfsense/FreeBSD-src/blob/7b30cdd1e579d000fab264695818b2da01014a43/sys/dev/usb/serial/u3g.c#L527

So 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

chpalmer

@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.??.

rico1471

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.

stephenw10

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

rico1471

The log:

Nov 9 00:44:39
kernel

ugen3.2: <CradlePoint MC400> at usbus3
Nov 9 00:44:39
kernel

uhub8 on uhub3
Nov 9 00:44:39
kernel

uhub8: <CradlePoint MC400, class 9/0, rev 2.00/32.98, addr 2> on usbus3

Nov 9 00:44:39
kernel

uhub8: MTT enabled
Nov 9 00:44:40
kernel

uhub8: 4 ports with 4 removable, self powered
Nov 9 00:44:51
kernel

ugen3.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

stephenw10

So only entries with lower case u? And no u3g entries in the boot log or system log?

Steve

rico1471

Correct.

stephenw10

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/758332

Last time I hit this I used this script to change it from Ubuntu:
https://git.mork.no/wwan.git/tree/scripts/swi_setusbcomp.pl

Like ./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

rico1471

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

stephenw10

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