PPP LCP configuration issue
Hi Kristen, so I added some debug code to actually print the options during the configuration stage. And something seems to be wrong here. lcp: pppcp_open_event: current state 0:INITIAL lcp: pppcp_up_event: current state 1:STARTING lcp: pppcp_initialize_restart_count: current state 1:STARTING lcp: pppcp_send_configure_request: current state 1:STARTING lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00 lcp: pppcp_process_configure_request: current state 6:REQSENT lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00 lcp: option 3 len 5 (Authentication-Protocol) c2 23 05 lcp: option 5 len 6 (Magic-Number) 01 ff ef e0 lcp: option 7 len 2 (Protocol-Field-Compression) lcp: option 8 len 2 (Address-and-Control-Field-Compression) lcp: pppcp_rcr_plus_event: current state 6:REQSENT lcp: pppcp_send_configure_ack: current state 6:REQSENT lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00 lcp: option 3 len 5 (Authentication-Protocol) c2 23 05 lcp: option 5 len 6 (Magic-Number) 01 ff ef e0 lcp: option 7 len 2 (Protocol-Field-Compression) lcp: option 8 len 2 (Address-and-Control-Field-Compression) lcp: pppcp_process_configure_ack: current state 8:ACKSENT lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00 oops -- found acked option 2 we didn't request lcp: pppcp_rca_event: current state 8:ACKSENT lcp: pppcp_initialize_restart_count: current state 8:ACKSENT I see the oops comment here, but we clearly requested the async control character map. So why does it get recognized as not requested? This is clearly a bug and needs to be fixed. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
Hi Denis, 2010/3/31 Denis Kenzior denk...@gmail.com: 1) and 2) are already done through D-Bus, only thing is missing is oFono core properly supporting transitions between Powered false and true. So I just checked again, and we remove all atoms when turning off (even if off subsequently fails). So I really don't see a need to expose the transition (e.g. going up, going down) as a property. How do you want to use this information? I want to prevent core from exiting while a modem is in transitional state. Before ofonod terminates, it calls disable and waits until Powered gets false. I'd rather change Powered to false immediately (when modem shutdown starts) but still keep waiting until modem is properly powered down. 1) If the modem reboots, then handle this inside the isimodem plugin of oFono. It is already handled fine in core. isidriver calls ofono_modem_set_powered(false) when it detects that isimodem reboots. When modem is back in business, it calls ofono_modem_set_powered(true). Is there a particular reason why I should reinvent the wheel? From your earlier posts it wasn't clear that you're happy with how this works. I perceived that there was some issue... It seems to me that Marcel and Aki want to control TX power with the Powered property. (BTW, there already is a post-sim mechanism to control the RX/TX, namely Register/Deregister.) No reason to involve userspace here. If the handset gets turned off, then the modem object just goes away. What is the difference between modem object not being there at all and modem object being there, but with Powered=false? Think of it conceptually as a USB device being in an off state but still on the bus. You still know the device is attached, even if it is of limited use. Remember that we use this to populate remote bluetooth devices, modems configured via modemconf and udev/netlink. This conveys presence and potential usability. That sounds sensible. With the current ofono core, removing the object path will also remove the config information. What are you using the config information for? It is possible that we should implement ofono_modem_unregister that would keep around the non-driver bits of the modem object. So far I have not done so because I saw no need... Currently I'm using config to determine if the isimodem should or should not control the modem and which phonet device it should or should not use. It is used to determine if ofonod is run with maemo5 cellular daemons or without them. 2) What do you mean by this. They are asynchronous. Not in the master branch. enable() and disable() are async, probe() and remove() are sync. probe and remove are sync for a reason, the core is going to become extremely complicated otherwise. Been there and done that, so you better have a very good reason for wanting this. How the driver knows if the disable() is called because someone just tried to set Powered=false or if ofonod is terminating? In first case, I just want modem to go standby (and flush the atoms) and keep the SIM warmed up and ready, in the second case, driver should ask modem to do proper power off and then does all the required jazz with the gpio lines. It would be help much if disable() would indicate if soft poweroff or hard poweroff is required; likewise This can be added, but the question is are you sure you need it? None of the other hardware we have would benefit from this functionality at all. This immediately raises the question of usefulness. Are you sure this isn't better accomplished by a specific plugin for your system as discussed elsewhere in this thread? You don't seem to handle modem resets at all. Once atdriver gets so far, other hardware will benefit, too. ofono_modem_set_powered() could take enum with transitional states (powering_on, powered_on, powering_off, powered_off + perhaps something like powered_standby). If you don't feel like doing it, I'm happy to contribute. Again, usecase please. How are you going to use this information? * clean handling of modem reboots * keep modem powered while ofonod is running, power it down before ofonod exits * allow applications to put modem on standby by with Powered property (however, with N900 modem, the standby is not different from the pre-sim state) 3) I don't understand this. We have pre-sim and post-sim functionality. If you RFKILL a radio it would be same as removing its object path. Or do you wanna access the SIM card while RFKILLed. What is that good for? Nobody wants to re-enter the pin code if they exit flight mode. It should be possible to spool SMSs while the device is in flight mode. Is there any good reason to keep SIM offlimits? Please note that if your enable/disable behavior only shuts the rx/tx circuits then repeating PIN entry won't be a problem. And I already commented on this elsewhere in the thread. All I ask is that before we start adding tons of
Re: Access to SIM card when Modem is not Powered
to, 2010-04-01 kello 11:14 +0200, ext Pekka Pessi kirjoitti: It seems to me that Marcel and Aki want to control TX power with the Powered property. (BTW, there already is a post-sim mechanism to control the RX/TX, namely Register/Deregister.) But then Register()'s meaning is overloaded to mean both RF on *and* (automatically) register. This doesn't work in the manual registration case, where after landing on the other side of the Atlantic, you first need to turn RF on, then select a roaming partner from a list. In fact, Deregister() is currently not all that useful, and not even implemented in isimodem. I think it should simply be removed. What we miss from the core is a way to do asynchronous cleanup (separate from Powered). A shutdown() method in modem driver and corresponding callback, like ofono_modem_shutdown_ready(). This way we can do what ever N900 requires us to do and there is no need to touch other drivers. That sounds reasonable to me. Cheers, Aki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Access to SIM card when Modem is not Powered
Hi Aki, to, 2010-04-01 kello 11:14 +0200, ext Pekka Pessi kirjoitti: It seems to me that Marcel and Aki want to control TX power with the Powered property. (BTW, there already is a post-sim mechanism to control the RX/TX, namely Register/Deregister.) But then Register()'s meaning is overloaded to mean both RF on *and* (automatically) register. This doesn't work in the manual registration case, where after landing on the other side of the Atlantic, you first need to turn RF on, then select a roaming partner from a list. I agree, Register is not the right one here. In fact, Deregister() is currently not all that useful, and not even implemented in isimodem. I think it should simply be removed. I'm actually fine removing it since most modems end up not supporting this either. Regards, -Denis ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [PATCH 1/5][RfC] Add functions to notify core of SIM insertion/removal/proactive command.
Hi Andrew,
Make every plugin generate a sim inserted event on start. For devices
with removable SIM card, the event should be emitted after the
plugin detects it.
---
+unsigned int ofono_sim_add_removed_watch(struct ofono_sim *sim,
+ ofono_sim_ready_notify_cb_t cb,
+ void *data, ofono_destroy_func destroy);
+
+void ofono_sim_remove_removed_watch(struct ofono_sim *sim, unsigned int
So let us refactor the existing SIM ready events and the SIM removed events
into a single set of watch functions with a state enum.
e.g. something like
enum ofono_sim_state {
OFONO_SIM_STATE_NOT_PRESENT,
OFONO_SIM_STATE_INSERTED,
OFONO_SIM_STATE_READY,
};
id); +
int ofono_sim_get_ready(struct ofono_sim *sim);
-void ofono_sim_set_ready(struct ofono_sim *sim);
+
+void ofono_sim_inserted(struct ofono_sim *sim);
+void ofono_sim_removed(struct ofono_sim *sim);
Lets make these into a single function with a ofono_bool_t parameter.
+void ofono_sim_proactive_command_notify(struct ofono_sim *sim,
+ int length, const guint8 *pdu);
Can you send this part in a separate patch? And this belongs on a separate
stk atom.
+void ofono_sim_inserted(struct ofono_sim *sim)
+{
+ sim-inserted = TRUE;
+
+ /* Perform SIM initialization according to 3GPP 31.102 Section 5.1.1.2
+ * The assumption here is that if sim manager is being initialized,
+ * then sim commands are implemented, and the sim manager is then
+ * responsible for checking the PIN, reading the IMSI and signaling
+ * SIM ready condition.
+ *
+ * The procedure according to 31.102 is roughly:
+ * Read EFecc
+ * Read EFli and EFpl
+ * SIM Pin check
+ * Request SIM phase (only in 51.011)
+ * Read EFust
+ * Read EFest
+ * Read IMSI
+ *
+ * At this point we signal the SIM ready condition and allow
+ * arbitrary files to be written or read, assuming their presence
+ * in the EFust
+ */
+ sim_determine_phase(sim);
+}
The only other issue here is that you have to wait for the sim atom to
register before you start the initialization process.
+void ofono_sim_proactive_command_notify(struct ofono_sim *sim,
+ int length, const guint8 *pdu)
+{
+}
+
This belongs on a separate stk atom.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [PATCH 2/5][RfC] Release calls when SIM is removed.
Hi Andrew,
---
+static void sim_ready_watch(void *user)
+{
+ struct ofono_voicecall *vc = user;
+ struct ofono_modem *modem = __ofono_atom_get_modem(vc-atom);
+ struct ofono_atom *sim_atom =
+ __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_SIM);
+ struct ofono_sim *sim = __ofono_atom_get_data(sim_atom);
+
+ /* Try both formats, only one or none will work */
+ ofono_sim_read(sim, SIM_EFECC_FILEID,
+ OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
+ ecc_g2_read_cb, vc);
+ ofono_sim_read(sim, SIM_EFECC_FILEID,
+ OFONO_SIM_FILE_STRUCTURE_FIXED,
+ ecc_g3_read_cb, vc);
+}
This part needs to be done when SIM is inserted. If you refactor the previous
patch, then we should also easily have INSERTED state notifications too and get
this taken care of properly.
+
+static void sim_removed_watch(void *user)
+{
+ struct ofono_voicecall *vc = user;
+
+ vc-flags |= VOICECALLS_FLAG_MULTI_RELEASE;
+
+ /* TODO: Don't hang up emergency calls */
+ voicecalls_release_queue(vc, vc-call_list);
+ voicecalls_release_next(vc);
I suggest you only shuffle the emergency numbers here. Let the modem driver
notify which calls have been terminated. If this is wrong we can fix it later,
but sending a CHLD=1X is actually wrong here.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: PPP LCP configuration issue
Hi Kristen,
so I added some debug code to actually print the options during the
configuration stage. And something seems to be wrong here.
lcp: pppcp_open_event: current state 0:INITIAL
lcp: pppcp_up_event: current state 1:STARTING
lcp: pppcp_initialize_restart_count: current state 1:STARTING
lcp: pppcp_send_configure_request: current state 1:STARTING
lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
lcp: pppcp_process_configure_request: current state 6:REQSENT
lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
lcp: option 3 len 5 (Authentication-Protocol) c2 23 05
lcp: option 5 len 6 (Magic-Number) 01 ff ef e0
lcp: option 7 len 2 (Protocol-Field-Compression)
lcp: option 8 len 2 (Address-and-Control-Field-Compression)
lcp: pppcp_rcr_plus_event: current state 6:REQSENT
lcp: pppcp_send_configure_ack: current state 6:REQSENT
lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
lcp: option 3 len 5 (Authentication-Protocol) c2 23 05
lcp: option 5 len 6 (Magic-Number) 01 ff ef e0
lcp: option 7 len 2 (Protocol-Field-Compression)
lcp: option 8 len 2 (Address-and-Control-Field-Compression)
lcp: pppcp_process_configure_ack: current state 8:ACKSENT
lcp: option 2 len 6 (Async-Control-Character-Map) 00 00 00 00
oops -- found acked option 2 we didn't request
lcp: pppcp_rca_event: current state 8:ACKSENT
lcp: pppcp_initialize_restart_count: current state 8:ACKSENT
I see the oops comment here, but we clearly requested the async control
character map. So why does it get recognized as not requested? This is
clearly a bug and needs to be fixed.
so I added pppdump support to GAtPPP and gsmdial. This allows us to
create log files that can be read by pppdump and Wireshark. The method
of debugging with strace is just not feasible. The attached log file is
one of these. I see a couple of confirmation requests that were send
twice in a row. That seems to be wrong. Can you explain what is going
on.
Regards
Marcel
Kµû ~ÿ}#À!}!}!} }*}}} } } } X{~Kµû U~ÿ}#À!}!} } }9}}} } } } }#}%Â#}%}%}}!}]+}'}}(}Ú~~ÿ}#À!}}!} }*}}} } } } 1}/~Kµû 8~ÿ}#À!}} } }9}}} } } } }#}%Â#}%}%}}!}]+}'}}(}}5Ö~Kµû ~ÿ!
(~Kµû D~ÿ}#À!}+}!} }(}!}]+}-}5~~ÿÂ# # Ú! Tdv®F µÞäEZEUMTS_CHAP_SRVR[¦~Kµû ~ÿÂ# 5Ü=ïW
×GÉ/ê½®äò~Kµû ~ÿÂ# y~Kµü $~ÿ!
åº~Kµü *~ÿ!
üB~Kµý $~ÿ!
=L~Kµý *~ÿ!
~Kµþ $~ÿ!
u ~Kµþ *~ÿ!
§Ë~Kµþ *~ÿ!
§Ë~Kµÿ $~ÿ!
©~Kµÿ *~ÿ!
Ä~Kµ $~ÿ!
Ôû~Kµ *~ÿ!
aK~Kµ *~ÿ!
aK~Kµ $~ÿ!
~Kµ *~ÿ!
~Kµ $~ÿ!
D_~Kµ *~ÿ!
Ñ~Kµ *~ÿ!
Ñ~Kµ $~ÿ!
Ïj~Kµ *~ÿ!
c~Kµ $~ÿ!
8~Kµ *~ÿ!
ÆQ~Kµ *~ÿ!
ÆQ~Kµ $~ÿ!
_Î~Kµ *~ÿ!
¥~Kµ $~ÿ!
~Kµ *~ÿ!
Ø~Kµ
*~ÿ!
Ø~Kµ $~ÿ!
þ+~Kµ *~ÿ!
þ~Kµ $~ÿ!
¶y~Kµ *~ÿ!
[X~Kµ
*~ÿ!
[X~Kµ $~ÿ!
n~Kµ *~ÿ!
8~Kµ $~ÿ!
Ý~Kµ *~ÿ!
Nä~Kµ *~ÿ!
Nä~Kµ $~ÿ!
xä~Kµ *~ÿ!
-¤~Kµ $~ÿ!
0¶~Kµ *~ÿ!
d~Kµ *~ÿ!
d~Kµ $~ÿ!
...@~kµ *~ÿ!
ë$~Kµ $~ÿ!
~Kµ *~ÿ!
Óí~Kµ *~ÿ!
Óí~Kµ $~ÿ!
I¥~Kµ *~ÿ!
°~Kµ $~ÿ!
÷~Kµ *~ÿ!
m~Kµ *~ÿ!
m~Kµ $~ÿ!
Ù~Kµ *~ÿ!
v-~Kµ $~ÿ!
S~Kµ *~ÿ!
t÷~Kµ *~ÿ!
