Hi Aleksander, I'll put in another recommendation for g_clear_object() :)
> ublox: new +UIPADDR=N response parser > ublox: new +CGCONTRDP=N response parser > ublox: implement connection using the 2G/3G logic in router or bridge It seems like the +CGCONTRDP parsing code could be generic and not limited to ublox. However, it looks like the ublox you have (and thus the code) uses a newer ETSI 27.007 verison of +CGCONTRDP responses. Somewhere between v9 and v11 they changed the format (surprise!) and Could you add an expected failure testcase for the old format that ensures we don't succeed in parsing the old format until we explicitly add support for it? I got really confused about UIPADDR vs. CGCONTRDP until I read some +UIPADDR documentation (AT-CommandsExamples_AppNote_(UBX- 13001820).pdf). That's probably on my list of dumbest things I've seen. The CGCONTRDP is supposed to supply the gateway address, but from the examples it looks like that's always the same as the reported IP address, while the completely different address from UIPADDR is the acutal gateway address? Wow. This at least deserves some documentation in the mm-broadband-bearer-ublox.c. > modem-helpers: new COPS? response parser Would be nice to have a testcase for the Option hex-encoded COPS case, here's some sample output for you: AT+CSCS="IRA" OK AT+COPS=3,0;+COPS? +COPS: 0,0,"T-Mobile",2 OK AT+CSCS="UCS2" OK AT+COPS=3,0;+COPS? +COPS: 0,0,"0054002d004d006f00620069006c0065",2 OK > ublox: if on LTE and empty APN given, use the default LTE bearer The disconnect code reads oddly here; LTE never gets an explicit disconnect? That doesn't match the commit message. My read is that if an APN was given and the access tech is LTE that APN won't get disconnected, which doesn't seem correct. Also, we need better handling of the default bearer in general. Any idea how other devices handle this? My Huawei E3276 doesn't auto- activate PDP context 0 (shown via +CGACT) when it's registered to LTE. Is the ublox special in this regard? Also, I'm not really sure about this in general. Usually a blank APN means "subscription value is requested", eg let the network figure it out. That isn't necessarily the Default EPS Bearer AFAICT. Maybe for LTE if we can detect there is a Default EPS Bearer active we just create an MMBearer for it by default? 27.007 is a bit confusing on the relationship between the "initial PDP context" and the "Default EPS Bearer"; I don't think the two are the same thing, but they both get activated automatically on network attach. > ublox: subclass the connection monitoring logic How about we do this monitoring for all modems? I was playing around the other day with a Sierra MC8781 and the only thing that reported disconnect when I removed antennas was AT+CGACT polling. It seems useful for all modems really. > ublox: new +CFUN? response parser Seems hard to believe we don't already have a CFUN parser somewhere? But we don't... I'd put this into modem helpers and then use it in linktop, mbm, ublox, and core. > ublox: custom parsing for CREG/CGREG/CEREG registration state values These CEREG values are standard ETSI 27.007 CEREG <stat> values, so can't this just be done in the common parser? > ublox: new +CESQ response parser > ublox: new helper to parse +CESQ response into MMSignal objects Also standard 27.007, can it be generic for all modems? > ublox: do not try to authenticate or activate the default LTE bearer context There's gotta be a way to figure out which PDP context the default bearer is using instead of assuming this... > ublox: implement supported bands loading I guess +UBANDSEL=? doesn't report anything useful? > ublox: new +UBANDSEL? response parser Maybe a use-case for the new mm_parse_uint_list()? Dan _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
