Aside from the questions over disconnect and/or powering off the hardware in my
mux driver, I want to step back a bit and dig into what's happening when the
modem is timing out of Data Mode but MM is apparently not realising. I want to
try to see the NO CARRIER that I see when playing with a terminal app. After
all, unless I can't get things to behave right in a failure condition then
there's no point in [for a robust solution] fixing the 'good' condition!
I've not yet been able to establish how the modem really behaves, but it may be
a complication of the mux driver that I'm using MM on. So I'll try removing
that and talking direct to the real serial port. Trouble is..... I can't get
the udev rules right to get it 'whitlisted'...
Can someone walk me through this please?
udev is showing ttymxc2's DEVPATH as
/devices/soc0/soc/2100000.aips-bus/21ec000.serial/tty/ttymxc2
In the rules I have
KERNEL=="ttymxc2", ENV{SYSTEMD_WANTS}="ModemManager.service"
ENV{ID_MM_CANDIDATE}="1"
ACTION=="add" KERNEL=="21ec000.serial",
ENV{SYSTEMD_WANTS}="ModemManager.service" ENV{ID_MM_CANDIDATE}="1"
ENV{ID_MM_PLATFORM_DRIVER_PROBE}="1"
I've reloaded the rules, and restart MM, but no joy with it being seen as
whitelisted.
-----Original Message-----
From: ModemManager-devel
[mailto:modemmanager-devel-boun...@lists.freedesktop.org] On Behalf Of
Aleksander Morgado
Sent: 26 January 2017 13:54
To: colin.helliw...@ln-systems.com
Cc: ModemManager (development) <modemmanager-devel@lists.freedesktop.org>
Subject: Re: Fetching signal quality during data connection?
> Regarding the failing PPP:
> Your enhancement probably to prevent a race is still a good idea in general.
> However I've now experimented manually (with a terminal app), and I don't
> think it is the Sig Quality which is breaking PPP. What I was actually doing
> was waiting so long before starting PPP that the *modem* is timing out -
> after the ATD it sends back 'hex' messages (presumably some sort of LCP
> request) a number of times, and then eventually times out and sends 'NO
> CARRIER'. This timeout also happens to be 30secs.
> I haven't found any 'ETSI' spec which defines a timeout from data mode, and
> nor is one mentioned in my modem's docs. However I did find a uBlox manual
> which states different negotiation/timeout sequences for their different
> modems
> (https://www.u-blox.com/sites/default/files/u-blox-ATCommands_Manual_(UBX-13002752).pdf
> , para 18.2). So maybe this behaviour is always manufacturer-specific.
> It would though be better if MM caught the 'NO CARRIER' and set the state
> back to disconnected?
MM should already be catching the NO CARRIER errors; could you gather debug
logs while reproducing this to see why it didn't catch it?
--
Aleksander
https://aleksander.es
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
