Reply
Thread Tools
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#21
@peterleinchen
Thanks for this method, it helped much with my son's device, which suffers from this problem (albeit it doesn't matter, as it's simless-device, relying on VoIP and WiFi, for voice conversations).

Hoever, I have found a nasty, reproducible side-effect. If one is using the "iw reg set JP" method for connecting to APs working on channel 13 & 13, avoiding to run sscd results in strange behavior. Channels 12 and 13 *gets* unlocked properly (as seen by iwlist wlan0 frequency), but everytime you actually try to connect to some network (by going status menu -> connect to network), it immediately gets locked again, and only channels up to 11 are visible.

Furthermore, if you have automatic WiFi scan and connect set up (for example, to scan every 10 minutes if not associated), it reverts to channels >=11 mas soon as it scans. So, basically, you're not able to connect to channels 12 & 13, at all.

I've tried commenting out just parts of the /etc/event.d/sscd script, and I determined that it's the "exec /usr/sbin/sscd -f" part that needs to be left working, in order to have channels 12 and 13 unlocked persistently. Hoever, it's the same bit that is responsible for those dreaded messages that your hack tries to solve (commenting out other parts of script doesn't seem to help), so it's a kind of closed loop

Any ideas how to get rid of those pesky "telephony functions disabled" message *and* keep "iw reg set JP" trick working?

/Estel

// Edit

It seems that something stupid is "fighting" for setting regulatory domain. If I do (from terminal):

Code:
iw reg set JP;sleep 2;iw reg set JP; sleep 4;iw reg set JP
...and after starting, quickly go to connecting, I can see (for a few seconds) my channel 13 network, connect to it, and it happily stays connected afterwards ("iwlist wlan0 frequency" lists channels 12 and 13 as available, too). Without the "sleep 4;iw reg set JP" part, I'm able to see my network and attempt connecting, but during it, channels get locked again and connection fails. So, basically, one need to automatically "spam" unlocking to keep channels unlocked, till connection is established.

It's irritating, and not a permanent solution by any means, as it still doesn't allow to have automatic wlan0 connection set up. Any ideas what the hell is responsible and how to fix it for good?

// Edit 2

This thread gives some insight on crazy way Maemo determines which channels to make available, initially (on SIM-less device):
http://talk.maemo.org/showthread.php?t=93263

But it still doesn't help to resolve the issue on sscd-less device

// Edit 3

Found this:
http://talk.maemo.org/showpost.php?p...94&postcount=6

...so, maybe just forcing module to load with JP (or EU) parameter would fix it? Gonna try...

// edit 4

Indeed, creating a file /etc/modprobe.d/cfg80211 with content like:

Code:
options cfg80211 ieee80211_regdom=JP
... makes channels 12 and 13 available as soon as modules (wl112xx, max80211, cfg80211, in that order) are loaded - so, it's better than any hack involving "iw reg set JP", because it doesn't require you to put the latter command into every thing that may enable or disable WiFi (advanced interface switcher, cleven, etc). Your modules just get loaded with proper config.

Hoever, it [b*doesn't*[/b] fix the issue with omitting /usr/sbin/sscd from start - just like with setting reg via iw, some s**t overwrites reg to US as soon as you (or device, automatically) scans for device. Why someone at Nokia coded something in such stupid way, that it overwrites variable took from module loadtime parameter, is beyond me Still searching for a way to disable useless SIM related things on device without functioning modem, and have upper WiFi channels fully available at the same time...
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!

Last edited by Estel; 2014-07-10 at 02:24.
 

The Following 3 Users Say Thank You to Estel For This Useful Post:
peterleinchen's Avatar
Posts: 4,117 | Thanked: 8,901 times | Joined on Aug 2010 @ Ruhrgebiet, Germany
#22
Hi!

That is interesting. And I would not call it dumb but 'legally correct' implementation?

Sorry I have no idea in the morning.
Just a quick one: what is sscd -w doing? Maybe try to modify /etc/inid/sscd and replace -f with -w? [really w/o any knowledge and guaranty]

--
I assume wlancond is requesting domain from sscd and sets back to US. So probably a hack with dbus waiting for wlan scan and then set reg_domain to JP in a loop?

And let's continue in the other thread if it is not related to sscd. Otherwise of course here.

--
another possible idea:
start on started hildon-desktop
may let you boot. And you will/should get that message later, but only once.
__________________
SIM-Switcher, automated SIM switching with a Double (Dual) SIM adapter
--
Thank you all for voting me into the Community Council 2014-2016!

Please consider your membership / supporting Maemo e.V. and help to spread this by following/copying this link to your TMO signature:
[MC eV] Maemo Community eV membership application, http://talk.maemo.org/showthread.php?t=94257

editsignature, http://talk.maemo.org/profile.php?do=editsignature

Last edited by peterleinchen; 2014-07-10 at 22:25.
 

The Following 2 Users Say Thank You to peterleinchen For This Useful Post:
Estel's Avatar
Posts: 5,028 | Thanked: 8,613 times | Joined on Mar 2011
#23
Re sscd - I wonder if we know how sscd answer regulatory domain? For devices without working modem, a dummy fake sscd that reply whatever it's told to reply could be created...

I still think that current implementation is not only dumb, but idiotic - No reason to have device falling back to some obscure* regulatory domain (US) in absence of info from SIM, if all other regional settings on the device points otherwise.

*no offense to US'ians - by "obscure" I mean "appropriate in minority of the world, and no real reason to use it as default". AFAIK, neither Europe, Asia, Australia, South America or Antarctica demand locking of upper 2,4GHZ channels. We could, as well, apply North Korean rules and lock all radios by default - you know, just to be on the safe side and avoid accidentally breaking radio laws...
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
 
Reply

Thread Tools

 
Forum Jump


All times are GMT. The time now is 01:07.