User Tools

Site Tools

ReadOnly
    ReadOnly

projects:glinet:e3372:fixing-drops

Fixing E3372 PDP Drops

The issue

So after a while the e3372 drops the connection with the carrier and beryl doesn't try to fix it. The issue is that the modem/giffgaff between them drop the PDP (who knows why - possibly the dhcp lease expires?) and don't fix it.

Notes here about beryl designated interfaces. This is so that the beryl gui can handle upstream connection failover.

wan is an interface for linking cable connections (eth0 or lan.?? depending on hardware) with red firewall zone.
wwan is an interface for linking a **wifi** device (eg: wlan-sta0 for mt1300 or apclix0 for mt3000) in client mode connected to host wifi (eg a hotel) to red firewall zone.
  Nothing to do with modems. Very confusing with wwan0 being a device for modems! (see later)
modem_1_1 is an interface. Links wwan0 to red firewall zone.
  The "device" set in modem_1_1 is usually path to a modem com port eg /dev/tty/USB0
  Usually points to ncm-modem_1_1 when the modem is down. Determined by the chosen protocol.
  Usually points to wwan0 when the modem is up. Determined by the device name created by netifd/ncm.sh when the modem is brought up.
wwan0 is a device mapped to the modem only present when the modem is up.
modem_1_1_4 and 6 are virtual devices created by ncm.sh for getting dhcp leases from the ISP.

What can be seen in the logs is:

Thu Feb  5 04:19:27 2026 daemon.notice netifd: Network device 'wwan0' link is down
Thu Feb  5 04:19:27 2026 daemon.notice netifd: Network alias 'wwan0' link is down
Thu Feb  5 04:19:27 2026 daemon.notice netifd: Interface 'modem_1_1_4' has link connectivity loss
Thu Feb  5 04:19:27 2026 daemon.notice netifd: modem_1_1_4 (23401): udhcpc: received SIGTERM
Thu Feb  5 04:19:27 2026 daemon.notice netifd: modem_1_1_4 (23401): udhcpc: unicasting a release of 10.150.170.138 to 10.0.0.1
Thu Feb  5 04:19:27 2026 daemon.notice netifd: modem_1_1_4 (23401): udhcpc: sending release
Thu Feb  5 04:19:27 2026 daemon.notice netifd: modem_1_1_4 (23401): udhcpc: entering released state
Thu Feb  5 04:19:27 2026 daemon.notice netifd: modem_1_1_4 (23401): Command failed: Permission denied
Thu Feb  5 04:19:28 2026 user.notice kmwan: config json str={ "op": 6, "data": { } }
Thu Feb  5 04:19:28 2026 daemon.notice netifd: Interface 'modem_1_1_4' is now down
Thu Feb  5 04:19:28 2026 daemon.notice netifd: Interface 'modem_1_1_4' is disabled
Thu Feb  5 04:19:28 2026 daemon.info avahi-daemon[6920]: Withdrawing address record for 10.150.170.138 on wwan0.
Thu Feb  5 04:19:28 2026 daemon.info avahi-daemon[6920]: Leaving mDNS multicast group on interface wwan0.IPv4 with address 10.150.170.138.
Thu Feb  5 04:19:28 2026 daemon.info avahi-daemon[6920]: Interface wwan0.IPv4 no longer relevant for mDNS.
Thu Feb  5 04:19:28 2026 daemon.warn dnsmasq[20913]: no servers found in /tmp/resolv.conf.d/resolv.conf.auto, will retry
Thu Feb  5 04:19:28 2026 user.notice kmwan: config json str={ "op": 3, "data": { "cells": [ "modem_1_1_4" ] } }
Thu Feb  5 04:19:28 2026 user.notice firewall: Reloading firewall due to ifdown of modem_1_1_4 ()
Thu Feb  5 04:19:28 2026 user.notice pdp-recover: ifdown call for interface: modem_1_1_4, device:

So the router:

Spots the link is down somehow (netifd?, ubus message?) and tears down modem_1_1_4
Releases the dhcp lease from the ISP
Other stuff (dns) cascade down the stack.
It doesn't tear down modem_1_1 for some reason.

I never figured why the PDP drops.

ISP/carrier timeout?
modem firmware had enough?
dhcp lease expires and doesn't get renewed?

Either way the PDP drops and needs reconnecting.

Using AT+CREG? or AT+CEREG? should show 0,1 for ok. No connnection they Show 0,2 (searching) or 0,3 (denied).
PDPisUP=$(gl_modem -B 1-1 AT 'AT+CGACT?' | grep ' 1,0') is what I used. (note leading space b4 1,0) 
AT^NDISDUP=1,1,"giffgaff.com" brings the connection back up and fixes it without tearing down the rest of the stack.

The fix that worked

So we are going to:

look for modem_1_1_4 going down (we can't catch wwan0 going down for some reason)
Check PDP is down. If it isn't we can't help. Maybe teardown is intentional then.
If PDP is down, try bring it back up.
If bringing PDP back up is successful, try rebuild modem_1_1_4 with code pinched from ncm.sh

Put this in /etc/hotplug.d/iface/99-pdp-recover and chmod +x /etc/hotplug.d/iface/99-pdp-recover

#!/bin/sh

. /lib/functions.sh
. /usr/share/libubox/jshn.sh

#[ "$DEVICE" = "wwan0" ] || exit 0
#logger -p notice -t pdp-recover "Call for interface: $INTERFACE, device: $DEVICE, action: $ACTION"
#exit 0


[ "$ACTION" = "ifdown" ] || exit 0
#[ "$INTERFACE" = "modem_1_1" ] || [ "$DEVICE" = "wwan0" ] || exit 0
[ "$INTERFACE" = "modem_1_1_4" ] || exit 0
logger -p notice -t pdp-recover "ifdown call for interface: $INTERFACE, device: $DEVICE"

# Debounce: avoid multiple triggers
LOCK="/tmp/pdp-recover.lock"
if [ -e "$LOCK" ]; then
    logger -p notice -t pdp-recover "Another call while recovery in progress, skipping this one."
    exit 0
fi
touch "$LOCK"
trap 'rm -f "$LOCK"' EXIT

logger -p notice -t pdp-recover "hotplug call: $INTERFACE link down — checking modem PDP state"

RAW=$(gl_modem -B 1-1 AT 'AT+CGACT?')
logger -p notice -t pdp-recover "modem AT+CGACT? output: $RAW"
PDP=$(echo -e "$RAW" | grep ' 1,0')
#PDP=$(gl_modem -B 1-1 AT 'AT+CGACT?' | grep ' 1,0')

if [ -n "$PDP" ]; then
    # PDP Recovery
    logger -p notice -t pdp-recover "PDP is down, attempting recovery"
    gl_modem -B 1-1 AT 'AT^NDISDUP=1,1,"giffgaff.com"'

    # Wait and confirm PDP is up before reloading netifd
    for i in 1 2 3 4 5; do
        sleep 2
        RAW=$(gl_modem -B 1-1 AT 'AT+CGACT?')
        # look for pdpd back up and exit the loop:
        echo "$RAW" | grep -q '^+CGACT: 1,1' && break
    done

    if echo "$RAW" | grep -q '^+CGACT: 1,1'; then
#        ubus call network.interface.modem_1_1 up
#        ifup modem_1_1 &

        logger -p notice -t pdp-recover "PDP came back up, recreating modem_1_1_4..."
        json_init
        json_add_string name "modem_1_1_4"
        json_add_string ifname "@modem_1_1"
        json_add_string proto "dhcp"
        proto_add_dynamic_defaults
        zone="$(fw3 -q network modem_1_1 2>/dev/null)"
        [ -n "$zone" ] && json_add_string zone "$zone"
        json_close_object

        ubus call network add_dynamic "$(json_dump)"

        logger -p notice -t pdp-recover "Done reecreating modem_1_1_4... that's me completed."

    else
        logger -p err -t pdp-recover "PDP recovery failed after 10 seconds — sorry, can't help."
    fi
else
    logger -p notice -t pdp-recover "PDP is not down, you're on your own."
fi

rm -f "$LOCK"

It listens for event wwan going down and issues AT^NDISDUP=1,1,“giffgaff.com” to bring it back up. Fixed.

Testing

Drop PDP for testing

gl_modem -B 1-1 AT 'AT+CGACT=0,1'

Bring PDP up:

gl_modem -B 1-1 AT 'AT+CGACT=1,1'

Note the latter doesn't fix a broken PDP (i don't think…), you need AT^NDISDUP=1,1,“giffgaff.com” for that.

projects/glinet/e3372/fixing-drops.txt · Last modified: by Andy Moore