@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):

...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:

... 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...