I see the same "No connections available" issue with OS 2006 3.2006.49-2, OS
2006 2.2006.39-14, and OS 2006 1.2006.26-8.  I do NOT see the problem with OS
2005 3.2005.51-13.

I'm in a very dense wifi environment, so when the scan results do return
something, I set up to 25 SSIDs listed.  If I move to a location that's more
isolated, the problem disappears and I see a handful of SSIDs on every scan.

Under OS 2005, I tend to see fewer SSIDs in general.

My guess is that the scan results are hitting some limit (at which point the
entire scan results are discarded).  The wireless device does seem more
sensitive under OS 2006, so the 770 is more likely to hit the scan results
limit when running OS 2006.

I have an N770 and an N800.  At home I have a Netgear WNR834Bv2 router with
firmware version V 2.0.8_2.0.8NA (an 802.11N router).  The N800 has never had a
problem connecting but the N770 was very rarely able to connect.  Today I
dropped the wireless connect speed from 130 Mbps to 54 Mbps and now the N770 is
able to reliably connect.  I suspect that the N770 was being overrun by the
higher speed --it would be nice if some sort of error message were output
instead of saying no connection found.  Dropping the speed resolved my N770
problem but of course I am not getting the speed advantage of an N router

I'm experiencing the exact same problem as Scott.  My N770 has gone from
finding connections well (better than a friend's laptop) to mostly NOT finding
any connections at all: "No connections available".  On the rare occasion that
it does find a connection, it will connect and work as expected.  It had been
working fine in the same environment before, but the number of wi-fi access
points have definitely increased in my neighborhood.

Like Henry, I've gone through all OS2006 versions without much luck and can
confirm that OS2005 does works.  Unfortunately OS2005 doesn't support WAP, only
WEP, which I'd rather not degrade to.

I have a Linksys WRH54G B/G router (which had been working well with the N770).
 Perhaps it's an N router in the neighborhood as Donald suspects?  Or maybe the
connections list is getting overflowed as Henry suggests?

I can confirm that the latest OS2007HE,
SU-18_2007HACKER_4.2008.7-1_PR_F5_MR0_ARM.bin,
has the same problem.

Just tried OS2008HE, SU-18_2008HACKER_4.2007.50-6_PR_F5_MR0_ARM.bin, with the
same results, "no connections available".

I took the N770 to two different areas with low wi-fi blanketing and everything
works as expected.  It does appear to be a problem with the connections list
overflowing.

Comment 6 Andre Klapper 2008-06-13 16:43:07 UTC

Thanks for all the coments! This report may deal with several issues, but
basically the assumption is that no access points get listed if there are lots
of wifis around, right?
Anybody also facing this problem with an N810?

Comment 7 Andre Klapper 2008-06-24 16:13:44 UTC

also see bug 1106 which could be a duplicate of this ticket.

Copying from bug 1106:

"iwlist is not working correctly in N800, that's why you see only so few APs
using iwlist. Could you please try scan from UI? If you have syslogd installed,
wlancond prints the scan results to syslog.
There's a limit for AP count, but it should much higher."

anybody able to answer this? thanks in advance!

All my scans have been through the UI.  I'm getting "No connections available"
without a list of any access points.  What test would you like run?  (I have an
N770.  No N800 or N810 to test with.)

I have same problem, OS2008HE on 770, no connections avaliable, But dmesg says:
"Scan complete, scanned 13 channels"

Comment 10 Andre Klapper 2008-07-14 18:39:08 UTC

When flashing to Diablo (or Hacker Edition in this case), did you restore
backup on first boot, or later?
also see https://bugs.maemo.org/show_bug.cgi?id=2926#c10

I am experiencing the exact problem as detailed by the reporter of this bug.  I
am currently running the latest official release (version 3.2006.49-2), but I
also tried the last two HE editions and had the same results.  It usually takes
about 20-50 searches to see my AP come up, and when it does I can connect to it
only about 10 percent of the time. This takes patience and a great deal of
time. Once the connection is established it stays up reliable for hours. 

One observation that I made is that a few weeks ago I was traveling at a
relatively remote area with only a few access points and my tablet was
connecting with only minor issues.  The problem is always manifesting itself in
a very densely populated area where my two laptops usually see more than 20 APs
at a time.  I am also never more than 4 metres away from my own AP with a
direct line of sight.  This observation appears to be in line with the
speculation made by others that the issue is related to the number of visible
APs.

I do have xterm and becomeroot installed.  Are there any cli commands that I
can use to diagnose and possibly to resolve the issue?

After a few experiments in order to test the hypothesis that this behavior is
related to the number and/or the signal strength of other APs, I discovered a
limited 'hardware' workaround to the bug.  This may sound a bit silly, but the
'hardware' part is a stainless steel mixing bowl which I used to shield the
tablet from nearby signals.  Here is what I did:

1. Take stainless steel bowl and go as far away from the most likely direction
of other APs, while still keeping a close proximity to the AP you wish to
connect to.

2. Start searching for APs while immersing the tables in the bowl. Shield the
tablet just enough to see your own AP with enough signal strength that will
allow you to connect.

This appears to work for me for now, and I can finally get my networking to
come up within a reasonable amount of time.  The only downside is that unless
you are willing to travel with a stainless steel mixing bowl accessory this
solution is only practical for home use.

Comment 13 Andre Klapper 2008-08-08 17:24:12 UTC

So, can somebody please provide a log by using syslogd? See
http://maemo.org/development/tools/doc/diablo/syslog/ .
(see comment 7)

(In reply to comment #13)
> So, can somebody please provide a log by using syslogd? See
> http://maemo.org/development/tools/doc/diablo/syslog/ .
> (see comment 7)
> 

If someone will post a pointer to a compiled binary, I'll post a log.  (I
really hate being the newbie moron, but I've looked all over and find lots of
general documentation and man pages, but no executable.)

Comment 15 Andre Klapper 2008-10-22 22:14:56 UTC

(In reply to comment #14)
> > So, can somebody please provide a log by using syslogd? 
> If someone will post a pointer to a compiled binary, I'll post a log.

Burgess:
We use repositories, not web downloads. :)
See http://maemo.org/development/tools/#apt-example for how to install.

Please also tell us your hardware and make sure to use the latest available
software version (N800 and N810: 4.2008.36-5).
Also see comment 7 about why I'm asking for this...

(In reply to comment #15)

> We use repositories, not web downloads. :)

Thanks, Andre.  Knew that, but didn't use the magic words.

> See http://maemo.org/development/tools/#apt-example for how to install.

Excellent.  Now, if I can just get reconnected...

> Please also tell us your hardware and make sure to use the latest available
> software version (N800 and N810: 4.2008.36-5).

This is on a 770 running 2007HE 4.2008.7-1

Assuming it does eventually reconnect, I will be back.

Andre - syslog sent via e-mail.

FWIW, this does not seem to be a dupe of 1106, at least not in my case.  I see
about the same number of APs as before -- when it sees any at all.  

And in the vein of comment 12, I can apparently "filter" whatever outside
influence seems to be causing the problem by "hugging" the 770 against my body
during the search, and again while it attempts to connect to my local AP.  I
look pretty stupid doing it, but it works for me 100% of the time.

Comment 18 Andre Klapper 2008-10-24 14:43:19 UTC

(Correcting the hardware info. I have no idea why I changed that to N800.)

So I've seen only reports about the 770 (with official and/or latest Hacker
Edition release), and one comment that the N800 works.
I really start thinking that this is a hardware issue, or that the 770 has some
kind of limit for scanning APs.

Comment 19 Andre Klapper 2008-10-24 14:44:11 UTC

Created an attachment (id=991) [details]
syslog

Burgess: Thanks for the for the great syslog!!

Quoting some parts here:

770 running 2007HE 4.2008.7-1
19:13:17 interesting stuff starts
19:13:26 Scanning the user's home ssid 'default' that I want to connect to
19:14:31, I was partially shielding the 770 by clasping it flat between my
palms.  At that point, you can see that it picked up a few APs.  When I
selected my local AP ("default"), I removed the shield and the connection
failed.
19:15:05, I again shielded the 770, but this time, I "hugged" it with the face
flat against my body and wrapped both hands over the back, covering it
completely.
19:15:12, it recognized ONLY my local AP -- no others showed up in the list.
I selected my local AP from the list and immediately shielded the 770 in the
same hugging manner as before.
19:15:23 Successful connection

I am certain now that this is related to some sort of local interference,
possibly from nearby n networks.  I repeated the "hugging" experiment 5 times,
and it worked every time.  Leaving the tablet unshielded resulted in the
failure to see APs and/or failure to connect to found APs.

I conducted these experiments within 6 feet of my own WAP.

BTW, I have taken the tablet to work where we have less networks and have not
experienced the same sort of failures -- the tablet sees APs and connects every
time on the first attempt.

Comment 20 Andre Klapper 2008-10-24 15:04:41 UTC

@Kalle, can you take a look at this and whether you have any ideas?
It's about the 770, but we've got a great syslog and lots of people running
into this.

(In reply to comment #19)

> ...I have taken the tablet to work where we have less networks...

This is not quite correctly paraphrased.  I normally see 5 APs at home and 4
APs at work -- not a significant difference, I would think.  I'm pretty sure
that the 5th AP visible from my home -- one that just recently appeared -- is
different in some way (802.11n?) and that may be the problem.  My own AP is
.11b and I'm sure none of the APs at work are faser than .11g.

I'd like to confirm a report of the same bug here.

Tried on OS2006 and OS2007HE (2008.7-1).

After struggling for some days with this, found this bug report and tried the
"shielding with the body" trick, and it consistently works.  (Hooray!)

Previously had no problems with either OS2006 or OS2007HE, but has been some
time since the N770 has been used for various reasons, so could be that new APs
have appeared in the meantime (maybe the dreaded 802.11n?).

Let me know if there's any info I can provide to help in this, got a couple of
wireless routers (SpeedTouch and Asus) here also if that would help in scanning
to see what APs are in the area in case that helps.

Comment 23 Kalle Valo 2008-11-04 18:03:22 UTC

(In reply to comment #20)
> @Kalle, can you take a look at this and whether you have any ideas?
> It's about the 770, but we've got a great syslog and lots of people running
> into this.

Sorry, no time for 770 anymore. Fremantle is keeping me very busy.

FWIW, I also seem to be experiencing this on OS2007 on an N800 - but not with
OS2008

Comment 25 Andre Klapper 2008-12-02 15:38:26 UTC

(In reply to comment #23)
> Sorry, no time for 770 anymore. Fremantle is keeping me very busy.

In fact this means WONTFIX.
Note that this is neither my nor Kalle's decision, but rather a Nokia
management one on priorities and manpower.

In general I prefer to be honest (and probably receive some rants) instead of
keeping reports open that will not get fixed & fueling expectations that will
not be fulfilled.

Sorry, and once again thanks for the great investigations to get this tracked
down, but apparently we were too late in Nokia's development cycle planning.
:-/

(In reply to comment #25)
> (In reply to comment #23)
> > Sorry, no time for 770 anymore. Fremantle is keeping me very busy.
> 
> In fact this means WONTFIX.
> Note that this is neither my nor Kalle's decision, but rather a Nokia
> management one on priorities and manpower.
> 
> In general I prefer to be honest (and probably receive some rants) instead of
> keeping reports open that will not get fixed & fueling expectations that will
> not be fulfilled.
> 
> Sorry, and once again thanks for the great investigations to get this tracked
> down, but apparently we were too late in Nokia's development cycle planning.
> :-/
> 

The workaround of "hugging" the 770 to one's body, as suggested in comment #17,
appears to work very well, and after some practice it provided me with a fairly
reliable methodology of getting the tablet to connect.  It works much better
than the "mixing bowl" method I suggested earlier in comment #12.  Can someone
at Nokia please document this "hugging" workaround in some official FAQ?

The hugging trick works for me too!  I still haven't mastered it, but at least
I'm getting use out of my 770 at home.  (It's been great for travel.)  Thanks
all!

Folks, the hugging or shielding trick did not work for me. I do a see a 802.11n
network near my home now. Maybe this is the culprit. Without the network, the
tablet is useless to me.

(In reply to comment #28)
> Folks, the hugging or shielding trick did not work for me. I do a see a 802.11n
> network near my home now. Maybe this is the culprit. Without the network, the
> tablet is useless to me.
> 

All I can suggest is hugging/shielding more - you need to somehow get it into a
position where it sees your network and not the 802.11n one

@Kiru -- it's definitely a matter of relative signal strengths. You must be in
a location where you can effectively shield the signal from the competing
network, while still being able to receive an adequate strength signal from the
preferred network. 

After installing Netstumbler on the laptop and doing a quick inventory of
signal strengths at various places in my house and around my property, I
determined the spots where I had the best chance of connecting to my own AP.
Away from home, I rarely have problems because most public APs I have found are
not 802.11n.  They're usually b or g and cause no problem.

I have the same problem, works fine in office but "no connection available" at
home.
I have confirmed that setting up wifi from command line works fine to me, so
this is the gui frontend problem.
Here's how I setup wifi from command line:
1. install packages like xterm, gainroot, wireless-tools
2. set wifi parameters:
iwconfig wlan0 key <your WEP key>
iwconfig wlan0 mode managed
iwconfig wlan0 essid <your ssid>
3. set ip parameters(you will use your own ip addresses of course):
ifconfig wlan0 up
ifconfig wlan0 192.168.0.60 netmask 255.255.255.0
route add -net 0.0.0.0 netmask 0.0.0.0 gw 192.168.0.1
4. set dns server
modify /etc/resolv.conf to set the dns server

Then I can use internet from command line, ping/wget/apt-get all worked well.
However, the browser still doesn't work, it will show "searching connections"
instead of fetching the URL. So I guess there must be a flag somewhere telling
the browser to setup connection even though the internet is working well
underneath.

(In reply to comment #31)
Oops, "ifconfig wlan0 up" should be the first command issued to make this work.

syslog shows that the built-in browser needs to query a daemon called icd on
"com.nokia.icd.connect" before doing anything. I tried minimo_0.20.2 and it
worked fine.
So, there are several possible solutions:
1. the built-in browser only queries icd if there's no available internet
connection
2. icd replies application query based on real internet connectivity
3. make wlancond communicate with the kernel properly, because the kernel
logging shows the scanning was successful:
Jan  2 23:22:10 Nokia-770-36 wlancond 1.1.12[1432]: Wlancond scan change,
old_state: SCANNING, new_state: SCAN_IDLE
Jan  2 23:22:10 Nokia-770-36 wlancond 1.1.12[1432]: Getting scan results failed
Jan  2 23:22:10 Nokia-770-36 kernel: [ 5546.829681] Scan complete, scanned 11
channels

Option 3 seems the best since it fixes the root cause.
Anyone knows where I can get the source code of wlancond ?

(In reply to comment #33)
Hmm,  this "Scan complete, scanned 11 channels" message may not mean the
scanning was successful; if that's the case, it might be easier to do something
on option 1 & 2 , to at least make the tablet useful when the AP's parameters
are known.

Well, this icd/wlancond stuff seems making simple things complicated. The maemo
connectivity framework should at least provide a way to enable/disable itself,
so users can have the choice of using wifi in the same way as on a laptop.
Currently I can use wifi from command line, and 3rd party softwares work well,
the only problem is that the built-in applications are not working, given that
each built-in application has several 3rd party substitutes, this is not that
bad, but still it would be great if the maemo connectivity module can provide a
way to enable/disable itself.

Comment 36 Kalle Valo 2009-09-12 18:01:41 UTC

(In reply to comment #35)
> Well, this icd/wlancond stuff seems making simple things complicated. The maemo
> connectivity framework should at least provide a way to enable/disable itself,
> so users can have the choice of using wifi in the same way as on a laptop.

Dummy IAP is for this:

http://wiki.maemo.org/USB_networking#Behind_the_scenes

(In reply to comment #36)
Cool, everything is working now, Thanks!

(In reply to comment #37)
> Cool, everything is working now, Thanks!

Is there any chance you (or maybe a kind soul @ Nokia) would take a few minutes
to write up a brief, simple, straightforward how-to so that those of us less
well versed in networking might reproduce your solution?  I looked at the info
on dummy IAPs, and I can see instinctively how it could help, but I don't have
a good enough grasp of the mechanics to get from there to "everything is
working."  I'm pretty sure I'm not alone.

(In reply to comment #38)
I agree if someone can make or port a GUI tool to do this(e.g., report error
and handle dhcp stuff) that would be the best. Here I just list what's working
on my 770 at home:

OS: os2007HE
installed packages: xterm, gainroot, wireless-tools

step 1: get root access in a xterm
step 2: run these commands in the xterm:
ifconfig wlan0 up
iwconfig wlan0 key <your wep key>
iwconfig wlan0 mode managed
iwconfig wlan0 essid <your ssid>
ifconfig wlan0 <your ip> netmask <your netmask>
route add -net 0.0.0.0 netmask 0.0.0.0 gw <your default gateway>
echo "nameserver <your dns server>" > /etc/resolv.conf
gconftool -s -t string /system/osso/connectivity/IAP/DEFAULT/type DUMMY

In the above commands, replace "<blahblah>" with parameters of your
network(without the '<' and '>').
Then minimo should work fine; when using any built-in applications and the 770
asks you to choose a connection, always choose "DEFAULT" from the list, and
then everything should work fine.
You can also put all the commands in a script to make it easier to run it
again.

(In reply to comment #39)
> ...Here I just list what's working on my 770 at home:

Excellent. Thanks.

I downloaded the sources of the platform from
http://tablets-dev.nokia.com/Nokia_770_OS.php?f=3.2006.49-2-srcs.tar.gz and
believe I have traced down the source of the scannning error wlancond is having
thanks to the attached syslog:

        if (ioctl(sock, SIOCGIWSCAN, &req) < 0) {
                /* Check if we got too many results for 
                   our buffer*/
                if (errno == E2BIG) {
                        DLOG_DEBUG("Too much data for buffer length %d "
                                   "needed %d\n", buflen, req.u.data.length);

                        char* new_buffer = NULL;
                        buflen = (req.u.data.length > buflen ?
                                  req.u.data.length : buflen * 2);
                        new_buffer = g_realloc(buffer, buflen);

                        buffer = new_buffer;
                        goto try_again;
                }

                /* Check if results not available yet */
                if (errno == EAGAIN)
                {
                        DLOG_DEBUG("Not yet ready...");
                        if (counter-- > 0) {
                                sleep(1);
                                goto try_again;
                        }
                }

                DLOG_ERR("Get scan results failed\n");

                goto param_err;

Looks like a buffer issue. I will dig a little more into this, but right now I
don't have any compiling environment set up.

This is likely a deeper issue with the wireless driver or in the kernel, as
iwlist uses the same API to get scan data (SIOCGIWSCAN)
http://stackoverflow.com/questions/925669/how-does-iwlist-command-scans-the-wireless-networks

It works when it is restricted to one channel (like when already associated)
but fails when I try to use the scanning when unassociated (all 11 channels).

heh, iwlist.c contains code which looks mighty familiar (almost identical to
the dbus handler for wlancond):
          /* Try to read the results */
          wrq.u.data.pointer = buffer;
          wrq.u.data.flags = 0;
          wrq.u.data.length = buflen;
          if(iw_get_ext(skfd, ifname, SIOCGIWSCAN, &wrq) < 0)
            {
              /* Check if buffer was too small (WE-17 only) */
              if((errno == E2BIG) && (range.we_version_compiled > 16))
                {
                  /* Some driver may return very large scan results, either
                   * because there are many cells, or because they have many
                   * large elements in cells (like IWEVCUSTOM). Most will
                   * only need the regular sized buffer. We now use a dynamic
                   * allocation of the buffer to satisfy everybody. Of course,
                   * as we don't know in advance the size of the array, we try
                   * various increasing sizes. Jean II */

                  /* Check if the driver gave us any hints. */
                  if(wrq.u.data.length > buflen)
                    buflen = wrq.u.data.length;
                  else
                    buflen *= 2;

                  /* Try again */
                  goto realloc;
                }

              /* Check if results not available yet */
              if(errno == EAGAIN)
                {
                  /* Restart timer for only 100ms*/
                  tv.tv_sec = 0;
                  tv.tv_usec = 100000;
                  timeout -= tv.tv_usec;
                  if(timeout > 0)
                    continue;   /* Try again later */
                }

              /* Bad error */
              free(buffer);
              fprintf(stderr, "%-8.16s  Failed to read scan data : %s\n\n",
                      ifname, strerror(errno));
              return(-2);

This has to do with buffer limits, but I don't know whether they are in the
driver or we can use some other workaround.

Created an attachment (id=3187) [details]
strace of iwlist scanning

iwlist uses a nearly identical codepath to scan for access points. It appears
the IO call does indeed return -1 EINVAL (Invalid argument). This could be
because of buffer issues, but could also be an issue with the lower level
driver.

Created an attachment (id=3200) [details]
syslog with cx3110x module debug turned on

Successfully compiled what I believe to be the latest patched version of the
driver from https://bugs.maemo.org/show_bug.cgi?id=2006 (source deb for
package).

I am not in an area with an N network. The included module (in 2008HE) works
without issue in this location.

Turned on debug in my compiled kernel, but it appears that it may not be the
the latest or there is a problem because I am getting null pointer exceptions
when scanning. I will attempt to rebuild this evening without the debug and see
if that was the cause. In the meantime I am attaching the syslog which includes
the debug messages from an area that works for me (with stock modules).

Created an attachment (id=3201) [details]
non-crashy debug module syslog

Looks like if I don't touch (reload) the umac.ko, then the kernel stays happy.
This is the syslog with all debugging turned on in cx3110x from a location
which does *not* have N network around.

it appears that we are having trouble getting the scan data which is performed
during:
sm_drv_oid_get: Get OID 0x1c000044, len 322

this attempts to set callb_mask with:
callb_mask = prism_softmac_conf(lp->sm_context, &smconf);

but callb_mask is < 0 so it produces the following error:
sm_drv_ioctl (Get OID 0x1c000044): sm_conf error -8
and returns -EINVAL (which is the source of the "Invalid Argument" mentioned in
previous comments.

        } else if(callb_mask < 0) {
                DEBUG(DBG_IOCTL,
                      "sm_drv_ioctl (Get OID 0x%x): sm_conf error %d\n",
                      smconf.oid, callb_mask);

                return -EINVAL;
        }

The failure is in a function which is in the User Mode area of the UMAC
(softmac2.h) which does not have source code released. Very frustrating.
http://www.gossamer-threads.com/lists/engine?do=post_view_printable;post=21639;list=maemo

./softmac2.h:SM_API int32_t SM_FDECL prism_softmac_conf( uint32_t *context,
struct s_sm_conf *conf );

Might have some luck with islsm:
http://lekernel.net/prism54/freemac.html

Err, not in user mode, it is a kernel module

(In reply to comment #49)
> The failure is in a function which is in the User Mode area of the UMAC
> (softmac2.h) which does not have source code released. Very frustrating.
> http://www.gossamer-threads.com/lists/engine?do=post_view_printable;post=21639;list=maemo
> 
> ./softmac2.h:SM_API int32_t SM_FDECL prism_softmac_conf( uint32_t *context,
> struct s_sm_conf *conf );
> 
> Might have some luck with islsm:
> http://lekernel.net/prism54/freemac.html
>

Are you going to try that road?
I may try ...

(In reply to comment #51)
> Are you going to try that road?
> I may try ...

After digging deeper, the error is in the lmac which is closed source.
Basically a dead end unless you can get the source. Recommend reverting to 2005
which has a different compile of the lmac which doesn't express this problem.

Hi to all,

Sorry for resurrecting this thread, but after reading it, here is my personal
workaround to deal with this problem (works for me but doesn't provides any
guaranty that it will do so in an other environment ;)) ).

Environment: Nokia N770 with 0s2007HE, Linksys router e4200 (hybrid mod 2.4 GHz
and 5 GHz all two functional with two different SSIDs).
Installed applications on N770 :
- becomeroot 0.1-3
- oss-xterm 0.13.mh24bora1
- wirelesstools 28-1

1. login as root in a console (xterm form example) by typing: 

sudo gainroot

2. Create /etc/init.d/my_wlan with this content (beginning with the first line
not empty eg "#!/bin/sh") :

#!/bin/sh

/etc/init.d/networking restart

exit $?

3. Make this file executable by typing in the root console: 

chmod +x /etc/init.d/my_wlan

4. Ensure it will be launched every time you boots your N770 (typing...):

update-rc.d my_wlan defaults 20

5. Modify your /etc/network/interfaces file to add a section for your wlan
device at the end of it (if already present modify it and keep old lines to
revert it in case it wouldn't work as expected by commenting them with a # at
the beginning of each line):

auto wlan0
iface wlan0 inet dhcp
pre-up iwconfig wlan0 mode managed
pre-up ifconfig wlan0 up
pre-up iwconfig wlan0 essid YOUR_SSID
pre-up iwpriv wlan0 set AuthMode=WPA2PSK
pre-up iwpriv wlan0 set WPAPSK='YOUR_PASSWORD'
pre-up iwpriv wlan0 set EncrypType=AES

Take care to replace YOUR_SSID with your real wireless LAN SSID, and
YOUR_PASSWORD with the real password to access your wireless LAN.

6. Reboot!

Your wireless LAN should be usable automatically.

To revert these settings use these steps:

1. Remove the links that launch your script at every boot:

update-rc.d my_wlan remove

2. Restore your settings in /etc/network/interfaces by un-commenting your own
comments and removing the line added in step 5 above.

3. If you know you won't never use these tips remove the /etc/init.d/my_wlan
file. You can also keep it, it won't hurt.

Hope this post should help you to keep using your tablet in modern wireless
environment! 

Cordially,


-- 
NVieville

(In reply to comment #43)

Great! Will be first thing I'll try tonight!
Thanks for sharing!

(In reply to comment #53)

I forgot to mention that modifications made to the /etc/network/interfaces file
were for WPA authentication.
One needs to adapt/simplify this in order to use it with WEP keys (not
recommended for security reasons), for example like this:

auto wlan0
iface wlan0 inet dhcp
pre-up iwconfig wlan0 mode managed
pre-up ifconfig wlan0 up
pre-up iwconfig wlan0 essid YOUR_SSID
pre-up iwpriv wlan0 set key 'YOUR_WEP_KEY'

with YOUR_WEP_KEY replaced with your real WEP key.

Cordially,


-- 
NVieville

(In reply to comment #55)
EDIT: fixes typo

Replace 

> pre-up iwpriv wlan0 set key 'YOUR_WEP_KEY'

with

pre-up iwconfig wlan0 key 'YOUR_WEP_KEY'

(In reply to comment #53)
Hi, I really want to try this method, however, I can not access the WIFI AP via
the tablet, so I can not get the xterm, becomeroot and wirelesstools either.
And there is no place  I can download these tools from my laptop.
Then I downgraded to OS2005, and it can find WIFI AP now, but it can do
nothing. It seems OS2005 can not install software from the Internet.
It is like a dead-loop problem. what can i do?
--from a desperate person