Notices

Thank you for camera feedback.

It already should work similar like this. There are two deadlines in GPS coordinate acquisition. Which ever is reached first causes a notification being sent:

• timeout reached (GPSTIMEOUT parameter, seconds, default 1800) and
• accuracy reached (GPSMAXDEVIATION, meters, default 50 - setting is not yet shown in SMSCON Editor)

It seems in your case the phone was located where it was not able to receive GPS satellite signals (deep indoor or the like)?!

Note that the timeout starts again after each successfully received GPS coordinate.

I can confirm this behavior. And to be honest, I'm not able to explain. I did some investigations now and found out that it can't work as expected. Because:

(1) If the phone is asking for the lock code on boot, then this will be the very first question et all. Even before SIM card PIN code is being asked for.

(2) The information whether the phone runs with authorized SIM card is first available after the SIM card PIN code question was displayed and answered by user.

(3) Consequence: Even if smscon would run before the lock code is being asked (it does not - this happens too early in the boot sequence) then smscon has no information about SIM yet. So smscon could neither lock nor unlock the phone depending on SIM authorization status.

This is amazing May be the order of questions was vice versa in earlier maemo/osso/firmware phone versions? I don't know. But this is the only explanation I have why smscon has this (not working) feature still.

Is there anybody having different experience in this issue? If not, this "feature" (and the setting to control it) should be removed in next release.

Wow, what did we discuss lock/unlock issues and either it worked in the past and/or nobody tried it.

To me it seem this way: If the phone was locked on shutdown then it is locked on boot and there is no, or at least no obvious or simple way to change it. May be usb-cable connection can change things. Haven't tried this yet.

BTW: I tried to start smscon earlier in the boot sequence to cope with that situation (namely as service at run level 2, started before lock code question). But I had no success. smscon depends on too many resources that are not yet available at this this time (dbus, network, python run time environment, ...). But even if I would got it run, what to do without SIM card information at this time?

Thanks a lot for investigating this.

sequence of events haven't changed since very beginning of Maemo - I always wondered, how SMSCON is supposed to achieve that. I suppose, that no one tried this before

USB cable connection won't change that - lock code is persistent even after reflash (although, not asked on boot). there *is* a hackish - yet, 100% safe and working - way to reset lock code to default, by placing certain file in appropriate directory and running it - I don't remember exactly, as it was one of first things I was doing with my N900 (seller had no idea about code he set, and re-gaining it wasn't possible - DES encrypted hash wasn't present at all [!]), but it was something about writing actual asterisks as lock code. Could re-find that utility, if needed.

Although - while it, probably, would allow SMSCON to reset lock code and disable asking for it on boot - it still doesn't answer, how we may achieve that, as different SIM card is recognized (and enabled, at all) *after* prompt for lock code.
---

I really hope, that someone will get an ingenious idea, as for now, it makes - sadly - smscon quite unusable in pair with lock code. First thing thief/people buying is going to do, if prompted for lock code on boot, is to - probably - flash device, which get rids of smscon :/ Our only "chance" to fool them into running N900 with SMSCON, was by providing access to device functionality, when it's stolen.

On the other hand, lock code is *very* essential for other anti-thievery things, like keeping personal files/photos/whatever in encrypted partition, mounted on boot via truecrypt. Such partition is unmounted on every reboot, so short lock code time ensure that - no matter what, even after complete reflash - no one will have access to our encrypted partition/container.

Add to this other use cases for lock code, and we have serious dilemma :/

/Estel

How did you achieve this while the phone was locked? Just a hint, please - no exact how-to In my experience a WLAN connection, prerequisite for remote login, is not available at this time.

Despite this, in my opinion the lock-code/SIM code dilemma should not be solved by somehow resetting the lock-code. Even less automatically on boot. The regular owner's lock code should persist even if phone is in thief or finders hands. May be a solution is, if smscon could change boot time order of questions to first SIM code and then lock code. Where SIM code may be skipped as usual but lock code can't. In other words, to reach a phone status that is similar to when a regular user locks the phone.

I've used to have security lock code enabled in every phone which I've had. So when phone is booted, it asks the security code. But because the known reasons with SMSCON, I do not have that setting anymore in N900.

Therefore, even when the phone is not lost or stolen,
I'd prefer SMSCON (optionally) to lock the phone after it has been booted up and SMSCON daemon has started. Is it possible?

(2nd solution)
Maybe it could even start an app, which doesn't allow itself to be killed nor switched to the background, and which will grab keyboard and touch screen. The unlock code would be given with the physical keyboard and if it would match, then the application would quit and free the access to the device.

If the SIM card had been changed, then based on the user settings either lock, do not lock, or run some other blocking or non-blocking app.

Edit2:
Also auto-locking after inactivity (1 - N min) should be inside smscon daemon, because the system setting for that cannot be used.

Hi guys,
too many healthy and technical disscusion here now a days( since i am noob i dont understand too much)

but as Estel says

so i think i should test it too!

i had some dead SIM cards(old sim cards which are not active now so i test with them)


but here in my case it is absolutely opposite happanes.

my n900 never ask for lock code on boot with both settings "Unlock Device" checked and unchecked.






NOTE:-

1. i am using PR 1.3
2. my smscon editor is 0.9.12-1
3. and smscon is 0.9.19-1
4. i checked with dead sim cards that on boot show "SIM card Registration failed"

EDIT: may be i should check with active sim cards

Yes, I think so. There could be a very small timing window until smscon starts up and does the job. Hackers which know what's going on could use the time to cancel locking. May be this risk, should it really exist, is only theoretical or so minor that it can be ignored.

Generally this to me sounds like a possible solution.

Yes, whereby smscon would only lock/unlock and try to notify the owner who is responsible to send further commands to start apps.

I don't understand why. Could you please explain?
-- OK, I got it. Because locking is turned of et all. Yes.

This has nothing to do with smscon. Do it like this:

• (1) First enable N900's own device lock function.
• (2) Then lock the phone explicitly. When locking the first time the phone will ask for lock code (just to ensure there is anybody who knows the code before it really goes locked).
• (3) Tab on the outside of the "enter lock code" window and the phone asks for shutdown. If you do so, it will ask for lock code on boot.

Maybe, if I want locking, smscon could enable the system setting after booting, and disable it on shutdown. This way the lock code would not be checked at boot time, default system locking would be switched on afterwards, and (hopefully) not too much extra code would need to be added to smscon itself. Also, if some attacker manages to kill smscon on the running phone, default system locking would still be activated.

The problem is, that with locked phone, we lesser our chances to retrieve phone - as normal solution for thief - when facing locked phone - is to flash it (or give to someone else to flash). This way, without knowing it, he also get rids of SMSOCN.

Optimal solution would be to have lock code present - to protect device from spying eyes and for protection of truecrypt partitions/volumes - but, to have a way to auto-disable lock code, when phone is in "stolen" state. This way, we present thief with "usable" phone (without access to our private things via truecrypt), so odds are, that he won't even flash it.

Ho ever, I've no idea how to achieve it

@yablacky
Method I've described (to reset security code) is only useful, when device have lock code set, but not asked during boot. Of course, You're right that there is no way to reset it when it's asked during boot, other than flashing.
---

Maybe SMSCOC should have a small part run via U-Boot/backupmenu? This way, it could reset lock code in a way we can do this via recovery console, manually (generic one, or bundled in backupmenu). After all, with proper mounting, everything can be achieved from recovery console - so, some script to automaticaly disable lock code, when pre-defined conditions are meet, should work too.

/Estel