View Full Version : StarV3 v1.2.7b build 2389 is ready for testing
The BETA has been released, and is available on http://files.star-os.com/
The Status of this BETA is stable, though use with caution and provide as much feedback as possible. Also, when upgrading to this release, ensure you make a configuration backup first. (starutil -d option)
While the change log is not complete at the moment, there are some changes listed on this thread http://forums.star-os.com/showthread.php?t=6714, and previous BETA postings (1.2.1b and newer)
!ATTENTION!: When upgrading the WRAP or PC releases, please make sure you do a file->save afterwords. While this is normally done automatically after the upgrade, there is a ~5% chance that it may not, and can cause your system to revert to factory settings on the next reboot. This has been resolved for the next release, and does not effect non-X86 platforms.
Changes since v1.2.6b build 2363
*) Large number of Atheros enhancements, including (but not limited to):
Many improvements, providing more performance and reliability in low signal or noisy environments.
Cloaking improvements.
Introduced a new ap / client concept called 'managed', which provides a much more reliable connection between AP and clients, as well as new features and abilities. Supported peers will have the 'M' indicator lit under the association screen.
Atheros configuration dialog now has a 'Sync' button, that will synchronize all associated 'managed' clients with the selected channel, cloaking and distance options.
The mode switch will be immediate, and no connection loss with the clients will occur. Non-managed clients will be disassociated from the AP so they can re-scan and associate again on the new channel. Only managed clients will follow the AP to a new cloaking mode.*) DHCP improvements, specifically with clients continually changing IPs when the AP has it's settings activated.
*) CPU % on the main interface does sample averaging to avoid large fluctuations during operation. (cosmetic)
*) VDS issue with fragmentation has been resolved.
*) SNMP 802.11 mibs now update stats every second, and not every 5 seconds as in past releases.
*) connlimit iptables support has been added.
Some operational differences include (mainly related to regulatory requirements):
*) Atheros channel and country code list no longer contains an 'All Channel' setting (## and #!).
*) U1 country code (US + FCC3) no longer contains the FCC3 channels, however country UZ can be used in it's place for systems that require them.
*) Due to the nature of our unique rate control, the rate specified is now a MAX rate, and not a FIXED rate.
*) The upcoming 1.3.0 release will contain both a World and FCC version. The World version will support the 'all channel' option.
For best operation, please ensure your client and AP use the same country code.
For those wanting to try the live upgrade feature via starutil, simply add the -a (apply) flag to the command line when uploading the firmware.
This requires that your system is using build 2321 or newer, and starutil 1.16.
HotSpot notes:
The HotSpot offered is vastly different from the version offered in V2.
To configure the HotSpot, there is a new 'hotspot' pull-down menu entry. The configuration script should be self explanitory.
The website users log into is now hosted on your own webserver, and not on the StarV3 box itself. We have offered a login webpage template on our files website, though any ChilliSpot login portal will work just as well.
While in the SSH interface, you can press ALT-H to view the on-line hotspot users. If there is a star (*) next to the IP address, that means the user has authenticated. The rest of the screen should be explanatory.
The hotspot user manipulation support via utilistar is also supported.
Sample HotSpot configuration steps:
Remove all IPs from wpci1 (this will be the AP the users log into)
Make sure your DNS server listed in "advanced->dns server list" is valid, as the hotspot service will require it.
Update RIP and OSPF (if used) to only advertise the Ethernet interface, as to not propagate the hotspot's private IP range.
Enter the HotSpot configuration script and enter the following commands:
hotspot enabled
interface wpci1
radius 1.2.3.4 <-- change to your radius server
radius_secret MySecret <-- change
login_server http://my-auth.server.com/ <-- change to the url where you installed the login script.
login_server_secret 5d8cp1fr9ua <-- change to match the one specified in your login script
dhcp_network 192.168.57.0/24
dhcp_dns 1.2.3.4 <-- change to your DNS server
Enter this in your NAT script: masq from 192.168.57.0/24 to dev ether1
Activate Changes, and you are done.If you use the default domain (hotspot.star-os.com), and default IP range of 192.168.57.0/24, then your customers can use the "exit" keyword in the Internet Explorer address bar to go to the logout page, if the popup window is closed. You can setup similar keywords for your own network if you do not use the default settings.
Notes regarding the Login script:
This is the web-based login prompt your HotSpot users will see when they try to access the Internet.
The system requirements needed for the Login script is a webserver and a stock install of PHP. (Perl login scripts are also available).
The only purpose of the login script is to collect a username and password from the user, and forward it back to the V3 hotspot system for authentication and can be hosted anywhere.
wwalcher
07-21-2007, 05:46 PM
Does this version have WMM QOS support?
bobbyc
07-21-2007, 06:18 PM
I have 5 WAR1 x2 SR9 clients running 1.1.13 off a 1.1.13 WAR4 x2 SR9 AP. Rates were locked to 18 on all clients and AP. Signals are good to provide very solid connections with ~600KBps rx/tx throughput with superA/G disabled and 0% packetloss from AP to clients even while performing throughput tests.
Things still seemed great and fast after I upgraded all 5 clients. I upgraded the AP and it seems that the association rates like to hover on 6 and 9 (mostly 9) rather than 12 or 18. Throughput is ~350KBps and there is packetloss to the clients when performing throughput tests.
I doubt its noise causing the 6 or 9mbps auto rates because of the good and stable performance the past few months at 1.1.13. Do you think there is more driver work to be done to the auto rate setting? Do you think its a good idea to offer a way to lock the rate like in the past other than a max rate?
Bob C
Does this version have WMM QOS support?
Yes, WMM / QOS is in this release.
Some of the new noise avoidance code in the clients need some time to 'warm up' so to speak, and will level out after a short period of time (and traffic).
In the new interface, different types of rate locking will be introduced. The lower than normal rates as seen are absolutely normal, and do not indicate a problem.
While this release has proved to operate exceedingly well, there is always room for tweaks and improvements. The rate thresholds and other items will be adjusted from time to time to give a good balance between performance, and reliability on marginal links.
I have 5 WAR1 x2 SR9 clients running 1.1.13 off a 1.1.13 WAR4 x2 SR9 AP. Rates were locked to 18 on all clients and AP. Signals are good to provide very solid connections with ~600KBps rx/tx throughput with superA/G disabled and 0% packetloss from AP to clients even while performing throughput tests.
Things still seemed great and fast after I upgraded all 5 clients. I upgraded the AP and it seems that the association rates like to hover on 6 and 9 (mostly 9) rather than 12 or 18. Throughput is ~350KBps and there is packetloss to the clients when performing throughput tests.
I doubt its noise causing the 6 or 9mbps auto rates because of the good and stable performance the past few months at 1.1.13. Do you think there is more driver work to be done to the auto rate setting? Do you think its a good idea to offer a way to lock the rate like in the past other than a max rate?
Bob C
pananix
07-21-2007, 08:57 PM
Some of the new noise avoidance code in the clients need some time to 'warm up' so to speak, and will level out after a short period of time (and traffic).
In the new interface, different types of rate locking will be introduced. The lower than normal rates as seen are absolutely normal, and do not indicate a problem.
While this release has proved to operate exceedingly well, there is always room for tweaks and improvements. The rate thresholds and other items will be adjusted from time to time to give a good balance between performance, and reliability on marginal links.
Hats off. Things are running _very_ well and the VDS issue is resolved. While I didn't upgrade the two units that reset themselves to factory under 2388 via the "shortcut" method (didn't feel like going out into the field at this late hour with the rain and all), I did upgrade them manually and all is well. Noticeable improvements all around. Now I just need a world version for a couple of systems.
Thanx Valemount team.
luke541
07-22-2007, 01:24 AM
I have 2 metro's that I just loaded the latest beta on. I can ping the ip of the eth0 interface and 2 of the wireless interfaces. The wireless interfaces show in a scan from my laptop with the ssid's I set etc, but I cannot associate, or ssh via direct ethernet connection to the ethernet port of the board. Connection refused each time. No startuil access either.
I seem to be locked out, anything I can do with the Serial cable Tony?
eoinok
07-22-2007, 04:23 AM
Hi Tony, does this release have the "improved" oslr in it?
Power cycle the board and see if it helps.
I have 2 metro's that I just loaded the latest beta on. I can ping the ip of the eth0 interface and 2 of the wireless interfaces. The wireless interfaces show in a scan from my laptop with the ssid's I set etc, but I cannot associate, or ssh via direct ethernet connection to the ethernet port of the board. Connection refused each time. No startuil access either.
I seem to be locked out, anything I can do with the Serial cable Tony?
Yes, it is using the latest OLSR.
Hi Tony, does this release have the "improved" oslr in it?
bobbyc
07-22-2007, 10:29 AM
Thanks. Everything else looks good. I'm keeping the AP and clients at this release. Quality is staying at 100 and I'm using WDS; was able to take the AP off the bridge group since it's not required there anymore.
I tested the 'sync' and it seems to be working great. Went from x2 to x4 and back, and the clients all followed and didn't complain.
I adjusted the distance from 3 miles (clients are probably half a mile max from this AP) to def, and back to 3 miles using the sync feature. 1 of the 5 clients never followed back to the 3 miles; even after repeatedly pusing the sync button on the AP. I manually set that client back to 3 miles.
Thanks,
Bob C
It's probably not a good idea to use 'def', as your clients will follow to it, however it's only good for a few hundred feet making it hard to get them back again. :)
esandine
07-22-2007, 10:35 AM
I have an WRAP AP with 5 users, a WAR1, WAR2 and 3 Deliberant 2300s. The site was B-only and working with no issues.
Upgraded WRAP AP and WAR clients, changed all clients to G-only when they rebooted. The three non-WAR cleints came back up fine, but the two WAR's IP won't come up. IP are static and signal is same as before.
I went to the WAR2 site and it shows its associated but can't pass traffic. Are there still issues with G?
Eric
bobbyc
07-22-2007, 10:40 AM
It's probably not a good idea to use 'def', as your clients will follow to it, however it's only good for a few hundred feet making it hard to get them back again. :)
Oops.
I manually changed the client distance back to 3 miles by logging into it over the wireless link in question... I wasn't locked out at all by setting the distance to def.
esandine
07-22-2007, 10:49 AM
Just rolled the WRAP AP back to 1.1.13-2080 and the WAR2 client came back up. The WAR1 client is still not connected and I don't have access to see what going on on the client side right now.
Funny thing is there is also a PTP SR9 link on the WRAP too. It is set to G-only and it stayed running fine. It goes back to a WAR4.
Eric
luke541
07-22-2007, 10:57 AM
Hey Tony, Tried that many times. It still won't let me ssh to it though.
Once you sync'd with the 3 miles distance, did you re-login to the client, or did you check the distance option on it using an existing login session? All options are updated (distance included), however you must re-login to the client in order to see the update.
Oops.
I manually changed the client distance back to 3 miles by logging into it over the wireless link in question... I wasn't locked out at all by setting the distance to def.
bobbyc
07-22-2007, 11:02 AM
I probably had a separate ssh login to the client the whole time, while I was logged into the AP via another putty window and playing around with the sync feature... so that explains it.
It's very cool BTW.
Bob C
There are no known issues with he 11G support in this release. Once a client associates, continually ping it and see if the client starts responding after a short time.
What signal levels do you see between the client and APs?
I have an WRAP AP with 5 users, a WAR1, WAR2 and 3 Deliberant 2300s. The site was B-only and working with no issues.
Upgraded WRAP AP and WAR clients, changed all clients to G-only when they rebooted. The three non-WAR cleints came back up fine, but the two WAR's IP won't come up. IP are static and signal is same as before.
I went to the WAR2 site and it shows its associated but can't pass traffic. Are there still issues with G?
Eric
If you can put a serial cable on it, and provide me a copy of the output via a PM message, that will help.
Hey Tony, Tried that many times. It still won't let me ssh to it though.
esandine
07-22-2007, 11:17 AM
At the AP the WAR1 client sig is -73 (same under both release and beta).
I upgraded the AP again to the beta (both clients are on the beta) with the same results. Neither WAR client will connect, though the signal looks the same as before.
As soon as I go back to the 2080 release the WAR2 comes back, but the WAR1 doesn't and stays in N.
Both WAR clients are set up the same.
The SR9 PTP is set to G-only , but the WAR4 that is it's AP is still on 2080.
mimbach
07-22-2007, 11:33 AM
snmp seems to be running correctly in this version. Thank you for fixing it.
What rates show on the association list? Also, can you try to select 802.11b/g mode, and see if the behavior changes when running the new release on the AP?
At the AP the WAR1 client sig is -73 (same under both release and beta).
I upgraded the AP again to the beta (both clients are on the beta) with the same results. Neither WAR client will connect, though the signal looks the same as before.
As soon as I go back to the 2080 release the WAR2 comes back, but the WAR1 doesn't and stays in N.
Both WAR clients are set up the same.
The SR9 PTP is set to G-only , but the WAR4 that is it's AP is still on 2080.
Yes, the snmp has gone through a subtle update in this release (updates every second, as opposed to every 5 in the past releases). This should make it easier for people to graph, and keep statistics.
snmp seems to be running correctly in this version. Thank you for fixing it.
esandine
07-22-2007, 11:53 AM
At the AP the rate was showing rx 1 tx 6 and N.
After 30 minutes and pinging over 1000 packets with 100% loss the WAR1 client came back to life. The AP is on release 2080 the client on the beta. Both are set to G-only and we're using WEP.
Now that everything is up again, I'll try putting the AP back to beta and see what happens.
EDIT - I tried using B, B/G and G-only prior to even posting with no noticable difference.
Thank you. Puzzle pieces are starting to fit together.
I am pleased to hear things are working well. Doing an upgrade, and saving afterwords is your best bet right now. After hearing about your problem on two systems, I have done much digging and found that there is a small chance that the configuration may not get automatically saved after the upgrade procedure. (using the GUI upgrade procedure, or starutil -f -a statement). This has been resolved for the upcoming release.
For the time being, simply do a file->save after an upgrade to guarantee everything is good to go.
This only effects X86 systems (X86-PC and X86-WRAP)
Thank you for bringing this to my attention.
Hats off. Things are running _very_ well and the VDS issue is resolved. While I didn't upgrade the two units that reset themselves to factory under 2388 via the "shortcut" method (didn't feel like going out into the field at this late hour with the rain and all), I did upgrade them manually and all is well. Noticeable improvements all around. Now I just need a world version for a couple of systems.
Thanx Valemount team.
Hmm, Haven't found a sync feature yet,
It's in the atheros configuration dialog. (can be used on any card that is in AP mode)
Beebe
07-22-2007, 12:23 PM
I just upgraded an AP with 9 clients associated. They are a mixture of war2 and compex clients. All use WDS. I set a ping watchdog on each client to make sure the WDS would stay established while I went through the upgrades. I upgraded the old fashioned way where I'd ssh into the board to do the upgrade. The upgrade went flawlessly. The AP and all 9 clients are on 1.2.7b. The ping times and throughput tests look really good. I'm pretty sure it's significantly improved, especially on the marginal links.
I like this release so far. I like that Compression and Fast Frames both work on wds clients now. Only thing I'm not so sure about is that the speed automatically backs off when you might not want it to. I'm not sure if this is the best thing to do, but I'm setting everything on auto since it doesn't really lock into the rate you set anyway. It seems like you might as well get the fastest rate you can?
Thanks,
Roger
esandine
07-22-2007, 12:59 PM
Tony,
I thnik something is definatley not working right when a WRAP is the AP with the new beta. I put release 2080 on the AP and the WAR2 comes right up and the WAR1 comes up after about 20-30 minutes.
I'll roll the clients back to 2080 and then update the WRAP AP to the beta and see what happens.
In the mean time I've upgrades a WAR4 AP and 3 WAR2 clients and they operate as expected.
Thank you. Puzzle pieces are starting to fit together.
esandine
07-22-2007, 01:31 PM
Spoke too soon. One of the WAR clients has not come back up, enroute to the site to see what the problem is.
Tony,
I thnik something is definatley not working right when a WRAP is the AP with the new beta. I put release 2080 on the AP and the WAR2 comes right up and the WAR1 comes up after about 20-30 minutes.
I'll roll the clients back to 2080 and then update the WRAP AP to the beta and see what happens.
In the mean time I've upgrades a WAR4 AP and 3 WAR2 clients and they operate as expected.
esandine
07-22-2007, 02:54 PM
Rolled back the WAR1 client to release 2080 and it acts as expected with AP both at release 2080 and beta, but with WAR1 on beta and WRAP AP on beta nothing with G-only and on B it takes 30+ minutes to associate.
The other site I've taken back to release 2080 without experimenting too much. WAR4 on 2080 and 3 WAR clients, only two came right back up the third didn't come back up after 25 minutes or after a power cycle. Rolled it back to 2080 and it came right back up.
Any ideas??
bobbyc
07-22-2007, 03:31 PM
Can you mention what distance and rate settings you have on AP and client?
Also, when B only with this new beta release after half an hour of waiting for it to associate, is it a solid link? What kind of quality and throughput are you seeing?
Bob C
bobbyc
07-22-2007, 03:36 PM
Did anybody else notice radius-acl being turned on when upgrading to this beta from 2080 on a war4? Is it normal and have to do with the hotspot features?
Bob C
Radius ACL is not related to hotspot at all. Are you using ACL at all (radius or not), or have any cards disabled in your system by any chance?
esandine
07-22-2007, 05:02 PM
Distance is less than 1 mile, some trees, but very good results using 2080. Rate at AP is 6, client auto.
Link is good. Quality between 90-100 and pushing 400KB
Can you mention what distance and rate settings you have on AP and client?
Also, when B only with this new beta release after half an hour of waiting for it to associate, is it a solid link? What kind of quality and throughput are you seeing?
Bob C
luke541
07-22-2007, 06:13 PM
I'll get to them tomorrow Tony and let you know on the serial output. I really don't know what happened. I had 2080 on both war metro's and uploaded the beta, flashed, and rebooted via the file menu. IP's came up on all interfaces, but it won't let me ssh to it. Instatly connection refused.
By the way, Hats off to you guys, this version is performing aswome! The Sync feature is working really cool for me too.
Keep it up. ;)
bobbyc
07-22-2007, 10:00 PM
Radius ACL is not related to hotspot at all. Are you using ACL at all (radius or not), or have any cards disabled in your system by any chance?
Hi,
Nope. What menu items should I look at to disable it? I don't think it was enabled in build 2080, unless by accident.
Bob C
Look under the ACL script under your wireless card's interfaces menu.
bobbyc
07-22-2007, 11:41 PM
Well this might help:
1st card is a WLM54G non super in AP mode (mac 7.8 phy 4.5 analog 5.6)
2nd card is a WLM54GS super in client mode (mac 7.9 phy 4.5 analog 5.6)
3rd card is a SR9 in AP mode (mac 5.9 phy 4.3 analog 4.6)
1st card 'radius and advanced acl' list is the older simple type of screen titled "#Atheros Access Control List (ACL)"
2nd and 3rd cards 'radius and advanced acl' list is the newer type titled "# Advanced ACL w/ Radius Authentication, Authorization, and Accounting (AAA)"
Anyways, I looked thru the lists and acl is disabled on all three cards.
Bob C
Thank you for the information.
pananix
07-23-2007, 12:19 PM
I like this release so far. I like that Compression and Fast Frames both work on wds clients now. Only thing I'm not so sure about is that the speed automatically backs off when you might not want it to. I'm not sure if this is the best thing to do, but I'm setting everything on auto since it doesn't really lock into the rate you set anyway. It seems like you might as well get the fastest rate you can?
Thanks,
Roger
Roger,
After upgrading, I tested a couple of my backhaul links and this is what I found:
In auto mode, rates would run 18-24 on one link, with link quality bouncing from high 90s to mid 60s (lots of retries). tcp throughput test showed an avg of 1800kbps but with lots of variation -- no big improvement over 2080.
Changed both sides of the link to 12Mbs. Link quality locked in at high 90s to 100. tcp throughput test jumped to 2600kbps.
So you might want to conduct your own tests. For me (one WRAP to a WAR) the backhaul link was faster and more stable on a lower rate.
David-
Magician
07-23-2007, 04:40 PM
I have had this link up for atleast a year. With 1.2.6 and prior the link would be -74 to - 82 and pushing 10+ meg with no failures. When I upgrade to 1.2.7 the link wont hook. Infact the client wont even see the ap on a scan. Flash the unit back to 1.2.6 and presto it works. I was really hoping to be able to have qos as there are several clients with voip and vpn's on the tower. Anyone else? Also with 1.2.6 the vds wont connecto to my house which is on a external network.
All 1.2.x releases have QoS available.
The upcoming 1.2.8 release is around the corner, and should help.
Magician
07-23-2007, 07:51 PM
You think it will help the 36+ shot?
luke541
07-23-2007, 08:52 PM
Tony, the Metro was setup with a public on eth0, wpci1, wpci2, rip was the only other service running, and dhcp-auto auth.
After hooking up via serial and getting through that a couple times I was able to get on the board and reflash to 2080. I am going to try and reflash again, but wondering if anyone else can confirm they are having luck flashing the metro with the latest beta?
Thanks!
The metro is one of our primary test platforms. It is strange that you have experienced an issue with it.
Give it a go, and if it acts odd in any way, let me know your configuration, power supply, and card types you are using.
luke541
07-23-2007, 09:11 PM
I would have assumed that. Maybe I have a bad download or something. Odd it happened to two identical metro's.
Anyhow another issue i'm encountering is a war2 with the letest beta that gets 1000's of errors and horrible connectivity in a, b or g, Its a routed ptp setup.. Radio's are a wlam54g, and a wlm54ag for the bakchaul. I switched out the wlm54a/g today with a cm9 and it was doing the same thing. I just reflahsed to 2080 and the issue went away and all is back to normal again.
Not sure that helps you much, but found it worth letting you know sense it only did that with the latest beta.
The cards are wlm54g's and wlm54ag's from one of your resellers. I have been noticing the labels are starting to randomly look differant. Not that it means anything. Power supplys are 24v are the ones' also provided by the reseller "3com" and direct to the board.