StarV3 v1.2.8b build 2396 is ready for testing [Archive]

tony

07-23-2007, 07:46 PM

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)

http://www.star-os.com/images/new.gif1.2.x client notes:
For best results, please use 1.2.x clients with 1.2.x APs. If you wish to inter-mix with V3 1.1.x, or other APs, please disable SuperA/G features on the client first as to prevent any incompatibilities that can cause connectivity issues.

Changes since v1.2.7b build 2389
*) Continual Atheros tuning to balance reliability and performance on marginal links.
*) X86 releases will now save settings immediately after an upgrade without the need to do a file->save before rebooting.

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.

There is an operational difference between release 1.2.6 and 1.2.7+:
Only managed sessions (the 'M' association option is lit) will benefit from the enhanced rate system used in StarV3. When the peer does not support managed sessions, it will resort to a different (more compatible, but less optimal) PER rate control system. The end result is that the clients with less then optimal links may experience slightly lower overall rates and/or Q%.

The upcomign 1.2.9b release will support fixed rates (not max rates) for the PER-based rate system, which will help in providing more reliable link.

The reason for this change is simply compatibility.

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.

Magician

07-24-2007, 07:18 AM

So far so good I havent had any complaints

tony

07-24-2007, 08:12 AM

Thank you for the update. This release should work quite well for most people.

bobbyc

07-24-2007, 08:40 AM

Very nice release. On one of my SR9 X2 APs, I have a client who can only get -82 signal with a rootenna. I've been meaning to go out there and try a grid antenna.

Anyways, his upload has been a very consistent 150KBps (without superA/G) and as soon as this release was put on the client, his upload is now 220KBps.
Bob C

mrmike

07-24-2007, 01:11 PM

One problem I saw last night on the 127b release was no IPs and no through put on an upgrade. I use WEP key 3. Is this fixed?

therealboss

07-24-2007, 01:17 PM

Just upgraded a WRAP to 2396, and found a problem with "Hide SSID", this WRAP is the client box and it will not connect. Logged on to the AP and turned off "Hide SSID" and I got a connection right away.

Setting on Both CPE & AP as follows:-

11.a
cloaking X2
Super A/G = yes
Short Peramble = yes
Inter BSS = off
Tx Power = 18
Radio CM9

CPE WRAP with 2396
AP WAR4 with 2080

tog

07-24-2007, 01:34 PM

ripv

07-24-2007, 02:12 PM

One problem I saw last night on the 127b release was no IPs and no through put on an upgrade. I use WEP key 3. Is this fixed?

Lonnie confirmed the key slot issue was fixed a while back see below..

No, that was fixed a while ago, so the key slot is fine. I do notice that the remote does not use compression or fast frames. Normally they show up so either you have shut them off or the radio card has a problem.

Did you configure the remote WAR1 by hand or transfer a config file?

Here is the full thread just in case it's any help

http://forums.star-os.com/showthread.php?t=6784

ripv

07-24-2007, 02:16 PM

therealboss, you are likely using a country code/frequency setting that enables DFS. As a client, DFS is passive and does not transmit solicitations for the SSID it's looking for.

So, when using DFS, you cannot hide SSID at the AP.

If Tony feels like getting super fancy maybe he could add a warning dialog to the GUI when DFS is active and Hide SSID is enabled...

You don't really need to bother hiding your SSID when using 2x cloaking.

Tog, sorry for being a little off topic but how/where would one find out what country codes / freq's use DFS ?
Is it new in the latest beta - all my ap / clients are .11a with 2x cloaking and all hide SSID
**Scratch that found the info on this thread http://forums.star-os.com/showthread.php?t=5358

Also on cloaking - is cloaking unique to StarOS or is it a standard ie. if you don't hide ssid can anyone with
CPE equipment supporting cloaking as a feature see your AP ?

tog

07-24-2007, 03:42 PM

To answer your question, StarOS 11a, 11b and 11g 2x and 4x cloaking is not a standard (IEEE or otherwise), however it is also not unique to StarOS. Even the IEEE 802.11n draft standard now has 10MHz wide channels in it.

Some other wireless software from other vendors (MT and the like) is able to at least see your SSID and some may even be able to communicate with you in 2x and 4x cloaking modes. Even a plain vanilla 802.11n atheros card in a client PC (Windows/Mac) seems to at least see 2x cloaked APs because 10MHz wide channels is part of 802.11n.

But I wouldn't worry too much about having to turn off "Hide SSID", it wasn't all that fantastic anyway. The most you could hope for from it is hiding your 11g AP's SSID from standard Windows/Mac client and even then there are some utils that pick up the "hidden" SSID anyway.

tony

07-24-2007, 04:16 PM

With regards to cloaking - we were the first to product it, but have since been duplicated by other vendors, some successfully, others not so much.

The only system we can guarantee compatibility with are other V3 systems, however others may be able to pick out the SSID as Tog mentioned.

5Mhz and 10Mhz in 4.9 band has since become the norm for public safety, but again, implementation differs from vendor to vendor.

With regards to DFS and Hidden SSID - StarV3 v1.1 and StarV3 v1.2 / v1.3 differ in how this is handled. v1.2 / v1.3 is standards based, and as such use 'passive mode' channels where required (marked with a star '*' in the channel list). Any channel that has a star on it cannot be used with Hidden SSID. (no, this is not a bug). As tog mentioned, a warning may be a solution to limit the confusion.

tog

07-25-2007, 01:16 PM

Well I'm afraid I only had about 5 minutes with 1.2.8b before I had to go back to 1.1.13. I killed my connection pretty quickly by uploading at full speed towards the AP.

This is my home client unit, it's on a v3 1.1.11 2x cloaked 11a AP.

I had set my transmit rate towards the AP to 36 and during an upload as the Q% wavered all over the place, the rate went down to 6 a lot. My speed was dismal, I usually get about 400K/sec with 1.1.13, here it was about 150K/sec if I was lucky.

So I forced my transmit rate to 24 with not really any better luck. Then I lost my connection to the AP and it went through a 15 second re-scan and re-associated.

I continued my uploading after that had timed it out and seized my connection up completely within another minute. It showed it was still associated and Q% showed normal (90 - 100) but it stopped passing traffic and was permanently stuck.

I went back to 1.1.13 and it's fine again.

tony

07-25-2007, 02:33 PM

What system did you upgrade, the AP or Client?

tog

07-25-2007, 05:33 PM

This was a 1.2.8b client (my home unit) and a 1.1.11 AP.

tony

07-25-2007, 05:35 PM

When you experienced the problem, did you upgrade both the AP and client, or just one of the systems?

Also, what signal do you have on the AP and Client?

tog

07-25-2007, 07:35 PM

I upgraded only the client, the AP remains untouched at version 1.1.11. It's a very important AP so I'm not upgrading it.

I have a -70 to and from the AP. The AP is locked to transmit towards me at 18 and my best performance towards the AP is when I am locked at 36. I just sent a non-compressible file towards the AP at around 600K/sec at 36mbit and the Q% with 1.1.13 on my client unit was around 90 - 95.

I'm only about a block away and the 5GHz AP antenna is a cute little 10 inch omni.

DLNoah

07-25-2007, 08:18 PM

We have a subnet with six different tower sites backhauling to three radios on our central tower, recently upgraded all the WRAPs involved to V3. All the boards were upgraded to 1.1.13 and were working correctly. Then, we upgraded one leg of the three (two backhauls to one AP on the main tower, a total of 3 sectors across two boards as APs for each remote tower site) to 1.2.8b, and would get intermittent broadcast storms running across the entire subnet, and people on the subnet were having problems getting DHCP addresses.

All our CPEs are 11b only units, our APs are set up with the wireless cards bridged to the ethernet 1, back to a central switch that routes traffic to the DHCP server. Downgrading just the radios involved in the backhauls (the AP on the main tower and the clients on the remote towers) to 1.1.13 resolved the broadcast storm and addressing issues.

tony

07-25-2007, 08:30 PM

When you say broadcast storm, what is the traffic in question, and what system is it originating on?

DLNoah

07-26-2007, 07:29 AM

The traffic was 200Kb-500Kb of ICMP traffic. In beacon it shows with 0.0.0.0 as both source & destination traffic. The end result was to make pings from our central gateway to several backhaul clients on the subnet (all on 1.1.13) unstable. The traffic would seem to come and go in intervals; sometimes it would last for a few minutes, then damp down for ten to fifteen minutes, then kick up again for five to ten minutes, and so forth.

tony

07-26-2007, 08:09 AM

There is no way for a V3 system itself to generate this traffic, but it would be interesting to know what client it's coming from.

Is your network bridged by any chance?

To find out which client (mac address) the traffic originated from, you can use the console tcpdump utility. (specify the -vve parameter to super verbose, which also shows source and destination mac addresses).

tony

07-26-2007, 08:16 AM

Thanks, that is exactly what I needed to know.

If you get a chance, can you try the 1.2.6 release, and let me know if it works similar to the 2080 release?

I upgraded only the client, the AP remains untouched at version 1.1.11. It's a very important AP so I'm not upgrading it.

I have a -70 to and from the AP. The AP is locked to transmit towards me at 18 and my best performance towards the AP is when I am locked at 36. I just sent a non-compressible file towards the AP at around 600K/sec at 36mbit and the Q% with 1.1.13 on my client unit was around 90 - 95.

I'm only about a block away and the 5GHz AP antenna is a cute little 10 inch omni.

tony

07-26-2007, 08:35 AM

Thread starter has been updated with new information.
http://forums.star-os.com/showthread.php?t=6832

DLNoah

07-26-2007, 09:38 AM

Yes, the network is bridged. I just wanted to post here in case it turned out to be some difference between 1.1.13 and 1.2.8b; when we downgraded both ends of the backhauls that had been on 1.2.8b to 1.1.13 the problem stopped. I will try the -vve if I have the ability to experiment with the beta again.

tony

07-26-2007, 09:46 AM

The 1.1.13 and 1.2.x releases are vastly different as the 1.2.x release does a better job to avoid 'censoring' (so to speak) traffic flowing over a bridge, and can be a little disconcerting finding more traffic than normal after an upgrade. Once you track down the culprit client, everything should go back to normal.

itcowboy

07-26-2007, 11:49 AM

I have read your directions for configuring the 'Hotspot' and have some questions. They largely relate to how you have implemented Chillispot / Radius.

Here is our generic configuration.
Gateworks GW2348-4 / Compex WLM54AG (4 installed)
StarOS build 2396
5 IP subnets configured - 1 on the ethernet, 1 on each AP (x 4)

1. I see that Chillispot has it's own DHCP Server but everything I've read about Chillispot says that it can only deal with 1 subnet. Can/Do we need to setup an instance of Chillispot for each AP interface? Otherwise are we expected to bridge all of the AP interfaces together? (hopefully no)
2. We use OSPF to route our network and we generally assign a /30 to customers. We do this by putting the gateway static on the interface they associate with and then we configure the OSPF to announce that network. If we have to remove the statics to make the hotspot work, does that make OSPF / statics and hotspot mutually exclusive?
3. In the configuration menu for a wireless interface, there is a new option that says 'radius and advanced acl'. When I open it, I see examples of how to implement an ACL, but nothing about radius. Is there a way to implement a radius based ACL?
4. There is an 'anyip' patch for Chillispot that allows for the use of any ip. Was this implemented? This may resolve many of my questions.

Here is what I'm hoping to achieve:

1. Hotspot Controller Listens on all defined interfaces
2. When a subscriber attempts an associates, it's mac is passed to a radius server that either returns configuration information (max upload/download, timeouts, redirection urls, etc) or returns a reject. If a reject is returned, the hotspot controller lets the user associate and then redirects requests to a 'hotspot session' that gathers information and hopefully returns with a valid session. If not, it redirects them to freeloader hell.

tony

07-26-2007, 12:06 PM

1. Yes, only one instance of the hotspot is needed / can be active. All interfaces participating in the hotspot are to be bridged together. This is not a deficiency or a bug by any means.

2. The Hotspot will be in sole control over assigning customers IPs. OSPF can continue to redistribute the hotspot's subnet by referring to the tun0 interface (which will contain the subnet in question).

3. There is a new (extended) ACL script available. If you already had an ACL script prior to installing the update, then you will not see the new features listed. The new script (for reference) can be downloaded here (http://www.star-os.com/factory-scripts/ath-acl.txt). This feature is in no way related to the hotspot functionality. While it will provide session limits and accounting, it does not handle bandwidth management or DHCP assignments.

4. We only use patches that can be considered reliable. We have not had a chance to evaluate the anyip support, but will add support for it in the future if it proves to be reliable.

-----

1. The hotspot will listen to all interfaces that are part of the primary interface's bridge group.

2. This would require the mac authentication support in the hotspot which is in development. If the mac authentication fails, it will present the end user with a login page, or a portal of choice.

itcowboy

07-26-2007, 12:39 PM

Thank you kindly for the answers. I need a little clarification on a couple of things.

1. If we have 4 AP units and they each have roughly 25 customers then that would end up with 100 subscribers on machine. Generally there would be an IP assigned to the subscriber module and one for the customers router/computer. That would mean that we have roughly 200 IP's in use. Is there some kind of mechanism to control chatter on the network from having that many computers on a bridge? We have seen incredible performance with very little chatter by breaking up the AP's into seperate subnets. Do I need to be concerned about this? I wasn't trying to say what you have is a bug and I wasn't calling it deficient. I'm just wondering if there is some code that will help mitigate that many IP's on a network. I'm just trying to get a sense of the design scope of the hotspot controller.
2. If the hotspot has to be in controll over all of the IP's, is it possible to assign a /30 to a customer? I don't see how that would be possible without being able to assign an ip to the bridge. Again, I'm just trying to understand what the scope of the hotspot controller is. It sounds great for doing temporary session controll, but isn't really designed to handle complex ip arrangements. Either way, I just want to understand what the intended design is.
3. Your new radius ACL script brings me pure joy!!! I have a question about this. How often does the radius client attempt to authenticate the client? Does it attempt everytime the subscriber associates? I guess I'm just wondering if there is a cache of attempted subscription attempts and if there is a way to set it so it doesn't attempt to auth every time. Otherwise, is there some other mechanism to prevent a flood of radius requests?

I'm seeing how complex it is to integrate the hotspot / radius / acl into the software. There are many mutually exclusive design goals. I would love to see how you intend to route through these.

At any rate, I LOVE what your software is doing for my business and this new release has rocked my world. I installed it, ran it, walked outside and shouted 'Can I get an AMEN!!' (my dog wagged her tail, the cat hid under a bush)

Thanks!!!

Will MacHugh

tog

07-26-2007, 01:22 PM

Thread starter has been updated with new information.
http://forums.star-os.com/showthread.php?t=6832

Hmm that's neat, so you'll probably end up with fully locked rates that don't shift down for un-managed clients and a more finely-tuned better working auto-rate for managed clients?

If you get a chance, can you try the 1.2.6 release, and let me know if it works similar to the 2080 release?

Ok, I am trying the same scenario that was a disaster with 1.2.8. This is a 1.2.6b 11a/2x client uploading hard towards 1.1.11 AP.

1.2.6b as the 11a/2x station is performing well with the tx rate locked at 36, it's performing about the same as 2080, the Q% is excellent during a full-speed upload towards the 1.1.11 AP. (1.2.8b's Qual would go nuts, all over the place, often below 10%)

The only problem I had with 1.2.6b is that it seized up and completely stopped passing traffic though the link still showed associated with a full Qual.

I just got 1.2.6b to do the same thing, even showing 90 - 100 Qual: It disassociated, scanned for 10s and re-associated for no particularly good reason during a full-speed upload at 24 rate.

Jul 26 15:10:23 wpci0:: Card was disconnected, scanning for a new access point

I'm sure if I keep doing this test I'll eventually seize it up completely where it shows it's still associated but no longer passes traffic since I was able to do it before with full-speed uploads. It's the only reason I'm not using 1.2.6b on an ongoing basis on my client. Though I believe it took quite a while to get it to that state, I ran 1.2.6b for 10 days before it did it (but I think day 10 was the first day I really railed on it with a full-speed upload when I scp'ed something)

If nothing else I do keep easily reproducing the disassociating/re-associating. Sometimes even twice in a row so the interruption lasts for nearly 30s.

Jul 26 15:13:09 wpci0:: Card was disconnected, scanning for a new access point.
Jul 26 15:13:26 wpci0:: Card was disconnected, scanning for a new access point.

It keeps doing this pretty reliably once every minute or two during heavy uploading, 1.2.8 was doing it, too, just not as reliably since it was shifting the rate around wildly and going much slower. 1.2.8b seized up and stayed associated without passing any traffic any longer really quickly though. Within 5 minutes.

tog

07-26-2007, 01:37 PM

Thank you kindly for the answers. I need a little clarification on a couple of things.

1. If we have 4 AP units and they each have roughly 25 customers then that would end up with 100 subscribers on machine. Generally there would be an IP assigned to the subscriber module and one for the customers router/computer. That would mean that we have roughly 200 IP's in use. Is there some kind of mechanism to control chatter on the network from having that many computers on a bridge? We have seen incredible performance with very little chatter by breaking up the AP's into seperate subnets. Do I need to be concerned about this? I wasn't trying to say what you have is a bug and I wasn't calling it deficient. I'm just wondering if there is some code that will help mitigate that many IP's on a network. I'm just trying to get a sense of the design scope of the hotspot controller.

I really wouldn't recommend using the hotspot stuff for this, you are limited to one big NAT'ed subnet for the hotspot.

You really should try to stick to a separate subnet for each AP in your case.

The interfaces all bridged together and the hotspot running them all would be fine for a more basic hotel or whatever hotspot setup where the clients are laptops roaming around. I wouldn't do the same type of setup for 100 fixed wireless subscribers delivering Internet to homes and businesses.

2. If the hotspot has to be in controll over all of the IP's, is it possible to assign a /30 to a customer? I don't see how that would be possible without being able to assign an ip to the bridge. Again, I'm just trying to understand what the scope of the hotspot controller is. It sounds great for doing temporary session controll, but isn't really designed to handle complex ip arrangements. Either way, I just want to understand what the intended design is.

You are correct with your second-to-last sentence, chilli is designed for a pretty simple one-subnet NAT setup. Chilli itself does the NAT'ing, it's not even handled by Linux's IP masq stuff.

I'm seeing how complex it is to integrate the hotspot / radius / acl into the software. There are many mutually exclusive design goals. I would love to see how you intend to route through these.

I don't think there's anything to keep you from using the RADIUS ACL and chilli together, however it doesn't make much sense since a hotspot is generally run as a fully open AP with an obvious broadcasted SSID and no security. The security is supposed to be handled by the hotspot captive portal bit.

If you really wanted to use RADIUS ACL I don't think there's any limitation stopping you from doing so.

Peanut

07-26-2007, 03:58 PM

I had an issue with two of my clients after moving an AP to this release.

They are both using a SMC-WEBTG EU ( part no 751.8103) -
http://www.smc.com/index.cfm?event=viewProduct&localeCode=EN_IRL&cid=5&scid=84&pid=1476

The chipset used is detailed here - (AP51 SoC/Atheros AR2316)
http://www.smcnetworks.cz/data/downloads/Katalogy/Catalogues/WLAN%20Chipset.pdf

Problem was that they couldn't associate with the AP, even though they could see it in the site survey. This was using any combination of b-only, g-only, or mixed b/g on the client.
The AP is set to b/g mixed, no encryption, and is using an NL-5354MP+ Aries 2 Senao card (also identical problem in a second AP using a R52 card)

I took one of the units back to investigate further, and found that it could in fact associate and pass packets at close range. However, the signal on the AP read -92.

I then went back to the 1.1.13-2080 release, and the signal improved to about -72, and the units started working again at the customer premises.

I'm not sure if this also happened in a previous 1.2 beta because I hadn't tried any previously.

tony

07-26-2007, 04:11 PM

Thank you for the information. If possible, please try release 1.2.6 or 1.2.7 if you have time, and let me know if the same problem persists.

tony

07-26-2007, 04:59 PM

I have just re-posted 1.2.7 and 1.2.6 releases for people to do comparison tests with.

I am very interested to hear which of the three releases works best, and how.

Peanut

07-26-2007, 05:35 PM

Thanks Tony,
I have tried both 1.2.6 and 1.2.7 but continue to have the same issue, until reverting to 1.1.13.
I'll try 1.2.1...
..no go on 1.2.1 either.

I really liked 1.2.8 when I had it on though - got a lot more stability from some dodgy connections, also the new signal level averaging(?) makes it a lot easier to compare levels from different cpes.

tony

07-26-2007, 07:22 PM

If possible, can you tell be the following regarding your AP:
1. What brand of card is it?
2. What is the power setting set too?
3. What antenna port do you have selected?
4. What country code are you using?
5. What band / channel are you using? (I'm assuming 11b/g from past messages)

The new AP requires the clients to send some data before you will see a proper signal level from them. (the hardware does averaging, so give it a few seconds to level out with traffic).

mimbach

07-26-2007, 11:09 PM

Tony,
I am still seeing snmp problems when looking at signal, noise, etc.
Thanks,

Mimbach

Peanut

07-27-2007, 03:51 AM

If possible, can you tell be the following regarding your AP:
1. What brand of card is it?

Senao/Engenius NL-5354MP+ Aries 2

2. What is the power setting set too?

def

3. What antenna port do you have selected?

B

4. What country code are you using?

US

5. What band / channel are you using? (I'm assuming 11b/g from past messages)

b/g channel 10

Note: I am also seeing the same problem with a second AP, similar settings apart from antenna port (A), channel (3), and card (R52). I also have other clients on the AP without issues.

The new AP requires the clients to send some data before you will see a proper signal level from them. (the hardware does averaging, so give it a few seconds to level out with traffic).

Yep, it's not this however, as using the older firmware I get the association in a few seconds, with the new beta I never get it. The client however, can see a good signal from the AP in site survey mode.

Thanks

tony

07-27-2007, 07:40 AM

What exactly are you seeing (or not seeing)? I need to know details, including snmp commands in order to troubleshoot your problem.

Tony,
I am still seeing snmp problems when looking at signal, noise, etc.
Thanks,

Mimbach

tony

07-27-2007, 07:57 AM

Peanut,

Try specifying a transmit port (20 for 11b/g), and a diversity antenna, and see if this helps.

Also, are you using WEP, or ACL of any kind?

Peanut

07-27-2007, 08:37 AM

Peanut,

Try specifying a transmit port (20 for 11b/g), and a diversity antenna, and see if this helps.

Also, are you using WEP, or ACL of any kind?

Hi,
Not sure exactly what you mean by transmit port?
There's currently only 1 antenna connected to the card & I don't think I can easily add another to the 2nd port on the card.

Regardless, I tried in diversity mode also without luck.

The AP is open, no WEP or ACLs etc.

tony

07-27-2007, 08:48 AM

Whoops, I meant transmit power, not port.

Diversity setting does not need two antennas, and will choose the one with the best signal (if there is only one, then the decision is easy). This is to avoid confusion as to which antenna ports are used while troubleshooting.

What distance are all your clients at, and what is their average signal levels (on both the AP and client), when using 1.1.13?

Peanut

07-27-2007, 09:30 AM

Ok I tried changing the tx power to 20 and setting diversity, it made no difference.

Clients are mostly at a mile away, although the two with the issue are closer, maybe 1/4 mile.

Signal levels with 1.1.13 are about -70 to -80 on average, and similar on 1.2.8, except for the fact that the problem clients disappear. The other clients all remain associated.

Like I said earlier, I brought one of the affected CPE units back to test-
I installed 1.1.13 on the AP - the AP showed the affected CPE connecting at steady -72, the other CPEs were fine
I installed 1.2.8b on the AP - the AP showed the affected CPE connecting at steady(ish) -92, the other CPEs were fine

tony

07-27-2007, 09:35 AM

I sent you a PM. I need to know more about the CPEs that are not supported.

sligbot

07-27-2007, 10:00 AM

Just verifying that the hotspot software is tested and live on several of our AP's. Nice work guys!

--Rich

tony

07-27-2007, 10:50 AM

Very nice, thank you.

DrLove73

07-27-2007, 01:45 PM

I have a question regarding "wpa and advanced security".
I am to swap 2 WRAP's with V2, with one WAR-METRO with V3 1.2.8b.
There are encripted links on them, and WAR is to remain connected with other V2's over encripted links afer the swap.

Current encription for Master side is:

encryption enable
authentication wpa-psk
cipher aes
keysource local
groupkeyupdate 3600
passphrase "password"and client is:

encryption enable
authentication wpa-psk
cipher aes
passphrase "password"Tony, can you please write us proper V3 1.2.8b conterpart script so WAR connects to WRAP V2?

DrLove73

07-27-2007, 02:07 PM

One other thing.
Guys, is 1.2.8b safe (as beta can be) for more serious use?
Do you have any issues other then tog?

Tony, is 1.2.9b planed to be released in next 48 hours, or will it be later?

tony

07-27-2007, 02:24 PM

Yes, the release is more or less solid outside of a few isolated issues.

The 1.2.9b release is cooking, and will be released this weekend, possibly as early as tomorrow mid-day.

tony

07-27-2007, 02:32 PM

This should do the trick.

master side:
process wpa-master
security enabled
wpa-mgmt psk
wpa-proto any
pairwise ccmp
group-rekey 3600
wpa-passphrase "password"

client side:
process wpa-client
security enabled
wpa-mgmt psk
wpa-proto any
pairwise ccmp
pwa-passphrase "password"

I have a question regarding "wpa and advanced security".
I am to swap 2 WRAP's with V2, with one WAR-METRO with V3 1.2.8b.
There are encripted links on them, and WAR is to remain connected with other V2's over encripted links afer the swap.

Current encription for Master side is:

encryption enable
authentication wpa-psk
cipher aes
keysource local
groupkeyupdate 3600
passphrase "password"and client is:

encryption enable
authentication wpa-psk
cipher aes
passphrase "password"Tony, can you please write us proper V3 1.2.8b conterpart script so WAR connects to WRAP V2?

sligbot

07-27-2007, 05:08 PM

One question about hotspots, though. Is there a way to whitelist clients as in V2? Got some customers that want to pay with cash as opposed to through PayPal and they seem to like that way....
Thanks in advance.
--Rich

tony

07-27-2007, 05:13 PM

Right now there is no automated way to white-list customers from having to be redirected to your login site.

DrLove73

07-27-2007, 05:24 PM

Thanks tony, well deploy METRO tomorow. WRAP's there lock up often (connections refusement, but ping passes), ~18pcs of 2,4 AP's broadcasting real nightmare.

If there is place to test power of V1.2.x, that is definetly the one.

Magician

07-27-2007, 08:47 PM

I upgraded my 37 mile shot yesterday and all is well.

Link consists of:

AP
war-4 gateworks
wlm54g
pac wireless 2' solid dish

Tower
war-4 gateworks
wlm54g
pac wireless 2' solid dish

This link averaged a 75-79. We just had a severe storm where I lost my dish network and I ran these tests through the storm.

79

mrmike

07-27-2007, 09:35 PM

This is the 3d beta I have tried to use on the systems at the house. I have 1 5.8 link to the main tower on a war2 talking to a metro 1.1.13, cloaked 4x, no encryption, and an AP on a war4. On 1.1.13, I get a reading of -80 on the link, with about 10M of throughput. Never burps, never misses a beat. The AP works just fine on 1.1.13. When I install the beta firmware, the reading on the links stays at -80, but it won't associate for a while, then it will associate with a Q reading of 13, then disappear. The site survey shows the AP for the link, but that is it.
The AP at the house will show the clients, but I can't ping the ones that are static, and the DHCP ones won't grab the IP from the AP.
Questions? Solutions?

Magician

07-27-2007, 09:38 PM

What Frequency and country code are you using?

tony

07-27-2007, 09:50 PM

I am assuming your client (WAR-2) is operating v1.1.13, and your AP (METRO) is using v1.2.8b. Please correct me if I'm wrong.

There are a few things to try, or make sure are done:

1. Both systems should use the same country code. Keep in mind that '##' and other special codes are not available in the BETA.

2. If you are operating on a passive mode channel (marked with a '*' in the channel list), make sure you do not have "Hide SSID" checked.

3. Make sure your transmit power is set correctly. If it's on DEF, change it to 20 and see if it makes any differences.

4. Make sure your antenna port setting is correct. See if anything improves by selecting Diversity.

5. Disable SuperA/G features, and see if things improve.

6. Make sure your distance option is set correctly.

This is the 3d beta I have tried to use on the systems at the house. I have 1 5.8 link to the main tower on a war2 talking to a metro 1.1.13, cloaked 4x, no encryption, and an AP on a war4. On 1.1.13, I get a reading of -80 on the link, with about 10M of throughput. Never burps, never misses a beat. The AP works just fine on 1.1.13. When I install the beta firmware, the reading on the links stays at -80, but it won't associate for a while, then it will associate with a Q reading of 13, then disappear. The site survey shows the AP for the link, but that is it.
The AP at the house will show the clients, but I can't ping the ones that are static, and the DHCP ones won't grab the IP from the AP.
Questions? Solutions?

nelson05

07-28-2007, 12:50 AM

One issue to report with our tests of 1.2.8 on a 802.11a 11.5 mile link w/ CM9s. We've been running 2080 on both sides for about 90 days with no problems and uploaded 1.2.8 yesterday on both sides of the backhaul.

The upgrade went smoothly and the link came back up with the same signal readings as on 2080. Transmit power was set to def on both sides and the rate was locked at 36 with SuperAG activated. We did notice that it shifted downward quite a bit under the beta even when the quality was 100, but the shifts didn't seem to effect our throughput tests with starutil or iperf- it seemed the same, maybe marginally better than under 2080. I'm sure it has been requested previously (heck, I think I even asked once before), but it would be nice to have a little more flexibility in entering fixed rates. The MAX speed for managed clients is interesting but it would be better if there was an option to specify a range like 18,24,36 or 6-18 alongside auto and MAX and just a single fixed rate.

Also, love the new managed concept - the sync button is great! Changed cloaking modes about ten times and was amazed to watch it all happen without dropping a single ping. Worked perfectly with one client..curious how it would work on a radio with 60 attached? How do you know that all clients follow and process the command other than watching the association count? Regardless, great feature!! We did notice an entry in the system log that indicated the new cloaking modes, but did not see the display updated on the client. Ex. cloaking mode changed to 2x and propagated with sync button, but client display still shows 802.11a though a sysem log entry notes the change. I feel that I saw this noted in the release notes of a previous beta, but wanted to make sure to report it in case.

Custom channel option appears to be broken on the client... at least it was when the AP was set to 2x cloaking on frequency 5180. Even though this was the only frequency in the custom channel list of the client, it continued to scan through the entire frequency range when searching for an AP when using 1.2.8. We were actually relocating one end of the link and greatly missed this feature whe attempting to re-align the antennas. Kept thinking we had something wrong until we finally reloaded 2080 and watched it search only on that channel and acquire the signal MUCH faster.

DrLove73

07-28-2007, 08:32 AM

I've instaled 1WAR and 1 x86-PC V3 1.2.8b. Connections look very good, so far can not see any problems there.

BUT, CBQ script doesn't do its job properly.

On X86-PC I have seen even 150KB/s for user with "fb 256K", and on METRO, I've seen ~60KB/s for user with "256K" in the script.

X86-PC is Upgraded today from 1.1.13, and next router in line (also 1.1.13) qshaped same user as set in the script.

Peanut

07-28-2007, 08:39 AM

A weird thing happened there when i was swapping between the beta and release versions on a compactflash in a WRAP.

I had configured a fresh install of 1.1.13 .cf image, selected firmware upgrade to 1.2.8, then tried a reboot but it wouldn't come back up.

So I put a new copy of 1.2.8 .cf onto the cf card, rebooted, and to my surprise, it had my old settings there (IP address, SSID etc.)..

tony

07-28-2007, 08:45 AM

The managed rate system should produce better results, even at lower rates (which is part of it's design). We will be adding an option to use managed rates, or fixed rates in the future.

Once the sync button is pressed, the client's configuration is updated however you need to log out of the client, then back in to see the changes.

It appears as the channel ACL support fell over and broke itself. I will get this fixed up for the next release.

One issue to report with our tests of 1.2.8 on a 802.11a 11.5 mile link w/ CM9s. We've been running 2080 on both sides for about 90 days with no problems and uploaded 1.2.8 yesterday on both sides of the backhaul.

The upgrade went smoothly and the link came back up with the same signal readings as on 2080. Transmit power was set to def on both sides and the rate was locked at 36 with SuperAG activated. We did notice that it shifted downward quite a bit under the beta even when the quality was 100, but the shifts didn't seem to effect our throughput tests with starutil or iperf- it seemed the same, maybe marginally better than under 2080. I'm sure it has been requested previously (heck, I think I even asked once before), but it would be nice to have a little more flexibility in entering fixed rates. The MAX speed for managed clients is interesting but it would be better if there was an option to specify a range like 18,24,36 or 6-18 alongside auto and MAX and just a single fixed rate.

Also, love the new managed concept - the sync button is great! Changed cloaking modes about ten times and was amazed to watch it all happen without dropping a single ping. Worked perfectly with one client..curious how it would work on a radio with 60 attached? How do you know that all clients follow and process the command other than watching the association count? Regardless, great feature!! We did notice an entry in the system log that indicated the new cloaking modes, but did not see the display updated on the client. Ex. cloaking mode changed to 2x and propagated with sync button, but client display still shows 802.11a though a sysem log entry notes the change. I feel that I saw this noted in the release notes of a previous beta, but wanted to make sure to report it in case.

Custom channel option appears to be broken on the client... at least it was when the AP was set to 2x cloaking on frequency 5180. Even though this was the only frequency in the custom channel list of the client, it continued to scan through the entire frequency range when searching for an AP when using 1.2.8. We were actually relocating one end of the link and greatly missed this feature whe attempting to re-align the antennas. Kept thinking we had something wrong until we finally reloaded 2080 and watched it search only on that channel and acquire the signal MUCH faster.

tony

07-28-2007, 08:50 AM

Since the CBQ does auto throughput averaging to obtain the correct throughput, it may allow a few traffic bursts through, which is normal however when you do a throughput test on the client's system, you will find the numbers are correct.

I've instaled 1WAR and 1 x86-PC V3 1.2.8b. Connections look very good, so far can not see any problems there.

BUT, CBQ script doesn't do its job properly.

On X86-PC I have seen even 150KB/s for user with "fb 256K", and on METRO, I've seen ~60KB/s for user with "256K" in the script.

X86-PC is Upgraded today from 1.1.13, and next router in line (also 1.1.13) qshaped same user as set in the script.

DrLove73

07-28-2007, 11:51 AM

No, no, this is not a case. Clients are cheap Ovislink 5460 AP's not Star-OS. On V3 1.1.13, qshape was (for that client) ~15-16KB/s since he downloaded heavy on "fb 256K".

When I upgraded to 1.2.8b, he downloaded constantly with variations at 50-60-80KB, and even 150KB at times.

Upgraded Star-OS is connected to V3 1.1.13 sistem, which still had old qshape entries for subnet in question. When I activated them, client was back to 15-16 KB/s.

Is it possible that CBQ script from 1.1.13 does not corespond to 1.2.8b?

bi-pipe 100 bw 15000K 15000K
bi-pipe 1000 bw 15000K 15000K parent 100

surf256 = "bw fb 256K 128K parent 1000" ## Surf 256 = 32 KB

qshape Ugljesa 1501 $surf256 192.168.210.101 on $omni

tony

07-28-2007, 12:24 PM

Everything should be the same between the two revisions. Can you go into your CBQ report and see if there are any hits in the CBQ rules you entered?

nelson05

07-28-2007, 01:55 PM

A question and suggestion for for the sync option...

I've always been under the impression that the AP's distance setting is always set to the distance between it and the most remote client plus a couple of miles for padding while each clients distance setting is set to the actual distance between itself and the AP plus padding.

The new sync option appears to make every client equal to the APs distance setting so that a client that is only .5 miles away could have its distance set to 15 if the AP had a client that was 13 miles out. Doesn't this produce a sub-optimal result?

Finally, it would be great after the sync button is pressed to have a menu presented on the confirmation screen that allows the user to select which elements of the configuration should be synchronized using checkboxes for channel, cloaking mode, distance, AND transmit rate and country code.

DrLove73

07-28-2007, 03:21 PM

There are only hits on upload, but not on download.
All I did was upgrade, I even did not realize at the time of upgrade, only 2-3 hours after.

On next in line 1.1.13, I can see hits both on download and upload, that one looks OK, but 1.2.8b CBQ hits do not.

In fact, none of the DOWNLOAD CBQ rules od that machine are hit, only upload ones.
I looked at WAR METRO, both download and upload rules are hit, so can problem be in X86-PC version of 1.2.8b.

I will try downgrading/upgrading at Monday, to be sure I can go up there if somthing goes wrong. I'll also try upgrading next in line router to se if problem persists (also X86-PC)

Everything should be the same between the two revisions. Can you go into your CBQ report and see if there are any hits in the CBQ rules you entered?

butchkemper

07-28-2007, 03:55 PM

When I install the beta firmware, the reading on the links stays at -80, but it won't associate for a while, then it will associate with a Q reading of 13, then disappear.

Today I replaced a link of YDI EX1 Bridges with a pair of War2 boards running 1.1.13. The antennas are 2' solid dishes.

Everything worked fine on the bench but when the radios were in the air, I had problems. Pings between the radios were very slow with times between 16000 and 32000. After a long while, I discovered that the link distance setting in the client was 6.00 and in the AP was 10.00. When I change the client to 10.00 miles, everything started working like it should.

I mention this because when the link distance in the client was incorrectly set, the client constantly showed a quality of either 13 or "*".

Butch

lonnie

07-28-2007, 05:24 PM

Before you get concerned I'd like you to do some tests with optimal distance setting and AP distance setting. I suspect you'll not see any difference, or at least not enough to cause any concern.

A question and suggestion for for the sync option...

I've always been under the impression that the AP's distance setting is always set to the distance between it and the most remote client plus a couple of miles for padding while each clients distance setting is set to the actual distance between itself and the AP plus padding.

The new sync option appears to make every client equal to the APs distance setting so that a client that is only .5 miles away could have its distance set to 15 if the AP had a client that was 13 miles out. Doesn't this produce a sub-optimal result?

Finally, it would be great after the sync button is pressed to have a menu presented on the confirmation screen that allows the user to select which elements of the configuration should be synchronized using checkboxes for channel, cloaking mode, distance, AND transmit rate and country code.

lonnie

07-28-2007, 05:27 PM

Link distance can be set to maximum and it will work just fine. If you set it too low it might not even associate and if it does the throughput is nearly zero.

Today I replaced a link of YDI EX1 Bridges with a pair of War2 boards running 1.1.13. The antennas are 2' solid dishes.

Everything worked fine on the bench but when the radios were in the air, I had problems. Pings between the radios were very slow with times between 16000 and 32000. After a long while, I discovered that the link distance setting in the client was 6.00 and in the AP was 10.00. When I change the client to 10.00 miles, everything started working like it should.

I mention this because when the link distance in the client was incorrectly set, the client constantly showed a quality of either 13 or "*".

Butch

nelson05

07-28-2007, 07:13 PM

No concern, just curious since it seems that distance has always been advised to be set in the manner I described.

If there isn't much of a difference, why bother setting the distance at all? Why not just make the distance setting default to an ACK suitable for 30 miles... probably would cut down on support issues, since you'll have one less setting that can be misconfigured.

I'll try to test it, but only have the beta on a PTP shot right now as I'm not quite ready to deploy it to a PTMP setup that would answer the question.

Beebe

07-28-2007, 08:29 PM

Layer7 appears to be broken in this release? I'm downloading in bittorrent a lot faster than I used to be able to.

Thanks,
Roger

mrmike

07-28-2007, 08:39 PM

The fourth time I tried this on the link, it caught, but with funny results. The card found the AP at -78, but within seconds, went to -84, then to -92, where it stayed. I tried other channels on the AP. Some would work, but others wouldn't. I tried 2x but it with the same result. I tried with super a/g, without; more mileage, less; 2x, 4x; def power, 20, 18;all results end up the same. Starts at -78 ( where it is on 1.1.13) and drops to -92.

tony

07-28-2007, 08:41 PM

Double check your layer-7 rules via the system report. Both layer-7, pp2p, and connlimit should be operational in this release.

tony

07-28-2007, 08:44 PM

Did you try my recommendation listed in a previous post in this thread?
http://forums.star-os.com/showpost.php?p=45963&postcount=55

Also, please list the configuration details for the client, and AP. (you can do this via PM if you wish).

The fourth time I tried this on the link, it caught, but with funny results. The card found the AP at -78, but within seconds, went to -84, then to -92, where it stayed. I tried other channels on the AP. Some would work, but others wouldn't. I tried 2x but it with the same result. I tried with super a/g, without; more mileage, less; 2x, 4x; def power, 20, 18;all results end up the same. Starts at -78 ( where it is on 1.1.13) and drops to -92.

Beebe

07-28-2007, 09:05 PM

Double check your layer-7 rules via the system report. Both layer-7, pp2p, and connlimit should be operational in this release.

It was working before and I'm 95% sure I didn't change any settings other than just do the upgrade from 1.1.13 to 1.2.7b and then 1.2.8b.

According to the system report there is no traffic hitting any of the pipes.

pipe 100 ( 36.62K): 0B, 0.00B - netfilter mark 100 out via eth1
pipe 101 ( 36.62K): 0B, 0.00B - netfilter mark 100 in via eth1
bi-pipe 110 ( 73.24K / 36.62K): rx: 0B, 0.00B/sec tx: 0B, 0.00B/sec, src 12.109.193.42 on eth0

The firewall has:
client = ether1
net = ether2

iptables -A PREROUTING -t mangle -m layer7 --l7proto bittorrent -j MARK --set-mark 100
iptables -A PREROUTING -t mangle -m layer7 --l7proto gnutella -j MARK --set-mark 100
iptables -A PREROUTING -t mangle -m layer7 --l7proto edonkey -j MARK --set-mark 100

And CBQ:
client = ether1
net = ether2
pipe 100 bw 300k #Upstream
pipe 101 bw 300k #downstream

shape all to pipe 100 from mark 100 out via ether2
shape all to pipe 101 from mark 100 in via ether2

DrLove73

07-29-2007, 05:43 AM

When you set distance to lower value, you can block clients further from your AP of associating, thus preserve your AP from donwgrading its performance. I think that is the point of distance setting.

If there isn't much of a difference, why bother setting the distance at all? Why not just make the distance setting default to an ACK suitable for 30 miles... probably would cut down on support issues, since you'll have one less setting that can be misconfigured.

DrLove73

07-29-2007, 05:52 AM

Looks similar as my case, but my CBQ rules are hit in one direction (upload), but not in the other (download). Is it possible that script compiler gets confused with what interface it is soposed to use?

It was working before and I'm 95% sure I didn't change any settings other than just do the upgrade from 1.1.13 to 1.2.7b and then 1.2.8b.

According to the system report there is no traffic hitting any of the pipes.

gunther_01

07-29-2007, 08:21 AM

My CBQ is getting hits both ways. Using a WRAP, and a WAR2 with this version. Didn't have to change a thing from previous firmware (2080? last stable release)

Beebe

07-29-2007, 09:06 AM

I set up a qshape rule for my IP address and it did throttle me, so the problem appears to be with layer7 filter and not necessarily CBQ itself.

Thanks,
Roger

Edit: this is the PC version of the release

tony

07-29-2007, 09:14 AM

It appears as though layer-7 support is slightly broken, and has been fixed for the upcoming 1.2.10b release. v1.2.9b will be released later today.

lonnie

07-29-2007, 12:14 PM

We tell people the actual plus 2 miles simply becuase people were UNDER estimating. You cannot go wrong by setting them ALL to the farthest actual plus 2 miles. Just don't go under.

No concern, just curious since it seems that distance has always been advised to be set in the manner I described.

If there isn't much of a difference, why bother setting the distance at all? Why not just make the distance setting default to an ACK suitable for 30 miles... probably would cut down on support issues, since you'll have one less setting that can be misconfigured.

I'll try to test it, but only have the beta on a PTP shot right now as I'm not quite ready to deploy it to a PTMP setup that would answer the question.

mimbach

07-29-2007, 12:53 PM

A war2 running 1.2.7b locked up hard yesterday. The system that locked up hard was feeding another tower and both were running ospf.
The odd part is the tower that is fed from the system that locked up hard was pingable but would not accept even a starutil reboot command, would not allow me to log in, would not allow routing, or associations. So I had to drive to two mountain tops yesterday and power cycle both boards.
Since I was unable to log in before rebooting I can not give you any syslog msgs.
Any other info I can give let me know.

Mimbach

lonnie

07-29-2007, 03:12 PM

Set up ping watchdog. Your unit did not fully die and thus hardware watchdog was still saying OK.

mimbach

07-29-2007, 03:55 PM

Lonnie,
Ping watchdog was enabled and setup

tony

07-29-2007, 04:42 PM

My recommendation is to update to the latest 1.2.9b release, and enable remote syslog. If the problem pops up in the future, it will aid in troubleshooting.

DrLove73

07-29-2007, 05:18 PM

I had similar/same problems but with V2.11-WRAP version, 3 systems connected to the forth, all locking in different times for several days.

It was suggested MAC poisoning, so I set MAC acl for clients. It helped to minimize lockups.

If it happens again, try ssh from linux system, or from another Star-OS system. If you recive "could not et remote version", or "connection refused", and can ping that machine, but none after that one, and ping wachdog does not work, then that are the simptoms I had (hope to be past). Sometimes, also, CBQ report showed blank, and once, CPU usage was 100% before it locked me out.

We put METRO with 1.2.8b on one others are connected , and havent had problem since (2 days now) witch would be min. 5-6 skiped lockups (reapearing even 5-10 minutes after manual reboot). Possible problem is overload of system for some reason.

A war2 running 1.2.7b locked up hard yesterday. The system that locked up hard was feeding another tower and both were running ospf.
The odd part is the tower that is fed from the system that locked up hard was pingable but would not accept even a starutil reboot command, would not allow me to log in, would not allow routing, or associations. So I had to drive to two mountain tops yesterday and power cycle both boards.
Since I was unable to log in before rebooting I can not give you any syslog msgs.
Any other info I can give let me know.

Mimbach