broadband-modem: enable and handle +CGEV indications

The +CGEV indications allow us to get notified of packet domain events like network-initiated or ME-initiated disconnections on specific connected contexts, as well as full PS detach events (all contexts disconnected). If the modem supports these indications, we will enable them with +CGEREP and will then process them when they are emitted by the modem.

If a full PS detach event happens, we will explicitly disconnect all connected bearers.

If a deactivation inidication is received for a single context, we will look for the associated bearer by CID and explicitly disconnect it.

added 1 commit

• 658e42ec - broadband-modem: enable and handle +CGEV indications

Compare with previous version

added 3 commits

• 658e42ec...2522efb3 - 2 commits from branch master
• 94d7cab0 - broadband-modem: enable and handle +CGEV indications

Compare with previous version

ETSI 27.007 11.6 allows:

+CGEV: ME PDN ACT <cid>[,<reason>[,<cid_other>]]

Oh wow, that is a mess. If I understood it correctly, that kind of notification including reason and cid_other may be given when we request to connect a IPv4v6 context identified via and instead of connecting that one, the modem ends up connecting a different context identified via <cid_other> that is either IPv4-only or IPv6-only... But this triggers a lot of questions, like, will the explicit AT+CGACT operation fail in this case and we still need to report it as connected because the modem was able to connect a different context automatically? Or would the operation succeed but the that was requested to connect would be disconnected after the AT+CGACT call (and a different cid connected)?

Not sure what to do here. I would make sure we can process those replies with the additional fields, but just ignore them for now... What do you think? We would need some major changes in the broadband bearer logic to handle this feature, because right now we assume that the cid we request to connect is the cid that will end up either connected or disconnected, we don't consider the case where the actual cid connected is a different one and of a different type (e.g. IPv4-only when IPv4v6 requested) as this case.

changed this line in version 4 of the diff

Looks like the parser was already considering the optional reason+othercid field (and ignoring them), and I even had unit tests for that. I've pushed a new update adding explicit comments about that feature that we're missing. One problem with the current implementation where we ignore the <other_cid> activation is that the connection checks would fail after a successful connection attempt of this kind because the we match in the connection checks would not be the one that was connected by the modem after all.

I've opened a new issue to track this: #93

added 2 commits

• bf1b3965 - 1 commit from branch master
• 69de0304 - broadband-modem: enable and handle +CGEV indications

Compare with previous version

added 9 commits

• 69de0304...73df7087 - 8 commits from branch master
• a15193b7 - broadband-modem: enable and handle +CGEV indications

Compare with previous version

merged