StarV3 1.0.0(beta-17) build 1000 (WAR Edition) is ready for testing

[tony]

The new release is on-line and ready for public testing. Please download it from the www.star-os.com/starvx (http://www.star-os.com/starvx) website.

Any and all comments are welcome.

Changes since the last beta:
*) quagga has been updated to the latest cvs version, which includes several ospf updates
*) dhcp auto-auth can now be used on bridged interfaces
*) clients using 802.11g turbo in '##' (all chans) country code would lock up the system
*) clients would not roam the full 2.4 band in 802.11b, g or turbo-g modes if '##' country code was selected
*) hardware-watchdog service is now in an 'enabled' state in the gui (cosmetics only, the watchdog is still enabled in earlier releases)

Release Caveats:
*) read the release notes.

[skyclimber]

My AP is a STARV3 (build 1000) on WAR board + Atheros SR2. Short preamble is disabled, power saving is OFF. My customers are 300 feet to 3 miles away using CB3 3054 or WRAPBOARD + CM9 as CPE.
I received a lot of calls of disconnected customers last days. They are listed as "N" on the association list. Customers randomly connect and disconnect "C or N". On the client side, the CB3 shows "AUTHENTICATING" but rarely "ASSOCIATED". I replace the WAR board for my old STAROS V2 WRAP BOARD and all customers associated.

Your OS is very good. I want to install my customers on WAR but i have this N issue. Maybe it's because they are idle but i never got this issue on StarOs V2 on WRAP even when clients closed their computer for several weeks.

Thank you very much,

Louis

[bobbyc]

Are you using SR2 in the WRAP?
Bob C

[skyclimber]

Yes I'm using SR2 on the WRAP.


Louis

[go.fast]

I received a lot of calls of disconnected customers last days. They are listed as "N" on the association list. Customers randomly connect and disconnect "C or N". On the client side, the CB3 shows "AUTHENTICATING" but rarely "ASSOCIATED".

I want to install my customers on WAR but i have this N issue. Maybe it's because they are idle


I am also seeing this problem with beta-16.
It's happening to all the war ap's that are "G". My "A" ap's don't do this. I originally thought it was just two of my new war "G" ap's, but It's happening to all of them now. When I pull up to a G ap that has gone into this state, my laptop with an atheros card running the driver written by VNC will not connect.
I can get into the AP via the wireless 5 gig wan side or the client ethernet side and reboot it, but I can't connect to it via the AP side.

( Hurry with the fix Tony)

George

[tony]

This is something we are currently investigating, and will get resolved as soon as possible.

[nelson05]

I haven't implemented beta-17 yet since we don't run OSPF and don't need any of the other fixes offered by the release.... I guess this is a good thing since it means I can pass this screenshot along where our WAR under beta-16 just passed the 14.5 day uptime mark. 14 days without having to touch the box- I remember when I was counting uptime in minutes and then hours with v3. A drastic improvement to say the least.

http://www.springvillewireless.com/images/WARUptime.png

I'm sorry to hear others are still having trouble with the 'N' issue - we've obviously been very pleased with beta-16 and it appeared to address all of our association and stability problems.

One quick thought- I posted the observations below regarding beta-15 and Tony mentioned he was going to take a look at the bridging issue I described. Tony, were you ever able to duplicate this? We've since moved back to a fully routed setup where ether1 and wpci1 are in different subnets and not bridged. Are those of you still experiencing problems with association issues bridging ethernet and wireless interfaces on the AP?

One last thing I wanted to mention is that I had a number of problems installing the new board. While beta15 went on without a hitch, I modified the configuration on the WAR so that WPCI1 was bridged to Ethernet1 so that if we did start having issues, converting clients back and forth to the Cisco AP wouldn't be as disruptive, since the IP could stay the same and one DHCP server would be keeping track of everything. The configuration seemed fine on first glance, with the two test clients I had, associating and obtaining IP addresses from our DHCP server. However, one fell off after about ten seconds and wasn't able to pass traffice and the other would follow suit after roughly 30 seconds to five minutes. The clients would remain in the list as being connected though I don't believe their signal readings would change. Additionally, clients began showing up in the association list that I knew did not have the same SSID though they would show up as "N". What was really odd was that clients that were only 802.11b capable would also show up, even though the AP was set to 802.11g mode only. I thought maybe I had a bad card since I was using the same CM9, so I swapped it out, but the issue remained. I went back to the original CM9 and converted back to my original configuration, where WPCI1 and Ether1 were not bridged, and the issues went away. Clients now remain connected with no problems and I don't see any of the phantom "N" associations from B mode clients or devices that didn't have matching SSIDs. Weird!

[tony]

While bridged, the AP would hear clients from other APs, and add them to the list under the 'N' status. This is normal as the AP is in promiscuous mode. The Beta-16 and newer releases will not exhibit this behaviour, and will now operate as expected. (nor more unknown client entries).

While most people are having great success using 802.11g on their AP, there are still a couple people that are having issues. We are investigating as we speak.

[greg]

What settings are recommended for War 2.4 AP's?

Tx Power - does this work the same as 5.x and 18 is where I want it?

How about Super A/G?

AP Power Saving?

I have an X in the Short Preamble which enables short/long

[lonnie]

TX power can be default or up to 20 for 2.4 GHz.

Super A/G use it for best possible performance.

AP Power Saving, on if the other units are WAR boards or off if they are the consumer wireless bridges. Most of them do not implement power savings properly and will cause the AP to crash.

Short Preamble, leave on for best performance, and especially if the other units are WAR boards. Turn off they are the consumer wireless bridges. Most of them do not handle short preamble and need extra time to synchronize the radios.

[greg]

How about the b/g settings?

What works best here:
a. b only
b. b & g mix
c. g only

I have mostly cb3 and Tranzeo clients but there are some wet11 units too. Might have a couple Lucent units still ticking too.

[lonnie]

Actually if you look at the processor, they are all the same as the wet11, which used the Ubicom processor. I would use b only, long preamble, power saving off.

How about the b/g settings?

What works best here:
a. b only
b. b & g mix
c. g only

I have mostly cb3 and Tranzeo clients but there are some wet11 units too. Might have a couple Lucent units still ticking too.

[i20access]

I am running beta17 and I could be missing something, but where do I enable the recursive DNS server at? The 'dns' service is not yellow, as it would be in v2 if I had enabled it under 'services'. Thanks.

[tony]

It is under system->services->dns server

Thanks!

[go.fast]

How are you guys coming with beta 18?
George

[tony]

It's coming along nicely. I have PM'd you.

Thanks!

[skyclimber]

1 - Will beta 18 include a fix for N state issue?

2 - Could i help you to resolve it? Maybe a driver issue. I'm using SR2 on WRAP StarosV2 and it works perfectly. It's now 3 days uptime no disconnected clients.
Comparison:
Same radio, same antenna, same cable, same tower, same power.
The main difference is the board and the OS Version. The DHCP server also differ but i do not think it cause problem.

3 - By the way, how do you assign static ip to clients mac address?

thanks,

Louis

[lonnie]

1. Maybe. It is being worked on.
2. Not really. The WRAP is different hardware and software. Not much is comparable.
3. Use static arp or static DHP. Read the manual on the ISC DHCP site or get the book I recommend in the Library section. I am sure your local Library can obtain it.

1 - Will beta 18 include a fix for N state issue?

2 - Could i help you to resolve it? Maybe a driver issue. I'm using SR2 on WRAP StarosV2 and it works perfectly. It's now 3 days uptime no disconnected clients.
Comparison:
Same radio, same antenna, same cable, same tower, same power.
The main difference is the board and the OS Version. The DHCP server also differ but i do not think it cause problem.

3 - By the way, how do you assign static ip to clients mac address?

thanks,

Louis