starv3-1.5.9b-3727 *beta* released

[tony]

There is a new firmware available for all platforms.

What has changed / been fixed:
*) starutil update to incorporate ssl support
*) association display now properly shows the ip address, rx rate, and quality
*) wds support (ap and client-side)
*) implemented atheros full-duplex (see notes below)
*) clients may, on a rare occasions, stop scanning for an ap
*) improved scan & associate behaviour
*) wpa master would sometimes beacon with an invalid ssid
*) quality is now shown in % from 0 to 100
*) ntp time updates now occur every 5 minutes, instead of every 24 hours
*) atheros is now more verbose when clients connect.

Release Caveats
*) a problem has been identified with wpa, that can, on some occasions cause a system reboot. this has been fixed for the upcoming release.

Full Duplex notes
Full Duplex is fully operational, however it cannot be used with WPA at this time. If you are upgrading a system that uses WPA with full duplex, please disable it and enable WEP instead (if needed).

DFS and Extended Mode / All Frequencies
The new All Frequency (AF) country codes are:
D1 - No DFS
D2 - FCC DFS
D3 - ETSI DFS

The channel list will display the channels that are DFS-enabled for the chosen country. APs that use these channels will wait 60 seconds before coming live, if the channel is clear.

NOTE: Frequencies between 5600 and 5650 are classified as weather radar channels in Europe (ETSI). As such, if these channels are used, there will be a 10 minute dfs wait.

Also note the Hide SSID feature must be DISABLED if your AP is using a passive channel (channels marked with a * in the channel list), as it will prevent cleints from discovering your AP's SSID, and therefor either greatly delay their association, or prevent it all together.

Rate Differences
If upgrading from 1.4.x, please keep in mind that the 1.5.x series no longer makes use of the rate aggressiveness feature. Those using that in conjunction to fixed rates, please set your system to auto before upgrading. Also, max auto rates should be changed to auto before upgrading, as this is not supported in this release. The max auto rate feature will be added again in a future release however.

Noise Buster mode notes:
This mode is to be used in extreme conditions where you have heavy interference. This mode has been proven to help tremendously with interference, however it will also cause interference to neighboring systems that use the same channel.

This affects the CSMA/CA, among many other hardware characteristics, and may violate regulations in some regions. Please use with planning, caution, and care.

Before upgrading your systems, please note:
This IS a beta, so please upgrade ONE of your easy to access systems before doing any mass upgrades.

Also, please read past release notes, specifically ones relating to DFS as they will affect the CA, and US country codes in 1.5.x.

With world mode '##' compatibility, please read past release notes, but also keep this in mind:
5.x GHz extended frequencies should be compatible between all major releases.
2.4 GHz extended frequencies are not compatible between major releases, however channels 1 - 14 are. We are still working on the 2.4 GHz extended frequency mode in the hopes to make it compatible with the 1.4.x series.

Please keep note of these 1.4.x features that are not implemented yet:
1. Managed Mode (Priority: high)
2. "max" auto rate (Priority: high)
3. MAC / Radius ACL (Priority: medium)
4. Channel ACL (Priority: low)

The X86-ALIX platform is for use with the PC Engines ALIX SBC. Both the ALIX.2D2 and ALIX.3D2 boards have been tested, and are fully functional with the exception of the LEDs, which will be supported in an upcoming release.

For those using the X86-PC release on the ALIX hardware, you can safely upgrade to the X86-ALIX version without any upgrade or licensing issues. The ALIX release is performance tuned, and will work better than the generic X86-PC releases, plus will offer a serial console much like the WRAP release. (serial console is 115200/N/1)

Please report any problems in this thread, and with all beta releases, upgrade one system that is easy to access and let it burn in for a while before rolling it out in the rest of your network. Please do this for each platform type you wish to upgrade.

Thanks again.

[tony]

starutil's ssl support requires a new starutil client which is not available yet. For the short term, you can continue to use the standard starutil.

[lonnie]

Here's hoping this satisfies a few people. The list is bigger than promised, hope nobody minds.

From here we go to 802.11n.

[go.fast]

Is managed mode there?

[lonnie]

No, it is not in this release.

[tony]

The post notes the bits that are not present, and their priority for addition. Since managed mode is not a critical feature, it will be added after our 11n support is complete.

[ninedd]

We upgraded an AP (Gateworks WAR2) with 2 AP Cards and 12 Clients to 1.5.9b today.

WPCI1 x2 with 8 Clients
WPCI2 x2 with 4 Clients

The AP and Clients were all 1.4.22r before and all performing OKish. The upgrades to the AP and all the CPE's over the air went well, with one exception (below). After they rebooted as 1.5.9b CPE's, they connected quickly, performance is good, signals are good, everthing looks good. The AP side of things have all the IP's and MAC's and the Q% all the appropriate flags displayed nicely. This is very encouraging results and from this, I see no 'show stoppers' for us to roll this out on several more AP's and their CPE's next week. :)

We will have to do more detailed tests and see how it goes how it goes over the weekend, but this is looking good so far.

Notes: The upgrades to all the CPE's over the air went well, except for one GW-WAR2 Client. I think we neglected to reboot that one first, which I think was recommended for GW-WAR2's, and it's seems stuck in 'busy' now. The CPE shows 16 used, 13MB free, and does have only 1 Card, so we didn't think we had to reboot it first or to be particularly careful. However, it's relinked fine and is performing well with 1.4.22r, so it's not a show stopper at all. We'll call and have the client power cycle it, which will probably take care of it.

[tony]

Thank you for the update. I am very pleased it is working well for you. This release should be quite reliable, and if you have any problems please let us know.

[esandine]

Upgraded two sites with 9B last night. Both War-4, 3 CM9s, 1 SR9. Both w/mix of alien and Star (23B) clients connected to each other via the SR9 PTP. The site with the SR9 in station mode came back up fine with all customers reconnecting. The site with the SR9 in AP initially came up fine and all customers reconnected, but after about 3 minutes the unit rebooted and continued to reboot every 2:40 to 3:15. I was finally able to roll it back to 23B and it connected fine, customers are back up and no reboots. The station side I left at 9B with no probelms connecting to the AP or the customers connecting to it. Before anyone asks - Ping watchdog is not turned on, I've checked it probably 10 times. Any other ideas?

[lonnie]

esandine, if you could have a remote log server and have the system send logs to it, we would appreciate it if you could try again on the AP, and get some more data for us.

Also, could you try and disable radios, one by one, to try and isolate if the failure is a specific radio and mode, or general issue with the firmware.

[esandine]

Working on it now.

Eric

[lonnie]

Thanks, I appreciate it.

[esandine]

Ok found some things out. At some point the 3 CM9s got replaced with two WLM54Gs and one KXS30SG. The power on the KXS30SG is set for 9 the WLM54Gs are at 14 and the SR9 is at 14. Power supply is a 24v .8.

Now with the troubleshooting. Upgraded to 9B and the reboots started at about 1:13. Disabled WPCI3 (WLM54G) and after 10 minutes no reboot. Reenabled WPCI3 and Disabled WPCI1 and nothing. Board never came back up. Went to site and connected via cable in second ethernet and found the board was completly reset, no config, password reset and was only showing 3 cards.
Downgraded to 23B all four cards reappeared and reloaded config and everything came back up and is running good.:confused:

Eric

[ripv]

I'd recommend upgrading the power supply.
Personally I never use anything less than 24v 5A on War4 although 24v 1.5A is enough.

[DrLove73]

Versions 1.4.x started drawing more power then 1.3.23b. This is true for 1.5.x also. So I agree, you just need stronger PSU.

[esandine]

I'll try another PS, but doesn't really explain why the other one works great with the same PS does it?
After checking the station that is running fine doesn't have CM9s either it has 3 WLM54G and 1 SR9 and same PS.

Eric

[ninedd]

Not sure if this should be in the 1.5.9 thread, or the '900Mhz Goodies thread', but either would do I guess. :)

New AP for us (our 49th Access Point - YAY!)

24v METRO with 1.5.9b
WPCI1 - Compex GP23 - Disabled
WPCI2 - Compex GP23 - Backhaul - 24bdi Grid
WPCI3 - Freespace KSG30 - 15dbi V Omni
WPCI4 - 900Mhz FLR9G30 - 9dbi H Omni

Solar site - 12v Batteries with a SolarConverters 12-24v converter.

Just one test customer so far, WAR1a with XR9 & 17dBi Yagi. ~ 5 miles, LOTS of trees. Ridiculous amount of trees. And then, behind those trees... there's some more trees.

Mainly this was to test how 1.5.9b worked with XR9/FLR9G30's. It's nerve-racking to try it live on an AP with 30 clients, but this is a newly erected tower, and a client that's a long way out, behind a lot of trees, so we can do some experimenting.

FLR9G30 AP Card is set at 20 (so 30dbi) and XR9 Client card is set at 17 (so 27dbi). Client hears the AP as -77ish, AP hears the client at -85ish. Client has ANI turned on, AP does not. Both sides are auto, since capping isn't supported so far. X2 Cloaking, 11g-only.

I should point out that all our other XR9 stuff is all 1.3.23b, since 1.4.22r has not really worked at all with XR9's for us. Honesly, we didn't try 1.4.22r on all our 900Mhz towers, we tried and failed with about 1/2 a dozen towers, and that's was enough to let us know that 1.4.22r and XR9's were a no-go. This 1.5.9b is working quite well, under a very difficult situation I think.

Performance testing - from the shell at the client CPE:

war-platform ~ > ping 10.49.4.1 -i .01 -c 100

--- 10.49.4.1 ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 1009ms
rtt min/avg/max/mdev = 1.121/2.962/11.396/1.769 ms, pipe 2

So, for those that are waiting to see if XR9's work with 1.5.9b, this is pretty good results, especially in a low signal situation. We'll load a few more customer's on to it next week and see how that goes. This is pretty encouraging. :) It will be good to have rate capping back, but even without it, this is working quite well with 1.5.9b so far.

[DrLove73]

I'll try another PS, but doesn't really explain why the other one works great with the same PS does it?
After checking the station that is running fine doesn't have CM9s either it has 3 WLM54G and 1 SR9 and same PS.

Eric
Difference is KXS30SG that draws how much more power then WLM54G?

[lonnie]

No it does not explain it. BUT, we have said that the boards do draw more power with the new firmware. There is an all new kernel and new driver and it seems that each one initializes differently and draws more power. There are posts in previous threads of people who have had instability, especially when writing the flash, which was cured by a bigger power supply. You have 2 high power cards in that system, and your minimum power supply should have been at least 30W all along.



I'll try another PS, but doesn't really explain why the other one works great with the same PS does it?
After checking the station that is running fine doesn't have CM9s either it has 3 WLM54G and 1 SR9 and same PS.

Eric

[ant]

Lab test of 1.5.9 full duplex with VDS on ALIX for 12hours, running aok, will undertake full duplex field test (28km PTP link) over next two days & advise. ant

[tony]

Thank you for the feedback.

For all others who are currently using, or have tried the 1.5.9b release. Can you please provide any feedback you can, it would be greatly appreciated as it will help us improve things further.

[ant]

Two PTP links both half duplex now operating on 1.5.9 in field

Link A - 28kms length, VDS active, firmware upgraded from 1.4.17 directly to 1.5.9, WP188 with DCMA82at both A & B ends. End customer (there is only one), reporting <7msec ping times to their HO/Campus, with heavy upload requirements. ..> 22hrs so far

Link B - 43kms length, VDS active, firmware upgraded from 1.4.17 directly to 1.5.9, WP188 with DCMA82 at both ends. > 20hrs so far takes combined traffic of LINK A + local access

General comments on both Link A & B:- speed bounces around a bit, overall though, speed is higher

ant

[tony]

excellent, thank you for the feedback.

[pops]

updated remote site with this release update from 1.4.22r
x4000 with 4 cards
wpci1 30sg card sta,##,11g 1x mode / tx=16 freq=2447 backhaul to another x4000 with ag23 radio & 1.4.22r
wpci2= disabled
wpci3= disabled
wpci4= 30sg / AP,US,11b 1x mode tx 16 freq=2412 w/ 8 clients 4 CB3's & 4 war1's
all signals seem to be the same and performance is the same or possibly a little better
this AP seems to be doing good since yesterday morning.
updated another remote AP
x2000
wpci1 ag23 tx 23 sta,US,11a,1x freq=5785 signal -67 backhaul to a metro with 1.4.22r sig= -67
wpci2 30sg tx 10 ap,US,11bg,1x freq 2412 with 8 clients 7 war1's 1 war1a
all clients updated to 1.5.8b a week back, tried to update the AP at the same time but the backhaul link
kept dropping out periodically so I put it back to 1.4.22r.
I had the same experience yesterday trying to get this updated, the clients all went from 1.5.8b to 1.5.9b
with no issues, when I updated the AP the backhaul link keeps dropping out periodically, it seems to be with a regular frequency
the station just leaves the network and then comes back, I did notice that it is much worse with ANI on.
it took quite a while to get it downgraded because of the disconnects
I would like to use this release but need to fix this backhaul issue any ideas appreciated

Pops

[SpecialK]

I tried this on an X4000 2.4 AP.
AP is XR2 card, X2, WEP, no client bridges all NAT.

For some reason a Ubiquiti Nanostation M2 client will not connect to an AP running 1.5.9b but works ok with 1.4.22.

I had to revert back until I can find out why.
I had the same problem with several other 1.5.X releases.
Did WEP change at all from 1.4.X to 1.5.X?
I know when hooking up a NSM2 I had to change WEP on the 1.4.22r AP to 104 yet it's on 128 on the NSM2.

[tony]

Windows, and some clients call 104-bit WEP, 128-bit for marketing reasons though they are both the same (same key length, of 104-bit). The encryption is compatible between all known releases, and 3rd part clients with WEP and WPA. Can you verify that you have open system / secret key authentication set correctly on both the NSM2 and 1.5.x AP?

[tony]

@pops
you mention the backhaul link (the x2000 you upgraded, and the METRO) both originally were 1.4.22. Did you upgrade the METRO in addition to the X2000, or left it at 1.4.22?

When the backhaul link drops out for a moment, are there any logs on the metro (ap-side) stating why it was disconnected? Also, are you using any form of security, such as WEP?

[lonnie]

pops, did you try a different channel on the AP? Does the F9 log show any reason for the disconnect?

[SpecialK]

Windows, and some clients call 104-bit WEP, 128-bit for marketing reasons though they are both the same (same key length, of 104-bit). The encryption is compatible between all known releases, and 3rd part clients with WEP and WPA. Can you verify that you have open system / secret key authentication set correctly on both the NSM2 and 1.5.x AP?


Current working settings:
The AP on 1.4.22r is set to 104-bit WEP and Shared Key Authentication.
The NSM2 is set to WEP, 128 bit, Shared key.

[tog]

You should be using 5.2.1beta3 if you want the NSM2 to work with 802.11b/g devices. The M/Airmax series has various compatibility issues with 802.11a and 802.11b/g and only that beta seems to have all the compatibility fixes.

[SpecialK]

You should be using 5.2.1beta3 if you want the NSM2 to work with 802.11b/g devices. The M/Airmax series has various compatibility issues with 802.11a and 802.11b/g and only that beta seems to have all the compatibility fixes.

Well for me 5.2 is the only version that worked OK with my Star APs up until now. I will try and put the latest beta on it first then try upgrading the AP.

[pops]

@pops
you mention the backhaul link (the x2000 you upgraded, and the METRO) both originally were 1.4.22. Did you upgrade the METRO in addition to the X2000, or left it at 1.4.22?

When the backhaul link drops out for a moment, are there any logs on the metro (ap-side) stating why it was disconnected? Also, are you using any form of security, such as WEP?

Tony
no I did not update the metro, yes updated from 1.4.22 I did try some other chanles 5745,5765
same results, I left it like that for a while and tried different settings, hide essid, ani, and freq's all to no avail the sys log on the x2000 gave no info other than the typical stuff you see when a station is disconnected from the ap, and the same with the log on the metro there was a line in the log with a regular frequency wpcix and mac address stating that the station left the network, iteresting after about an hour and half of playing the backhaul AP rebooted, I don't know if it is related, this is our main backhaul AP with 4 radio cards and 5 station connects and it had been up for 186 day's when I started this, so it is kinda hard to play with becuse it efects all the other connections , I am working on splitting off the backhaul to this specific ap to it's own radio so I can play and not interfere with the others.

I will let you knowas soon as I have it.
and give it another try

[DrLove73]

@pops, you did not give any signal and rate info.

Also, have you switched rate to "AUTO" on X2000 before upgrade to 1.5.x?

[SpecialK]

You should be using 5.2.1beta3 if you want the NSM2 to work with 802.11b/g devices. The M/Airmax series has various compatibility issues with 802.11a and 802.11b/g and only that beta seems to have all the compatibility fixes.


Ok, upgraded NSM2 to 5.2.1beta3. This client now seems to work better with a Star-OS AP running 1.4.22r.

Putting 1.5.9b on the AP loses the NSM2 the same as before.
Will have to try things on the bench and narrow down the issue before I can upgrade to 1.5.9b.

[pops]

@pops, you did not give any signal and rate info.

Also, have you switched rate to "AUTO" on X2000 before upgrade to 1.5.x?

rates are set to auto and mostly settle at 36, I did try to set them to 18 & 24 but nothing I could do changed things except when I turned on ani it got much worse.

Pops

[tony]

There is a possibility that the NSM2 has an odd or non-compliant shared key implementation. Can you try Open System WEP instead, and see if that woks.

Ok, upgraded NSM2 to 5.2.1beta3. This client now seems to work better with a Star-OS AP running 1.4.22r.

Putting 1.5.9b on the AP loses the NSM2 the same as before.
Will have to try things on the bench and narrow down the issue before I can upgrade to 1.5.9b.

When you turn on ani, do you do this on the AP, or the Client? (it should only be done on the client). What do the logs say on the AP when the client connects or disconnects?

From past posts, your are using a metro on one end of the bachhaul (AP mode) running 1.4.22, and the x2000 on the other end running 1.5.9. Is it possible to upgrade both sides to 1.5.9 to see if this stabilizes your link?

rates are set to auto and mostly settle at 36, I did try to set them to 18 & 24 but nothing I could do changed things except when I turned on ani it got much worse.

Pops

[lonnie]

pops, if you can upgrade both ends, Tony and/or I will be available when you do the switch. Get us the IP, password and time you expect to do it we will be standing by.

We would really like to get this sort of upgrade going smoothly.

[gunther_01]

I can confirm the NS"M"2 issue as well with this release. X-2000 with Hpol omni, 2x, 1.4.22 upgraded. One unit on 5.2, another on Beta2. Both disappeared and one of them is almost directly under the AP with -60's signals.

If it helps to anyone. the beta2 unit is running full data rates, and the 5.2 is capped at a single chain rate. Both have auto ack off, and aggregation enabled. But other then that there isn't many settings you could try other then multicast.

I'm throwing this out there for tony and Lonnie. But the Rocket AP with dual chain sucks "stuff" when it comes to mixed mode with N and Gonly connected to the AP. So I have to wonder if their same software doesn't like N mode to G only or some derivitive of your N based firmware. IDK.. But is a big part of why I asked for UBNT M series porting. I like the hardware. CAN'T stand the firmware on the Rocket AP. The clients have worked well for us on G only 2x sites, and B only sites in both H pol and Vpol. with 1.4.22 and 1.3.23b

[pops]

pops, if you can upgrade both ends, Tony and/or I will be available when you do the switch. Get us the IP, password and time you expect to do it we will be standing by.

We would really like to get this sort of upgrade going smoothly.

all I read indicates thaere should be no incompatibileties between 1.5.x & 1.4.x if you would like me to update the remote pop again and give you access to it so you can see what is going on I will do that, the backhaul ap is a 24v metro with 4 xr5,s 1.4.22r as follows
wpci1,ap,US,11a,1x tx 14 2 station asociations
wpci2 disabled
wpci3,ap,US,11a,1x tx 14 1 association
wpci4,ap,US,11a,1x tx 14 2 associations

I can arange access for you to both units if you like.

Pops

[lonnie]

pops, thanks. We feel there should not be any incompatibility, but obviously there is, and we need to get on your system and see what is going on.

What I would like is for you to get the new 1.5.9b firmware loaded and flashed but NOT rebooted, so that it is still running the 1.4.22r. Send us the IP and password and we will login, reboot and start to troubleshoot. This will minimize the downtime for your customers.

If you can do this during your late evening, it is our daytime here, so we can easily get on it and possibly your customers will be in bed, and not even know we were playing around. If your phone starts to ring we will not get much time to play.

[pops]

yes I can do that, I too would like to resolve this, I will need to poke a hole for port 22 in the border acl can you pm me the IP you will be comming from?

pops

[DrLove73]

yes I can do that, I too would like to resolve this, I will need to poke a hole for port 22 in the border acl can you pm me the IP you will be comming from?

pops

I think they are on ADSL, so they might have dynamic IP from ISP.
If you agree on the time they will be connecting, you can poke a hole for all IP's, but keep fairly good password. Potential cracker would need to find your poked hole in specific frame of time and know both username and password to do any harm, and you will close that hole anyway in few hours.

[tog]

I can confirm the NS"M"2 issue as well with this release. X-2000 with Hpol omni, 2x, 1.4.22 upgraded. One unit on 5.2, another on Beta2. Both disappeared and one of them is almost directly under the AP with -60's signals.

If it helps to anyone. the beta2 unit is running full data rates, and the 5.2 is capped at a single chain rate. Both have auto ack off, and aggregation enabled. But other then that there isn't many settings you could try other then multicast.

I connected an NSM2 running 5.2.1beta3 to an X4000 running 1.4.22r as an AP using 104-bit WEP. All worked fine.

Then I upgraded the X4000 to 1.5.9 and it continued to work fine, throughput was slightly reduced until turning on noise buster and ANI, then it was slightly higher than 1.4.22. No interesting settings to speak of on the NSM2, pretty much defaults, station not station WDS, left the rate at normal (MCS12 max in WEP mode).

I have bench-tested StarOS 1.5.x as a client on a 5.2.1beta3 AP and it worked with 104-bit WEP and with WPA2.

I just found a critical panic/reboot bug in 1.5.9 with WPA2 while bench testing, though. WEP 104-bit works fine, but switching the 1.5.9 AP from WEP to WPA (wpa-master) crashes and reboots the X4000 within a minute or two. There's nothing interesting in syslog, but here it is below anyway. It boots, station connects, next thing you see is bootup-related messages.

Everything is perfectly fine and stable using 1.4.22r or using WEP with 1.5.9 or with no security.

I also just tried changing the 1.5.9 AP's IP configuration from bridged to just having 192.168.1.1 on wpci1, no change, still crashes and reboots.

<13>Dec 31 16:01:06 kernel: klogd started: BusyBox v1.9.0 (2010-07-23 11:49:45 ICT) 192.168.1.1 27/07 12:00:29.910
<14>Dec 31 16:00:18 kernel: br0: topology change detected, propagating 192.168.1.1 27/07 12:01:07.255
<14>Dec 31 16:00:18 kernel: br0: port 2(wpci0) entering forwarding state 192.168.1.1 27/07 12:01:07.256
<86>Dec 31 16:00:21 dropbear[683]: Running in background 192.168.1.1 27/07 12:01:08.727
<14>Dec 31 16:00:21 kernel: tun: Universal TUN/TAP device driver, 1.6 192.168.1.1 27/07 12:01:08.785
<14>Dec 31 16:00:21 kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> 192.168.1.1 27/07 12:01:08.786
<14>Dec 31 16:00:21 kernel: br0: port 2(wpci0) entering disabled state 192.168.1.1 27/07 12:01:09.061
<14>Dec 31 16:00:21 kernel: br0: port 2(wpci0) entering learning state 192.168.1.1 27/07 12:01:09.606
<14>Dec 31 16:00:21 kernel: br0: topology change detected, propagating 192.168.1.1 27/07 12:01:09.607
<14>Dec 31 16:00:21 kernel: br0: port 2(wpci0) entering forwarding state 192.168.1.1 27/07 12:01:09.608
<13>Dec 31 16:00:22 bus: Detected interfaces: 192.168.1.1 27/07 12:01:09.812
<13>Dec 31 16:00:22 bus: [IXP4xx Network Processor] 192.168.1.1 27/07 12:01:09.880
<13>Dec 31 16:00:22 bus: platform-bus - 00:19:5f:00:e6:4d/ether1 cable connected 192.168.1.1 27/07 12:01:09.915
<13>Dec 31 16:00:22 bus: [IXP4xx Network Processor] 192.168.1.1 27/07 12:01:09.942
<13>Dec 31 16:00:22 bus: platform-bus - 00:19:5f:00:e6:4e/ether2 cable not connected 192.168.1.1 27/07 12:01:09.969
<13>Dec 31 16:00:22 bus: [Compex WLM54AG[23] Atheros 2.4/5.8GHz Wi-Fi] 192.168.1.1 27/07 12:01:09.998
<13>Dec 31 16:00:22 bus: 0000:00:01.0 - 00:80:48:60:69:2b/wpci1 cable connected 192.168.1.1 27/07 12:01:10.025
<13>Dec 31 16:00:22 bus: [Compex WLM54AG[23] Atheros 2.4/5.8GHz Wi-Fi] 192.168.1.1 27/07 12:01:10.053
<13>Dec 31 16:00:22 bus: 0000:00:02.0 - 00:80:48:60:69:2a/wpci2 cable not connected 192.168.1.1 27/07 12:01:10.082
<13>Dec 31 16:00:22 bus: [Compex WLM54AG[23] Atheros 2.4/5.8GHz Wi-Fi] 192.168.1.1 27/07 12:01:10.109
<13>Dec 31 16:00:22 bus: 0000:00:03.0 - 00:80:48:60:69:29/wpci3 cable not connected 192.168.1.1 27/07 12:01:10.138
<13>Dec 31 16:00:22 bus: [Compex WLM54AG[23] Atheros 2.4/5.8GHz Wi-Fi] 192.168.1.1 27/07 12:01:10.166
<13>Dec 31 16:00:22 bus: 0000:00:04.0 - 00:80:48:60:68:cc/wpci4 cable not connected 192.168.1.1 27/07 12:01:10.194
<12>Dec 31 16:01:16 kernel: wpci0: station 00:15:6d:b0:cb:9a [rates: 12] associated with aid 1, QoS 192.168.1.1 27/07 12:02:04.657
<86>Dec 31 16:00:20 dropbear[683]: Running in background 192.168.1.1 27/07 12:03:29.749
<14>Dec 31 16:00:21 kernel: tun: Universal TUN/TAP device driver, 1.6 192.168.1.1 27/07 12:03:29.928
<14>Dec 31 16:00:21 kernel: tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> 192.168.1.1 27/07 12:03:29.931
<14>Dec 31 16:00:21 kernel: br0: port 2(wpci0) entering disabled state 192.168.1.1 27/07 12:03:30.374
<14>Dec 31 16:00:21 kernel: br0: port 2(wpci0) entering learning state 192.168.1.1 27/07 12:03:30.821
<14>Dec 31 16:00:22 kernel: br0: topology change detected, propagating 192.168.1.1 27/07 12:03:30.872
<14>Dec 31 16:00:22 kernel: br0: port 2(wpci0) entering forwarding state 192.168.1.1 27/07 12:03:30.873
<13>Dec 31 16:00:22 bus: Detected interfaces: 192.168.1.1 27/07 12:03:31.001
<13>Dec 31 16:00:22 bus: [IXP4xx Network Processor] 192.168.1.1 27/07 12:03:31.040
<13>Dec 31 16:00:22 bus: platform-bus - 00:19:5f:00:e6:4d/ether1 cable connected 192.168.1.1 27/07 12:03:31.087
<13>Dec 31 16:00:22 bus: [IXP4xx Network Processor] 192.168.1.1 27/07 12:03:31.116
<13>Dec 31 16:00:22 bus: platform-bus - 00:19:5f:00:e6:4e/ether2 cable not connected 192.168.1.1 27/07 12:03:31.145
<13>Dec 31 16:00:22 bus: [Compex WLM54AG[23] Atheros 2.4/5.8GHz Wi-Fi] 192.168.1.1 27/07 12:03:31.174
<13>Dec 31 16:00:22 bus: 0000:00:01.0 - 00:80:48:60:69:2b/wpci1 cable connected 192.168.1.1 27/07 12:03:31.202
<13>Dec 31 16:00:22 bus: [Compex WLM54AG[23] Atheros 2.4/5.8GHz Wi-Fi] 192.168.1.1 27/07 12:03:31.231
<13>Dec 31 16:00:22 bus: 0000:00:02.0 - 00:80:48:60:69:2a/wpci2 cable not connected 192.168.1.1 27/07 12:03:31.258
<13>Dec 31 16:00:22 bus: [Compex WLM54AG[23] Atheros 2.4/5.8GHz Wi-Fi] 192.168.1.1 27/07 12:03:31.286
<13>Dec 31 16:00:22 bus: 0000:00:03.0 - 00:80:48:60:69:29/wpci3 cable not connected 192.168.1.1 27/07 12:03:31.314
<13>Dec 31 16:00:22 bus: [Compex WLM54AG[23] Atheros 2.4/5.8GHz Wi-Fi] 192.168.1.1 27/07 12:03:31.342
<13>Dec 31 16:00:22 bus: 0000:00:04.0 - 00:80:48:60:68:cc/wpci4 cable not connected 192.168.1.1 27/07 12:03:31.370
<12>Dec 31 16:00:22 kernel: wpci0: station 00:15:6d:b0:cb:9a [rates: 12] associated with aid 1, QoS 192.168.1.1 27/07 12:03:31.603
<12>Dec 31 16:00:22 kernel: wpci0: station 00:15:6d:b0:cb:9a [rates: 12] reassociated with aid 1, QoS 192.168.1.1 27/07 12:03:31.680

[SpecialK]

I connected an NSM2 running 5.2.1beta3 to an X4000 running 1.4.22r as an AP using 104-bit WEP. All worked fine.

Then I upgraded the X4000 to 1.5.9 and it continued to work fine, throughput was slightly reduced until turning on noise buster and ANI, then it was slightly higher than 1.4.22. No interesting settings to speak of on the NSM2, pretty much defaults, station not station WDS, left the rate at normal (MCS12 max in WEP mode).

I have bench-tested StarOS 1.5.x as a client on a 5.2.1beta3 AP and it worked with 104-bit WEP and with WPA2.

[/CODE]


This is interesting Tog.
Did you try 2x 10 mhz channels?
It looks like both gunther_01 and I have no luck and we both use X2.
I have tested since 1.5.6b and not got it to work yet.
I run pretty vanilla stuff.
I have also tried on several APs.

[tog]

I just tested the X4000 in station mode with wpa-client, it associates and crashes instantly when you try to send the first packet.

I pulled out the WAR1a system and tried that again with WPA and it worked fine with 1.5.8. I upgraded it to 1.5.9 and WPA crashed/rebooted, so this WPA crash seems to have been introduced between 1.5.8 and 1.5.9.

[tog]

This is interesting Tog.
Did you try 2x 10 mhz channels?
It looks like both gunther_01 and I have no luck and we both use X2.
I have tested since 1.5.6b and not got it to work yet.
I run pretty vanilla stuff.
I have also tried on several APs.

Yes, 2x cloaking 10MHz wide channels are working fine with StarOS 1.5.9.

Normal auto-rate with 5.2.1beta3 using 104-bit WEP shared-key. I just did it a moment ago and did starutil -rx and -tx tests across it, all performed fine and sturdy.

[rbolduc]

What channels are you using? 1.4.22 and 1.5.x series are different no 2402 or 2407 I am also using NSM2 and can connect to a 1.4.22 and a 1.5.x with no issues except I am not using wep/wpa


Reed

[tony]

Thank you tog, I will investigate and get this fixed for the upcoming release.

I just tested the X4000 in station mode with wpa-client, it associates and crashes instantly when you try to send the first packet.

I pulled out the WAR1a system and tried that again with WPA and it worked fine with 1.5.8. I upgraded it to 1.5.9 and WPA crashed/rebooted, so this WPA crash seems to have been introduced between 1.5.8 and 1.5.9.

[tog]

What channels are you using? 1.4.22 and 1.5.x series are different no 2402 or 2407 I am also using NSM2 and can connect to a 1.4.22 and a 1.5.x with no issues except I am not using wep/wpa


Reed

Using 2412-2472 in 2x/10mhz mode, works fine with 5.2, 1.4.22 and 1.5.x.

[rbolduc]

Using 2412-2472 in 2x/10mhz mode, works fine with 5.2, 1.4.22 and 1.5.x.

I second that... no problems to speak of

[ninedd]

Hi. Upgraded another AP to 1.5.9b with good results. AP was 1.4.22r and didn't have any major problems with the clients, although we had people set to -1 and one customer to -2 agressiveness because of minor problems, and we like the rate agressivness to help smooth those things out.

All StarOS client (MIPS) in 2x. Cards on the client side are all Valemount 54Gs or GP23's, AP side is a Gateworks style WAR2.

WPCI1 = 2 Clients, 2x, -78 & -84 (OUCH!)
WPCI2 = 6 Clients, 2x, -61 to -74

Everyone upgraded smootly over the air, no surprises.

Signals are pretty much in line with 1.4.22r, but rates negotiated are a bit higher because we had everyone set to -1 agressiveness. We find that the rates flap around somewhat now, and since rate capping isn't available yet, that's a bit of a problem on the guy we had set at -2 before. He sometimes jumps up to a 36Mbit rate, and right then, may drop some pings. His connection will then drop to a 1Mbit and then climb back up. If we could keep it auto, but cap it at 24Mbit, I think it would be fine, but when it jumps to 36, that looks to be a bit high for him. It's performing OKish anyway, and the other clients all seem pretty good. We'll have to put it through it's paces over the next few days, but seems good so far.

[gunther_01]

Interesting with the NSM2's. I did nothing but upgrade/from 1.4.22 and the NS's just didn't come back.. We do not use encryption, and thhe client is set as a standard client (no WDS)

[go.fast]

I don't use u gear.
But I have had issues with 2x on 1.5.x connecting to 1.3.23, but not all the time. Just a couple of installs.
Most 2x with 1.5.x talking to 1.3.23 works fine.

Not sure why, but it sounds like it's similar to the situation going on in this thread.

[handyman]

I just tested the X4000 in station mode with wpa-client, it associates and crashes instantly when you try to send the first packet.

I pulled out the WAR1a system and tried that again with WPA and it worked fine with 1.5.8. I upgraded it to 1.5.9 and WPA crashed/rebooted, so this WPA crash seems to have been introduced between 1.5.8 and 1.5.9.

Well, this would explain what I saw today. Upgraded a live X4000 AP from 1.3.23b to 1.5.9 and it came alive with backhaul associations but I never could log into it. I guess it kept crashing and rebooting. It uses WPA both as master (PtMP) and client (PtP).

Rolled the truck and swapped in a replacement. Back on the bench, the errant unit ran fine. I assume it runs on the bench because there is no actual traffic flowing under WPA.

Thanks, tog, for saving me some troubleshooting effort.

[David L. Vrablic]

Tony:
I just upgraded 16 camera sites in a string.
I wanted to see what difference I had in latency one end to another.

Terrific improvement. A couple of things I have run across that cut the limb out from under me.
The whole system is 1.3.23b and I am taking it up to 1.5.9.
1. After the upgrade a link that was on a PS 49xx freq did not come back.
The CC was ## the freq entered as 4980.
I changed the freq to 5220 activated and it came right back up.
----------
2. Another section had the threshold set to -30 and the power offset set on the other end set to 10 for a RX of -53 signal. When I did the upgrade the signal increased to a -35 and it failed to connect. I turned the threshold off and the link came back up.

This most likely is because I pre set every radio on both sides to auto before the upgrade. The rates jump around a lot but overall the latency is so much better.
Should I leave everything running auto or should I set a capped rate?
What is going on with the 4.9 and what is the work around for those units that have to operate in that band.?

[tony]

@all

Thank you for your reports. Please keep them coming, as this is important for us to know how things are running, and will allow us to continue improving the release.

@David L. Vrablic

Thank you. I am glad the updates went smoothly for the most part. I will have a look at the 4.9GHz range. Can you tell me what cloaking mode you were using with channel 4980?

Thanks!

[gunther_01]

Somthing interesting I just caught on to. We have another site that is B only with this firmware that has a NSM2 that works just fine. This unit is a WAR2 vpol, where the other unit (that NSM's disappeared on) is runing 2x Hpol G only is a x2000.

I'm not sure if B mode works better for them or what, but thats one of the differences "I" can see/think of on our network.

[David L. Vrablic]

@all

Thank you for your reports. Please keep them coming, as this is important for us to know how things are running, and will allow us to continue improving the release.

@David L. Vrablic

Thank you. I am glad the updates went smoothly for the most part. I will have a look at the 4.9GHz range. Can you tell me what cloaking mode you were using with channel 4980?

Plain old 1X
Now I lost all connections beyond that point.
Truck roll in the morning I guess. Associated but can not ping or pass traffic.

Name MAC IP Q% sig rx tx AQUEP CFTWM kbs-rx kbs-tx idle
Middle of String >b9:b0 249.242 81 -80 24 24 ***- ---*- 0 0 33s^

Thanks!
2 short

[lonnie]

Have you tried to log into the unit just before it, go to system, sh, and then then run ssh from that system? Sometimes you can connect but routing has not completed so it is accessible from the AP but not the world.

[tog]

Well, this would explain what I saw today. Upgraded a live X4000 AP from 1.3.23b to 1.5.9 and it came alive with backhaul associations but I never could log into it. I guess it kept crashing and rebooting. It uses WPA both as master (PtMP) and client (PtP).

Rolled the truck and swapped in a replacement. Back on the bench, the errant unit ran fine. I assume it runs on the bench because there is no actual traffic flowing under WPA.

Thanks, tog, for saving me some troubleshooting effort.

You're welcome, I guess you need to use 1.5.8 for now until that is fixed. All my testing so far with 1.5.8 and WPA has been fine.

Also, on that subject, does anybody know for sure if the 1.5.x releases for MIPS-COMPEX omitted WPA? I don't seem to have any WAR1's left to play with, all are deployed. I know it's missing from 1.4.x on the MIPS-COMPEX platform due to lack of flash space so I'm assuming it still is missing WPA in 1.5.x.

[tony]

WAR1 (original model) has wpa-client, but not the authenticator (ap-side)

[bobbyc]

I have a 1.3.23b site that is x2 cloaked and bullet M2's take 10-30 minutes to associate.
AP Card is a WLM54GP23. I've tried every setting on the tower and the bullet M2's (including different bullet firmwares) and the problem continues.

From the bullet/client end, the tower shows up in the site survey just fine.

Been planning on converting the sector to uncloaked to see if that weird problem goes away; but there's more important stuff always on my platter :)

So if this is related to your NSM2 issues, I have a feeling it's not just 1.5.9 with the issue; and it is more to do with cloaking support/handshaking. Maybe I will uncloak the sector and see if that issue goes away.

Edit: I think the u gear has the main issue, not star.
Bob C

[tog]

WAR1 (original model) has wpa-client, but not the authenticator (ap-side)

Oh, nice! Under 1.4.22r I notice wpa-client is listed in the service summary but "wpa and advanced security" is greyed out in the menus. If it's now enabled again in 1.5.x that's great news.

[tony]

I have finished auditing the wpa support, and found that there is a problem that can, on occasion cause a system reboot as tog pointed out (thanks!). The problem has been fixed for the upcoming release. This problem only affects the 1.5.9 release.

Thanks again.

[David L. Vrablic]

Have you tried to log into the unit just before it, go to system, sh, and then then run ssh from that system? Sometimes you can connect but routing has not completed so it is accessible from the AP but not the world.

Yes sir. That's what I have been trying to do. Funny after a time I get the address of the next radio but I can't get to it.

Update: It takes 20 seconds for the association to show up.
Then another 30 seconds for the IP to display.
Pinging from this box to the next one up the line it shows packets transmitted but none recieved.
Attempts to ping or ssh just sit there with no error nor connection.
I am getting an association attempt now with the 4980 freq it just has that 20 second delay.
I tried both ## CC with the 4.9 freq and US CC and 5220 with the same results.
Could DFS have something to do with no connection is there some special CC to use on these freqs when DFS isn't needed?
Just seems there should be a connection with 1.5.9 on both boxes with the following readings.
Name MAC IP Q% sig rx tx AQUEP CFTWM kbs-rx kbs-tx idle │
│ a site in the middle>b9:b0 249.242 77 -83 24 6 ***- ---*- 0 0 2m52s

I'll crank up the bucket and visit the rec site in the later AM ..I can't do any more with this so I might as well put my head down for a couple of hours. I'll report back later..

[David L. Vrablic]

Arrived on site and found the client unit with Q 100% sig -57 noise -105 rate 24
I set the rate to auto and activated it and I had conductivity and could ping both ways up and down the 14 unit string..
This is on a 4.9 freq and a scan shows nothing that it can see.

In auto mode the rate hops from 6 to 36 randomly.
I set the ANI to on and the only change was that the rate now hops from 6 to 54. I left it on.
I tried the other 4.9 freqs. with now change.

It seems that this version has to have both ends set to auto or it does not complete the association.

Unrelated but this one system just fell apart today so I have had a real day of it. Not of any relevance to this FW version but very strange happenings indeed.
Back to playing detective..:confused:

[DrLove73]

1.5.x versions tend to drop rate to 6 extreamly quickly. The links I have put 1.5.9b (and 1.5.8b) even with -67 start to fluctuate from 36 to 6 and back, every 2-3 seconds. With 1.4.22r and rate agressivnes to -1, and max rate to 24 I get solid rates of 12 or 18. With 1.5.x I get 200-300-1000 ms pings (1400Byte) and jumping rates.

[ninedd]

That is the only really noticeable thing we're dealing with on 1.5.9b I think - that is the lack of capping. There are lots of links which benefit from capping them at 24Mbit for example, and in 1.5.x that would currently mean locked at 24, not just auto-capped at 24. Along the same lines, the rate agressiveness in 1.4.22r was nice to solve problems for those customers with decent signal, but who couldn't quite seem to be reliable at the speeds that auto wanted to pick on it's own.

Generally though, we're getting better overall results with 1.5.9b and auto, even if the rate display jumps around. When we're able to cap that, that'll be even better. :)

[handyman]

I was able to confirm the 1.5.9 WPA master failure using units on the bench.

Briefly, X4000 with 1.5.9 as AP and WPA master, WAR1 with 1.3.13 as WPA client but lacking IP addresses on the wireless interface. X4000 ran fine for 24 hours. Client associates, no problem. Assign an IP address to the client wireless interface and the X4000 immediately reboots. Behavior is reproducible.

Update: With 1.5.9 on the client, the reboots occurred more easily. Just having the client associate, or fail to associate due to using the wrong WPA passphrase, causes the X4000 to reboot, without any IP addresses or traffic. With 1.3.23 on AP and 1.5.9 on the client, associate is OK, assigning IPs to interface is OK, but client's first attempt to pass traffic causes client to reboot.

[ninedd]

A definate minor hiccup when upgrading from an earlier version (like of 1.5.3b) to 1.5.9b over the air on a number of SIAM boards we have in the field. I'm pretty sure this has been discussed somewhere, but though I'd remention it again to be sure...

What we saw was that on upgrade, the antenna connectors are swaped. In other words, a customer that's on connector 'b' for example, working OK with 1.5.3b, and when we upgrade him to 1.5.9b and reboot, he goes off the map. When we get logged back in, we switch him to connector 'a' and all is well again.

So, what we're doing now is this:
1) Ping watchdog back to the AP and SAVE/ACTIVATE
-> (we like to use 5 pings, 60 seconds, for a 5 minute reboot cycle, but whatever...)
2) Switch antenna connector to DIVERSITY and ACTIVATE (NO SAVE!)
3) If that reassociates fine, then SAVE to save the Diversity setting.
4) Upgrade firmware, apply and reboot.
5) When it relinks, it'll be Diversity on 1.5.9b
6) Change to a connector (eg 'a') and ACTIVATE (NO SAVE!)
7) If that relinks fine, then SAVE
8) Otherwise wait for reboot & do the other connector & ACTIVATE (NO SAVE)
9) If that relinks fine, then SAVE

From what I understand, the antenna connectors aren't really being 'switched', but rather that the very early 1.5.x's were always on diversity, so that in essense, when it was, for example, on 'b' and should have been on 'a', it was really on diversity so it didn't matter as much. On upgrade, the 'a' or 'b' took effect, so suddenly it looked like it's switched. So, a bit of a minor hiccup, but pretty much OK when we do these steps. Again, this only is between the earliest 1.5.x's we have, so won't be an issue going forward anyway. :)

[lonnie]

We have found a minor/major glitch but it does not seem to be always.

On a 1.5.9b client to a 1.4.22r AP we are seeing periodic disconnects and reassociations. We thought it was just when ani was enabled but over night it seems to be just in general. ANI seemed to make it more visible, but is not the cause.

Please check the logs for 1.5.9b to 1.5.9b systems and let us know if they ever do that disconnect/reconnect cycle.

[tony]

As a note for those using 1.5.x, this is a problem found on one system, and we need to know if it is specific to this one install, or if others have experienced the same problem.

Symptoms include a complete link outage when a burst of traffic is initiated (via download or starutil), causing the client to disconnect.

In this instance, the ap is 1.4.22r, and the client is 1.5.9b.

We have been unable to replicate this issue (so far) in the lab or on our test network.

[kbldawg]

I pushed 1.5.9b out to three WP188 boxes and about 7 clients today, all at the same time to maintain firmware version continuity.

Box 1
wpci1 - backhaul-AP (5.320gHz) to box 2
wpci2 - disabled
wpci3 - disabled
wpci4 - disabled

Box 2
wpci1 - backhaul (5.825gHz) to box 3
wpci2 - disabled
wpci3 - 2.4ghz AP (all clients were upgraded to 1.5.9b)
wpci4 - backhaul (5.320gHz) to box 1

Box 3
wpci1 - backhaul (5.825gHz) to box 2
wpci2 - 2.4ghz AP (all clients were upgraded to 1.5.9b)
wpci3 - disabled
wpci4 - disabled


Services running...snmp, ntp, ospf, isc-dhcp (box1 only), plus the defaults of course.


Everything ran great initially. We were able to make use of the enhanced features to fix some screaming clients and backhauls looked really good. Everything ran from about 10am until about 10pm and then I lost the backhaul link from box1 to box2... (5.320ghz)

From the AP, the first thing I noticed was the rate difference. The rx/tx was 36 / 6

Next I noticed the link dropping off every few minutes. Right before it would drop the station, the signal would start falling off from about -75 to -90s.

At first I thought maybe I had made radio card and the link couldn't support the capped rate of 36 so I had my tech at the station side of the link verify the rate was set to auto, he changed that and the rates went to 6 on both sides, but the signal kept fluctuating very drastically.

We tried adjusting a few settings with no results...

Made sure all rates were set to auto
Tried changing antenna ports
Removed wireless securty (WEP 128bit)
Rebooted both sides

Then, I went in to the system reports and noticed that there was some mention of DFS scanning and that my station kept getting kicked. Then I realized that box 3 backhaul to box 2 was fine. No problems at all. The only setting difference was the freq. So, I moved up to 5.745ghz on box 1 - box2 backhaul and the link came back up

AP is -68 to -70 , 54mbps rate
Station is -65 to -69 , 54mbps rate

Additional info...

At boxes 1 and 2, I have canopy backhauls co-located with the staros gear. Box 3, no canopy. Although, I do have good freq seperation, I'm not sure if that could have been a factor or not.

More food for thought on the canopy...

At box 1 the canopy is approximately 60' from the staros box. At box 2 site, the canopy is virtually right next to the staros box. Maybe nothing, maybe something, dunno.

I'd be interested if anybody else using the 5.180 - 5.320 freq for backhauls has had any problems with this release.

[David L. Vrablic]

As a note for those using 1.5.x, this is a problem found on one system, and we need to know if it is specific to this one install, or if others have experienced the same problem.

Symptoms include a complete link outage when a burst of traffic is initiated (via download or starutil), causing the client to disconnect.

In this instance, the ap is 1.4.22r, and the client is 1.5.9b.

We have been unable to replicate this issue (so far) in the lab or on our test network.

@Tony
This sounds a bit like what I thought I saw happening with that problem this morning. When I made an upgrade to the client end it looked like a "Partial" association on the AP up the street. I could not ping the client side from the preceding AP.
When it first initialized it looked like it was going to pass traffic then it just shut down or locked up. If I viewed the connection via F2 and watched, there s a slight blip of of the traffic numbers then tx and rx go to 0 and the idle timer starts counting up.
The camera on that location generates about 1 meg so it would have had that traffic plus whatever it saw from up the string if it did make a quick connection before it froze up.
---------------
I had to access the client side and set the rate to auto from the 24 it was set to. It had a -55 signal with no noise on a ## 4.9 freq.
I put 1.3.23 back on and all is well again.
---------------
Last night I was upgrading a string of 14 drop and hop boxes client side in and AP side out with a camera on the eth port.
I checked the log but I really didn't see any disassociation just a log full of NTP time sets.
-----------
Tonight I just finished putting everything back to 1.3.23 because there is some strange stickiness in the data transport. I try testing more this week but not on such a grand scale. I couldn't put my finger on the problem.
---------
I can set up a dedicated test out on the end some place if you can tell me what to look for. I haven't been using 1.4.22 because you told me not to.
But I can load a W188 with whatever will make you happy.
Let me know.

I forgot to tell you I am running OLSR on this system if that figures into anything.

[DrLove73]

We have found a minor/major glitch but it does not seem to be always.

On a 1.5.9b client to a 1.4.22r AP we are seeing periodic disconnects and reassociations. We thought it was just when ani was enabled but over night it seems to be just in general. ANI seemed to make it more visible, but is not the cause.

Please check the logs for 1.5.9b to 1.5.9b systems and let us know if they ever do that disconnect/reconnect cycle.

I think I have what you are after. But even worse, I have 1.5.9b client (connected to 1.4.22r) randomly rebooting. It is like that for 2 days now, since it waas put up. I do not have remote log, but I pull all logs every 1h. I will see to compile something with additional info and post

[tony]

What platform is the client?

[DrLove73]

Work in progress! I'll post when I finish.

Both are X86-PC. Is it possible that something on that unit does not like 2h difference in clock?

AP side:
wpci2, CM9
Link is 11a, no Turbo
Freq 5240,
Tx auto,
dist 15 miles (link is 13km),
Country code D1
Tx Power override 18
1x
Power savings [x]
Short [x]
SuperA/G [x]
Rate agg OFF
Low -83
High -50

Signals from -71 to -75
Rx rates from 1.5.9b = 54 - 24
Tx rates

Client side:
wpci1, CM9
Tx auto,
dist 15 miles (link is 13km),
Country code D1
Tx Power override 18
1x
Enable ANI[x]
Short [x]
Low -80
High -60

Signals from -71 to -75
Rx rates from 1.5.9b = 54 - 24
Tx rates

Changing frequency does not help. Signal got 4-5 db better but same thing happens.
It starrted this morning to reboot continualy.

[tony]

Thanks. To narrow down the problem, could you disable SuperA/G on the AP? I would like to see if this helps any.

No, time differences between the systems do not matter.

Thanks again.

[DrLove73]

I have seen few unprovoked reboots with 1.5.9b when I give activate changes command. not too often, but 1/10 or so. I think I used ANI everywhere (on client sides).

Disabling ANI on 1.5.9b client did not help. I just disabled SuperA/G.

[DrLove73]

Unit stoped rebooting, but I am not sure why for now. I disabled SuperA/G on 1.4.22r AP Enable ANI on 1.5.9b CPE and changed Frequency to 5300, but I also disabled wpci2 on that same CPE, 2.4GHz 11b AP (omni). There is no reboots for 12 minutes.

I am going to turn wpci2 ON to see if anything changes.

[DrLove73]

OK, that is interesting. I had MAC 00:15:... connecting with -91 signal from time to time, and today I have seen it few times in logs, always 2-6 seconds before reboot. I do not think I saw IP on it ever. I disabled 11b AP radio and it worked fine with no reboots. Tried this several times, always the same result.

I enabled wpci2 radio but set Low threshold to -55 and high to -50 so no one can connect. So far 14 minutes without reboot. I will raise low threshold to eliminate just offending MAC.

[ninedd]

This is a minor, non-critical issue. From a program like StarMAN that is doing SNMP Queries, it's seems to be often (but not always) reporting 0 for the CPE's RX Speed when the CPE is 1.5.9b. I haven't done much digging to find out why this is - I noticed it a week or so ago, and haven't had time to do any investigation, so I though I'd just mention it on here incase it's a simple/obvious solution. Thanx.

[DrLove73]

There is an potential problem with 11a Turbo Mode when 1.4.22r is AP and 1.5.9b is CPE, but the same configuration with reversed roles works like a charm.

I will try to find free time to write all configs.

[DrLove73]

I had to revert all units to 1.4.22b. 1.5.9b has much higher pings and worse rates on same settings. so far, Only 1.4.22r gives me stable network.

[pops]

I noticed the same thing, it looked good at first but did not last long.

Pops

[DrLove73]

I think rate inteligence of the driver (using average as well as current situation for number of lost packets) plays very large role in stability, along with other factors I guess.

[ninedd]

We find that generally there are very encouraging results. However, with the lack of being able to cap the rate (right now, caping is locking) then we get strange results. If we set them at auto, they'll skip from 1Mbit to 36Mbit, and if we lock them at 24 or 18, that may be too agressive. Without being able to cap, it's difficult to tell what the situation is.

[pops]

I have this release on a couple of sites where we are 11b only and all rates are auto it does perform well , but we were not able to get it on sites where we have an 11a backhaul on the same sbc as the AP because the backhaul kept droping out.

pops

[DrLove73]

I have this release on a couple of sites where we are 11b only and all rates are auto it does perform well , but we were not able to get it on sites where we have an 11a backhaul on the same sbc as the AP because the backhaul kept droping out.

pops
If AP side of the backhaul is 1.4.22r, then that is what Tony wrote about and might be fix in the next release.

[greg]

I've got several 1.4.22 connections to/from 1.5.9 on A links without issues. I just make sure the speed is set to auto before rebooting. And I'm using CM9's and/or WLM-AG-23 radios on the backbone links.

[cephlon]

I have been running a small 2 port War board for the last couple weeks with 5.8 and now 5.9. It seems to be running fine. It only has 6 customers and all the signals all below -65.

I rolled it out today on a little bit larger AP. This is a Metro Board. Wpci1 is a DCMA82, Wpci2 is an XR5, WPCI3 is a KSX Valemount card. WPCI4 slot is empty.

There are about 14 clients on the KSX and 4 clients on the XR5. The client upgrades went fine. I upgraded the Metro board and it came back no problem.

The only odd thing is the rates are really high, and then they drop down to 1 or 2. The throughput seems to suffer when this happens to.

[mike]

It seem like rate agressiveness should be back in 1.5.X.

Even if you say that we sould not need it, their always situation we need it because the auto rate fix the rate for the signal received instead of fixing it for the signal received on the other side and sometime, we can have 10 db of difference between the 2.

[tog]

It seem like rate agressiveness should be back in 1.5.X.

Even if you say that we sould not need it, their always situation we need it because the auto rate fix the rate for the signal received instead of fixing it for the signal received on the other side and sometime, we can have 10 db of difference between the 2.

That was behavior specific to 1.4.x. I don't see that 1.5.x is setting its transmit rate in that backwards manner (seemingly based on rx signal) like 1.4.x was. It does seem to need a bit of tweaking, though, tx rate selection currently can be a bit "jumpy".

[lonnie]

Tony will soon release rate capping which will allow you to set a tick or two below its peak.

[tony]

The new release will have the max rate support as lonnie mentioned in addition to a few other goodies. The release is not too far off.

[mike]

though, tx rate selection currently can be a bit "jumpy".

Maybe this beavior is fix on 1.5.X but a "jumpy" rate meen that the rate go too high, then their paquet lost or latency, the quality drop so rate drop too to fix the quality. Once the quality is ok, rate goes up again. rate agressiveness would be useful again in this case.

Also human intelligence will always be better then a computer. A other useful case is in noisey area when the signal is not that bad, a lower rate will help a lot for paquet lost. I think rate agressiveness should be back in 1.5.X, it a lot better to have auto rate droped then fix it and take more air time for station with good signal that could transfer at higner rate

[tog]

I would be fine if it were just tweaked some to avoid being too overly aggressive in choosing too high a rate and then too overly aggressive in correcting it. I've actually been running all my 1.5.x WAR1a clients with fixed rates so far.

[greg]

I *need* to be able to use 2407 with new clients. There are several AP's that we use that on and all we have for installs are the new war1's.

[tog]

I *need* to be able to use 2407 with new clients. There are several AP's that we use that on and all we have for installs are the new war1's.

Yeah we miss it, too. We are used to using ## and a custom scan list of 2407-2472 with x2/x4.

[mickeym]

Ditto!

[om]

+1 for 2.4 extended channels. We have been holding installation of new WAR1-a waiting for new release to support it.

Thanks.

[lonnie]

PPPoE will make it in the next release, but it might be too big for the War1. It will fit in the new War1a.

The channel numbers are a problem and we cannot be compatible with any other version, so the deal will be that we can hit the channels but only with other 1.5.x systems.

[om]

Any possibility of Virtual AP feature in coming release? What I understood from earlier release notes, this feature is ready in code, only GUI front end is remaining to be done.

Thanks.

[lonnie]

No, the Virtual AP will not make it in. It takes some GUI changes, but then all scripting has to change to take into account the extra devices that are related to the real AP. It might sound simple, but it will be a HUGE undertaking to get it going properly.

The code is in the driver and it does work when loaded and configured by hand.

[om]

Lonnie,

I understand it is a huge task to accommodate Virtual AP features in current GUI setup.

Any ETA as to when this feature will be available? In the meantime, is it possible to make Virtual AP featuer configurable from console only until the GUI is reworked?

Thanks.

[lonnie]

To configure it from the console requires manual commands and scripts to bring up/down the virtual devices. It will not be possible to have that level of access from command line.

I cannot say when it will come, except to say that it will be after the 802.11n driver.

[go.fast]

For example, when we upgraded all the client on one of our towers to 1.5.9b last week, we have to log into each one of them and turn ANI on according to the recommendations. It would have been GREAT to be able to write a script to download the config, toggle that item, and to re-upload/activate that change.

- Todd

Good idea on your suggestions.

As for the ANI, if it should be turned on for 1.5.x, then maybe ANI ought to be enabled by default, instead of disabled, in the firmware. So when we do an update it's already done.

[ninedd]

The channel numbers are a problem and we cannot be compatible with any other version, so the deal will be that we can hit the channels but only with other 1.5.x systems.That's a major problem for us. However, if there simply won't/can't be compatibility between the versions, then it's good to know and we can start hanging other gear to work around this.

[tog]

That's a major problem for us. However, if there simply won't/can't be compatibility between the versions, then it's good to know and we can start hanging other gear to work around this.

You should be able to update everything to 1.5.x. It is available for all of the older platforms.

[ninedd]

Just one test customer so far, WAR1a with XR9 & 17dBi Yagi. ~ 5 miles, LOTS of trees. Ridiculous amount of trees. And then, behind those trees... there's some more trees.

Mainly this was to test how 1.5.9b worked with XR9/FLR9G30's. It's nerve-racking to try it live on an AP with 30 clients, but this is a newly erected tower, and a client that's a long way out, behind a lot of trees, so we can do some experimenting.

FLR9G30 AP Card is set at 20 (so 30dbi) and XR9 Client card is set at 17 (so 27dbi). Client hears the AP as -77ish, AP hears the client at -85ish. Client has ANI turned on, AP does not. Both sides are auto, since capping isn't supported so far. X2 Cloaking, 11g-only.

I should point out that all our other XR9 stuff is all 1.3.23b, since 1.4.22r has not really worked at all with XR9's for us. Honestly, we didn't try 1.4.22r on all our 900Mhz towers, we tried and failed with about 1/2 a dozen towers, and that's was enough to let us know that 1.4.22r and XR9's were a no-go. This 1.5.9b is working quite well, under a very difficult situation I think.More update on this AP. We had to roll this AP (and a couple others doing a PTP Link) back to 1.4422r. The 1.5.9b signals/strength has been 'degrading' every day or so, so that signals dropped by 6-10 dbi, and rates have eventially dropped to 6 - 12 Mbit and that even pinging the AP is difficult. We rolled them back to 1.4.22r a couple days ago, and the links are all good since then. On this particular AP, the XR9 CPE is a SIAM board, so we're stuck at 1.5.x there. When we rolled the AP back to 1.4.22r, the SIAM CPE reports the signal strength much higher than when the AP is in 1.5.9b mode.

So, in our PTP Link we have a GW-WAR2 (10.50.x.x) to a METRO (10.51.x.x) with 24dbi Grids at 22Km. On 1.5.9b we would have signals in the mid 60's and rates of 24-54Mbit. As has been reported before, rates have been jumping from 1 to 54, but when the boards are newly powered up, that didn't seem to be affecting performance to terribly much. However, a day later the signals would be -70 and rates would be 6 or 9Mbit only. Since roling back to 1.4.22r, the signals are a fairly steady -67 and rates stat at 48Mbit both sides - occasionally dropping to 36, but mostly 48.

[deano]

Just starting to test the 1.5.X release.

I notice now that NTP is checking every 5 minutes, in the future, can this time be configurable?

Also, it would be nice if the server edition could run NTPD as master and client.

Testing on WAR1 now, upgraded from 1.2.32b, and AP is 1.3.23b, everything looks good so far but it's been less than 24 hours.

Just thought I would comment.

Thanks.

[go.fast]

I have a war1a running 1.5.9b
The site survey keeps showing inconsistant data.
For one it does not show the ap I am connected to. Although in one of the survey's it showed at least 8 ap's..
I am connected at 69, 1x, antenna a, b/g, auto, ani, short, and interbss on

Also, aside from it not showing all ap's all the time, it is showing wep on and off on one particular ap, depending upon which time I hit site survey.

Figured you would want to kow this and here is a qucick copy paste of the variations.

===================================
Security ON:

Cell 01 - bssid: 00:00:00:00:00:00 ^│
│ ssid: <hidden> ▒│
│ frequency: 2.437 GHz ▒│
│ signal level: -88dbm ▒│
│ security: wep ▒│
│ supported rates: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mb/s ▒│
│ ▒│
│Cell 02 - bssid: 00:1D:5A:1D:DE:59 ▒│
│ ssid: "Austin" ▒│
│ frequency: 2.437 GHz ▒│
│ signal level: -86dbm

======================================
Security OFF

Cell 01 - bssid: 00:00:00:00:00:00 ^│
│ ssid: <hidden> ▒│
│ frequency: 2.437 GHz ▒│
│ signal level: -89dbm ▒│
│ security: off ▒│
│ supported rates: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mb/s ▒│
│ ▒│
│Cell 02 - bssid: 00:1D:5A:1D:DE:59 ▒│
│ ssid: "Austin" ▒│
│ frequency: 2.437 GHz ▒│
│ signal level: -86dbm

====================================

Also I rebooted this unit and it still only shows 2 ap's and not the one I am connected to at 64

[go.fast]

I went through the steps of b/g ANI off then on, and B ANI on then off and got the same 2 ap's.
Here's a site survey after powering down and swapping from b/g to G with ANI on or off:

Cell 01 - bssid: 00:00:00:00:00:00 ^│
│ ssid: <hidden> *│
│ frequency: 2.437 GHz │
│ signal level: -86dbm │
│ security: wep │
│ supported rates: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mb/s │
│ │
│Cell 02 - bssid: 00:1F:B3:1C:0D:49 │
│ ssid: "2WIRE645" │
│ frequency: 2.462 GHz │
│ signal level: -93dbm │
│ security: wep │
│ supported rates: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mb/s │
│ │
│Cell 03 - bssid: 00:0B:6B:37:1E:93 │
│ ssid: "wildwinds" │
│ frequency: 2.427 GHz │
│ signal level: -64dbm │
│ security: off │
│ supported rates: 1, 2, 5.5, 11 Mb/s │
│ extended abilities: QoS SuperAG │
│ │
│Cell 04 - bssid: 00:0B:6B:36:E2:DC │
│ ssid: "OREGONFAST_WW" │
│ frequency: 2.447 GHz │
│ signal level: -80dbm │
security: off │
│ supported rates: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mb/s │
│ extended abilities: QoS SuperAG │
│ │
│Cell 05 - bssid: 00:15:05:1C:B4:21 │
│ ssid: "faye" │
│ frequency: 2.452 GHz │
│ signal level: -82dbm │
│ security: off │
│ supported rates: 1, 2, 5.5, 11, 22, 6, 9, 12, 18, 24, 36, 48, 54 Mb/s │
│ │
│Cell 06 - bssid: 00:23:A3:8C:0F:90 │
│ ssid: "qwest0592" │
│ frequency: 2.412 GHz │
│ signal level: -91dbm │
│ security: wep │
│ supported rates: 1, 2, 5.5, 11, 22, 6, 9, 12, 18, 24, 36, 48, 54 Mb/s │
│ │
│Cell 07 - bssid: 00:1D:5A:1D:DE:59 │
│ ssid: "Austin" │
│ frequency: 2.437 GHz │
│ signal level: -84dbm

[go.fast]

Also, noticed in the latest survey it shows cell #5 #6 and then skips to cell #10.
7,8,9 are not to be found.
1,2,3,4 showed up, but I didn't copy them :


Cell 05 - bssid: 00:23:A3:8C:0F:90 │
│ ssid: "qwest0592" │
│ frequency: 2.412 GHz │
│ signal level: -92dbm │
│ security: wep │
│ supported rates: 1, 2, 5.5, 11, 22, 6, 9, 12, 18, 24, 36, 48, 54 Mb/s │
│ │
│Cell 06 - bssid: 00:24:7B:24:3D:D2 │
│ ssid: "myqwest5121" │
│ frequency: 2.412 GHz │
│ signal level: 162/162dbm │
│ security: wpa (group: proprietary, pairwise: tkip), wpa2/rsn (group: tkip, pairwise: ccmp │
│ authentication suites: psk │
│ supported rates: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54 Mb/s │
│ │
│Cell 10 - bssid: 00:1E:E5:6B:38:07 │
│ ssid: "crazeedave" │
│ frequency: 2.462 GHz │
│ signal level: -81dbm │
│ security: wpa (group: proprietary, pairwise: ), wpa2/rsn (group: tkip, pairwise: ccmp tki │
│ authentication suites: psk │
│ supported rates: 1, 2, 5.5, 11, 6, 9, 12, 18, 24, 36, 48, 54, 1, 2, 5.5, 11, 18, 24, 36, │
│ extended abilities: QoS

[bbronco]

I need channel 0 fixed!!!!! im out of old wars and going to have to start looking for something else. almost every cloaked tower we have is on channel 0!!!!!!!!!!

[SpecialK]

How do you guys get away with using channel 0 in the US?
Every mini pci card I have ever seen is only certified from 2412 to 2462

[ninedd]

How do you guys get away with using channel 0 in the US?
Every mini pci card I have ever seen is only certified from 2412 to 2462Those frequencies are the center frequencies, but are assuming you'll be using a 20Mhz wide channel. When your channel width is only 10Mhz or 5Mhz, then the 'centre' of that narrower channel can be higher or lower than normal, because the absolute lowest or highest end of the chirp will be within the legal bounds.

[SpecialK]

Thanks Ninedd,

But if we could use them legally why is that missing from Star-OS firmware in the FCC version?
Every version I have 1.3.13, 1.4.22r, etc. do not allow you to chose 2407 or 2467 when X2 is chosen.

This would be nice to have if legal for us.

[deano]

Thanks Ninedd,

But if we could use them legally why is that missing from Star-OS firmware in the FCC version?
Every version I have 1.3.13, 1.4.22r, etc. do not allow you to chose 2407 or 2467 when X2 is chosen.

This would be nice to have if legal for us.

I agree.

If it is legal in the US, the fcc ver should show them in the channel list.

[ninedd]

Hmmmm.... I don't know. :D I'm Canadian, eh, so I guess I shuda kept my trap shut, and let some Yank in the know pipe up. :D

[pops]

Best I know leagal spectrum in the US is 2450 +/- 50Mhz

we use 2407 x2 & x4

[lonnie]

Atheros uses the IEEE channel numbering convention and ---> channel 0 is illegal to the driver and IEEE convention. Thus to use their numbering, which the driver does, we cannot hit channel 0. Tony is working a mechanism to replace the channel numbering but it is a lot of work and requires changes in MANY parts of the driver.

It is work in progress and should make it into the next release.

Thanks Ninedd,

But if we could use them legally why is that missing from Star-OS firmware in the FCC version?
Every version I have 1.3.13, 1.4.22r, etc. do not allow you to chose 2407 or 2467 when X2 is chosen.

This would be nice to have if legal for us.

[Mark]

I set up an access point here in the house using a wrap board and 1.3.23b, and cloaking at X4. I then set up a client using the latest WAR1a and beta release. This is to mimic my 900 mhz network setup.

Since nothing has high gain antennas attached, and some distance between them, I had radio rates reported as 18 and 24. I got LESS THAN 200KB speed test between them.

That is pitiful. I connected the system to my in house AP which is a brand U, in G mode, at 54mbit, and I only got 450KB download through it, though my house has ~30mbit connection.

This looks like a disaster. I"m supposed to install two clients tomorrow, using WAR1a's and XR9's. I'm sure neither is going to work for beans.

We are SOOOO screwed. No Atheros enhancements at all, and throughput so awful it's near pointless. I've tried to read through and see what's going on before I bought these, but it seemed nobody noticed any of this? So, instead of buying Alix boards, I spent a bunch on WAR1a's and now see no point in using them. My customers have been less than fully patient waiting for me to get some boards in... and now that I have some, I don't see how I can even use them. ONE client will take the whole access point down, by monopolizing it just for 2 mbit.

I understand this is beta and I understand we're changing generations, so I wasn't expecting miracles or anything. Didn't anyone notice this? Lonnie, a heads-up that we can't use these on our legacy access points would have been helpful.

Off to find something to dull the knot in my gut and figure out how to deal with tomorrow....

[ninedd]

Mark, it has been mentioned here that 1.3.23b and 1.5.9b don't work that well together. In our experience, 1.3.23b works fine with 1.4.22r, and 1.4.22r works fine with 1.5.9b - but going from 1.3 to 1.5 is pretty persnickety and doesn't work well in many situations.

That being said: we have 52 AP's and ~1400 StarOS CPE's and we DO have a number of places with 1.3.23b AP's where we have used 1.5.9b CPE's that are working well. We do generally find that they like to have mid-60's signals in order to work well, but we have a number of them out there.

On one of our busiest AP's, we have a 1.4.22r METRO with three 120 degree sectors, and 80 clients, 100% of them are 1.5.9b and it's performing pretty good. In another location, we have a 1.4.22r AP with an XR9 Card and 1.5.9b SIAM XR9 clients, and again, it's working OK enough to connect new customers.

We have purchased 300 SIAM boards so far, and have been quite pleased. Sure the current version still has a few limitations, but in other situations, 1.5.9b has totally rocked. We have places with known high noise that were running 1.4.22r that didn't work all that well. In several places, upgrading over the air to 1.5 and turning on ANI has made it work well. At on of our staff's homes, his microwave would always cut the internet off, and NoiseBuster on 1.5 makes it work fine now. Obviously 1.5.x isn't perfect, but I would recommend you give it a go and see how it goes for you. We have had a couple 1.3-1.5 no goes, but we have dozens and dozens of 1.3 to 1.5 working OK.

Alternatively, maybe it's an option for you to try a 1.5.9b AP at this location? I don't know, maybe that's not feasable for you, but maybe you can double-up with a WAR1A/XR9 as a new Access Point? Maybe that's un-doable for whatever reason, but we have (or will be) doubling up in a few locations so that we can experiment with 1.5AP to 1.5CPE without buggering our 1.4 customers.

So - I FEEL YOUR PAIN - it has been a very rough last few months with not being able to get product. For me, that's my #1 beef. However, as things are moving forward, we are honestly very excited and encouraged about the future. I frankly wasn't sure 2 month's ago at all, but I'm pretty pleased with what I see so far.

[ninedd]

Just tested some performance figures on our 900Mhz stuff with 1.5.9b CPE's to 1.4.22r AP.

This is a METRO board with 1.4.22r on the AP side.
WPCI1 is BackHaul card
WCPI2 is DISABLED
WPCI3 is 2.4Ghz KSG30 in 2x mode - 15dbi Omni
WPCI4 is 900Mhz XR9 in 4x mode - 11dbi Yagi

CPE is SIAM/XR9 with 1.5.9b in 4x Mode, signals in low 50's @ about 1/4 to 1/3 mile, fairly SOLID Spruce/Pine trees.

Performance on build in Throughput tests, tested from CPE.
RX'ing from AP, 367KB Download @ 18Mbit
TX'ing to AP, 633KB Upload @ 48Mbit (auto)

This is about 1/4 to 1/3 mile of fairly SOLID Spruce/Pine trees. We had them connected with a 30db 2.4 card and 24dbi grid, but could only muster a -76 on a good day and would work OK, but which was a -82ish on a bad day, and would work badly for them. We installed an XR9 today in the 1.4.22r/METRO AP, with a 11dbi Yagi. They have a -53ish both ways, and performance is just excellent.

Additional Performance Testing:

AP : Metro XR9 1.4.22r - Capped at 18, 24, 36 & 48Mbit rates
CPE: SIAM XR9 1.5.9b - AUTO (it had picked a TX rate or 48Mbit)
Throughput Test running from CPE, RXing (Downloading) from AP.

AP TX 4x 2x
18Mbit 367KB 707KB
24Mbit 463KB 906KB
36Mbit 609KB 1182KB
48Mbit 732KB 1394KB

[DrLove73]

Can somebody give us ETA on 1.5.10b? Like: "It will NOT be released in in next X weeks."

Thanks.

[tony]

It will be released soon. Some of the features being added take a little time to complete, but are well worth the wait.

[lonnie]

You seem to follow the Forums, so why did you NOT see where we have said 1.3.23b is a poor choice when dealing with 1.5.x series. We've said 1.4.22r works quite well, and is what we have tested to. Also, we have said 1.5.x to 1.5.x is the best choice.

Also, maybe you missed that we have put in a lot of extra work and ported the 1.5.x series to ALL the older hardware. Maybe we wasted our time. We felt we were doing you guys a service, but maybe we need to be like the other guys and only support the new hardware with the new firmware. That would be for another thread though.


I set up an access point here in the house using a wrap board and 1.3.23b, and cloaking at X4. I then set up a client using the latest WAR1a and beta release. This is to mimic my 900 mhz network setup.

Since nothing has high gain antennas attached, and some distance between them, I had radio rates reported as 18 and 24. I got LESS THAN 200KB speed test between them.

That is pitiful. I connected the system to my in house AP which is a brand U, in G mode, at 54mbit, and I only got 450KB download through it, though my house has ~30mbit connection.

This looks like a disaster. I"m supposed to install two clients tomorrow, using WAR1a's and XR9's. I'm sure neither is going to work for beans.

We are SOOOO screwed. No Atheros enhancements at all, and throughput so awful it's near pointless. I've tried to read through and see what's going on before I bought these, but it seemed nobody noticed any of this? So, instead of buying Alix boards, I spent a bunch on WAR1a's and now see no point in using them. My customers have been less than fully patient waiting for me to get some boards in... and now that I have some, I don't see how I can even use them. ONE client will take the whole access point down, by monopolizing it just for 2 mbit.

I understand this is beta and I understand we're changing generations, so I wasn't expecting miracles or anything. Didn't anyone notice this? Lonnie, a heads-up that we can't use these on our legacy access points would have been helpful.

Off to find something to dull the knot in my gut and figure out how to deal with tomorrow....

[lonnie]

That would be a NOT ETA (or NETA). It should be soon, measured in days.

Can somebody give us ETA on 1.5.10b? Like: "It will NOT be released in in next X weeks."

Thanks.

[Mark]

You seem to follow the Forums, so why did you NOT see where we have said 1.3.23b is a poor choice when dealing with 1.5.x series. We've said 1.4.22r works quite well, and is what we have tested to. Also, we have said 1.5.x to 1.5.x is the best choice.

Also, maybe you missed that we have put in a lot of extra work and ported the 1.5.x series to ALL the older hardware. Maybe we wasted our time. We felt we were doing you guys a service, but maybe we need to be like the other guys and only support the new hardware with the new firmware. That would be for another thread though.

YOU are complaining? I'm the guy who is going to have the whining customers...or maybe ex-customers.

Uhhm... Ok, so if I convert the whole 900 mz system to 1.5.x, the backhaul comes from 1.3.23b, and it's a long distance shot, with signal in the high 70's low 80's, depending on atmospherics. Sounds like my backhaul would no longer work, and I'd be in even worse shape. Rather than having some bad clients, I'd have a whole area complaining.

Again, I wasn't expecting miracles, but saying "from x to x isn't the best" isn't very informative. I had no idea that the "super" features weren't working. I didn't read that anywhere. Our 900 systems depend on them to have any kind of performance at all.

Perhaps we need a little clarity... Are the "super" features permanently gone?

[deano]

Also, maybe you missed that we have put in a lot of extra work and ported the 1.5.x series to ALL the older hardware. Maybe we wasted our time. We felt we were doing you guys a service, but maybe we need to be like the other guys and only support the new hardware with the new firmware. That would be for another thread though.

Lonnie,

Please do not lump me, and I assume a lot of others in with, "you guys" all together, based upon the remarks of one person.

I for one, appreciate all the effort to support the older hardware with current firmware releases.

And I do not believe, that you are wasting your time.

Thank you.

[Mark]

That being said: we have 52 AP's and ~1400 StarOS CPE's and we DO have a number of places with 1.3.23b AP's where we have used 1.5.9b CPE's that are working well. We do generally find that they like to have mid-60's signals in order to work well, but we have a number of them out there.


Alternatively, maybe it's an option for you to try a 1.5.9b AP at this location? I don't know, maybe that's not feasable for you, but maybe you can double-up with a WAR1A/XR9 as a new Access Point? Maybe that's un-doable for whatever reason, but we have (or will be) doubling up in a few locations so that we can experiment with 1.5AP to 1.5CPE without buggering our 1.4 customers.

So - I FEEL YOUR PAIN - it has been a very rough last few months with not being able to get product. For me, that's my #1 beef. However, as things are moving forward, we are honestly very excited and encouraged about the future. I frankly wasn't sure 2 month's ago at all, but I'm pretty pleased with what I see so far.

Almost all my AP's are "full", so adding marginal equipment or shots is out of the question. I need to take some load off them, not worsen throughput. I've been in a holding pattern since, sheesh, before the year began, trying to figure out what to deploy in the next round of "installing capacity". I put up one test case MIMO system to try out, with a mix of good and disappointing results. I was hoping to try star-os's MIMO to see if it's any better before pressures of growth forced me to just move "to what's available". I"m NOT putting up any more legacy gear, as both my physical space for antennas and spectrum's pretty crowded. Throughput tests for MIMO are eyeball popping. And at the moment, it appears that useage is going to climb, and that more and more are going to be watching movies and tv online, so I'm determined that whatever I put up is going get me more bytes/mhz, to keep up with demand.

I guess I had just breathed a sigh of relief when everyone started saying that lockups and over the air updates and lots of other early stages pains were mostly gone, and now I realize that I'm still stuck in the same spot I was before. The legacy interop performance isn't adequate, MIMO's not ready to compare, so I'm just still in the holding pattern. Without the "super" features, moving the whole network to 1.5.x would be an epic disaster. and because my network is SO "air" oriented, there's no physical interfaces to allow parts to be segmented off. Backhauls have to interop with the rest of the network.

well, time's going by, I have no solutions to "customers down" or wanting on now... And a chunk of money sitting here in bubble and foil wrap I can't use. And nothing left in the bank. For which I guess, I am an ingrate.

Sigh.

[lonnie]

Super features are gone in the new driver.

Why do you assume your backhaul won't work?

[lonnie]

Super features do give a boost to "some" traffic, but in today's Internet most of what goes across is already compressed.

The new driver has higher performance, and even though it has lower numbers due to lack of compression, it actually outperforms the older systems.

[lonnie]

Sorry, maybe it was a tough day and I'm cranky.

It is not just the remarks of one guy though, it is all of the reports that 1.5 has problems with 1.3.23b. We KNOW that and I say to update to 1.4.22r or better yet the latest 1.5 and still guys will report problems from 1.3.23b AP.

Give us reports of 1.5 to 1.5 problems and we'll do whatever we can to fix it.

The 1.5.10 will be very soon, so for all those waiting, perhaps that will be the release to turn the tide and get all that old firmware upgraded.

Lonnie,

Please do not lump me, and I assume a lot of others in with, "you guys" all together, based upon the remarks of one person.

I for one, appreciate all the effort to support the older hardware with current firmware releases.

And I do not believe, that you are wasting your time.

Thank you.

[go.fast]

I've been using 1.5.9b clients with success on my 1.3.23 ap's.
These days when I am installing a new sub or replacing a bad board, I try war1a 1.5.9b 1st to see if it works.
Only a couple times have I had to use a war1 with 1.3.23b instead.
I also have a couple xr9 war1 1.5.9b talking nicely to a 1.3.23 ap.

So the mismatch between 1.3.23 and 1.5.9b is not too much of a problem.
I be moving ap's over to 1.5.managed mode when it comes out, which sounds pretty soon.

I also want to point out that the vast majority of my 1.5.9 cpe's are easy close shots that should not have any problems.
Have yet to try it on a difficult situation.

[mrmike]

Mark, I don't blame you. I set up 2 APs with 1.5.9; one with 2 xr9 radios and a link, and 1 with 32 clients. The link went from 15M throughput to less than 1, and it doesn't matther what I do. Right now it is on 1x, as 2x and 4x don't pass traffic very well. The customers go from connected to not connected, they have an IP but they can't be pinged.
The link is at -75, most customers are at least -80 or better, and if it doesn't improve today, it's all going back to 1.3.23. Lonnie looked at the 1 AP a couple of weeks ago, and tweeked it a bit, but about 2 days later, everything kind of stopped.
I'm at a loss. I have 1300+ clients, all star-os, and I'm running out of spares. These clients, especially the 2.4 that are in plain site of the AP, that's 6 miles out of town, don't want to connect properly.
I'm loyal to a fault. I will not contemplate changes until I hit a breaking point, but this is pushing it. I'm awfully glad I'm not expanding this year.

[SpecialK]

Lonnie,

I would love to upgrade to 1.5.x

Simple truth is it does not work for me.

I have 1.4.22r on several APs working ok.
I put 1.5.9 on them and lose people, some work like real crap, and brand U will not connect with WEP turned on as others have reported.

If I could get by these obstacles, and at least get my cpe to associate so I could start changing settings I would try it.
And the only reason for brand U is that for quite a while you had no product to sell us. You can't tell customers we have no idea when we can install you.

Also, it seems crazy to purchase equipment that is not MIMO or has an upgrade path to MIMO. I know you are working on the driver OK good.
Where is the MIMO hardware?
I see and hear no mention of it.
You don't want to tip your hat to the competition I understand.
And the track record does not show me anything to be excited about.
So even if you get MIMO driver working we will have to wait months and months for a hardware option.

[lonnie]

Is there any chance you did not login and save settings? I told you I would leave that task to you, so if you had a power bump 2 days later it would all go back to the way it was.

Mark, I don't blame you. I set up 2 APs with 1.5.9; one with 2 xr9 radios and a link, and 1 with 32 clients. The link went from 15M throughput to less than 1, and it doesn't matther what I do. Right now it is on 1x, as 2x and 4x don't pass traffic very well. The customers go from connected to not connected, they have an IP but they can't be pinged.
The link is at -75, most customers are at least -80 or better, and if it doesn't improve today, it's all going back to 1.3.23. Lonnie looked at the 1 AP a couple of weeks ago, and tweeked it a bit, but about 2 days later, everything kind of stopped.
I'm at a loss. I have 1300+ clients, all star-os, and I'm running out of spares. These clients, especially the 2.4 that are in plain site of the AP, that's 6 miles out of town, don't want to connect properly.
I'm loyal to a fault. I will not contemplate changes until I hit a breaking point, but this is pushing it. I'm awfully glad I'm not expanding this year.

[mrmike]

All settings saved at the time. I think I have spent 5 hours just on the link I got that link to finally give me 5 megs throughput last night, but this morning it's back to less that 1 meg

[lonnie]

When we could only offer WEP all we ever heard was that WEP is no good. Now we have WPA, so why not use it?

MIMO hardware is everywhere. There are many companies selling Atheros MIMO cards. People have antennas for sale. The War1a has the performance to utilize the speeds. I'd say you don't have long to wait once we have the firmware.

I've said before, but it is worth repeating ..... When you encounter an issue with the new firmware, send Tony and I a PM with login details. The time zones are roughly 12 hours apart, so 11:00 AM in Central USA is 11:00 PM here. Tony and/or I are typically monitoring the Forums from 8:00 AM until nearly midnite our time. We need to see these things misbehaving so we can find and fix the issue. Obviously we have not released code that we knew had an issue. When we find or duplicate something we fix it.

Lonnie,

I would love to upgrade to 1.5.x

Simple truth is it does not work for me.

I have 1.4.22r on several APs working ok.
I put 1.5.9 on them and lose people, some work like real crap, and brand U will not connect with WEP turned on as others have reported.

If I could get by these obstacles, and at least get my cpe to associate so I could start changing settings I would try it.
And the only reason for brand U is that for quite a while you had no product to sell us. You can't tell customers we have no idea when we can install you.

Also, it seems crazy to purchase equipment that is not MIMO or has an upgrade path to MIMO. I know you are working on the driver OK good.
Where is the MIMO hardware?
I see and hear no mention of it.
You don't want to tip your hat to the competition I understand.
And the track record does not show me anything to be excited about.
So even if you get MIMO driver working we will have to wait months and months for a hardware option.

[SpecialK]

Lonnie,

I will try it again.

I do not want to run with WEP but I had to in 1.4.x.
Now I would need to get 1.5 on everything before I can change to WPA.
As soon as I can get the brand U cpe to connect I will try again.
The other reason is that I tried 1.5.6 and newer and the cpe were so bad that I had to revert back.
So if I change to WPA and then have to revert back I am screwed and have to change all back to WEP again. Even with only 14 or so cpe on a test AP it takes quite a while.

[DrLove73]

Again, I wasn't expecting miracles, but saying "from x to x isn't the best" isn't very informative. I had no idea that the "super" features weren't working. I didn't read that anywhere. Our 900 systems depend on them to have any kind of performance at all.

Perhaps we need a little clarity... Are the "super" features permanently gone?
Missing SuperA/G featuries WERE discussed, NUMBER of times. I am surprised that you missed it if you followed every post on forums. These are the ones I found on the first page of release note threads:

http://forums.star-os.com/showpost.php?p=72781&postcount=1
http://forums.star-os.com/showpost.php?p=72729&postcount=8
http://forums.star-os.com/showpost.php?p=72730&postcount=9
http://forums.star-os.com/showpost.php?p=73569&postcount=8

And it was clearly stated that performance hit was negligible, so something else was at work on your setup.All you/we need to do is to find what and fix it.

And I would suggest that this argument is postponed until 1.5.10b sees the light of the day.

Guys, there is large possibility that managed mode and other improvements, and fixes like for WPA bug, will make it possible to use it as equal replacement for 1.3.23b and 1.4.22r. You can all wait several more days without non-productive complaining (things that should be fixed or added in 1.5.10b, excluding reports or access to units for Lonnie and Tony).

As for Lonnie, forgive me, and do not get me the wrong way, but there are still few show-stoppers or uncomfortable things in 1.5.9b for wider testing or full replacement/upgrade on LIVE networks, so I think the best thing to do for you would be to refrain few more days from taunting (or be taunted) the rest of the members until we get to test 1.5.10b.

I am only writing this since majority of stuff being so feverishly argued should be fixed in upcoming release, and in my book all this heated discussion is just pissing up wind for no reason, for both sides.

[Mark]

Super features are gone in the new driver.

Why do you assume your backhaul won't work?

for this reason: "super features are gone..."

It's 18 miles, has trees and ground fresnel encroachment, and operates over constantly shifting temperatures/air currents over a mountainside slope so RXSL is all over the map at times. Despite the fact it often runs at 6,9,12 mbps according to the display, it semi-adequately feeds 19 customers. Lose the "super" features and I"ve got a link that will move... errr... 3 mbit, maybe? I routinely see it move 600 to 900KB without terrible latency. YOu gonna try to tell me that without "super" features I'll get MORE throughput? How?

Sure, the new routes in and backhaul will cure it, but that's another month or two till I can get a tower climber.

BTW, I installed "a" customer today. Was a 300 kbit bandwidth customer. At -73 RXSL and 10 mhz channel using XR9, it was 40 percent ping loss and slowed to less than measurable throughput after being connected for about 1 to 2 min. Repeatedly, I could connect, it would work for 1 to 2 min and then it would simply slow to a stop and never restart while rates flickered all over between 48 and 1. I tried all combinations of settings, nothing was better than just defaults. I finally got it connected to the other AP @ 5 mhz channel and it at least moves enough to keep up with 300kbit. Q never fell lower than 91 during all this.

Should not be any noise. This is way out in the boonies and surrounded by trees and hills, and 400 feet from another customer that works flawlessly, but who is lower down and has more trees in the way.

[Mark]

Sorry, maybe it was a tough day and I'm cranky.

It is not just the remarks of one guy though, it is all of the reports that 1.5 has problems with 1.3.23b. We KNOW that and I say to update to 1.4.22r or better yet the latest 1.5 and still guys will report problems from 1.3.23b AP.

Give us reports of 1.5 to 1.5 problems and we'll do whatever we can to fix it.

The 1.5.10 will be very soon, so for all those waiting, perhaps that will be the release to turn the tide and get all that old firmware upgraded.

But 1.4.22r doesn't work for spit either. It has all sorts of headaches with "spiraling death" syndrome where the rates shoot up, latency goes into the seconds, and data moves at about 3 kbps for a while and then mysteriously resumes. This is seriuosly bad in turbo mode. It has serious ping loss in at least some P2MP situations and is utterly unworkable for XR9's, won't pass data hardly at all except in the highest signal levels, like in 50's or very low 60's.

I do have some P2P links using 1.4.22r, since in certain p2p situations, where there isn't any noise, it will move more data than 1.3.23b will. I've got hours and hours of experimentation and testing... more like DAYS of it where I sat hunched over my desk till dawn so I could do the testing while few people were on.

I don't have any dream to repeat those days again, so, no, I'm not going to. I've had my fill of 1.4.22r.

[Mark]

Missing SuperA/G featuries WERE discussed, NUMBER of times. I am surprised that you missed it if you followed every post on forums. These are the ones I found on the first page of release note threads:

http://forums.star-os.com/showpost.php?p=72781&postcount=1
http://forums.star-os.com/showpost.php?p=72729&postcount=8
http://forums.star-os.com/showpost.php?p=72730&postcount=9
http://forums.star-os.com/showpost.php?p=73569&postcount=8

And it was clearly stated that performance hit was negligible, so something else was at work on your setup.All you/we need to do is to find what and fix it.

And I would suggest that this argument is postponed until 1.5.10b sees the light of the day.

Guys, there is large possibility that managed mode and other improvements, and fixes like for WPA bug, will make it possible to use it as equal replacement for 1.3.23b and 1.4.22r. You can all wait several more days without non-productive complaining (things that should be fixed or added in 1.5.10b, excluding reports or access to units for Lonnie and Tony).

As for Lonnie, forgive me, and do not get me the wrong way, but there are still few show-stoppers or uncomfortable things in 1.5.9b for wider testing or full replacement/upgrade on LIVE networks, so I think the best thing to do for you would be to refrain few more days from taunting (or be taunted) the rest of the members until we get to test 1.5.10b.

I am only writing this since majority of stuff being so feverishly argued should be fixed in upcoming release, and in my book all this heated discussion is just pissing up wind for no reason, for both sides.

You're way off track here. What's going to happen is that we're going to have to wait until MIMO is implemented and then try that. Despite the fact that 2.4 MIMO antennas are pretty much constructed of 90 percent unobtainium and 5 ghz MIMO antennas are just backordered into the foreseeable future, we'll somehow get to see how it does. If I can wait that long, that is.

I can't imagine what a disaster it would be to try to change out all the deployed radio cards after updating to non-super A or B or G modes and then eventually doing a middle of the night switch to N single chain.

It has the look and sound of customers leaving in droves, so, no I'm not going to try that.

Frankly, I'm waiting to see if I can use StarOS MIMO AP's and brand U clients, since thier dual chain clients are LESS than the price of just the antennas you can find listed ( but are not available because they're all sold out). That wasn't my original plan, and even that may not be workable, since nobody has breathed a word about anything being FCC legal yet. No radios I can find to buy are advertised as being certified with the antennas we can find.

I started with CM9's, and no, they weren't "legal", but then nothing was you built yourself. The FCC changed policy subtley and then modullar certification became the means by which we became legal, and from that moment I've used nothing but FCC legal combinations.

The software issues are only the first 20 feet of a 100 food bridge, and right now, that's the only part of the bridge that exists.

[DrLove73]

You're way off track here. What's going to happen is that we're going to have to wait until MIMO is implemented and then try that. Despite the fact that 2.4 MIMO antennas are pretty much constructed of 90 percent unobtainium and 5 ghz MIMO antennas are just backordered into the foreseeable future, we'll somehow get to see how it does. If I can wait that long, that is.

Having 11n driver and card is not just about MIMO antennas. The ISP company that I get my bandwidth from installed pair of UBNT Rocket's (11n on 5GHz) on a 30Km link to my location (I also gave them my place for hop for their network to other towns) and only way they were able to make them anywhere near reliable is using unused frequencies. Speed they got ranged from 1-30Mbps on speedtest net web site. Antenna they used as far as I can see is regular U brand Dual polarity.

I have used/tested 1.5.9b and where it has not created problems, some links worked, others have not:
- due to missing max rate for problematic link and insane attempt to get much higher rates with lot of interference
- Missing managed mode made it impossible to do fast searches for available frequencies when I had those problems.
- Missing MAC address ACL made it impossible to block offending unknown MAC address that crashed one of my AP's 3 seconds after it tried to connect (or do something wierd I have not figured out), continuing for several hours until I figured out what is happening.

On my office link, main one, I used 11a Turbo mode with -68 signal and 1.5.9b worked like a charm, I never noticed a difference in speed.

I can't imagine what a disaster it would be to try to change out all the deployed radio cards after updating to non-super A or B or G modes and then eventually doing a middle of the night switch to N single chain.

It has the look and sound of customers leaving in droves, so, no I'm not going to try that.

Why would you want to do that? Once 11n driver is activated, 1.5.x will support both 11a/b/g and 11n radios in the same unit, so all you will be required to do is to prepare (in software settings) for the change of radios if necessary, and to swap them. They will/should work together with different type of the radio on the other end.

Also, if you want to avoid downtime, you will just prepare another unit with 11n radios in them and swap units, or prepare backup/temp unit (with same config and radios) you will hook up to antennas on site while you work on unit on site. Once you swap unit/radios, you will be able to swap regular antenna for MIMO when you feel like it. Or just use 1-2 dualpol antennas for 2x2 MIMO link.

IEEE 802.11n-2009 is an amendment to the IEEE 802.11-2007 (http://en.wikipedia.org/wiki/IEEE_802.11-2007) wireless networking (http://en.wikipedia.org/wiki/Wireless_network) standard to improve network throughput over the two previous standards — 802.11a (http://en.wikipedia.org/wiki/802.11a) and 802.11g (http://en.wikipedia.org/wiki/802.11g) — with a significant increase in the maximum raw data rate (http://en.wikipedia.org/wiki/Bit_rate) from 54 Mbit/s to 600 Mbit/s with the use of four spatial streams at a channel width of 40 MHz.[1] (http://en.wikipedia.org/wiki/IEEE_802.11n-2009#cite_note-0)[2] (http://en.wikipedia.org/wiki/IEEE_802.11n-2009#cite_note-802.11-2009-1)
EEE 802.11n is an amendment to IEEE 802.11-2007 as amended by IEEE 802.11k-2008 (http://en.wikipedia.org/wiki/IEEE_802.11k-2008), IEEE 802.11r-2008 (http://en.wikipedia.org/wiki/IEEE_802.11r-2008), IEEE 802.11y-2008 (http://en.wikipedia.org/wiki/IEEE_802.11y-2008), and IEEE 802.11w-2009 (http://en.wikipedia.org/wiki/IEEE_802.11w-2009), and builds on previous 802.11 standards by adding multiple-input multiple-output (http://en.wikipedia.org/wiki/Multiple-input_multiple-output) (MIMO) and 40 MHz channels to the PHY (physical layer) (http://en.wikipedia.org/wiki/Physical_layer), and frame aggregation (http://en.wikipedia.org/wiki/Frame_aggregation) to the MAC layer (http://en.wikipedia.org/wiki/MAC_layer).Frame aggregation is a feature of the IEEE 802.11e (http://en.wikipedia.org/wiki/802.11e) and 802.11n (http://en.wikipedia.org/wiki/802.11n) wireless LAN standards that increases throughput by sending two or more data frames in a single transmission.
Every frame transmitted by an 802.11 device has a significant amount of overhead, including radio level headers, media access control (http://en.wikipedia.org/wiki/Media_access_control) (MAC) frame fields, interframe spacing, and acknowledgment of transmitted frames. At the highest data rates, this overhead can consume more bandwidth than the payload data frame.[1] (http://en.wikipedia.org/wiki/Frame_aggregation#cite_note-cisco-0) To address this issue, the draft 802.11n standard defines two types of frame aggregation: Mac Service Data Unit (MSDU) aggregation and Message Protocol Data Unit (MPDU) aggregation. Both types group several data frames into one large frame. Because management information needs to be specified only once per frame, the ratio of payload data to the total volume of data is higher, allowing higher throughput.As you can see, even 11a/b/g with those implementations could acquire grater throughtput, and since compression adds overhead to RPU (radio procesing unit) of radio card, removing it will allow faster data transmition and higher throughtput of compressed data since most things are zipped/archived with much higher ratio on much more powerful PC CPU's.


I do not see why you would make such dramatic performance like world is going to end, except to be consistent with past posts. Save the drama for 2025-2030 when world oil production drops to 20-30% of current level and prices of oil go through the roof so no one will be able to pay for them, and 70-90% of human population disappears because there is not enough food to go around.

[mike]

Having 11n driver and card is not just about MIMO antennas. The ISP company that I get my bandwidth from installed pair of UBNT Rocket's (11n on 5GHz) on a 30Km link to my location (I also gave them my place for hop for their network to other towns) and only way they were able to make them anywhere near reliable is using unused frequencies. Speed they got ranged from 1-30Mbps on speedtest net web site. Antenna they used as far as I can see is regular U brand Dual polarity.

I don't want to talk about other product on Star forum, but you should try a product before writing about them. Ubnt have a lot of thing I hate but performance isn't one of them.

[DrLove73]

I was next to the installer sent to fix failing link. He was frustrated as well, wishing they would let him use MT (he never used StarOS). I used my own notebook, next to his, in speed testing. So everything I said is true.

But point was not if their product works better or worse. The point was that you can use regular dualpolarity antennas, or even 2-3 regular antennas to create MIMO (multiple streams IN, multiple streams OUT). You just hook them on one 11n radio and you have MIMO system. I guess 3-polarity antenna (180 degrees like tripod) on one dish would be enough to have good MIMO antenna.

And that throughtput gain is not about special MIMO antennas, but in legalizing 40MHz channels (Turbo) on each frequency, using multiple streams/antenna ports simultaneously, and compacting more datagrams in single radio package.

[rbolduc]

Having 11n driver and card is not just about MIMO antennas. The ISP company that I get my bandwidth from installed pair of UBNT Rocket's (11n on 5GHz) on a 30Km link to my location (I also gave them my place for hop for their network to other towns) and only way they were able to make them anywhere near reliable is using unused frequencies. Speed they got ranged from 1-30Mbps on speedtest net web site. Antenna they used as far as I can see is regular U brand Dual polarity.



So what was the final fix? a channel change to a clear one? or are you saying they used illegal frequencies?


On another tangent...

I have a star 5ghz (war4 533) and a cheap U nano Bridge link about 4' separated vertically on a tower going back to my NOC Getting 2600K tops over the Star and 3900K over the U. for less than $200usd to my door. The star was running latest beta and quality is all over the place, back to 1.4.22 is much better with quality. Both links are 10Mhz.. Star with MIMO would be great but sometime before the newest/faster/better/hotter setup comes out into the world, we are on over 2 years now on a good working driver and as of today no full blown N Star anything, I have bought licenses to upgrade to play and end up going back to the old stuff so that's $$ down the drain

untill then I have to wait and use other products that are undoubtedly inferior but walk all over star in terms of performance\pricing\availability. Someday the old valemount will be back I hope and Ill be here waiting for the next Cadillac of systems is ironed out and released not a yugo with a Cadillac sticker on it

Reed

[rafamous]

I have experienced the 60 to 120 second window for the XR9 to work and then die with this version.

Maybe a clue of what's going on. Stay encouraged guys. Screw the naysayer.

[DrLove73]

The other thing you mentioned. Only thing that worked on that stretch, and even then there was need to change channel or whatever now and then. I think there are my posts dating to 2006/2007 where I whined about my old upstrem ISP having problems on the basicaly the same link direction. During the evening and night gremlins come out to play I guess. Niether Madwifi, nor MT nor U are able to repel them.

I am in same boat with you guys, I also need stable driver without problems. 1.5.x shows real promise, waiting several more days for new one.

About Yugo, since it was built in my country.... Before. that crap we had Zastava 101 (http://www.eatliver.com/i.php?n=2817), a copy of Fiat 128. An 10 year old car was still more robust than brand new Yugo. Factory now belongs to Fiat, they are producing Fiat Punto for EU market, and they might be moving their production of some models from Torino here. No more Yugo, yeahhh :D (I drive Renault 4 GTL, conqueror of time ;)).

[rbolduc]

I have experienced the 60 to 120 second window for the XR9 to work and then die with this version.

Maybe a clue of what's going on. Stay encouraged guys. Screw the naysayer.


I agree Encouraged is great way to keep motivation and get the driver right.. but its sad to see no real improvements in a while, if you were a brand new customer downloaded the beta to try and saw all the problems then what would you say? go down to a release version? oh that does not work on the war1a sorry guess ill stack these in the corner for now.

I am just to use to spending money on stuff that works or at least had a larger test bed of users, not $$ to be in a ongoing beta program at my customers expense.. I know I know take my dribble elsewhere I get it, no discouraging comments, no criticism. All rainbows and puppys here must have forgot my happy pill today.

[rbolduc]

About Yugo, since it was built in my country.... Before. that crap we had Zastava 101 (http://www.eatliver.com/i.php?n=2817), a copy of Fiat 128. An 10 year old car was still more robust than brand new Yugo. Factory now belongs to Fiat, they are producing Fiat Punto for EU market, and they might be moving their production of some models from Torino here. No more Yugo, yeahhh :D (I drive Renault 4 GTL, conqueror of time ;)).

I Remember wanting a yugo when I was in 6th grade I thought it was such a neat looking car, but of course I also wanted a v8 engine in it :-0

[rafamous]

LOL :)

Maybe we need to get Valemont another network so they can do trench testing again. :p

I wish I could give them a log in when I'm testing but it's always fire on the behind at that moment if ya know what I mean.

[rbolduc]

LOL :)

Maybe we need to get Valemont another network so they can do trench testing again. :p

I wish I could give them a log in when I'm testing but it's always fire on the behind at that moment if ya know what I mean.

I know the feeling god forbid if someone can't get onto facebook or yahoo messenger for 5 min while I do a test..and I thought that was from all the Tabasco I ate ;)

[tony]

The star was running latest beta and quality is all over the place, back to 1.4.22 is much better with quality. Both links are 10Mhz..

As a note to all. The 1.5.x quality score cannot be directly compared to the 1.4.x releases, as they are calculated via different means. The 1.4.x shows the score based on error rates of the rate you are on, while 1.5.x also takes into account the signal level, so if you have a low signal, you will also have a lower quality score. The quality score is only provided for informational purposes, and is not in any way tied to how the system performs overall.

[ninedd]

Guys - first, I'm not wanting to sounds like a StarOS ''Cheerleader''. Lonnie and I have had differences, and I often don't agree with all their decisions, BUT, I also dont want to pick on them for things that are not their fault. Let's all remember where the current situation stems from:

1) The MIPS CPU's were (suddenly) EOL.
2) That meant that board manufacturers (Compex) had to get different CPU's
3) That meant that software vendors (StarOS) had to totally re-write their OS's.
4) That meant that we all had to wait for working hardware/software solutions.

I do certainly feel and understand everyone's pain. The lack of stock for me was the biggest problem. I don't mind 1/2 finished stuff in a pinch, but not being able to get anything at all for month's on end, that was nearly fatal to our 100% StarOS (in 2.4ghz) goal. It's got ZERO to do with cheaper, fancier, slicker, etc... it simply had to do with AVAILABLE for a while! I totally agree, that if StarOS wants to be in the hardware manufacturing business, then they need to be in the hardware manufacturing business and need to have product in distribution chains ALL the time. I do trust that when this whole deal is over, that we will have a good supply of StarHardware again. :)

SO - Let's try to separate the real issues that they are 'guilty' of, and the ones that have been forced on them because of the MIPS CPU's Discontinuance is all I'm saying. It's frustrating for us, and it's frustrating for them I'm certain. :) We are all on the same side, and frankly, I can't tell you how excited I am to maybe be just weeks/month's away from having the same OS across the whole network! When Motorolla comes out with a new Firmware, we apply it across the whole Canopy network without having a mix-match and that's wonderful. When we can finally apply 1.5.10 or .11 or .whatever across our whole network and have it work everywhere, that'll be wonderful. For one, I applaud them getting 1.5 on all the legacy hardware - that's a REMARKABLE thing.

Maybe we need to get Valemont another network so they can do trench testing again. :pI agree. That is troubling for me to - now that they don't have a WISP that they can real-world test things in, that would seem to be a problem for debugging. However, that also means they rely on US to give them good, detailed reports, and logins. Reports like "didn't work no matter what I tried" don't really help, and reports that are overly negative because of 6 month's of frustration don't help. Again, I feel everyones pain - I've got installers & managers about ready to quit - but we need to a) understand where the current crisis comes from and b) understand that Lonnie/Tony and us are all on the same side. :)

- Todd

[Mark]

news you can use. By changing the XR9 card to "b/g" instead of "g only", I got some relatively stable behavior. By that, I mean, it passes packets and continues to do so.

Client end display:
wpci1: atheros 89 -75dbm -95dbm 1 2442 sta,US,x2 00:15:6d:94:0c:3b

AP end display:

customer 77:60 120.141 0 -85 1 9 **** 0 0 0s

It's still passing packets and will reliably feed the 400kbps the client's set for.

[Mark]

Guys, I think we're overlooking a few things here..

1. I never asked Lonnie to do anything but say "It won't work with your legacy stuff". That's it. No demands for changes to the driver or features or blah. They're going to have to make the run for the future goal now, and skip the intermediate steps. My opinion, at least.

2. It's unfortunate that both a cpu shortage and a generational change in wireless protocols had to occur at the same time. None of this is Lonnies or Tony's fault, ain't nobody's "fault", really.

As for my backhaul not working? I already did bench test between my old AP version and the new version, and throughput... .is horrible. So, no, i can't switch this ONE site to the new version. The feed to it won't work. Again, we're just plain hosed on interoperability. This, however, is NOT unique to Star-OS, as everyone else is having the same pains and meeting them with variable success, again, nothing new or unexpected here.

I'm just ticked because I bought some WAR1a's and I have no present use for them, because I didn't think that the term "doesn't work the greatest" meant something along the lines of "really is totally unacceptable".

Presumeably, the newest generation talks acceptably to itself, with acceptable behavior. I just don't have any use for that right now.

Right at this moment, if I were in Lonnies shoes... this is what ** I ** would do: Suspend features and cosmetics upgrades, go directly for "good functioning MIMO" and the ability to do greenfield deployments, as in "good interference rejection". Even if that means killing CSMA off totally and going for some kind of round robin monopoly prevention / prioritization.

Then, addressing the lack of MIMO hardware and FCC certification issues. Even if the software becomes astoundingly awesome, it won't matter if we can't find antennas and radios and it'll be even worse if a MIMO client is near $300. We'll have a great product without a market to buy it.

[ninedd]

Hi Mark,

Just for clarily - that 'b/g mix' change on what side of the link? Or both sides? This is a 1.3.23b AP and a 1.5.9b (SIAM) CPE, correct?

[Mark]

Hi Mark,

Just for clarily - that 'b/g mix' change on what side of the link? Or both sides? This is a 1.3.23b AP and a 1.5.9b (SIAM) CPE, correct?

Yeah. The b/g mix is on the client end, not AP.

edit: forgot to add that staros speed test shows 40KB/sec throughput, max. On a 10 mhz channel.

[ninedd]

Hmmmm. Well, our XR9 to XR9 tests from SIAM (1.5.9b) boards show MUCH better results for some reason. As has been said by Lonnie/Tony, we have had poorer results with 1.3 to 1.5 than other firware mixtures, however, for us, it hasn't been a total deal-breaker. We have 1.5.9b SIAM boards running XR9's connecting to both 1.4.22r and 1.3.23b AP's.

From a 1.4.22r AP (METRO) to a WAR1A (SIAM), these are our Results:
Built-in Throughput Test running from CPE, RXing (Downloading) from AP.

AP : Metro XR9 1.4.22r - Capped at Various Rates
CPE: SIAM XR9 1.5.9b - AUTO @ 48Mbit (-52 Signal)

AP TX 4x 2x
18Mbit 367KB 707KB
24Mbit 463KB 906KB
36Mbit 609KB 1182KB
48Mbit 732KB 1394KB

From a 1.3.23b AP (METRO) to a WAR1A (SIAM), these are our Results:
Built-in Throughput Test running from CPE, RXing (Downloading) from AP.

AP : Metro XR9 1.3.23b - Capped at 18 & 24Mbit
CPE: SIAM XR9 1.5.9b - Fixed at 12Mbit (-77 Signal)

AP TX 4x 2x
18Mbit N/A 247KB
24Mbit N/A 420KB

I didn't test this AP to too many speed/cloaking combinations, or from
any other CPEs with a better signal, because there are 12 clients on
the OMNI and they are active during these tests.

As I say, we have 1.5.9b SIAM boards connecting to both 1.4.22r and 1.3.23b AP's that are working well enough for us to connect customers, while we wait for a 1.5.x that we can install accross our whole network.

[mlarsen]

Long time no post. :^)

One of my consulting clients uses a lot of 900mhz StarOS with XR9 cards. We had poor results with the 1.4.x series of firmware, so we stuck with 1.3.23b.

One of his APs lost all of its clients on Tuesday, for no apparent reason. After a lot of messing around with it, I concluded that it was definitely interference, and appeared to be bad enough that it could take all of the clients down with it. About noon on Wednesday, clients came back up. Thursday morning, they were up and down all morning. Looked like pretty obvious interference, but it was hard to tell without a built-in spectrum analyzer.

With nothing to lose, we decided to try out the 1.5.9 firmware. It was a challenge to get it loaded, and we had to disable the other AP on this tower and move to its channel to get all of the radios associated, but finally got CPEs and AP moved to 1.5.9.

After spending a couple of hours trolling the StarOS forums, I finally found the settings that made the problem sector run like a top.

Here is what turned things around:

1) Upgrade firmware on CPEs and AP to 1.5.9b.s.
2) Set the Transmit Rate to “auto” on all APs and CPEs
3) Turn on “NoiseBuster” on the AP
4) Turn on “Enable ANI” and “Noise Buster” on the CPE units (do not use “Enable ANI” on the APs)

I finally got all of these settings into the CPE units and I dropped it from 2x cloaking back into 4x cloaking. Here are the results for each customer on the AP:

Armstrong is at a -81, and is not working great, but it is passing traffic at an average of 384K with some dropouts – 50% loss with 1500 byte packets.

Foley was essentially worthless before, -88 signal and was dropping about 95% of large ping (1500byte) traffic. After all of these settings were adjusted, Foley settled in with a -81 signal, and only dropped 8% of large ping traffic while running a speed test with an average of 512Kb. Not perfect, but a hell of a lot better than what it was seeing before.

Bluthardt is at -78, passes 1meg on the speed test and dropped 20% of large packets.

Ziegler is at -78, passes about 512kb on the speed test and dropped 34% of large packets.

Gooding is a -70, passes 2meg on the speed test and dropped 1% of large packets.

Burrill has a -63 signal, and they did not drop ANY 1500 byte packets and it was passing 1.5meg average during a speed test.

Conclusions:

1) 1.5.9 is excellent firmware and looks to be stable enough for use on the 900mhz aps
2) Signals of -80 are borderline unusable, -75 to -80 are usable for slower speeds, -74 and better should allow full performance (up to 2meg with 4x cloaking)
3) Noise Buster mode and “Enable ANI” on the CPEs does appear to help quite a bit.

I’d like to see how it handles interference during the day, but 1.5.9 and the noisebuster settings took this AP from useless to usable.

Hope that helps!

Matt Larsen
vistabeam.com

[ninedd]

Most excellent post, dude!

[lonnie]

Thanks Matt. Tony has worked out some tweaks that will be even better cloaking.

Did you also use the high threshold on the AP? We feel that is a very good way to get rid of interference from the other AP's on the tower.

[Mark]

update... Unless there's a ping running steady, the system still loses connection. So, changed back to the 5 mhz channel (X4) access point and running in B/G mode and we seem relatively stable. it even reports the right speed to the AP. Throughput is 240KB/sec, which is pathetic, but since it's a 300kbit customer, that will work.

Seems to be an issue with X2 cloaking.

[DrLove73]

Mark, do you by any chance have WDS (bridged wpci1 and ether1 on the CPE) active?

[Mark]

Mark, do you by any chance have WDS (bridged wpci1 and ether1 on the CPE) active?

Nope. I do NAT on the CPE. Everyone's routed, I don't use bridging.

[deano]

Mark,

Does the connection drop occur with any consistency, after a set amount of time? is ping watchdog on?

[Mark]

I've got the ping watchdog on, and am pinging it every 20 seconds from outside the area. So far, I am getting 92% success pinging, b ut it appears many of the "missed" pings are merely long - like 70, 90 or 200 ms, even though the other clients on the AP dont' have this behavior.

I started a ping from the AP to the client, and have noticed that as long as there's a constant ping (every second or so) the client seems to remain active and working.

[Mark]

Mark,

Does the connection drop occur with any consistency, after a set amount of time? is ping watchdog on?

If the pings are 10 seconds apart, it will lose connectivity and the customer can't regain it.

Steady ping from the AP to the client @1400 byte ping, and connectivity is unbroken. the "magic" time for this client, at least is less than 10 seconds, or it falls off. And how it falls off is that it passes ever smaller packets until it passes nothing, and then some reset happens, and pings restart.

[ninedd]

Throughput is 240KB/sec, which is pathetic, but since it's a 300kbit customer, that will work.Hi Mark, if I read back correctly, this is a client with a -75 signal on his end, and a -85 signal on the AP side, correct? If I decypher the info you posted correctly, you're seeing a 9Mbit radio rate, correct?

If that is all correct, 9Mbit @ 20Mhz, is like 4.5Mbit @ 10Mhz, which is like 2.25Mbit at 5Mhz - and that's the total Raw Signalling rate, your TCP/IP rate will be considerably less than that.

Also, I'm confused a bit on the two numbers you posted....

-> Throughput is 240KB/sec, which is pathetic, but since it's a 300kbit customer

...because 240KB/second is typical for about a 2,000kbit connection.

[DrLove73]

...because 240KB/second is typical for about a 2,000kbit connection.
And since there is no compression, on 1.3x or 1.4x on the CPE that would correspond to 400-600KB/s of the built-in test, right?

And that times 4 (for x1 connection) would be 1600-2000KB/s on the built-in test. Am I correct?

[tog]

I would use 1.5.x on both ends, not 1.3.23b on the AP side. I think it has already been mentioned more than a few times that 1.3.x and 1.5.x compatibility isn't optimal.

I'm still using 1.4.22r everywhere myself except on the WAR1a/SIAM CPE. Even on the couple of not-very-well-liked XR9 APs we have we are using 1.4.22r.

[Mark]

I tried the 1.4.22 for 900 use and after immense grief finally got my clients back to the 1.3.23b and have never had any wish to slash my wrists again.

I can't move this to 1.5.x because the backhaul is in the same box and that backhaul will have to talk to a 1.3.23b on the other end, and my experimentation showed that is a no-go as well. This is simply a chasm you can't leap in two bounds, and worse than that, some of my clients are UBNT and that REALLY doesn't like 1.5.x at all. ( meaning I can't do the whole network, for absolutely sure)

Frankly, I'm just screwed. I'm sending the customer his check back. So far this experiment has cost me more than a day of my time, about 900 bucks, and enough stress to last me months. And, of course, this customer is the pickiest, crankiest, nastiest I've ever dealt with. They've already filed complaints against me with the BBB, and nasty emails and whatnot. And that's BEFORE I got the equipment up in the air.

So, I'm telling them I just can't do this.

Cut my losses and run.

[Mark]

I would use 1.5.x on both ends, not 1.3.23b on the AP side. I think it has already been mentioned more than a few times that 1.3.x and 1.5.x compatibility isn't optimal.



I didn't ask for "optimal". I simply assumed that "not optimal" meant that it actually worked in some fashion, which it does NOT.

If I reboot the thing, it works for about 1 to 5 min, and then it simply falls apart, with 70 percent ping loss or higher. Obviously, not workable.

[lonnie]

Mark, you resist the advice given, so all you have left to do is complain. We cannot help you until you have a problem report with 1.5 to 1.5 firmware. The 1.3 and 1.4 are EOL and are not maintained. The best mixed firmware results are 1.4 to 1.5. We only work on the 1.5 series and perhaps you should take another serious look at 1.5.10 when it is released shortly. It will have managed mode to allow easier playing with configs over a whole system and some cloaking tweaks, rate capping and the "missing" extended 2.4 channels.

As for the UB clients limiting your upgrade choices, well ......., what can I say? We are not at the point yet of porting any other hardware. The driver is taking way longer than anticipated, but each release is improving.

[ninedd]

I tried the 1.4.22 for 900 use and after immense grief finally got my clients back to the 1.3.23b and have never had any wish to slash my wrists again.You know, we never really gave 1.4.22r on 900 much of a try until just recently when we figured we HAD to try it with 1.5.9b clients. As I posted before, we DO have some 1.5.9b clients on 1.3.23b AP's, but they are persnickety and much lower performing that 1.3-1.4 or 1.4-1.5 links, so we recently gave 1.4.22r to 1.5.9b links another try in 900Mhz, and had some most surprisingly good results.

I can't move this to 1.5.x because the backhaul is in the same box and that backhaul will have to talk to a 1.3.23b on the other end, and my experimentation showed that is a no-go as well. This is simply a chasm you can't leap in two bounds...Well, I can tell you after 13 years of doing this, we really found the benefit to having backhaul boards and customer-facing boards totally separate, and connected via Ethernet only. We do NOT have it that way everywhere yet and still have some extra boards to hang, but frankly, that is the only way to build a network. For my 2c, this is what I'd recommend for you. Add another board at the AP side - even if it's just a SIAM board and a YAGI - so that you can run 1.3.23b for your existing clients, and 1.5.x for the new clients. Or, as Lonnie says, you may be pleasently surprised by 1.5.10 in a few days.

NOW, that being said, again, I understand. We have a mix-match of 1.3.23b, 1.4.22r and 1.5.9b all over our network, and we're constantly running into situations where this won't work with that, or this uses a channel not available on that, or some mix-match nonsense. We do feel that total ## compatibility between the versions is a must, and without it, it does complicate upgrading the network greatly.

We are (as I said above) going through our network and moving toward having all 'Infrastructure' boards separate from customer-facing boards. That really is the ONLY way to do it, regardless of what brand of OS you're using. That would be my same advice if you were building a network with any product - keep your network backhauls on separate boards than the customer connecting AP's, and use Ethernet to connect them. For my money, the ONLY board I want to use on our Network now is the ADI METRO's. 533Mhz, 4 MiniPCI Slots and 2 Ethernet (A MUST!!!) for $220ish, is money well spent on an AP. Two of these at each location (or one METRO for backhaul and a WP188 for Customer facing stuff) and you're set to easy service/upgrades.

...and worse than that, some of my clients are UBNT and that REALLY doesn't like 1.5.x at all. ( meaning I can't do the whole network, for absolutely sure)I feel your pain there. With the long term lack of Star products, many people had little choice except to stray. Its not always about price, fancy features, 'TDMA', slick web interfaces, etc.. - it's often just about availability. We had many discussions here about what we should do, and how long we could hold out without product. We really, really didn't want to polute our network with something alien, and to trade known issues with a whole new raft of unknown issues. For us, we were able to struggle through, but mainly by focusing on our Motorolla Canopy side of the network. We have about 300 SIAM Boards now, and we're pretty pleased so far with 1.5.9b and are very excited about moving the whole network over to to 1.5.10 or .11 and finally having the same firmware across the whole network. That will be wonderful. :)

Frankly, I'm just screwed. I'm sending the customer his check back. So far this experiment has cost me more than a day of my time, about 900 bucks, and enough stress to last me months.I know that hindsight is 20-20, but you could have put up a second AP running 1.5.9b with an XR9 for that amount of money, and broadcast to your new clients with this new Firmware, and left your existing AP as a Backhaul for now, until you can move it to 1.5 later on. And, of course, this customer is the pickiest, crankiest, nastiest I've ever dealt with. They've already filed complaints against me with the BBB, and nasty emails and whatnot. And that's BEFORE I got the equipment up in the air. So, I'm telling them I just can't do this. Cut my losses and run.Mark, for my money, sometimes that's simply the best thing. I guess this advice is off-topic, because that's regardless of the firmware versions. There are some customers that are just too high-maintenance to be worth it. Now - I do understand that IF there was still a 1.3.23b solution available for you, then perhaps you could have done this customer - or if they could wait for 1.5.10 or 1.5.11, then again you could have maybe done this customer. However, for my money, any customer what would file a BBB complaint on me BEFORE I had them connected... I really, truly, honestly would want my competition to have the pleasure of dealing with that dude long term. :)

[ninedd]

I didn't ask for "optimal". I simply assumed that "not optimal" meant that it actually worked in some fashion, which it does NOT.We have a 1.3.23b AP running an XR9 with a dozen clients on it, including both 1.3.23b and 1.5.9b boards with XR9's. The 1.5.9b clients have a bit lower performance (as expected in this mismatch) but they are working quite well. Our standard service in these locations is a 1.5 MegaBit service, and the 1.3.23b AP to 1.5.9b CPE is perfectly capable of delivering this in our experience.

[lonnie]

In Valemount we standardized on at least 2 four port boards per tower. One for 5GHz backhaul and one for 2.4 GHz and 900 MHz customer AP units. Some towers have a third unit for additional 2.4 GHz AP units.

Having separate boards just seems to make the organization task easier, but that is just my personal opinion. I know that from a system viewpoint each radio appears separate, so it does not matter which system it is located in.

[lonnie]

Just another update on the upcoming release. The extended channels are taking more time that we hoped, and we really want to get an interim release with cloaking tweaks and rate capping. Expect it soon, and I apologize for the 2.4 GHz extended channels being delayed.

[tog]

Just another update on the upcoming release. The extended channels are taking more time that we hoped, and we really want to get an interim release with cloaking tweaks and rate capping. Expect it soon, and I apologize for the 2.4 GHz extended channels being delayed.

(And WPA fixed so it doesn't kernel panic instantly I hope)

We are (as I said above) going through our network and moving toward having all 'Infrastructure' boards separate from customer-facing boards. That really is the ONLY way to do it, regardless of what brand of OS you're using.

I actually do two WAR4s (whether they be Metro, WP188, Gateworks, whatever) per tower and often two backhauls to each site. The two backhauls are separated, one backhaul on each board. This has helped me before when a board died, I had a customer-last-mile AP or two knocked out by losing a board but everybody else was fine.

[lonnie]

tog, I think Tony already said WPA was fixed, so just another reason to get this out quickly.

[tony]

Yes, the WPA issue has been fixed for the upcoming release.

[go.fast]

One thing that is being overlooked and could have alleviated some of the issues is that you guys tend to drop any support for older working formware for new boards.

If you had made 1.3.23 work on the siam boards, there would be no cries of pain, or time consuming work arounds.

Yep, we all want the latest greatest, but, we also need consistency and if that means staying put till we can get there, then so be it.

Call it a flawed business decision, or a philosophical difference in how to run a business.

[mrmike]

One thing that is being overlooked and could have alleviated some of the issues is that you guys tend to drop any support for older working formware for new boards.

If you had made 1.3.23 work on the siam boards, there would be no cries of pain, or time consuming work arounds.

Yep, we all want the latest greatest, but, we also need consistency and if that means staying put till we can get there, then so be it.

Call it a flawed business decision, or a philosophical difference in how to run a business.
I agree 100%. Allowing backwards compatibility to 1.3.23 and 1.4.22 would have alleviated lots and lots of headaches. We all could have just plugged along with existing infrastructure and tested the new firmware and fine tuned without having customers up our butt, or even worse, quitting.

[DrLove73]

I partially agree with you, but do not forget the packet loss when CPE transmits high volume of data on 1.3.x line. That was the reason they started from scratch with 1.4.x and HAD to develop whole new driver.

And don't forget whole hysteria that followed PL issue in 1.3.x. Some of you/us were screaming bloody murder because of the lack of solution. They could not have pleased everybody so they made very hard choice.

[Mark]

You know, we never really gave 1.4.22r on 900 much of a try until just recently when we figured we HAD to try it with 1.5.9b clients. As I posted before, we DO have some 1.5.9b clients on 1.3.23b AP's, but they are persnickety and much lower performing that 1.3-1.4 or 1.4-1.5 links, so we recently gave 1.4.22r to 1.5.9b links another try in 900Mhz, and had some most surprisingly good results.



So, what on earth settings did you use? Because I've tried every freaking combination that didn't kill my other clients to try to get them to communicate, and they won't. No matter what I do, the link gets to about 80% ping loss after a few minutes. when it's first reset, it may work great for a little bit, and then just gets worse and worse.

[lonnie]

Sorry in advance for the rant.

You conveniently overlook the LOUD screams of anguish that we did not/ do not have 11n. We took the path that had the greatest chance of getting us a new 11n driver and support for the new hardware.

As has been stated many times, the 1.3.23 was replaced by the 1.4 series, so there is no way we were ever going to port it to the new hardware.

I also take issue with the "tend to drop any support for older firmware for new boards" This war1a is the FIRST new hardware in quite some time, so this is the first time it has happened. Thus the "tend to" is quite an over statement. Why would you say such a thing?

Also, do you really expect us to back port and forward port ALL firmware to all hardware? Get a grip if you really think that. I consider you are very lucky to have old hardware supported by new firmware. Few companies, and none our size, do that. Most are into whizzbang and the next latest greatest, and leave people sitting with old hardware running old firmware. We do our best to give you the tools to run your business and I want as much compatibility amongst StarOS units as possible.

You guys are so quick to complain about the little things that you miss the really big things we do for you.

Rant over.

One thing that is being overlooked and could have alleviated some of the issues is that you guys tend to drop any support for older working formware for new boards.

If you had made 1.3.23 work on the siam boards, there would be no cries of pain, or time consuming work arounds.

Yep, we all want the latest greatest, but, we also need consistency and if that means staying put till we can get there, then so be it.

Call it a flawed business decision, or a philosophical difference in how to run a business.

[lonnie]

Had you followed the 1.4 development branch you would have seen it was an all new driver. The 1.3 series was carried forward from the VxWorks days and we needed the new framework to be able to add the new ways of doing things for the newer chipsets.

Unfortunately things had to change again in order to get 11n. We could endlessly spend time making old and new work like a charm, or we could get the new firmware for everything and let you simply update.

Change is sometimes not easy, and we never make a change simply for the sake of change.

I agree 100%. Allowing backwards compatibility to 1.3.23 and 1.4.22 would have alleviated lots and lots of headaches. We all could have just plugged along with existing infrastructure and tested the new firmware and fine tuned without having customers up our butt, or even worse, quitting.

[go.fast]

Well 1.3.23 was not the 1st.
It happened with 1.1.13 and the wp188 boards.

[lonnie]

Are you using high threshold? It sure sounds like you have local source of noise. Not sure if you caught it, but a long time ago but we had a customer in Valemount on 900 MHz that would absolutely tank when she used her 5 GHz portable phone. It was one of those long distance units that went farther than any 2.4 GHz phone and extended out to the yard. Sure it had 5 GHz, but it also had 900 MHz which is how they got the extended distance. Some of them always beacon so that they pick right up and do not miss 2 or 3 rings. There is also video cams to watch out for. Aren't you the least bit curious why one site is so poor and others are good? Surely it has occurred to you there has to be a local noise source.


So, what on earth settings did you use? Because I've tried every freaking combination that didn't kill my other clients to try to get them to communicate, and they won't. No matter what I do, the link gets to about 80% ping loss after a few minutes. when it's first reset, it may work great for a little bit, and then just gets worse and worse.

[go.fast]

Anyways, getting back to the issue at hand,

You should have known that not *all* of your customers moved their networks over to 1.4.x from 1.3.23.
It was said over and over again, that there were issues with XR9 and 1.4.x and even though some people will pop up and say they have 1.4.x working fine with XR9, many said they did not and had to stick to 1.3.23. The issue seems to have been 1.3.23 handled noise much better than 1.4.x has. At least in my experiences that was my conclusion.

Guys like me, and Mark, and many others have said this.


Personally I never felt you guys addressed the issue seriously because you guys didn't sell that hardware and it's a competitors product.
I'm surprised that now you guys are willing to port new firmware to new competitors boards, but yet, overlook your current customers existing networks made up of your boards and firmware.

I'm looking forward to star N, but, it's going to be a cautious approach.

And don't forget a growing percentage of our networks are 900MHz.

[lonnie]

That was a special case and we had to make a release tag work for 2 hardware versions. 1.1.13 would have taken all new kernel, loader and driver, and by then we were onto the new firmware.

I'm sorry the world is not perfect. We do not have the resources for multiple teams to keep all older releases up to date with old and new hardware. Many companies do not even support older hardware with new firmware, and they are much bigger, so I feel we are not doing so bad.

Well 1.3.23 was not the 1st.
It happened with 1.1.13 and the wp188 boards.

[lonnie]

We took it seriously, which is why we moved to the 1.4 series. Almost everyone was fed up and was saying we were ruining their ISP because the 1.3 did not have software retry. I said there had to be other issues at play, but in bulldog fashion everyone grabbed onto software retries and never let go. We gave you software retries and all of a sudden the 1.3 was OK, and in fact was better than 1.4. What to do? No way could we add retries to 1.3 since the driver framework was not designed with it in mind.

Unfortunately 11n came along and we have changed again. The 1.5 series will have support for old and new. Just be patient. The next release is nearly at hand.

Anyways, getting back to the issue at hand,

You should have known that not *all* of your customers moved their networks over to 1.4.x from 1.3.23.
It was said over and over again, that there were issues with XR9 and 1.4.x and even though some people will pop up and say they have 1.4.x working fine with XR9, many said they did not and had to stick to 1.3.23. The issue seems to have been 1.3.23 handled noise much better than 1.4.x has. At least in my experiences that was my conclusion.

Guys like me, and Mark, and many others have said this.


Personally I never felt you guys addressed the issue seriously because you guys didn't sell that hardware and it's a competitors product.
I'm surprised that now you guys are willing to port new firmware to new competitors boards, but yet, overlook your current customers existing networks made up of your boards and firmware.

I'm looking forward to star N, but, it's going to be a cautious approach.

And don't forget a growing percentage of our networks are 900MHz.

[go.fast]

We took it seriously, which is why we moved to the 1.4 series. Almost everyone was fed up and was saying we were ruining their ISP because the 1.3 did not have software retry. I said there had to be other issues at play, but in bulldog fashion everyone grabbed onto software retries and never let go. We gave you software retries and all of a sudden the 1.3 was OK, and in fact was better than 1.4. What to do?.

Look, I've been using your software since before you were Star-os.

I have followed you every step of the way and only used what hardware you recommend and sold.

I have a pretty good memory of what was what.

To use an example of the 900MHz situation I will use one particular pop I built out on.
I started with a war2 and 1.1.13 and a SR9. I was seeing 8 megs both direction and no problems.
You came out with 1.3.1 and I was one of the first beta testers on that 900MHz pop.
Performance went to hell. I upgraded every step of the way.
Not untill we got to 1.3.23b did we see stability, but half the performance.
Reason we had to go to 1.3.23b? The only boards you sold were war1's or wp188 with 1.3.23 loaded on them.

We moved from SR9 to XR9 to standardize our network, which is important to the way I run things.

At that pop, there was a customer that needed more speed and at times had some consistant bandwidth usage. He is an admin for other networks connected to our network and wanted the boost i could give him to access his clients.

So we built him a dedicated link. We did not add the additional 900 at the pop, we popped out one of the subs close to him that we could feed by adding a 2gig sector by changing out the main pops war2 to a wp188 (end of going back to 1.1.13).

On that new micro pop repeater we added a 2nd board for the new 900 shot to my admin client

1.4.22 was out, so we started out with xr9 and 1.4.22
It originally worked, but not as well as we wanted. It became erratic and unusable at times.
I went through channel changes and cloakings on both the main 900 pop, his 900 shot and two others that vaguely appeared in site survey.

Was a hell of a mess. There was other 2gig in the area and some 900 and it was more susceptible to noise and the XR9 and 1.4 couldn't handle it as well as 1.3.23


We went to 1.3.23 on the two boards, and he has been stable ever since.

So with that experience, would you want to convert a couple hundred cash paying customers who may quit on you or tell their friends we suck, from what works *ok* to the *unknown* ?

It's a small town and we have a reputation to uphold.

[Mark]

Are you using high threshold? It sure sounds like you have local source of noise. Not sure if you caught it, but a long time ago but we had a customer in Valemount on 900 MHz that would absolutely tank when she used her 5 GHz portable phone. It was one of those long distance units that went farther than any 2.4 GHz phone and extended out to the yard. Sure it had 5 GHz, but it also had 900 MHz which is how they got the extended distance. Some of them always beacon so that they pick right up and do not miss 2 or 3 rings. There is also video cams to watch out for. Aren't you the least bit curious why one site is so poor and others are good? Surely it has occurred to you there has to be a local noise source.

I've thought about that. I moved all the clients onto the other AP at the site except this one, so I can fiddle with it without affecting them. So, I've been from channel 4 to channel 7, no change. I tried with and without thresholds, no change. It works vaguely better if I uncheck "short preamble". Certain sequences of change will result in it working for up to 5 min, and then it slowly falls back into the same mode.

This is a small housing development. All private land. This customer is in between two other customers. the only unique thing about them, is that they should slightly BETTER signal than their neighbors because of their higher elevation. But don't. It's a 42 mile drive to visit them. The ONLY reason I'm willing to return to that place is to hand them their money back. That's it. I'm so sick of these people already I will have difficulty being civil. I understand they're not getting what they want. But they're demanding as hell and anti-social to begin with.

My advice is to scrap trying to make the N driver backward compatible - ain't nobody else made it work well either - and just go for a great N setup, preferrably one we can interop with other equipment with. Get N working, and let's see if we can get say, a couple MT boards and U's Rockets or nanobridges working. Nanobridge is an awesome cpe form. 1 foot solid dish, under $100. Give us the routing and other stuff that U cares nothing about, and I'd buy licenses for it - Gimmee a CPE license for 20-30 bucks and I'll buy them on a very steady basis for years. no way in hell can we buy a WAR1a, radioc card, antenna, piggy, psu, and be even double that price.

Give us the functionality boost that Star-OS originally was way back when, and you've got your market and purpose back.

Heck, for those who need it, why not just include the binaries for both legacy and N, and make us choose which to run for each radio card. Quit trying to make one do it all. Can that work? I suspect it can.

[go.fast]

Look, I've been using your software since before you were Star-os.

.

Hope to put a positive spin on this thread.

Having been using siam and 1.5.9, I'm feeling pretty good that we are moving forward and will soon have something that extends the life and capacity of my network with out having to break my *standardization* policy.

The previous posts did not concern 1.5. just backwards firmware updates and should be moved to a separate thread.

It's a nice Saturday here on the coast and I'm going to go enjoy it.

[ninedd]

The ONLY reason I'm willing to return to that place is to hand them their money back. That's it. I'm so sick of these people already I will have difficulty being civil. I understand they're not getting what they want. But they're demanding as hell and anti-social to begin with.Every once in a while, that is the best policy. :) Either because they are too high maintenance, or because they are in a bad location technically, or whatever the reason, it is sometimes the best option, and you can use the time that they'd consume in servicing several other doable ones instead. :)

My advice is to scrap trying to make the N driver backward compatible - ain't nobody else made it work well either - and just go for a great N setup, preferrably one we can interop with other equipment with.As far as I know, 'n' with backward compatibility is almost done, so I don't want them to change that now. I for one really want to be able to have any mix of 'b' 'g' 'a' and 'n' cards in the same board at the same time, running the same firware across the whole network, on new hardware and on hardware that's been hanging for 5 years - if we can get that all working, I'll be very pleased.

Gimmee a CPE license for 20-30 bucks and I'll buy them on a very steady basis for years.Hopefully their CPE price point will be affordable enough to lure customers to try it. It may be a difficult sales job to take a $50 board that comes with several free/included OS's and to have people jump at the $20-$30 firware option. For an ISP with 1,000 CPE's out there, that's a BIG chunk of coin. I was hoping it'll be priced about like an upgrade price, but that's of course up to them and their marketing guy's to come up with. I would think that they'd certainly do 5x as many licenses at $7 vs $20-$30, and then it'd snowball from there. However, that would be up to them to figure out the magic price/return point. :)

no way in hell can we buy a WAR1a, radioc card, antenna, piggy, psu, and be even double that price.For me, I'm less concerned about the exact price as I am about the time/effort to source and assemble a whole bunch of different parts. We built CPE's 5-10 years ago, when we were doing an install or two per week. Now we really like to get back to the days when we can do 3 or 4 or 5 installs, so going back to the "flavor of the day assembly project" is not what I'm wanting to do. I loved when we had a good supply of 1208's with 26dbi cards. They were great for short range customers, and simply adding a pigtail and a grid, and we had a great long range CPE. This 'DIY' mode we are entering is not idea as far as I'm concerned.

Just to add my 3c though, we're really pleased with what we've seen from 1.5.9b so far. We have some smaller AP's entirely converted and are doing pretty well. That may be just because on those AP's we finally have all the same firmware across the whole AP. We also have a larger AP with 3 sectors and 85 clients. The Clients are all 1.5.9b and the AP is still 1.4.22r because of interoperability with other AP's. We're really looking forward to the next few days (or whenever it's out) when we can hopfully get 1.5.10 across the AP and all it's CPE's. So far, things have been steadily improving in 1.5 and I really think that Star has a winner here. :)

[mrmike]

Not to rant, not to complain, but I did have 2 AP completly converted to 1.5.9, and just about lost 10 customers. I could not, for the life of me, get more that 500k out of 90% of the 20.4 customers. I couldn't even get more that 500k out of the 2.4 link between the 2 towers. I did pm Lonnin about this link, but didn't hear back after a couple of days, so I have to spend 5 hours yesterday getting 1 of the APs and customers back to 1.3.23, and the other AP to 1.4.22, though the customers are staying at 1.5.9. Throughput went back to 10M right away. I'm just frustrated. I do have a long memory on all the upgrade troubles right from 2.1.x series on wraps. I know; it will come. (I hope)

[lonnie]

I did login and I replied earlier that we would do some more checks because there was one odd ball card that was not like the others. Tony did confirm it was an XR9 and not a SR9 like I suspected.

I think I also said I would adjust settings but not save, so it you had any sort of power bump or reboot my settings would disappear and you'd be back to your setting.

When I left the system it was pulling 10 mbps everywhere except that oddball radio.

Not to rant, not to complain, but I did have 2 AP completly converted to 1.5.9, and just about lost 10 customers. I could not, for the life of me, get more that 500k out of 90% of the 20.4 customers. I couldn't even get more that 500k out of the 2.4 link between the 2 towers. I did pm Lonnin about this link, but didn't hear back after a couple of days, so I have to spend 5 hours yesterday getting 1 of the APs and customers back to 1.3.23, and the other AP to 1.4.22, though the customers are staying at 1.5.9. Throughput went back to 10M right away. I'm just frustrated. I do have a long memory on all the upgrade troubles right from 2.1.x series on wraps. I know; it will come. (I hope)

[tony]

Hold tight guys, the new release is almost here. This upcoming release has many cloaking and compatibility updates not to mention managed mode, and more.

[Mark]

Just to add my 3c though, we're really pleased with what we've seen from 1.5.9b so far. We have some smaller AP's entirely converted and are doing pretty well. That may be just because on those AP's we finally have all the same firmware across the whole AP. We also have a larger AP with 3 sectors and 85 clients. The Clients are all 1.5.9b and the AP is still 1.4.22r because of interoperability with other AP's. We're really looking forward to the next few days (or whenever it's out) when we can hopfully get 1.5.10 across the AP and all it's CPE's. So far, things have been steadily improving in 1.5 and I really think that Star has a winner here. :)

I don't mind the DIY aspect. For one, usually there's multiple sources for radios, cpu boards, pigtails, antennas, etc. When one's out, something else is available. That's the upside.

right now, the downside, is that the integrated radio/cpu/antenna/dish/etc is killing us on price, since they're VERY inexpensive.

Normally, I don't have use much 900, so I just tend to "eat" the extra cost, because I'm the only one there and the only game in town, so it means they'll stay around for a long time. Everyone there's a homeowner, they're not moving on a whim.

[cephlon]

Just remember what Henry Ford said: "If I had asked my customer's what they wanted, they would have said a faster horse."