View Full Version : StarV3 v1.1.5b build 1616 (beta 1) is ready for testing
The new release is available for testing. It is extremely BETA, and should not be used on mission-critical systems.
Downgrading back to previous V3 releases is possible.
Do not upgrade this release unless you are planning on working with us to help improve it. There are known problems, and there is a very good likelihood that your system will eventually lock up during testing.
Outside of the updated wireless support, the rest of the system should be reliable.
For more information, please visit the release page.
http://www.star-os.com/release-notes/starv3-1.1.5b-1616.htm
Please post your results in this thread.
Primary focus of this release is compatibility, and stability testing.
go.fast
09-22-2006, 02:27 PM
You guys are charging right along!
---------------------------------------------------------------------------
Atheros support has had a major update & redesign
New features
Atheros Adaptive Radio (AR)
Atheros Dynamic Turbo (also known as Turbo Prime and Friendly Turbo)
Atheros Auto channel selection support
802.11e (QoS w/ Bursting and Aggregation)
802.11h (DFS v1, and DFS v2 for FCC3, ETSI and MKK4)
Dynamic WDS with full SuperAG and 802.11e support (testing needed)
Strives to be in compliance with known governing bodies
http://www.star-os.com/starv3/images/pointer.gif802.11i (WPA and WPA2/RSN) will be in the next beta
It's a start. More will come with subsequent beta releases.
bobbyc
09-22-2006, 04:14 PM
I see a vision... it looks like V3 WRAP upgrade license purchases... lots of them :)
Thanks,
Bob C
Regarding WDS with SuperAG features:
1) Awesome, you got all of it working with WDS
2) Wouldn't disabling SuperAG at the client end also work fine as a workaround for 1.1.4 <--> 1.1.5 WDS/SuperAG incompatibilities? Your release notes only mention disabling it on the AP side, but as I understand it, SuperAG will be disabled just fine for any individual client that doesn't mention SuperAG during the association process.
Yes, it only matters between the peers (AP and specific client), so as long as one of them has the features disabled, you will be Ok.
bobbyc
09-23-2006, 05:27 PM
No problems on the bench thus far. Got a WRAP running 1 cm9 client and 1 prism 2.5 AP with a CB3 client. Also got a WAR4 with exact same setup.
EDIT:
On the WRAP prism 2.5 AP, the CB3 dissapeared from the Association list. The main screen also reports 0 associations on the prism 2.5 AP. But, the ping is still alive to the CB3 client.
I am pleased to hear. Thank you for your results.
It will also be interesting to hear the results of a CM9 AP using the beta, against some of the clients our 1.1.4 release had problems with (such as CB3s, etc). We are hoping the compatibility is improved.
bobbyc
09-23-2006, 06:00 PM
I logged out of the WRAP. Went outside to do some yard work. Came back, logged in, and the association list was corrected.
Bob C
Thank you. Problem has been resolved for the next beta.
oscarBravo
09-23-2006, 06:47 PM
The use of country code ##, and U1 have been removed. Tony, would it be possible to see a table of available frequencies by country code? As I recall, a large chunk of legal spectrum has been left out of the "IE" country code in the past. We've worked around that using "##", but obviously that's not an option once that code is gone.
[edit] One other thing: 802.11i (WPA and WPA2/RSN) will be in the next beta Remember we flagged a problem with WPA in 2.11.0? That has prevented us upgrading all our customer-facing APs past 2.10.0. Presumably with the driver rewrite, whatever issue crept into that release isn't necessarily going to be a problem in v3, but it's one we'll be testing and reporting back on.
We have no master list on hand, however I will see what it will take to get one.
The WPA implementation is of a new design, and should not have the same issues as people had in v2.
Stratolinks
09-23-2006, 07:08 PM
A question that comes to mind with the elimination of the ## country code is this..
When all the paperwork is done to get a licensed frequency assigned by Industry Canada how does one put a 6GHz frequency in under the new system?
To stay in compliance, we cannot provide a ## country code, or any other that will potentially cause problems. When new country codes are ratified, and approved my Atheros and the various governing bodies, we will provide support for the new bands and codes, and any radar requirements that go with them.
bobbyc
09-23-2006, 08:09 PM
Have you tried to enter the ## country code in this release? It still gives you the pop up warning that it allows all frequencies, so is it indeed no longer used?
Bob C
The interface still accepts it, but the underlying Atheros support does not. It will remain at the 'NA' country if an invalid one is selected.
lonnie
09-23-2006, 09:28 PM
Tony, we cannot be spending time like that. The list you use is what has been approved for use by Atheros. That is the best we can do or we lose certification on the driver.
People cannot just use any country code they choose or they break some serious rules which are in place for aircraft radar.
Take this seriously people. When the EC agrees on channels and such, Atheros will update the country codes and tables. We cannot do anything else until then.
We have no master list on hand, however I will see what it will take to get one.
The WPA implementation is of a new design, and should not have the same issues as people had in v2.
Skaught
09-23-2006, 09:32 PM
I have an application in right now for a public safety band use for a link I built for the airport security.
I am using ## on V2.
lonnie
09-23-2006, 09:51 PM
We can work with you on a new licensed frequency option. The rules we have to obey are for unlicensed. We will work out a mechanism for having a frequency or range as part of the license.
Now, having said that, do not expect it real soon. We have a full plate and demand for licensed channels has not exactly been over whelming (well at least for legitimate use).
I have an application in right now for a public safety band use for a link I built for the airport security.
I am using ## on V2.
StarV3 1.1.5b has a "PS" country code for the public safety band already.
I tried it (indoors!) for a moment and it did indeed scan around 4950 - 4980 or something close to that.
Magician
09-23-2006, 10:02 PM
I just loaded it on a wrap will be testing over the next few days
Stratolinks
09-23-2006, 10:53 PM
I have an application in right now for a public safety band use for a link I built for the airport security.
I am using ## on V2.
I assume that the new PS country code would cover that one.
My initial question still stands. How do you go about selecting a frequency of 6.02 GHz or 6.05 GHz after getting a license approved for it.
EDIT:
OOPS sorry. I see my question has now been answered. I took too long posting I guess.
Stratolinks
09-23-2006, 11:03 PM
We can work with you on a new licensed frequency option. The rules we have to obey are for unlicensed. We will work out a mechanism for having a frequency or range as part of the license.
Now, having said that, do not expect it real soon. We have a full plate and demand for licensed channels has not exactly been over whelming (well at least for legitimate use).
Hey sounds great. Our timeline on this is at least a year off anyway. Demand is understandably low, it is a lengthy process to get a licensed frequency assigned for equipment that isn't specifically manufactured and pre-approved for that range.
bobbyc
09-24-2006, 12:43 AM
I am pleased to hear. Thank you for your results.
It will also be interesting to hear the results of a CM9 AP using the beta, against some of the clients our 1.1.4 release had problems with (such as CB3s, etc). We are hoping the compatibility is improved.
A bench test has never revealed the 'N' problem for me. When I put the release on to a tower, I'll see.
The only thing I've noticed thus far is the atheros AP doesn't idle timeout the client after 6 minutes.
Bob C
Yes, this mechanism has changed and should work much better now. Idle users will no longer drop off after 6 minutes. Clients that have been powered off, or not associated any more will be pruned every few minutes.
bobbyc
09-24-2006, 09:28 AM
Overnight I left the WAR4 on with the Prism 2.5 as the client, and the CM9 as the AP with a CB3 client associated to it.
What is the idle timeout now? I woke up and checked on my putty session I kept alive overnight, and the idle time for the CB3 client was 23 minutes.
Also, I tried to use the ping utility, and no matter what IP I pinged, it said "stream returned nothing". I checked the system log and it was empty. I logged out of putty, logged back in, and I could ping again, and the system log showed back up.
A few minutes later, the problem showed back up.
Bob C
This has been resolved for the next release. There is a small resource leak in the Prism2 handling in the UI that will eventually cause the SSH session to do strange things after an extended period of time. Logging out, then back in is a quick fix.
The idle timeout is a few minutes, however it will only remove clients that are truely gone (powered off, etc.) and not clients that are associated, but simply not sending data.
I put this on a War in operation here. It's in a very noisy area and had a cm9 in it. It was set to channel 6 and had 10 associations. Most are businesses and don't use it much on Sundays. I've tried both channels 1 & 11 but have quite a few cpe that won't associate at anything other than 6. So it stays on 6.
After the upgrade, I got 8 associations pretty quick. Waited 30 mins and still saw 8. Seemed to be working all right, some data was moving and IP addresses were showing up in the associated list. Tried both channels 1 & 11 and got 3 associations even after waiting 15 mins.
Changed to a WLM54G Atheros. Pretty much mirrored the results above. Couldn't get more than 3 associations other than channel 6.
Changed to a Prism 2511 on channel 6. Got 10 associations including two that weren't in the original list. This was after 1 min. Changed to channel 1 and it seemed to hang but finally cleared. I never saw the association list refresh so I rebooted. After 2 mins, it had 10 associations with IP addresses. There's nothing in the rx or tx columns so I can't easily tell how much if any data is moving but I'm impressed. All the signals are in the 40's and 50's which are considerably better.
bminish
09-25-2006, 11:06 AM
Tony, we cannot be spending time like that. The list you use is what has been approved for use by Atheros. That is the best we can do or we lose certification on the driver.
Do atheros publish this anywhere? I will bring the current list of what is allowed in Ireland to Atheros if it is incomplete.
Ireland has less restrictive rules on 5.X Ghz use than the EU in general and it's a another problem for us with deploying Star V3 more widley if we have to redo our frequency planning just to implement V3 in places where we have working (& legal) V2 links.
The problem is not with the IE country not providing the ranges in question, it's the fact that the IE country is part of the ETSI1 regulatory region that is shared with many other countries, and imposes it's own official ranges. (don't you love standards).
ETSI1 is allowed ranges 5180-5240, 5260-5320, and 5500-5700. 11A turbo not allowed, and ETSI DFS required.
There are 6 ETSI regions in total, ETSI1 providing the most frequencies.
I put the Atheros radio (cm9) back in after a complaint this morning from a customer. All of the signals were better by 10-15db with the prism but the data rates went from mostly 11's down to 1-2 for the most part. He said the data was just crawling compared to before.
It takes a painfully long time to clear when applying changes to the Prism radio. The association list does not zero out and come back after a change is applied, like changing a channel. I assume it requires a reboot for the changes to take effect? Again, there is nothing in any of the tx or rx on the association screen with the 2511.
bobbyc
09-25-2006, 12:59 PM
Greg do you lock your clients at 11 or leave them at auto? What about the prism AP, locked at 11 or auto?
Also regarding the clients re-associating: If you aren't encountering the bug listed earlier where you have to log out of ssh and ssh back in in order for things to display properly..., when applying changes on a prism or orinoco AP with V2, I have always changed the channel, applied changes, and then changed back to the original channel, and applied changes. If I don't do that procedure, I would get CPEs that didn't re-associate until the customer power cycled it. Rebooting the AP would always reassociate the CPEs, but my procedure listed above is a little quicker.
Bob C
I put the Atheros radio (cm9) back in after a complaint this morning from a customer. All of the signals were better by 10-15db with the prism but the data rates went from mostly 11's down to 1-2 for the most part. He said the data was just crawling compared to before.
It takes a painfully long time to clear when applying changes to the Prism radio. The association list does not zero out and come back after a change is applied, like changing a channel. I assume it requires a reboot for the changes to take effect? Again, there is nothing in any of the tx or rx on the association screen with the 2511.
The association list clearing issue has been resolved for the next BETA. Thank you for pointing it out.
Greg do you lock your clients at 11 or leave them at auto? What about the prism AP, locked at 11 or auto?
Neither the clients or AP are locked, all are on auto.
bobbyc
09-25-2006, 06:12 PM
Hmm. I have many WRAP V2 with CM9 backhaul and 2511 AP. They are rock solid right now. I want to cloak the backhauls though, so I was planning on upgrading them to V3.
The difference in my case is that I have the AP locked to 11, and the clients are all locked to 11. It is rock solid with V2. I think I am going to upgrade them after the next beta release.
Bob C
In general, for pretty much everything whether it be a P2P backhaul, a point to multipoint AP, atheros or prism... I always lock the transmit rate.
If you want maximum throughput and latency stability (no "jitter") you'll want to do this.
For example, a point four hops into my backbone had a lot of the 11a backhauls between NOC and there set to auto. I locked the transmit rates on all the 11a backhauls (both ways) and this point four hops in suddenly got a lot more sturdy and reliable when doing a throughput test. It wouldn't go all over the place between 1200K - 2000K/sec any longer.. it would stay solid at 2000 - 2200K/sec.
All of my standard non-cloaked atheros APs are locked at 11mbit transmit rate and so are the clients. The cloaked atheros APs I don't have very many yet, but I expect I will lock the clients at 12 - 24 transmit rates depending upon how good the client's path is, and I expect I will try to lock the AP at 18 or 24.
If you have a P2P link that likes to teeter between 36 and 48, lock it at 36. Try it. Lock it at 24. Try it. Chances are 36 is the best but sometimes you'll find the best performance is 2 notches down from where auto wanted to hover. Most often 18 and 24 are the best, once you go above 24 your transmit power starts getting lowered automatically in the radio card itself and even though auto wanted to try to use 36 - 48, it wasn't necessarily the most reliable performance.
In summary, lock your transmit rates everywhere for maximum performance.
i20access
09-27-2006, 12:02 AM
Anyone else having trouble locking a rate in Turbo mode in this version? Maybe I am not setting it right. I have tried 108, 96, 54, 48, and the rate still adjusts itself.
Regards,
xandor
09-27-2006, 01:55 AM
HI,
Please add in new release 1.1.5 outdoor field prsent in old releases.
I have tested this new release as station with SR9 and 1.1.4 as ap with SR9, there are differences about signal.... With two systems with 1.1.4 and SR9 cards signal level is better...
Regards
Xandor
Outdoor field is obsolete, and has been removed. You can specify your own scan list in the newer releases.
i20access, specify your turbo and base rates from 1 to 54.
Yeah, in v3 including the new 1.1.5b, if you want, for example, 72mbit data rate in turbo mode... You still set your transmit rate to 36.
Yes, this differs from v2 where you did actually put in 72. Oh well, as long as you know about it, it's a minor cosmetic thing. Even if you specify an incorrect rate it just ignores you and uses auto anyway.
I put the beta on a war4 unit that has been working pretty well until recently. Has 3 CM9's, one to 2.4 clients. The signal strength had gone down and I tried the upgrade to see if it would fix anything. Rebooted and couldn't access the system. This one is in the boonies but I needed to trek out anyway, just hadn't planned on so soon. Last mile is uphill and on foot. Only passed one rattle snake next to what might generously be called a cow path. He didn't make any noise, nor did I notice until I was past it. Made the trek up the mtn more brisk, what with all the adreneline present!
Got to the top, hooked up notebook. Unit had rebooted and all was looking normal except no link back to backbone. Was at 5300 before. Rebooted and power cycled it but still no change. Tried changing channels, set tx rate back to auto on both sides but still nothing. Finally flashed it back to 1500 and rebooted. Linked right back up. This is a fairly long link, 16 miles, if that makes any difference.
Heh wear long pants and high boots.
You were using US country code? (meaning DFS was disabled)
From the little information I have no idea what/why.
Heh you shouldn't be using 1.1.5b on something that's that far away and difficult to get to.
I remember the warning issued.
We have a wrap that connects to the 2.4 side that has been down for a couple of days. We suspect the radio at this tower in the war needed replacing so we were headed out fairly soon anyway. For that and maint to get ready for lots of snow. I've upgraded a couple live AP's but most were AP's with 2.4 clients - none had 5.x radios before this try. I didn't anticipate any issues with the 5.x side.
bobbyc
09-27-2006, 09:45 AM
Maybe you ran into one of these caveats:
# Cloaking has been updated to be more compliant with other countries that require 10 and 5 Mhz channel bandwidth spacing, and as such, the rate set advertised by the AP, and accepted by the client are scaled to reflect the bandwidth used. This may cause some compatibility problems between StarV3 1.1.4 and StarV3 1.1.5 as there may only be one or two compatible rates between the two versions that can be negotiated.
# With cloaking enabled, we have found better results connecting a 1.1.5 client to a 1.1.4 AP, than a 1.1.4 client to a 1.1.5 AP. Best results will be using the same software version of ether 1.1.4 or 1.1.5 on each end of the connection.
# 1.1.5b clients will not associate to an AP that masks it's ssid (hide ssid option), while using a DFS country code. This is not a bug, but rather a requirement for the client's passive scanning capability.
ninedd
09-27-2006, 09:57 AM
Anyone else having trouble locking a rate in Turbo mode in this version? Maybe I am not setting it right. I have tried 108, 96, 54, 48, and the rate still adjusts itself. Regards,I saw the same thing with 1.1.4 - when I picked 108 or 96, but when I specified 54 in the dialog, it linked at 108. I havn't done a lot of testing to confirm this, but perhaps the turbo and cloaking speeds are (cosmetically) 1/2 or double as the channel size changes?
Maybe you ran into one of these caveats:
# 1.1.5b clients will not associate to an AP that masks it's ssid (hide ssid option), while using a DFS country code. This is not a bug, but rather a requirement for the client's passive scanning capability.
That one is probably the reason. We don't broadcast ssid on any link. That might have saved me the trip yesterday but I needed the exercise anyway and it twas a gorgeous day for a hike!
I tried this on another live link and the 5.8 link won't come back up. I'm broadcasting ssid from the AP. Any other ideas why this won't come up? Works ok with earlier versions.
Can you provide some information on the system you upgraded, such as mode, channel, country code, distance, etc.
Also, what channels are listed in the configuration dialog.
Mode is 11a. Channel 5745 - Distance is 6 miles, Short preamble, Power saving and Super A/G selected.
I just tried taking out all options, nothing is X'd from AP but still no association.
Country code was u1 in the AP, changed it to US. Still nothing.
Other side was US, all looked normal except for the CM9 link to the backbone. It was scanning for a connection. I tried taking out all the options first, applied changes and it appeared to associate. I couldn't ping anything, then noticed it was scanning again. Flashed to 1509 and it came back up fine.
Thank you.
What is the average signal level between the client and AP using the 1509 release?
Current channel is 5825 and shows 74/75 for signal.
i20access
09-29-2006, 07:10 PM
Will the quality in % be coming back, possibly under another column? Can you post a new .pdf of the association display detailing the new options?
Thank you,
The PER rating for quality will come back in the next few beta releases. We will generate a new .pdf once the new association dialog layout is finalized.
Short rundown of the changed columns:
Q)
Quality of link (dbm + 95)
T)
Link type, C = client / association, W = wds connection
AQUEP)
A = "Client is authenticated"
Q = "QoS is being used"
U = "uapsd is being used"
E = "erp is being used"
P = "Client is in power savings mode"
CFTWX)
C = Compression
F = Fast Frames
T = Dynamic Turbo
W = WDS
X = XR
The rest of the fields should be the same.
dduck313
10-01-2006, 06:17 PM
I'm using a prism 2.5 and an atheros 5213 in a WRAP. Prism works fine but atheros didn't. When I set it to 802.11b only, it will locked at 5200MHz. But if I set 802.11bg, it works fine (but decrease in B performance of course). I guess it's the new bug of #1616.
Oh yeah, is there possible in future Star-OS release can set up Prism country code and TX Power?
lonnie
10-01-2006, 06:57 PM
What country code did you use?
dduck313
10-01-2006, 09:08 PM
I'm using FCC Senao SL-2511MP that works in channel 1-11 200mW. I'd like to use channel 13 (ETSI) while keeping the TX Power 200mW. ETSI Senao NL-2511MP run only in 100mW and less sensitivity than FCC.
lonnie
10-01-2006, 10:23 PM
I meant the Atheros since you say it only goes to 5200 MHz. What country code did you use? What channel did you enter?
Prism is locked based on its eeprom setting. There is no reliable way to set prism power output. The documented technique creates RX trouble and a very noisy TX output. Many people use that tweak to get 400 mW and more, but they are simply creating noise and wrecking the spectrum.
I'm using FCC Senao SL-2511MP that works in channel 1-11 200mW. I'd like to use channel 13 (ETSI) while keeping the TX Power 200mW. ETSI Senao NL-2511MP run only in 100mW and less sensitivity than FCC.
Lonnie is correct. Prism cards do not have country codes, but they do have a locked channel list that is specific to the country you purchase the card from. This cannot be changed.
The Prism firmware also does not support tx power control. While there have been many hacks in the past to do it, in the end many vendors have removed them as it is very card specific, and causes far too much noise and interference, enough to violate most regulations you may be required to follow.
I'm using a prism 2.5 and an atheros 5213 in a WRAP. Prism works fine but atheros didn't. When I set it to 802.11b only, it will locked at 5200MHz. But if I set 802.11bg, it works fine (but decrease in B performance of course). I guess it's the new bug of #1616.
Oh yeah, is there possible in future Star-OS release can set up Prism country code and TX Power?
kuggie
10-02-2006, 04:16 PM
We are running a 6 mile, non LOS link with WRAPs and SR9's. Upgraded (from V2) to V3 1.1.4 (both ends) and everything was okay. Cloaking didn't seem to do much so we tried 1.1.5. After upgrading, as time went on, the throughput went down from a "normal" 600k/sec (router to router throughput test) to 75k, even though signal level reported was a solid 25. Tried all legal channel and cloaking scenerios, not much luck. Rates locked at 2m for no cloak and x2, 1m for x4. Sometimes it worked - most times not. Downgraded back to 1.1.4 and the link is back solid, no cloak - rate locked at 11 m. I seen the differences mentoined below (quoted) about the signal, as the link wouldn't even support ssh at times with 1.1.5. While the report of the signal seems similar between the two versions, I had no luck with 1.1.5 and the SR9. The link was tested over a 6 day period with 1.1.5. The guy's did say "extremely beta", and it should be heeded. 1.1.4 has been running for 24+ hours and been no trouble at all.
Kevin Custer
KC-Wireless
HI,
Please add in new release 1.1.5 outdoor field prsent in old releases.
I have tested this new release as station with SR9 and 1.1.4 as ap with SR9, there are differences about signal.... With two systems with 1.1.4 and SR9 cards signal level is better...
Regards
Xandor
Am I the only one having problems using this ver with a p2p 5.x link? I've tried it on two different systems and can't get either to link. Flash back to earlier ver and they link fine. I have this running fine on a couple of 2.4Ghz AP's with independent links back to the shop.
dduck313
10-02-2006, 07:27 PM
I'm using country code: ID. Channel 13. Default card regulation ETSI. TX power DEF. TX rate AUTO. Link distance 7 miles. Cloaking 1x. When I switch to 802.11b only, it shows 5200. But when I switch to 802.11bg, it shows 2472. But it's only happened in #1616. In #1509 everythings works fine.
This has been corrected in the next beta.
bobbyc
10-03-2006, 05:37 PM
Rates locked at 2m for no cloak and x2, 1m for x4. Sometimes it worked - most times not. Downgraded back to 1.1.4 and the link is back solid, no cloak - rate locked at 11 m.
Why did you have the data rates set so low? Wouldn't that explain your slow speeds?
Bob C
kuggie
10-03-2006, 07:47 PM
Why did you have the data rates set so low? Wouldn't that explain your slow speeds?
Bob C
I had to use the slower speeds to have a reliable connection. With anything over 2M, the link wouldn't stay connected or be stable enough to pass any traffic. Even when not cloaked, and set to 11M, the throughput was erratic. However, with it locked to 2M with no cloak or x2, I'd expect to see better then 75k throughput. Sure with a 1M setting, 75k is about right.
Kevin