StarV3 v1.2.0b build 1669 is ready for testing

[tony]

The new release is available for testing. Please visit www.star-os.com (http://www.star-os.com) for download instructions.

[pti-andy]

I've been having some strange things happen with this version.

My bench setup was using 1.1.4 with one PC bridged to another. I am using 2x cloaking with 2 CM-9's. They worked perfectly passing data at the highest rates possible.

After upgrading to build 1669 the data rate went to less than 1Mbps with packet loss from PC to PC but retained full speed from WAR to WAR using the built-in speed test. I noticed that the Rx rate of the AP changed to 6M even though the Tx rate of the client is 54M. When using manual speed settings there is no connectivity at all to the PC but yet the WAR itself is reachable on the other side of the link. Only the Auto setting will bring back the connection to the PC again with horrible data rates. Downgrading to v1.1.4 fixes the problem.

Should bridging be function in this version or am I jumping the gun?

-Andy
PTI Wireless

[greg]

I've seen the same on one link that I tried this on. Another link came back up fine but has one hell of a strong signal. Mine are all routed. I could reach the problem one barely but noticed the same characteristics. Worked better under auto and the rate was jumping all over the place. I tried changing channels and locking the rate at 6 on both sides, things got worse with that. They would not associate on any channel except the one originally set at which was 5220. I bumped up the tx rate from 18 but it didn't seem to help. When I was connected, packet loss was very high and signal quality as a % jumped around from 0 to 100 but usually very low. It took several attempts and a long time but I was able to flash it back to 1664. Rebooted and it is very stable again. Current noise is 95 and signal is 79, rates are locked at 12. It will sustain better than that but I don't need any more and trying to compensate for snow and bad weather coming.

[tony]

Thank you for the update

[bobbyc]

Has anybody else noticed rx sensitivity issues with this release? I'm not sure if it is effecting performance or just cosmetic; but I have noticed it.
Bob C

[tony]

There is no sensitivity issue, however the number that is displayed is averaged, and will need some traffic flow in order for it to show the correct number.

[bobbyc]

Thanks. I just wanted to report it because I tested build 1664 this afternoon and the averaging was not present in that build.
Bob C

[tog]

I just tested this build on my 5GHz home unit. My 5GHz home unit is unable to pass traffic and will only show associated for a few seconds before it resumes scanning.

I am using country code UZ, the AP is 1.0.3 using country code ## on 5660. No turbo, no cloaking, standard 802.11a with WEP, SSID is not being hidden.

For the few seconds that my 1669 client shows associated on the 1.0.3 AP, it shows the signal strength (received signal at AP from 1669 client) is about 20dB lower than normal. Then as soon as it goes to N again the signal strength shows normal.

This is reminiscent of the problems I saw with the beta series prior to 1664.

[cal361]

Using a WRAP board and this version of V3 as a client I am unable to associate to a v2 senao 2511 AP site. This link is working fine in both the stable release of v3 and v2. I have tried two different CM-9 cards, two different SR2 cards, and an NMP-8602. All cards function properly in stable v3 and v2. The link fails with the previous beta release as well.

No NAT, CBQ, or other functions being used. Simple routing, DNS, and DHCP is all that is running. 20Mhz Channels being used.

[bobbyc]

Cal that is interesting. I have a V2 prism 2.5 AP 4 miles away from my home, and I've been testing these beta releases from there. I had no issue connecting to the V2 AP with this or the previous build. I'm not sure what is causing your issue. Are you running any WEP on the link?
Bob C

[cal361]

Nope. All clear. Absolutely nothing above the bare minimum to support a link. As a caveat, this system was upgraded to the betas, it is not a fresh load. However, this unit is used only for testing v3 and has only ever had bare minimum settings so I can do throughput tests with various cards and releases. I lost an AP yesterday so I figured I'd give it a go.

[Mark]

I am attempting to use this version with SR9's and I can't.

If you set the speed at anything but AUTO, at least one direction of the link will be 6, and usually the other will be 9, sometimes 6 no matter what the signal level.

No real throughput.

If you set it AUTO, the speed jumps to 48 and 54 and throughput falls to negigible, as the cards don't seem to like running that high.

[David L. Vrablic]

Mark, wasn't there some discussion about the distance setting when using 900?
What is your actual distance and what do you have it set to.?
I'll do a search next and see what I can find.

[Mark]

They're about 4 or 5 feet apart, using small rubber duckies with stuff in the way to bring down the RSSI to reasonable levels and the power set to 1.

[lonnie]

Mark, the SR9 is very powerful and very sensitive. My suggestion is to take this outside. You can't expect a good test indoors, due to the masssive amounts of multipath you'll get. Put it under real conditions and then your testing is going to be valid. Your current test will not be very relevant for real use.

[bobbyc]

This thread has been too quite lately. Any good news regarding the beta series?

Bob C

[robert]

I am running a WRAP with SR5 and SR2's in it. Running 1669 I am seeing some weird issues with signal indications for the SR2 and a cm9 that I was running in it. The SR5 works great. Using tkip for encryption on the SR5, that's why Beta version. But the SR2 is showing me stronger survey signals when I choose the antenna port that the antenna is Not on and the output is only strong when I'm on the port that the antenna is on. So to make a moderately distant shot connect to a strong amped cm9 at 3 miles requires a diversity setting on 1669. At this there is a lot of variation of quality and throughput is on the floor. Any help here?

Robert

[gunther_01]

Get rid of the amp, and don't use diversity. Something is a miss there, maybe the radio card

[greg]

Gee, I was going to suggest more power! ;)

[robert]

Naw the amp is on the other side of the link, not the V3 side... I'm using a SR2 on the V3 that and saw the same behavior on a cm9, which makes me not suspect the cards. Once the card seems to associate the behavior seems to go away except in survey mode...

Robert

[David L. Vrablic]

I had unpredicitable results using the SR2' s to the point that I replaced them with plain old CM-9's.
1. There was some issue with associations and "no beacons received" error messages at one point.
2. Then later there was a firmware change so the factory sent me new units to test.
3. I never did get an answer from anywhere if they fixed the problem with the MCX port being lower in signal than the primary ufl port.
(I believe it was something about an impedance miss match)
Finally I just gave up on them.
------------
Thinking about it now, I also got rid of all amps in our systems.
After a couple of years the Teletronics seemed to just get flakey about associating and switching like they should.
Also noticed that the amps would "seem to work" with a Prism card but with the Atheros CM9 had serious association, connection and throughput problems rendering the AP useless.
Forget using the SR2 (with the power turned down on a auto gain TT amp. I could not get it to work at all.
(It is all I had with me at the time)
We just pulled them all and went to CM9.
I just cleaned up everything and now all is well.
--------------
Now the SR-5's seem to work fine for us on the longer shots but I have found that the CM-9 with a good dish works best there also.

Your post sounds very very familiar!

[gunther_01]

Robert, No ofense here but do your self a favor and ditch the amp, the sr2 and go straight with cm-9s. If you can't get a 3 mile link to work with out an amp you really need to consider the equipment (antennas) or environment (high noise/wrong frequency range/Line of sight) you are trying to link in.

You asked and there it is.

[robert]

Gunther,
No offense, but if you read my reply, I tried the cm9 and got the same effect as the sr2.
I was running a v2 StarOS with a 2511 in exactly the same location and it worked beautifully. I wanted to upgrade to V3 for some of the new features and because the hype about the new atheros drivers. Have you tried a V3-1.2.0b system with an sr2?
This isn't about the environment. I'll try a 2511 in place of the atheros next as they always have worked... I'm hoping Lonnie will chime in here...

Robert

[tkerns]

I have 2 WAR's, one running an SR2 and the other a WLM54G. I am running V3 1.1.5b 1659. I find that if I make changes, reboot, etc. about 20-30% of the clients come right back, the rest will return, but over a period of a couple hours. It appears they come back when the customer goes to use their system. I have not had reports of having to reboot the client radio.

I have found release (1.1.5b)to work reasonably well, prior releases I had many problems with all the clients going to "N" state and staying. I have not tried the 1.2 with these 2 WAR's. Trying to provide a stable environment.

I tried the latest V3 1.2 release on a WRAP with a 2511 and it was not pretty. All the clients reassociated right away, but the signal level of the clients were 10-15 db higher than with V2. I started getting complaints of poor performance, and my own connection was barely running. Pings started to mostly timeout. I went back to V2 on the WRAP and things returned to normal.

I would be interested in your results if your try ths release with 2511's.

[gunther_01]

So to make a moderately distant shot connect to a strong amped cm9 at 3 miles requires a diversity setting on 1669. At this there is a lot of variation of quality and throughput is on the floor. Any help here?

Robert

I have read your post and following post. My thought is that you are testing a beta. You have an amp on a 3 mile link that shouldn't or need to be there. Your symptoms possibly could be from amp problems and make it very hard to determine what the problem actually is. If the amp is on the other end of the link in question, get rid of it for testing a beta so you can actually see the problems without an additional piece of equipement in the way. Even though it worked before with a prism card doesn't mean it will work right with an Atheros.

And no I have not used that beta with a SR-2. I used a SR-2 with V2 and static got it, never went back.. Only cm-9 in that AP now.

I will bow out of this, hopefully you find a solution. I offered my opinion, so there it is.

[tog]

The 1.2.0b beta builds with the new atheros driver have atheros problems.

I would suggest that you use 1.0.3 or 1.1.8.

[pachitoone]

Hey tog, I have a very noisy environment, have you tested the new driver under that conditions? What are your impressions? What are the problems you have found? Thanks.

[tog]

I have done extremely limited testing of the new driver because it's not good enough to use on a real AP yet so I couldn't begin to tell you how it fares in the face of interference.

I have found that the new driver in its current state will not lock transmit rate, it displays and performs as if signal levels are about 10 - 15dB lower than they should be and I've seen consistent packet loss to clients when using the one older 1.1.5b build where the driver had the signal level problems fixed and I was able to associate everybody to it.

[robert]

The thing that was really important here is that when doing a site survey the signals are showing stronger when you set the interface as using the connector the antenna is not on. I was hoping that would get a quick look at the driver from Lonnie et. al... and a possible quick fix. I'm totally guessing here that it's a simple antenna selection issue...

Robert

[greg]

I haven't tried any 2611 radios with v3 but I do like the AP side of things using Atheros radios for 2.4 clients. The current downside is that 5.x links go to hell so I can only use this on sites where the 2.4AP is a separate unit from the backbone connection. I have a handful of sites that qualify and they work very well with a variety of clients.

[tog]

They are actively working on the new Atheros driver.

I haven't observed any antenna port selection issues myself with the new driver, though, but I'm sure they'll see your post and take it into consideration.

[jeff]

Since the driver in this version is in such a state of flux I thought I would make a suggestion. How about adding the ability to set a maximum rate rather than a fixed rate. That way if the noise floor rises the automatic algorithm would hopefully keep you connected at a slower rate, but it wouldn't always be trying higher rates that it probably doesn't have enough margin for anyway. This would let me be more aggressive than I can be now without risking noise or a failing component from disconnecting me altogether.

Just a thought.

[pti-andy]

Jeff, That's a good idea. A max rate would help me as well for my PtMP applications.

[tog]

It must be a good idea since I just wrote the same thing a couple of minutes before I read your post.

[lonnie]

It is already a max rate control. Auto will go as fast as possible and slow down in the face of packet retries and lower signal.

[jeff]

It is already a max rate control. Auto will go as fast as possible and slow down in the face of packet retries and lower signal.

You misunderstood what I meant. I would like to be able to set the maximum rate the auto algorithm will try. Currently our choices are to let the auto code search or lock it to a specific speed. I would like a third option which is to let the auto code run but limit the max speed it will try.

I currently lock all my backhauls to a fixed speed, but when anything goes wrong (like an accumulation of snow for instance) I would like the auto code to kick in and back the speed down to try and keep a connection. My experience with auto has been latency issues during the speed selection. I would like to be able to cap the speed so it wouldn't jump as often.

[ninedd]

It is already a max rate control. Auto will go as fast as possible and slow down in the face of packet retries and lower signal.I think he meant a way to set a maximum speed of 24 or 36, but not to have it fixed at that, and still allow fallback to 18, 11, etc.

EDITED: Oops, I see he beat me to the punch. :) FWIW, I'd like the same thing and have suggested that earlier elsewhere. On some long links, if we do auto, the link will switch back and forth from 48 to 54, and ever so occasionally a 36. We're hesitant to 'fix' it at 48, or even at 36. if there's ever a temporary issue that can't maintain those speeds. However, we'd love to be able to set the MAX at 48, and would be comforted if it could still drop to whatever was needed to maintain a usable link. It's just that it wouldn't train-up faster than MAX.

[pti-andy]

Yup, same here. I had a similar issue where my radio was fixed at 48 but my tower climber did a sloppy job of weather sealing and some water got in the line. There was still signal but not enough to maintain a 48Mb link so it went down until I figured out what was going on and set the link to 24 where it came back up. If I were to use the auto setting it constantly tries 54 and falls back to 48 causing latency.

A MAX rate setting could actually replace the "auto" setting because the MAX rate of 54 is the same thing as "auto". Thus having a check box of "max rate" next to the rate field would set the number in the field as the maximum instead of fixed manual rate. I know it's easier said than done, but at least the change in the GUI would be simple and negate the need for the auto setting.

-Andy
PTI Wireless

[tog]

It is already a max rate control. Auto will go as fast as possible and slow down in the face of packet retries and lower signal.

I'm going to throw my explanation in, too :P

Correct, Lonnie, but sometimes the rate that auto chooses is not the best performer. We'd like to still have auto-rate but we'd like to cap it at 36 or 24 for example because 48 doesn't actually perform as well even though auto-rate is choosing it. Or cap it at 36 or 24 because auto-rate constantly shifts back and forth between 36 and 48.

It provides the best of both worlds, we can be conservative (our link will always work because it's willing to shift down) but at the same time get near max performance.

Normally my being really conservative means setting my max tx rate to about 2 rates down from max performer. If auto is choosing 48 I might go with 24, etc.

This way, if auto is choosing 48, I can set max to 36 and not worry if I ever have signal fade that brings me down to max sustainable rate 24.

[lonnie]

Your idea is fine UNTIL the rate wants to shift between your setting and the setting just below it. Then you have the same issue. What is needed is some tweaking for the rate control to not shift as often or to choose a more conservative rate. Automatic with manual override is simply creating another set of issues and does not actually fix anything.

[tog]

I still like it a lot, I feel this feature has a real purpose independent of simply improving the auto-rate behaviour. For a PTP link that's juggling between 36 and 48, I could set the max rate to 24 and I would expect it would almost always stay at 24 solid.

Now, if that link ever dropped enough signal that the auto-rate algorithm started trying 18 or 12, then I likely have a real problem that needs fixing. The only difference now is that I don't have to drive to the remote site to change the tx rate I have forced it to in order to get it back up temporarily.

I'm having trouble determining what problems the addition of this feature could cause? Thoughts?

Of course it's always wise when taking a serious look at a feature addition to determine what the possible downsides could be as well as figuring out if it's really necessary.

You are correct that if you tuned the auto-rate algorithm to be way more conservative than it is now you might be able to achieve the same desired effect for the PTP link. To be completely realistic, though, I truly don't believe the auto-rate algorithm will ever be smarter than I am in determining the best max rate. Sometimes there's little rhyme or reason for 48 performing poorly when 36 is fine. 48 will show a PER of 95% or better. 36 will show similar, yet 36 will perform WAY better than 48. The auto-rate algorithm will choose 48, though, and I don't know what criteria it could use that it isn't already using to figure out that 48 isn't the best place to be.

So, long story short, I really do think this feature has its place even if the auto-rate algorithm were to be improved.

Actually the feature that I originally proposed involved setting a range such as 12-24 or a list like 12, 18, 24.

This would not only allow us to use this feature to make our PTP links more comfortable, it would also allow us to use the auto-rate algorithm for PTMP.

On a PTMP AP, if one client is unable to communicate except at 2mbit I'd rather the client just be offline until they're fixed, so I'd prefer my client-bearing cloaking AP support only 12, 18 and 24 mbit rates. You must be this tall to ride.

[DrLove73]

I to think that MAX auto rate would be good addition. It would not require to much code changing, an would give us excelet tool. I have PtP link that is -74 to -75 constantly (v2) with rate constantly (1-2 sec) jumping from 36 to 48 or 48 to 54 Mbps. But 15 days ago, we had interference in 100Km radius for 4-5 days, so link went down to -78, and rate went down to 24Mbps with couple faillbacks to 18Mbps. Luckily, I left it on auto, so link never went down, but in normal situations it is better to lock speed litle below optimum.
This way, we would be in control of our links fate.

[pti-andy]

I don't have a problem with how the current auto rate works. I think it does a good job but no matter how conservative it is there will always be a case where it will fall between the cracks of two different rates. This feature is not to fix anything that is wrong but rather to give us more control over rate settings and have backup protection if something goes wrong.

I will many times set the rate three of four levels below what auto would pick to increase fade margin and give greater output power/range etc. This always works good until something goes wrong like water getting in the line or the antenna gets blown off axis. I think it is very common for users to use slower rates on purpose especially for PTMP and this feature is for all of those circumstances. It really would be a huge benefit.

-Andy
PTI Wireless

[DrLove73]

I agree pti-andy, I thought I sad the same thing, only I gave example for a situation. If I set it to some specific speed, I could have problem when something goes wrong, and that speed is suddenly too high. It algorithm is caped with max rate, I can sleep peacefully.

[bobbyc]

Any news regarding a new beta coming out with improvement on the rate issue this beta has?
Bob C

[tony]

There is nothing new to report at this time.

[go.fast]

There is nothing new to report at this time.

What are you guys working on?

Not that I am trying to push buttons :cool:

[lonnie]

Nothing I care to report on at this time.

What are you guys working on?

Not that I am trying to push buttons :cool:

[go.fast]

Your going to surprise us with some new ground breaking feature?

[lonnie]

I say nuuthinng.

[bobbyc]

I know you guys haven't got much feedback regarding the prism support, but is it agreed that there is something wierd going on with possibly the CPU usage VS V2? I know the prism eats up more processor vs atheros, but the prism driver in V3 seems to use more than the prism driver in V2. There is also unexplainable packet loss, unless the increased cpu usage would explain it.

Thanks,
Bob C

[lonnie]

The prism driver is not the same driver as v2. I have said previously that we no longer use the Intersil AP firmware but have changed to the HostAP driver, thus all the extra CPU usage. It will be more in tune with new cards, which the older unmaintained firmware was not. In a nutshell --> the prism driver is a stop gap measure because some clients have trouble with Atheros.

Atheros still rules the airwaves and you have to seriously consider your client choice if it does not work with our Atheros driver, which represents the future.

[cephlon]

I had a peculiar situation with signal strength on one of my clients. Its a V3 15dbi Wartenna connected to a V2 AP. I was doing some wiring at their house and decided to upgrade the War to 1.2.0b-1669 and see the results.

The signal reporting on the Wartenna before the upgrade was -61. The signal reported at the AP was -72. After the upgrade the signal on the War jumped to -72, but the signal at the AP remained unchanged, except for the TX jumped to -80.

I then upgraded to 1.1.10 and the signal on the War went back to -61. I guess I'm still confused on the difference in signal reporting between the AP and Client and thought I would report my findings.

[bobbyc]

A couple more bug reports:

As Cephlon described above, the reported receive sensitivity is poor, but I only noticed it when using WLM54G (AR2413) and WLM54AG (super AR5414) cards. I don't see this issue when using 5004 cards.

Regarding prism support; I understand that the increased CPU usage is most likely due to a different driver (hostAP) than the V2 prism driver. I also noticed in testing today that I couldn't get the prism 2.5 minipci card to associate to the AP when the prism was locked at 11mbps.

Bob C

[nickwhite]

Hey guys. A few things to report here. This seems to be working very well with one of my APs that was having N association problems - several Prism(Tranzeo) clients. But I'm having issues with OSPF/Quagga restarting.

A little while ago I had to default the OSPF config in order to get Quagga to start. Then when I went to put in this network command it kept bailing and the logs showed it restarted.
network 12.22.30.112/30 area 0.0.0.0I'm also having issues where it randomly restarts - almost infinitely until I have to default the config and re-enter it. Here are some logs:

Jan 2 17:39:16 zebdog: ospfd has been [re]started
Jan 2 17:39:19 zebdog: ospfd has been [re]started
Jan 2 17:39:21 zebdog: ospfd has been [re]started
Jan 2 17:39:23 zebdog: ospfd has been [re]started
Jan 2 17:39:26 zebdog: ospfd has been [re]started
Jan 2 17:39:28 zebdog: ospfd has been [re]started
Jan 2 17:39:30 zebdog: ospfd has been [re]started
Jan 2 17:41:29 zebdog: ospfd has been [re]started
Jan 2 17:41:49 zebdog: ospfd has been [re]started
Here is my config - this appears to work for at least several hours.

ospfd# show run

Current configuration:
!
hostname ospfd
password password
!
!
!
interface beacon
!
interface cbq
!
interface eth0
!
interface eth1
!
interface lo
!
interface wifi0
!
interface wifi1
!
interface wpci0
!
interface wpci1
!
router ospf
ospf router-id 12.22.30.114
network 12.22.30.100/30 area 0.0.0.0
network 12.22.30.112/30 area 0.0.0.0
network 12.22.30.136/30 area 0.0.0.0
network 12.22.30.140/30 area 0.0.0.0
network 12.22.30.160/30 area 0.0.0.0
network 12.22.30.172/30 area 0.0.0.0
network 192.168.19.0/24 area 0.0.0.0
network 192.168.21.0/24 area 0.0.0.0
neighbor 12.22.30.113 poll-interval 30
neighbor 12.22.30.162 poll-interval 30
neighbor 12.22.30.174 poll-interval 30
!
access-list vtylist permit 127.0.0.1/32
access-list vtylist deny any
!
line vty
access-class vtylist
!
end
Just thought I'd share. Keep up the great work guys!

-Nick

[tony]

Thank you, we will try and duplicate your problem with the configuration you posted.

[nickwhite]

To add to this and my other post Tony, I did try upgrading that system to 1.1.10 (instead of beta 1.2.0; it was previously 1.1.4) and it exhibited the same behavior - quagga/OSPF reboots.

It's now running rip and generally seems fine - no rip/quagga reboots yet.

[cletus]

I had this happen before. cm9 card/wrap, it looped over and over, even after reboot. cpu was ~75% for no reason.. only way it stopped was go in to wireless settings and OK'ed it again then apply settings.


Jan 16 22:30:26 kernel: wifi0: stuck beacon; resetting (bmiss count 4) │
│Jan 16 22:30:27 kernel: wifi0: stuck beacon; resetting (bmiss count 4) │
│Jan 16 22:30:30 kernel: wifi0: stuck beacon; resetting (bmiss count 4) │
│Jan 16 22:30:33 kernel: wifi0: stuck beacon; resetting (bmiss count 4) │
│Jan 16 22:30:36 kernel: wifi0: stuck beacon; resetting (bmiss count 4) │
│Jan 16 22:30:38 kernel: wifi0: stuck beacon; resetting (bmiss count 4)

[cletus]

Looks like its not just me

http://madwifi.org/ticket/1003

[tony]

It's a common problem that Atheros cards can get into in face of interference on the channel they are on (11g being the most sensitive). Normally kicking the card will help, however on rare occasions if it does not, you may wish to look into changing the channel and see if the problem persists.

[cletus]

I went back to the current stable firmware for weeks, no worries at all
went back to beta, and its happening AGAIN within few hours, so its something to do with the driver,
As for channels, i am on the quiet one here !

One thing i did note with the current beta is the signal is better then with the production version (more stronger and on the very egde connections can connect where couldnt see a signal at all before)

[tony]

Thank you for the update

[bobbyc]

I haven't seen this error on my 1 AP that has been up for a couple months. It is a SR2 in 802.11b mode though.

WLM cards still have a rx sensitivity problem with the beta series though, so for now only 5004 cards work well in the beta series.
Bob C

[nickwhite]

I haven't seen this error on my 1 AP that has been up for a couple months. It is a SR2 in 802.11b mode though.

WLM cards still have a rx sensitivity problem with the beta series though, so for now only 5004 cards work well in the beta series.
Bob C
The only thing I've seen with the SR2 in the beta is if the power is set too high: after a while (few hours?) I start seeing +32 for the signal under several clients, rather than an actual -75. A colleague of mine had the TX Power set to 20. After I set it down to 16, all has been well for 3+ weeks now.

[lonnie]

The SR series of cards do not have the proper gain numbers. The card adds 6 to 7 dB to your setting.

[bobbyc]

I always use 14bB on the SR2, that turns out to be 22-23bB.
BTW, I sent this message on my nintendo wii opera browser :)
Bob C

[tony]

I tried a few times on my wii, however I found that gmail keeps causing the system to lock up, so gave up on that idea. :)

[David L. Vrablic]

Any idea what "def" puts out?
I just pulled a couple of SR2's out of my drawer and put them in an dual AP just to use them up.
How timely!

[bobbyc]

I tried a few times on my wii, however I found that gmail keeps causing the system to lock up, so gave up on that idea. :)

I'd give it another try this morning, after I read this:
http://gizmodo.com/gadgets/software/gmail-now-open-to-everybody-236554.php

Bob C

[pachitoone]

Any news on this thread?