miniPCIE modem troubleshooting

lange.ludo

Thought I'd share my experience because I feel shameful regarding the fix I found…

I bought one of these HUNSN firewall along with a Quectel EC25 4G module.

Figuring out the right COM port wasn't too difficult:

[2.5.0-RELEASE][whoami@pfsense]/root: usbconfig
ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen0.2: <Quectel EC25-EUX> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

Thus assuming that will probably be /dev/cuaU0.2 as a modem port in the PPP Configuration…

And voilà it connected.

Problem starts when I'm clicking the « Disconnect PPP » button within the « Interfaces » : « Status » page…

The modem wouldn't reconnect was getting:
« CHAT: The modem is not responding to "AT" at ModemCmd: label. »

Then while trying to power cycle the device « usbconfig -d 0.2 power_off/on » got:
« can't open /dev/cuaU0.2: Device not configured »
«MODEM: Fail to open serial port /dev/cuaU0.2 on speed 115200 »

I figured out the device serial port « /dev/cuaU0.2 » was locked and not free. Thus while powering on the port was changing to « /dev/cuaU1.2 », « /dev/cuaU#.2 » …

The workaround I found is to insert within « /usr/local/sbin/ppp-linkdown »:

[…]
LOCAL_IP="${3}"

# POWER CYCLE DEVICE
usbconfig -d 0.2 power_off

[…]
/usr/local/sbin/pfSctl -c 'service reload dns'

# POWER CYCLE DEVICE
( sleep 3; usbconfig -d 0.2 power_on ) &

Which is obviously a hardcore way of getting things done but works in that scenario since I only use one PPP interface.

That said if someone helpful and awesome enough has a better alternative, be my guest

stephenw10

Hmm, so it was actually coming up as a different device just by disconnecting it?

Or it stops responding on the existing port when you manually disconnect?

Steve

lange.ludo

@stephenw10 it stops responding when manually disconnecting.

When I'm trying to send commands to the device it looks like the tty is frozen (impossible to type anything). I suppose the MPD script has the same issue thus throwing « CHAT: The modem is not responding to "AT" at ModemCmd: label. ».

If I'm power cycling the device it then appears as a new device (I suppose because the /dev/cuaU0.2 is still being used / locked).

Hence why I'm powering off the device before "cleaning" PPP and power it back on 3 seconds after ppp-linkdown is terminated. This makes sure the port is free and available for a new PPP session. But it really looks slapdash.

jpdsc

You're workaround also fixed the issue for me!

The issue on my machine was not because of manual disconnects; it was when probably renewing DHCP every 24h. Sometimes it would not come back online and it would give:

« CHAT: The modem is not responding to "AT" at ModemCmd: label. »

Error in log.

power_off and power_on solved it without having to reboot the whole machine. Seems like for some reason /dev/cuaU0.2 was locked also but it doesn't appear in the logs.