StarV3 v1.3.0 build 2446 has been released.

[tony]

This is the Release version, and is no longer in BETA.

Release notes between 1.1.13 and 1.3.0 will be posted later today.

NOTE: The X86-WRAP edition is fully compatible with the Geode-based RB220 & RB230.

Changes since v1.2.11b build 2426
*) Shared-key WEP should now work as expected with SuperA/G features enabled.
*) Firmware has been split into 2 locational releases, one being fcc and the other being world. United States and Canada are to use the fcc version.
*) Two OEM versions have been released. Generic (gen) and the standard release (vnc). The Generic release is not branded, and is ideal for OEM distribution.

Problems found in this release include
*) WPA-enabled AP interfaces will lose their static routes. Dynamic routing is not effected. (resolved in upcoming release)
*) Radius ACL will disconnect users after 5 minutes, requiring them to re-authenticate. (resolved in upcoming release) http://www.star-os.com/images/new.gif

NOTE: Due to people abusing the '##' option in the previous releases, we are forced to exclude support for this option from the general release. We see the need for such an option for people with lagitimate licensed bands, and are working on a solution.

Some operational differences include (mainly related to regulatory requirements):
*) When using 802.11g in cloaking 2x, or 4x - make sure you do not lock to a CCK rate (1, 2, 5.5, 11) as they are not valid. If you must lock a rate, ensure it's an OFDM rate. http://www.star-os.com/images/new.gif
*) 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 (world release) 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.

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.

HotSpot Script Additions in 1.2.11b+:

There is now support for mac-level authentication with static IP assignments via Radius.

If you have previously configured hotspot, then you will not see the script updates once you update.

The two new HotSpot commands are:
# @@ macauth <state>
# used to enable or disable hotspot mac-level authentication when
# the client obtains a dhcp lease. if authentication fails, the
# standard web-based login will be presented to the client.
# >> valid values: enabled, or disabled
# >> default: disabled

# macauth enabled

# @@ static_network <network>
# radius Framed-IP-Address replies during mac authentication will
# considered valid if it's within this network block. If an
# invalid reply is given, a dynamic IP will be handed to the client.
# >> valid values: network block in CIDR notation
# >> default: none

# static_network 192.168.57.0/24

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.

[Stratolinks]

NOTE: Due to people abusing the '##' option in the previous releases, we are forced to exclude support for this option from the general release. We see the need for such an option for people with legitimate licensed bands, and are working on a solution.

I can understand the rationale for doing this I have seen abuse in the 2.4GHz and 5GHz bands as well. Had someone running a high powered P2P link in the 5.1GHz band. They have been forced to move up to the 5.8GHz band, although I wish they would have been forced to use better antennas and less radio power instead, not sure if they were fined or not.

A question I now have is:
Have you been able to add the additional channels that are legal (in Canada) when using 2x or 4x cloaking (this would mean anything fully contained in the 2400-2483.5 MHz range)? I ask because I am using a couple of these channels in a couple places.

[tony]

When cloaking, frequencies 2407 (ch 0) and 2467 (ch 12) become available.

[bobbyc]

This is a historic day. Congrats on 1.3.0. I'm on a new customers roof right now, just wanted to check in.
Bob C

[Stratolinks]

When cloaking, frequencies 2407 (ch 0) and 2467 (ch 12) become available.

COOL! OK this release is looking good, really good. The features I really wanted to see were Radis ACL, and Radis DHCP autoauth, and I got not one, but both of them in one release.

This will work way better than using the ## to get these frequencies bacause it won't have to scan all the way through the 2.3-2.7GHz range to find it.

Now if we can also manage to squeeze 2472 and 2477 in at the top of the band (only with cloaking), then we actually have full use of the allotted spectrum for Canada. You could legally use 2467 in Canada even without cloaking, but who cares now.

[mrmike]

A few small problems. I have a metro with just 3 cards in them, 2 AP and 1 backhaul. The first card is uncloaked, with wraps, and wars attached to them. When I try to adjust the SuperA/G, the system will sometimes re-boot itself. The other cards seem fine.
With SuperA/G on, I cannot access the wraps or wars. I can with SuperA/G off

I upgraded a war1 and war2 that were in beta already, but could only access them with superA/G on. I tried to be smart, and dis-able the superA/G on their end, but now I can't access them at all. They show up on the list, but there isn't any IP

[tony]

Make sure your clients are also updated to the new release. You may also want to double-check the power being provided to the METRO, as it is one of the most common causes of system reboots or other oddities during operation.

If you are using WEP, make sure you use the 1.3.0 release.

If you continue to have problems, please PM me the Atheros MAC revisions from both the AP, and effected clients as well as your configuration settings for the Atheros cards.

Thanks!

[klyne]

Upgraded from 1.1.11 to the 1.3.0 and all the sudden all the clients could not associate, or more acurately keep their association. They would come on for less than 1 second and then flip off again. The base is a WAR4 where 1 CM9 is linking back to a basestation and the other 3 CM9s are serving customers.

The link back to the base was fine but the client association would show clients comming online and imediately go back off.

The clients are all running 1.1.8 and are using the US county code as is the base.

No cloacking. what did i miss between releases? also i cant seem to find a history of the differences between releases. The forum that holds BETA and previous BETA releases only has the current release and change log or nothing at all. Is there a place i can find the change logs?

MM

[tony]

The release notes are still being typed up, and will be available on our website later today, or tomorrow.

Make sure you have your tx power set to a sane value (17 is good for the CM9 for instance), and that your distance is set correctly.

If you continue to have issues, please PM me your AP configuration details.

Thanks!

[DLNoah]

klyne: did you upgrade just your base station, or the clients as well? It is my understanding that there are differences between the 1.1.x series firmwares and 1.3.x series that makes it strongly recommended to use 1.3.x on all, or 1.1.x on all, and not intermix.

[tog]

How are the clients configured, are they using WDS or anything?

As much detail as you can provide about the AP and client configuration would help, are you using WEP, WDS, SuperAG? I don't know of any remaining SuperAG problems, but as a test you can try turning SuperAG off at the AP real quick to see if it helps.

If I remember correctly, 1.1.8 had a dangerous bug related to possibly corrupting your configuration and you should update them all ASAP to at least 1.1.13 even if you do not want to go to 1.3.0. I believe the bug had a low chance of being randomly triggered by saving your configuration.

Upgraded from 1.1.11 to the 1.3.0 and all the sudden all the clients could not associate, or more acurately keep their association. They would come on for less than 1 second and then flip off again. The base is a WAR4 where 1 CM9 is linking back to a basestation and the other 3 CM9s are serving customers.

The link back to the base was fine but the client association would show clients comming online and imediately go back off.

The clients are all running 1.1.8 and are using the US county code as is the base.

No cloacking. what did i miss between releases? also i cant seem to find a history of the differences between releases. The forum that holds BETA and previous BETA releases only has the current release and change log or nothing at all. Is there a place i can find the change logs?

MM

[tog]

klyne: did you upgrade just your base station, or the clients as well? It is my understanding that there are differences between the 1.1.x series firmwares and 1.3.x series that makes it strongly recommended to use 1.3.x on all, or 1.1.x on all, and not intermix.

I can tell you from firsthand experience that it is ok to run 1.1 and 1.2/1.3 talking to each other in either AP or client roles, but there are a couple of situations where I would not expect 1.1 <--> 1.2/1.3 to work, such as when WDS is in use. I wouldn't expect WDS to work between 1.1 and 1.2/1.3.

2x cloaking is compatible, WEP is compatible, SuperAG has shown to be fine and compatible. OLSR is compatible :)
I haven't tested 4x cloaking myself, haven't used it anywhere that I have updated.

[David L. Vrablic]

A few small problems. I have a metro with just 3 cards in them, 2 AP and 1 backhaul. The first card is uncloaked, with wraps, and wars attached to them. When I try to adjust the SuperA/G, the system will sometimes re-boot itself. The other cards seem fine.
With SuperA/G on, I cannot access the wraps or wars. I can with SuperA/G off

I upgraded a war1 and war2 that were in beta already, but could only access them with superA/G on. I tried to be smart, and dis-able the superA/G on their end, but now I can't access them at all. They show up on the list, but there isn't any IP

Mrmike
I just got my first 2 METROS and I was surprised that some of the cards I thought would be fine with a 800 Ma wall wart (just for testing ) were doing all kinds of resets and such.
Found there jusst wasn't enough "skizzewatts" to run everything.
I was just wondering what power supply you were using and what 3 cards.
I just want to add this info to my info base.
I wound up with a 24vdc 4 amp (5 lb) PS when I installed on site.
It has 4 SR-5s in it (Turned down now) and it is solid as a brick with many mode changes during testing.

[soulmata]

I've finished upgrading our 900MHz POP to 1.3.0

I must say, I am impressed and I would like to thank the Star developers for giving us a very worthy upgrade:

http://whatthebert.com/soulmata/images/staros/ofdm130.png

x4 cloaking, only 3 of these clients has what approaches line of site - the rest are in a very heavily wooded area.

The packet loss for the entire AP has dropped significantly, and throughput across the board has been improved. I can get 7mbps+ to several units.


There is only one suggestion or request I would ask for a future release, and that is the return of the aggregate indicator at the top that gives us the total RX/TX count for all clients. I understand that the RTTM can do this, but it would be nice.

[tony]

I am pleased it is working well for you.

The total RX / TX counter would be handy indeed.

[pachitoone]

Question: Channel 6 is now marked as dymanic. How can I assure that it will change automaticly to a clear channel? Thanks.

[tony]

I'm not 100% sure as to your question. You want to be assured that it (channel 6?) will change automatically to a clear channel (not 6?).

[pachitoone]

Yes, I have a tower with four 90 degree antennas connected to War2's access points. The channels I have selected are 1,4,8,11 but sometimes there is so many noise in any of these channels. I want to keep channels 1 and 11 static, but for the other two I want that they scan the clearest channel available. Do you understandme or I'm wrong with I want to do? Thanks.

[pti-andy]

I am still having the same issues with this version as with the 1.2beta versions. I’m using WDS and DFS on a WAR-2 AP and two WAR-2 clients.

After upgrading the AP jumped again to a frequency outside the ACL and CPU went up to over 80% with no traffic running. Ip connectivity to clients comes and goes during this condition. To remedy you have to pretend to make a change in the radio config and activate changes. It then goes back to the correct freq and the clients come back up. CPU then returns to 1%.

This happens after most reboots or upgrades and sometimes happens on its own. It renders this version completely unusable with DFS because the jump can be all the way down to 5100 or as high as 5800 and this will be outside of the ACL of most clients so they never attach. Even if it was in the ACL the antenna doesn’t have that wide of a freq range to make a reliable connection.

Secondly, the ARP issue with WDS is still not fixed. The only way to reach a client radio is to ping it first with the AP or clear the ARP table of the router that I’m trying to reach it from. If one of the clients is experiencing any kind of connection issue then clearing ARP won’t even help and all client radios become unreachable. In other words, once the problem happens it is global and not just isolated to the one client. This is not true for IP addreses behind the radio, only the radio itself. At one point to get back into the radio I had to clear ARP and ping from the AP about every 30 seconds just to keep the connection up. On average if all connections are rock solid I have to re-ping from the AP about once every 10 minutes or the connectivity will go away.

Neither of these issues exist with v1.1.x and downgrading will bring everything back to normal. It is somewhat agravating to report these problem over and over during the beta cycle and then the release comes without addressing it. Please, please get this fixed as I still can’t use my WAR-1 clients with WDS until 1.3 is working and I have a sizable investment of WAR’s that can’t be deployed until it is.

Andy
PTI-Wireless

[tony]

The dynamic option on channel 6 means it can be used for either standard operation (802.11b/g), or turbo.

If you want the AP to scan for a clean channel, you need to select 'auto', or 0 for the channel number on the AP.

[rkreigh]

Can you elaborate on the scanning, how does it do it. What does it do if it doesn't find a good channel. Oh, and does the auto work the same way in V2?

Thanks,
-Russ


The dynamic option on channel 6 means it can be used for either standard operation (802.11b/g), or turbo.

If you want the AP to scan for a clean channel, you need to select 'auto', or 0 for the channel number on the AP.

[tony]

The DFS jumping w/ channel ACL support is still in development, but should be ready in an upcoming 1.3.x release.

The WDS issue you are encountering is unusual, and can only be caused by ARP poisoning on your network. (the AP is hearing workstation multicast traffic without first going through the client). I am unsure as to how this is occuring, but a detailed description of your AP, and the type of clients you have attached will be handy. (PM me this information).

Do you have the InterBSS Relay option enabled on the AP?

I am still having the same issues with this version as with the 1.2beta versions. I’m using WDS and DFS on a WAR-2 AP and two WAR-2 clients.

After upgrading the AP jumped again to a frequency outside the ACL and CPU went up to over 80% with no traffic running. Ip connectivity to clients comes and goes during this condition. To remedy you have to pretend to make a change in the radio config and activate changes. It then goes back to the correct freq and the clients come back up. CPU then returns to 1%.

This happens after most reboots or upgrades and sometimes happens on its own. It renders this version completely unusable with DFS because the jump can be all the way down to 5100 or as high as 5800 and this will be outside of the ACL of most clients so they never attach. Even if it was in the ACL the antenna doesn’t have that wide of a freq range to make a reliable connection.

Secondly, the ARP issue with WDS is still not fixed. The only way to reach a client radio is to ping it first with the AP or clear the ARP table of the router that I’m trying to reach it from. If one of the clients is experiencing any kind of connection issue then clearing ARP won’t even help and all client radios become unreachable. In other words, once the problem happens it is global and not just isolated to the one client. This is not true for IP addreses behind the radio, only the radio itself. At one point to get back into the radio I had to clear ARP and ping from the AP about every 30 seconds just to keep the connection up. On average if all connections are rock solid I have to re-ping from the AP about once every 10 minutes or the connectivity will go away.

Neither of these issues exist with v1.1.x and downgrading will bring everything back to normal. It is somewhat agravating to report these problem over and over during the beta cycle and then the release comes without addressing it. Please, please get this fixed as I still can’t use my WAR-1 clients with WDS until 1.3 is working and I have a sizable investment of WAR’s that can’t be deployed until it is.

Andy
PTI-Wireless

[tony]

Simple.

If you select 'auto' for a channel, it will scan all available and pick the one with the lowest interference. If you select 'auto' on a 802.11a w/ a DFS enabled country, then it will scan all channels for radar, then pick a random channel per DFS spec.

The auto-channel selection feature was not complete until v1.2.x, so older V2 and V3 releases pick the first channel in the given band when set to auto.

Can you elaborate on the scanning, how does it do it. What does it do if it doesn't find a good channel. Oh, and does the auto work the same way in V2?

Thanks,
-Russ

[tog]

Andy, at the place where you have tested the WDS issue, how is it setup?

Is the AP interface(s) bridged to ether1 and there's a router on ether1?

I can't reproduce your issue with WDS clients where my AP is all routed and the StarV3 AP itself is the router with no bridging.

[pti-andy]

Thanks for the quick reply. It is good to hear that the DFS support will be working soon. I will post my config here in case Tog has any ideas as well.

My WDS setup is simple: Both AP and Client radios have Ether1 bridged to wpci1 and InterBSS relay is on. I made a previous post in the 1.2.11b thread that contains the rest of the radio params but I don't think they are relevant.

The Network connections are as follows:

Cisco 7206 <-> Cisco 2912 switch <-> WAR-2 AP
Client 1: WAR-2 <-> Cisco 3620 router
Client 2: WAR-2 <-> Linksys router

The Catalyst switch above also has another WAR-2 AP attached for a different sector sharing the same subnet from the Cisco but is not passing traffic for this scenario or related to this issue since it is on v1.1.13. There are no workstations attached on the AP or Client segments so the only broadcast traffic would come from the routers or the WAR-2's.

All WAR-2’s are on a reserved /24. Routers belong to a public /28 subnet. The 7206 has IP’s from both subnets assigned to reach both. This is how all of my POPs are setup and I can duplicate this problem elsewhere on entirely different subnets except one location that only has one WAR-1 client.

The Cisco 7206 will have valid ARP entries for both clients with the correct MACs associated with the IP addresses.

As soon as I do an "activate changes" on the AP both units are unreachable permanently from the router even though the ARP entries in the 7200 router have not changed.

It will also loose connectivity if one of the clients is having low link quality due to the DFS jump. When this happens ALL clients loose connectivity, not just the one with a signal problem.

In another case the clients will loose connectivity just by waiting 5 or 10 minutes. No traffic is passing and signal is great at -58 with no data loss.

In all cases pinging from the AP or clearing the ARP table in the Cisco will bring them back. In all cases the ARP entries in the Cisco never change or go away. This is why I believe it is not an ARP issue outside of the radio even though a new ARP request will bring it back.

Another thing to keep in mind is that in ALL of these cases I NEVER loose connection or drop a packet to the router behind the client radio. I just loose the client radio itself. Also, in all cases downgrading just the AP to v1.1.13 returns to normal operation with no troubles.


-Andy
PTI Wireless

[tog]

All right, that was the important bit. You are bridging wpci1/ether1 on your StarV3 AP so your setup is a lot more complicated and your problems are beyond what I can really help with.

Have you tried toggling STP off or on to see if it makes any difference with your problems? At the AP and also at the client?

Because I like to keep everything simple and my power requirements low, I do not have any APs left with an external router attached to ether1 with the AP having a bridged wpci1/ether1. All my StarV3 systems themselves are my actual routers.

[lonnie]

Have you tried this with interBSS relay off?

[Mkleibrink]

I upgraded some of my stations and had a problem that they don't want to connect to my main backhaulk staion. After playing around for hours i found out that hidden ssid was the problem. When I turned of hidden SSID my Stations connected flawlessly.

So far everything works good. I am just missing the ## option.

Greetings from Serbia

[tog]

Is your AP on a channel that uses DFS?

Hidden SSID will not work on DFS channels.

[rkreigh]

Ok, a couple things.

In DFS mode, does it scan for interference also, or just radar, then pick a channel.

Will it change channels if it sees interference, or just on bootup, or an activate??

If so, what must be met for it to decide to switch, signal decrease, Q% low, etc?

Thanks,
-Russ

Simple.

If you select 'auto' for a channel, it will scan all available and pick the one with the lowest interference. If you select 'auto' on a 802.11a w/ a DFS enabled country, then it will scan all channels for radar, then pick a random channel per DFS spec.

The auto-channel selection feature was not complete until v1.2.x, so older V2 and V3 releases pick the first channel in the given band when set to auto.

[tony]

The system will never change channel, regardless of the interference (if it did so, that would be detrimental to any reliable WISP operation).

If radar is detected at any point during operation, then the channel will change.

[tdereggi]

Which are the FCC3 channels?

[lonnie]

Ok, a couple things.

In DFS mode, does it scan for interference also, or just radar, then pick a channel.

Will it change channels if it sees interference, or just on bootup, or an activate??

If so, what must be met for it to decide to switch, signal decrease, Q% low, etc?

Thanks,
-Russ
DFS is for radar avoidance, not for noise. Auto is for initial choice and it is automatic, choosing the best (at that point in time).

[tony]

This depends on the country code you select. For example, in the world release the UZ country code will provide the FCC3 channels.

Which are the FCC3 channels?

[tdereggi]

That didn't answer the question. Of course I could flash the new US version and check. But to be more specific in question...

In the FCC compliant build, and US Country code, which of the following channels are still included (other than just 5.725-5.850 and 2.4G ch1-10) ...

5.150-5.249 ?
5.250-5.350 ?
5.4-5.7 ?

For DFS (Radar detection), Which channels is this implemented on...

5.250-5.350 ?
5.4-5.7 ?

Am I correct that the only thing missing in theory from software for FCC listed requirements is Automatic Power Control?

[lonnie]

Since we do not have the software approved for DFS2 use we have removed any DFS required channels from the FCC release.

[tony]

With respect to the FCC3 requirements, DFS is active on:
5250 - 5320
5500 - 5700

TPC is part of the DFS spec, and is supported.

To use the FCC3 / DFS channels, you must use the world edition, and the UZ country code.

The US country code in the FCC release does not contain any of the FCC3 specific channels, or DFS requirements.

That didn't answer the question. Of course I could flash the new US version and check. But to be more specific in question...

In the FCC compliant build, and US Country code, which of the following channels are still included (other than just 5.725-5.850 and 2.4G ch1-10) ...

5.150-5.249 ?
5.250-5.350 ?
5.4-5.7 ?

For DFS (Radar detection), Which channels is this implemented on...

5.250-5.350 ?
5.4-5.7 ?

Am I correct that the only thing missing in theory from software for FCC listed requirements is Automatic Power Control?

[tdereggi]

Sorry to be so dumb, but I'll try again...

What channels are DFS channels?

5.1G ?
5.3G ?
5.4-5.7 ?

I know 5.4 requires DFS (radar detection). But what about 5.3 and 5.1?
My understanding was 5.1 didn't, as it was only allowed for indoor use...
And 5.3 just required ATPC, (and of course 250mw TX limit) ...
Is that correct or incorrect?

[tony]

I have listed the ranges above.

[tdereggi]

Tony,

Thanks! That clears it up. (Missed it orginailly)

[tony]

Not a problem.

[pti-andy]

Have you tried this with interBSS relay off?

Yes, InterBSS relay, Short Preamble, and SuperA/G have no effect on the problem.

A note when testing: If you leave your SSH login to the client radio open during the test you will not see the problem because the SSH console keeps it alive. To reproduce the results, only have the AP console open and simply pretend to make a radio change and "activate changes". Once the client radios drop off they will never come back although the routers behind them do.

This also holds true for any loss of connectivity to the client even if for a millisecond.

Eventually the connection will dissappear on its own but it is easier to test by dropping the connections from the AP instead of waiting.

Hope this helps.

-Andy
PTI Wireless

[klyne]

few post have appered in between, but just wanted to answer the questions from the people kind enough to answer.

No WDS or encryption.

The setup is a WAR4 all CM9 one interface backhauling in client mode. the 3 remaining interfaces serving 3 bridged clients. All features exept for Outdoor only channels is tuned on on the clients and AP.

The units are really close to each other <1mile and have signales about -25dBm which i know i too hot, but i dont like to polute with lower gain antennas and i dont have any pads (TX power is at 1 on both sides). And again it works fine with 1.1.11.

In the mean time i have updated a few "client only" boards, and they seem to work fine.

MM

[pti-andy]

Not to be a party pooper but, in further testing I found that the 10M full duplex setting is still not functioning as it does in v1.1.x. It stays at half duplex even though manually set to full.

Also I have been able to regularly crash (lockup or reboot) 1.3.0 AP's by running numerous speed tests and "activating changes". I have three AP's that this has happened to and in all cases it occures during the "activate changes" process or speed testing from the AP. It seems to require regular use of the utility or frequent activations. It only affects the AP running the test from, not the destination unit.

One of the AP's does not even have any clients associated and is just being used right now for speed testing out it's local Ethernet port.

If I leave them alone and just pass data they stay running. I had this issue in the beta releases as well. The 1.1.x releases do not have this issue and can run tests all day long.

If it locks up the only thing that will bring them back is a power cycle. I've been making a lot of driving trips to continue the debugging of the WDS issue.

-Andy
PTI Wireless

[mrmike]

Mrmike
I just got my first 2 METROS and I was surprised that some of the cards I thought would be fine with a 800 Ma wall wart (just for testing ) were doing all kinds of resets and such.
Found there jusst wasn't enough "skizzewatts" to run everything.
I was just wondering what power supply you were using and what 3 cards.
I just want to add this info to my info base.
I wound up with a 24vdc 4 amp (5 lb) PS when I installed on site.
It has 4 SR-5s in it (Turned down now) and it is solid as a brick with many mode changes during testing.

I switched out the 24V PS from Valemount, and added one from Digi-key, a 2.5A. It really helped before the update.

[mimbach]

We have seen our units lockup hard under circumstances like what Andy has noted.

All units that locked up hard were moved to not just a larger power supply but to a battery bank. When this did not help I noticed all towers having the problems where the first batch of war2's that were ever shipped. So I replaced them with new war2's and now I can not recreate the problem. I put the old boards on towers with far less load.

I understand this does not fix the problem and that the problem can be recreated with little effort... it does however offer a solution.

Lonnie and Tony do you guys have any input on this?

Mimbach

[tog]

I know there was mention of problems toggling SuperAG on and off and losing communication with the clients.

Here is what I have learned about that:

You can solve this problem by disabling the AP for a bit (let's say 30 seconds) and re-enabling it or simply rebooting the StarV3 system if you prefer. Whatever turns the AP off for a spell so the clients notice and reset.

If the clients don't get a chance to actually notice the AP's absence and disassociate and reassociate, then you end up not being able to communicate with them after toggling something really important like SuperAG.

[soulmata]

There is a major issue with 1.3.0 and ESP traffic


It is mangling it or not forwarding it, and thus it is breaking Cisco VPNs.

This issue does not occur with 1.1.13. Our border router, running 1.1.13, handles ESP traffic gracefully with no issue. On 1.3.0, it's dead - and anything relying on ESP, such as a PIX VPN, will die along with it. The tunnel, which is using UDP, will still come up - but the layer 3 ESP traffic is dead in the water.


If anyone has any potential ideas as to a workaround, I would greatly appreciate it. IN the meantime, I cannot upgrade any of our towers or routers to 1.3.0, or any clients who rely on this type of VPN.

[pti-andy]

We have seen our units lockup hard under circumstances like what Andy has noted.

All units that locked up hard were moved to not just a larger power supply but to a battery bank. When this did not help I noticed all towers having the problems where the first batch of war2's that were ever shipped. So I replaced them with new war2's and now I can not recreate the problem. I put the old boards on towers with far less load.

I understand this does not fix the problem and that the problem can be recreated with little effort... it does however offer a solution.

Lonnie and Tony do you guys have any input on this?

Mimbach

The WAR-2 boards I am using are all newer 48V models running on 48V supplies. The lockups occure when using the SSH console to run speed tests or during an "activate changes." I have not run extensive traffic through the new version except for speed testing. It has not been stable enough to put valuable customers behind so I can't say if it will lock up at any other time. So far getting it to lock at the SSH utility is very repeatable and not specific to any particular unit.

By the way, all of my results are using WDS with the AP bridged if that helps any.


-Andy

[tog]

Is this with any of the StarV3 systems doing NAT?

I am passing ESP protocol 50 traffic through my 1.3.0 client unit right now just fine, though mine is all routed and I dont even have connection tracking enabled.

There is a major issue with 1.3.0 and ESP traffic


It is mangling it or not forwarding it, and thus it is breaking Cisco VPNs.

This issue does not occur with 1.1.13. Our border router, running 1.1.13, handles ESP traffic gracefully with no issue. On 1.3.0, it's dead - and anything relying on ESP, such as a PIX VPN, will die along with it. The tunnel, which is using UDP, will still come up - but the layer 3 ESP traffic is dead in the water.


If anyone has any potential ideas as to a workaround, I would greatly appreciate it. IN the meantime, I cannot upgrade any of our towers or routers to 1.3.0, or any clients who rely on this type of VPN.

[soulmata]

This is using 1:1 NAT

Our routed systems aren't having problems

Should have mentioned that

however, since currently 100% of our customers are either behind a generic NAT or 1:1 NAT, it is pretty important

[tog]

I'm afraid my ability to help you stops at coaxing the necessary details out of you.

I know this doesn't help you, but I am surprised that it was working at all before, even with 1:1 NAT. IPSEC or any other ESP-using VPN generally doesn't like NAT unless it has been specifically extended to be able to traverse NAT.

When I provide somebody with Internet connectivity where they're going to be using an IPSEC or similar VPN, I just route them an IP and make sure NAT stays out of it.

[pachitoone]

Hi
I want to report that this version is not playing nice with 1.1.x(War1's and War2's) clients. The problem is that the clients connects well for 15-20 minutes then they stop transmit data or become very slow(2000-3000ms pings). Curiously clients with wet54g and pci cards doesn't have the problem. I set the AP to b/g mode then I downgraded to b only. Upgrading clients to the newer version helps but not a lot. I'm seeing some upgraded clients with minor losses but now with some DUP!s. The upgraded clients don't
change fast to another AP with better signal but stay with the first that they associate(I see this after activate changes on one AP to make channel change or something that reactivates the wireless card). Has someboby experienced this behavior? It's a bug, incompatibility or need I to readjust settings to the new release?

Settings that works well with 1.1.13 AP and now with problems under 1.3.0:

Country US
distance 7.5
1x cloaking
tx power 20dbm(wlm54g)
No hide ssid
No short preamble
No InterBBS Relay
No SuperA/G
mode 11b

All AP's have mixed clients(WARs,Wet11,wet54,PCI cards,TT Versarouters). The majority are 11g.

Some suggestions?

[tog]

What is your tx rate at the AP set to and are you using WEP? (If so, what are your WEP settings, key length, open/shared, etc.)

Since you asked... I have had very good interaction between WAR1s, WAR2s and WRAPs running 1.1.x and 1.3.0. I've had no problems between 1.1.x clients and 1.3.0 APs, nor have I had any particular incompatibility problems with 1.1.x APs and 1.3.0 clients.

Are your 1.1.x clients bridging wpci1/ether1 (using WDS) or NAT'ing or routed or what?

Have you tried different channels?

I have not used 11b only mode and I haven't had any 11b clients on my network so I haven't tried that. Everything on my network is 11g so my APs have been set to 11b/g or 11g.

[pachitoone]

>What is your tx rate at the AP set to and are you using WEP? (If so, what are your WEP settings, key length, open/shared, etc.)

Auto, WEP disabled

>Are your 1.1.x clients bridging wpci1/ether1 (using WDS) or NAT'ing or routed or what?

Routed all, except one WAR2 in client bridge mode because it connects a Linkys VPN Router(This WAR never could establish a connection to the AP, was kicked off every time that it intend to connect.)

>Have you tried different channels?

Yes

After struggling all day with the new version, I restored the previous version(1.1.13) and all back to the normality.

I think that there is a bug with new driver in 11b and 11b/g mode. Putting it in 11g only seems to work correctly, but users with 11b equipment can't connect. Any ideas. In this moment I'm upgrading all users with WAR's to the new version. Monday I will give it another try.

[gregg]

Last night I upgraded my access points at home with my laptop (dell xps m1210, vista ult.) from 1.1.13 to 1.3.0 and encountered an issue with data loss that didn't occur before the upgrade.

The particulars:

A while back I upgraded my wireless card from intel pro/wireless 3945 garbage to an atheros ar5006ex mini pci express card and life was good using driver from atheros communications inc. v.7.2.0.179 dated 3/17/07.

Access points are war2 and wrap both are configured with 40bit wep, super a/g, short preamble, interbss relay, b/g mixed mode, US, default power, auto rate, with war2 on channel 1 and wrap on channel 11.

Downgrade to 1.1.13 and all is super. Upgrade back and data loss again.

My wifes laptop and my daughters Macbook and the VOIP appliance are unaffected by the upgrade and continue to operate as normal while this occurs.

The issue presents itself as about 20 seconds of good traffic and about 20 to 30 seconds of no data at all. While pinging the access points I get about 15 to 20 pings through and about 13 to 18 reports as "general failure". See photo attached.

http://forums.staros.com/attachment.php?attachmentid=89&stc=1&d=1187466284
http://forums.staros.com/attachment.php?attachmentid=89&stc=1&d=1187466284

I do not loose connectivity to the APs at all and the rate shows as 54 tx and rx. I have tried g only, long preamble, and various other changes and nothing makes it better or worse.

Any reason you can think of that might cause this?

Stumped...
Greg W.

[tony]

There are two things to try.

There is a known issue with the Vista Atheros ANI support that will cause issues such as this. To disable it, set the driver's enableANI option to 0. (it may be burried in the registry, but a search should uncover it).

The other thing to do is set the txpower of your AP to something other than 'def', just to be safe.

[gregg]

Will do, thanks Tony.

Time to go registry diving. woohoo.....

[c.davis]

I was having simialar issues running Vista with an Atheros card and solved it by turning Power Save Mode to off on the Advanced tab for the wireless device in the device manager.

[soulmata]

I'm afraid my ability to help you stops at coaxing the necessary details out of you.

I know this doesn't help you, but I am surprised that it was working at all before, even with 1:1 NAT. IPSEC or any other ESP-using VPN generally doesn't like NAT unless it has been specifically extended to be able to traverse NAT.

When I provide somebody with Internet connectivity where they're going to be using an IPSEC or similar VPN, I just route them an IP and make sure NAT stays out of it.

I truly would like to do that. Unfortunately, that's a techincal impossibility - I can't route externals past our DC due to the dismal way our upstream provider has handed us our IP blocks.

It only bothers me because it has functioned fine in the past; it worked well with the PIX, worked well with V2, works well currently with 1.1.13 - but upgrade the router to 1.3.0 and bam - no more VPN.

And I definitely want to keep that unit upgraded.

[tony]

In general VPN servers do not operate over NAT properly due to both the inability to NAT GRE packets without special help, and the fact the remote VPN servers are typically anal regarding which IP the VPN connects from. (if it's not the IP on the VPN client, they will refuse the connection).

If you enable the GRE nat helper on each system performing NAT, you should be OK. If you can get your VPN to do UDP encapsulation, instead of dumping GRE packets directly on the network, that will also allow it to traverse NAT networks without any special consideration.

[soulmata]

GRE nat helper is already enabled


As I stated, it works just fine in 1.1.13

Is there any potential change which could have caused it?

[valenti]

I've upgraded a few WAR2's here and have a few questions.
(these are on a backhaul link that isn't productional yet)

ntp doesn't seem to work now. I'm pretty sure it was working under 1.2.4b build 2358 and it certainly works on 1.1.13 2080. This is with an OpenBSD ntp server. I can ping and ssh into it from the WAR2. There are two log entries: ntpdate[1401] no server suitable for synchronization found; and the same message with [1409]

Otherwise the WAR2's seem better.

Where are the instructions for doing the upgrades? (I thought they were bundled in with the beta release files, but don't see them now) I muddled thru and figured it out, but it took a while.

Tony mentioned some release notes in the original posting, are those available yet? Would that document some of the new features (such as sync on the wireless config page - I think that was mentioned in the forums, but sometimes it is hard to pull that info out)

I don't suppose the manual is being updated?

Thanks for this new release! I think it covers all the new features I was hoping for.

PS - shouldn't this thread be in the "Releases" category, and not "Beta"?

[tog]

Do not use "def" for your tx power setting at either AP or client for now if you are in the process of updating from 1.1.x to 1.3.0. If the client is still 1.1.x, having "def" set as the tx power at the 1.1.x client and/or the AP can be troublesome once the AP is updated to 1.3.0.

As has been mentioned before, sometimes when the client has "def" set as their tx power, they will act as if their tx power were set to 1 or 0 (if 0 is possible) and will be perfectly fine again as soon as you specify a tx power of some kind.

Also worth mentioning, you can get around the problem temporarily by resetting the AP. This should give you some time to get into the troublesome remote client unit and set its tx power to something besides "def" before it turns its tx power down again.

I do not currently know if this "def" tx power problem occurs between 1.3.0 AP and 1.3.0 client, I only know for sure so far that it occurs between 1.3.0 AP and 1.1.x client.

[pachitoone]

Can be this my problem reported before in b/g mode tog?

[pti-andy]

Do not use "def" for your tx power setting at either AP or client for now if you are in the process of updating from 1.1.x to 1.3.0. If the client is still 1.1.x, having "def" set as the tx power at the 1.1.x client and/or the AP can be troublesome once the AP is updated to 1.3.0.

As has been mentioned before, sometimes when the client has "def" set as their tx power, they will act as if their tx power were set to 1 or 0 (if 0 is possible) and will be perfectly fine again as soon as you specify a tx power of some kind.

Also worth mentioning, you can get around the problem temporarily by resetting the AP. This should give you some time to get into the troublesome remote client unit and set its tx power to something besides "def" before it turns its tx power down again.

I do not currently know if this "def" tx power problem occurs between 1.3.0 AP and 1.3.0 client, I only know for sure so far that it occurs between 1.3.0 AP and 1.1.x client.

Tog,

I have noticed this happening when upgrading from 1.1.x to 1.3.0. After it comes up for the first time on the new version the TX power is actually saturated causing a nearly 100% error condition. I get just enough connectivity back to the client to get it rebooted.

BTW, I have an HP power meter that has turned up some interesting result about the power settings and "actual" power output. Rarely are they ever close to being the same.

[tog]

Can be this my problem reported before in b/g mode tog?

If it were, you would see very low signal at the 1.3.0 AP from the 1.1.x clients.

If this was your symptom, then yes, what I said earlier is the fix. Get into your clients and set their tx power to something besides "def"

[simcor23]

Is this something that happens only when upgrading or should the setting always be something other than def with 1.1.x

[tog]

So far it has only been a problem when attaching 1.1.x client to 1.3.0 AP.

I would recommend setting a tx power of some sort anyway, whether it be 23, 20, 18 or 10 or whatever appropriate for your radio card and your link.

[simcor23]

I was just wondering because when I upgraded to 1.3 some clients were stil 1.1.13 and showed some of those issues but seem to have mellowed out after a day or so and dont seem to exhibit those problems the last few days. I was just wondering if I needed to change the def setting anyways to be sure.

[tony]

It is always a good idea to set the tx power, as you never know what 'def' relates too, as it differs between brands of cards.

[David L. Vrablic]

Maybe others are getting a little BeFuddled as I am by past post that advised us to stay out of trouble with the FCC regarding power levels by setting the radio to DEF and you would never go wrong.

Now I am reading.... Never set it to Def because you might be turning it off or full up ..
OK It,s a new day with better info.
! I have been confused before and will be again.

Moral of this post ...Make sure you know what your radio cards are doing when you make adjustments.???

[palmczak]

Also confused...

After making sure all CPE's are set to DEF now we are needing to set a tx power.

Can I get a bit of information about what signal levels to shoot for? I have customers that are -50 when set to DEF,(build 2080 wlm54g war1 and 2) is this to high or?? some giudance regarding the new build and "ideal" signal levels would be helpfull.

Does the country code still define the DEF level? What are valid TX power levels for CM9,wlm54g,wlm54ag,SR9??.

This thread talks about the system adjusting power levels to maintain clean spectrum and ideal levels. Is this not the plan for the new release or just not yet?

http://forums.star-os.com/showthread.php?t=6581&highlight=def+power

Just want to get it as right as it can be...

Joe

[simcor23]

I was also under the impression from previuos posting advising not to touch the def setting as well. I used to always change the setting and eventually switched all the radios in my network back to def for fear of over powering the radios

[tony]

It is always a good idea to set the tx power to a known setting, as you need to know it in order to stay within FCC compliance. (larger the antenna, the lower the tx power level should be set). We have never recommended otherwise.

[jeff]

I'm seeing the same problems with ntp going to a stock Ubuntu 7.04 server with the default ntp package installed. Works to other units, not to 1.3.0. I changed it to an ntp server off my network and it synced fine.

I've upgraded a few WAR2's here and have a few questions.
(these are on a backhaul link that isn't productional yet)

ntp doesn't seem to work now. I'm pretty sure it was working under 1.2.4b build 2358 and it certainly works on 1.1.13 2080. This is with an OpenBSD ntp server. I can ping and ssh into it from the WAR2. There are two log entries: ntpdate[1401] no server suitable for synchronization found; and the same message with [1409]

[nelson05]

Tony,

I was also under the impression that it was best practice to always set the cards to 'def'. Here is a thread in May where Lonnie gives this exact advice and the reasoning for it and in doing a search for def, I found numerous threads where this is the recommendation over the last couple of years.

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

Def always seemed to work well in the 1.1X series and it is only the betas and new 1.3 release where it seems to produce problems. Though we can make this change on all units, we really never kept track of which version of a radio card went where so aside from the MAC address which can probably tell a lot about the model, it is a little bit of a guessing game. Seems a bit of a hassle when def worked well before.


It is always a good idea to set the tx power to a known setting, as you need to know it in order to stay within FCC compliance. (larger the antenna, the lower the tx power level should be set). We have never recommended otherwise.

[lonnie]

Its time to update the Ubuntu package and OpenBSD servers. We updated our client with this release. Also, people have reported that Layer7 rules mess with ntp.

[lonnie]

I do advise to leave it at def because most people go crazy and try 30 thinking they'll get more power, but end up with tons of noise.

If you are reasonable and stay within card limits then it is best to set a value so that you can keep you overall emitted power (card output plus antenna gain) within the regs for your country.

It's sort of like this --> if you have to ask, then use DEF. If you know what you are doing then likely you are already using an override number.

Tony,

I was also under the impression that it was best practice to always set the cards to 'def'. Here is a thread in May where Lonnie gives this exact advice and the reasoning for it and in doing a search for def, I found numerous threads where this is the recommendation over the last couple of years.

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

Def always seemed to work well in the 1.1X series and it is only the betas and new 1.3 release where it seems to produce problems. Though we can make this change on all units, we really never kept track of which version of a radio card went where so aside from the MAC address which can probably tell a lot about the model, it is a little bit of a guessing game. Seems a bit of a hassle when def worked well before.

[soulmata]

Does anyone have any other suggestions regarding ESP traffic? If not, I'm stuck with 1.1.13 on the border router. Does anyone know if something has changed regarding layer 3 filtering that could have caused this?

[rbolduc]

I'm seeing the same problems with ntp going to a stock Ubuntu 7.04 server with the default ntp package installed. Works to other units, not to 1.3.0. I changed it to an ntp server off my network and it synced fine.

Me too I was using a cisco router internal to my network to sync with to get around the layer 7 stuff, but I cannot update NTP to any server any more.. what changed?

[pti-andy]

One thing to keep in mind is that the number you put in the tx power is not necessarily the actual power that the card puts out in dbm. In many cases full power is reached with a setting of between 17 and 20 depending on the card. An example is an XR2 puts out around 500mw with a setting of 20 even though 20dBm is really 100mw. The only way to know for sure what your card is putting out is to measure it with a power meter.

[lonnie]

The typical cards like CM9 and WLM54 use the Atheros technique of calibrating the output after the power amplifier, so the output should be fairly close to the setting. The UBNT radios add an extra amplifier but they did not move the power calibration point so you are actually setting the input to the final amplifer. No big deal and it works well, as long as you know you get 10 dB more than the setting says.

[Magician]

Lonnie, Why is this tread under "BETA" ? I see there is a new 1.1.14 build under release. If this the Final 1.3 release or are we expecting a new build? Thanks

[tony]

It is posted here for sake of the change log between 1.2.x and 1.3.0.

[Mark]

I do advise to leave it at def because most people go crazy and try 30 thinking they'll get more power, but end up with tons of noise.

If you are reasonable and stay within card limits then it is best to set a value so that you can keep you overall emitted power (card output plus antenna gain) within the regs for your country.

It's sort of like this --> if you have to ask, then use DEF. If you know what you are doing then likely you are already using an override number.

Errrrr... Problem: I have a number of clients, all using CM9's or WLM54AG's, that when set to "def" had almost no output. Less than if you set the tx power to "2". I know, I tried. These clients all but fell off the ap after firmware upgrades, and after setting them to 14 dbm, went from -91 to -72 at the AP.

[Mark]

There is a serious problem with X4 cloaking in 11A mode. I may also affect other modes. It has existed since at least as far back as 2412 and maybe before.

I have a rock solid link (-69 to -71) that will fall to -82 or so if you just switch to x4 cloaking from x2 cloaking. I wanted to use X4 because I have only a very few clients on this link and was trying to preserve spectrum at the dist site.

But I can't get more than about 2 mbit throughput in x4, because the signal level falls into the 80's and the speed falls to 6 or 9 and pings are a bit unstable.

go to the ap side and switch from x2 to x4 and the rxsl falls by at least 10 db. Reverse is true, repeatable.

I have tried a number of channels in x4, and only SOME of them will the client associate. II switched from 149 to 152 in X4 and the client never came back. Moved to 153 and it instantly hopped back on.

AP is WAR2, client is WRAP.

All are THIS release.

One last detail. Although when associated in x4, I get an RXSL of -81 or so, but site survey STILL shows at -69 or so, just like you'd get in x2.

If you reset the link by changing something, the client side will briefly show -70, but then will drop to -80.

[sligbot]

Has anyone had any issues with HTTPS? We're slowly upgrading all of our APs to 1.3 and have noticed that https sometimes (maybe 9 times out of 10) does not work. That said, we now have a mix of StarV3 units with different firmware in our network. Probably the obvious thing to do is try to finish upgrading the all to 1.3 but I thought to see if this issue was not limited to my own network.
--Rich

[tog]

Could you be more specific? From behind a 1.3.0 NAT router or all-routed with no NAT or what?

Have you tried wireshark at a problematic client machine (hopefully your own laptop or something to make it easy) to capture your traffic to see what's going on with it? Could it be an MTU problem?

I'm not having any odd http or https problems with either NAT'ed 1.3.0 client or all-routed 1.3.0 client or 1.3.0 WDS bridged client.

[tony]

StarV3 1.3.0 'problems' list has been updated to include:
WPA-enabled AP interfaces will lose their static routes. Dynamic routing is not effected.

The problem was reported today, and has since been duplicated and fixed.

[lonnie]

There is a serious problem with X4 cloaking in 11A mode. I may also affect other modes. It has existed since at least as far back as 2412 and maybe before.

I have a rock solid link (-69 to -71) that will fall to -82 or so if you just switch to x4 cloaking from x2 cloaking. I wanted to use X4 because I have only a very few clients on this link and was trying to preserve spectrum at the dist site.

But I can't get more than about 2 mbit throughput in x4, because the signal level falls into the 80's and the speed falls to 6 or 9 and pings are a bit unstable.

go to the ap side and switch from x2 to x4 and the rxsl falls by at least 10 db. Reverse is true, repeatable.

I have tried a number of channels in x4, and only SOME of them will the client associate. II switched from 149 to 152 in X4 and the client never came back. Moved to 153 and it instantly hopped back on.

AP is WAR2, client is WRAP.

All are THIS release.

One last detail. Although when associated in x4, I get an RXSL of -81 or so, but site survey STILL shows at -69 or so, just like you'd get in x2.

If you reset the link by changing something, the client side will briefly show -70, but then will drop to -80.

We have audited the code and it works properly. What we are finding is that "some" cards are not calibrated properly, so that they have a card maximum of 0.

When def is set for power we honor the country code maximum up to whatever the card maximum says. Thus we never over drive the card, even if the country code says 30 dB (none do, but I'm just illustrating the point). We will always cap the power at the lower of the card maximum or the country code channel maximum. This creates a problem if some cards do not have the necessary calibration, or maybe the calibration is messed up.

This is why Tony (and now Lonnie as well) advise that you should set a Tx power.

Anybody who sees the very low signal with def should enable snmp and send us the results of the following line:
snmpwalk -v 2c -c public -m VLMT-EXP-802DOT11EXT-MIB <war-ipaddr> vlmt802dot11ext

[Mark]

We have audited the code and it works properly. What we are finding is that "some" cards are not calibrated properly, so that they have a card maximum of 0.

When def is set for power we honor the country code maximum up to whatever the card maximum says. Thus we never over drive the card, even if the country code says 30 dB (none do, but I'm just illustrating the point). We will always cap the power at the lower of the card maximum or the country code channel maximum. This creates a problem if some cards do not have the necessary calibration, or maybe the calibration is messed up.

This is why Tony (and now Lonnie as well) advise that you should set a Tx power.

Anybody who sees the very low signal with def should enable snmp and send us the results of the following line:
snmpwalk -v 2c -c public -m VLMT-EXP-802DOT11EXT-MIB <war-ipaddr> vlmt802dot11ext


WHAT are you talking about?

THe power is NOT set to "def". I spent several very late night hours painstakingly going through all my clients and setting the power because I suddenly had serious problems after updating to V3.

The cards are CM9's, and the power is set on both of them to 14 or 15 (memory fails), and when I switch to x4 cloaking, I lose 10 or more db RSSI.

When I switch back, I gain the RSSI back. I've switched this a half dozen times and changed channels all over, the pattern follows this.

I've played with pretty much all the settings and it's very consistent. I just put this link up yesterday.

X4 cloaking loses 10 db or more RSSI on this link.

I just tried this on another backhaul link. This time between PC and WRAP. Exactly the same behavior.

ALL have the power set. None are "def". I lose 12 db rssi on that link, when I switch from 2x to 4x cloaking.

I just tried this on a 2.4 link, and the rssi remains within a db or two.

[lonnie]

If you want me to interact with you then you better back off a bit. Tone it down. OK?

[lonnie]

We do not see this on a WAR1 or WAR2 client to a WAR4 AP. It could be a x86 code issue with regards to data alignment.

Are you able to run that snmp line I provided and give us the results?

[Mark]

We do not see this on a WAR1 or WAR2 client to a WAR4 AP. It could be a x86 code issue with regards to data alignment.

Are you able to run that snmp line I provided and give us the results?

Not at the moment, but I'll be glad to give you the IP's and even logins of the machines in question.

Please understand, though. The link in question feeds someone who runs a VPN over it to telecommute for her work, and if we break thier vpn, it costs her quite a while on the phone while tech support unflags her file access so she can get access again. The second one feeds half my customers, and X4 isn't enough bandwidth, I only did it briefly to test.

Just pm me or email, I'll respond with the data.

On second thought, I'm just sending you the info via pm.

[lonnie]

I just tried this on a link and the signal always gains 2 dB when switching to X4 from X2. These are on WAR4 AP and WAR1 client.

If you can give me the login for the AP and a couple of clients I will check it out. I will mess with your feed to half your customers so as not to lock out a business customer. Mostly I just want to observe the system. I am sending a PM now.

[redstaab]

Sorry to steer from the subject, but is there going to be an "Upgrade" to the 1.3.0?

I am running 1.1.13 and 1.1.14 and dont have a jtag to re-install the base 1.3.0 on the gw2348-4's

[lonnie]

HUH? Just use starutil or Utilistar and upgrade.

[tony]

The 1.3.0 is a normal upgrade from 1.1.x, and does not need to be jtag'd. Simply upgrade to it as you would any other version.

[hatster]

Hi,

I also have a RSSI problem. This only appeared today a few days after I upgraded to 1.3.0.

My AP is v2.10.0 on WRAP, the client is Wrap V3 1.3.0. Site survey showes that my AP is the only AP in the 5ghz range, and the signal is -69, yet the card locks on at -86. Both cards are Atheros 5213 chipset, model: WMIA-123AG, not sure of the make. Never had this problem before.
From the AP the association is showing as -70.

Best Regards,

Kev.

[pachitoone]

Hi

I previously posted that a war2 with 1.1.13 configured as a station and wireless/ethernet bridged(intended to function as a transparent bridge) could not connect to an AP with 1.3.0(War2). Does someone have this issue? Loonie/Tony have you tried this? I need this configuration because the client have a VPN with Linksys routers. I have tried many times and it did not works. Thanks.

[tony]

There are no known incompatibilities between 1.3.0 and 1.1.13 WDS clients, however the ideal solution is to upgrade the WAR2 to 1.3.0 as well.

Alternatively, you can try and disable SuperA/G on the AP (or client) and see if that helps.

[Beebe]

Just wanted to say, I know it seems like a lot of people are having problems, but we pretty much flawlessly upgraded an AP and all 6-7 clients today from a wrap/v2/prism AP to a war4/v3 1.3.0/compex. We also swapped out the omni to a dc grounded antenna.

We went to each customer and swapped out their CB3 for a compex 1-port board. we had no hardware issues (except for a heatsink had fallen off a board in shipping). All customers pegged very close to the CBQ speeds we had them set at, and signals were improved.

All customers were using WDS on public IPs.

Great release from what we've seen.

Thanks,
Roger

[tony]

Based on the shear number of users using StarV3, the incident level is actually quite low. We are pleased with the new release, which will only continue to improving over time.

[lonnie]

Roger, we can replace that WAR1 or you can operate it without the heatsink. We asked that it not be used but Compex insisted. We did all sorts of testing and these units never get warm enough to come anywhere near hot. All of our development and evaluation boards did not use nor require a heatsink.

[Bossman]

Back to the country codes

*) 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 (world release) can be used in it's place for systems that require them.

Is there anything that will work to get a frequency like 2367 MHz? We occasionally go outside briefly to see if an issue we have is in fact interference.

[Mkleibrink]

Hi,
i tried your new release and it brought me just trouble.
First I tried some locations with a few customers. Everything seemed normal.
So I started to upgrade our main link to the internet. The link started to become unuseable, my WAR4 started rebooting because the CPU maxed out. I had problems to gain access to it. I had not much time to investigate because it was my main link, so I switched back to 1.14. The problems did not go away. After I switch out the WAR4 with a WRAP with version 1.14 the link normalized. After testing the WAR at home it became obvios that the CPU maxes out when I begin to pull any traffic through it, even after I downgraded to 1.14. I turned every service of and same thing. Maybe something got messed up during the upgrade and prevailed during the downgrade. My Question is how can I set the WAR4 to factory default.

The other problem occured two days later. Some customers complained that they can't connect to our Base station. At the customers location I found out that his AP (Compex NetPasage Atheros Chipset) sees our Station but can't connect. After downgrading to 1.14 it worked again. Same thing happened to some other customers with wireless cards. I don't know the brand.
After all this problems I switched everything back to 1.14 and know it works as usual good.

I did a throughput test from pc starv3 1.3 another pc and was amazed with the throughput. But i was forced to downgrade because of the cpu max out issue and the incompatibility problem.

Maybe you should offer some compatibilty option for AP use.

Keep up the good work

[tog]

To reset to factory defaults:
Go to the system menu and bring up the system console. Then type "system factory" and hit y to confirm.

I've upgraded quite a few things from 1.1.11 and 1.1.13 to 1.3.0 and also a few things from 1.3.0 back down to 1.1.14 with no problems...

[hatster]

ok, folowing my previous post, i have changed nothing, and not rebooted anything, today the signal from the client wrap has gone back to -70 as before, but now all associations on this wrap (wpci2 AP) are lower by about 10db than they should be. This is the same problem I had when i first upgraded from v2 to v3 1.3.0, see my post in the support section "upgraded v2 to v3 Help!!"

Im guessing here that there must be an incompatibility issue with this particular type of card, i dont know the make, but the details from the card are:
Model: WMIA-123AG
FCC ID: MXF-M 930907

Is anyone else using these cards ? they came with our wrap boards, normally we buy all CM9.

Best Regards,

Kevin.

[nickwhite]

ok, folowing my previous post, i have changed nothing, and not rebooted anything, today the signal from the client wrap has gone back to -70 as before, but now all associations on this wrap (wpci2 AP) are lower by about 10db than they should be. This is the same problem I had when i first upgraded from v2 to v3 1.3.0, see my post in the support section "upgraded v2 to v3 Help!!"

Im guessing here that there must be an incompatibility issue with this particular type of card, i dont know the make, but the details from the card are:
Model: WMIA-123AG
FCC ID: MXF-M 930907

Is anyone else using these cards ? they came with our wrap boards, normally we buy all CM9.

Best Regards,

Kevin.
http://www.sparklan.com/product_details.php?prod_id=22

http://www.sparklan.com/data/prod_data/19/prod_data.pdf

That the card? What's your TX Power setting, Rate setting, etc?

[hatster]

yeh thats the card. TX power = 17, TX rate = 11. BUT its not the transmit thats the problem. The clients all see normal signal strength, its the reception side of the card that is the problem. CPE are varied, but some are CM9 Wistron, I know these are all good. ALL associations are showing the same loss of signal on the association list of the Sparklan card

Kev.

[nickwhite]

Have you tried disabling extra features such as SuperAG or Short Preamble?

[pachitoone]

There are no known incompatibilities between 1.3.0 and 1.1.13 WDS clients, however the ideal solution is to upgrade the WAR2 to 1.3.0 as well.

Alternatively, you can try and disable SuperA/G on the AP (or client) and see if that helps.

I have configured AP and client to b mode only. Well, I will drive to the client location to upgrade the WAR.

[lonnie]

The simple answer is no. We will implement a license mechanism at a later date. The simple fact is that the FCC and Industry Canada are increasingly protective about spectrum misuse.

Your little incursion into 2367 is what they are very concerned about. You have no monitoring so you have no idea whether a legitimate user is using that channel and you might very well have affected a licensed user.

It is simple to find interference without abusing the rules BUT it means you need to invest in a spectrum analayzer. I consider it essential.

Back to the country codes



Is there anything that will work to get a frequency like 2367 MHz? We occasionally go outside briefly to see if an issue we have is in fact interference.

[lonnie]

I wish to ensure that everybody begins to use a country code for their systems and that they use the same country code for all systems they have.

The new driver does use the country code information for all kinds of RF settings, so you really have to feed it proper information.

[vinezero]

I had a recurrance of a problem with one link after upgrading to 1.3.0
This has been a problem link before I assume due to some interference I have not be able to locate the source of.
The customers is about 7 miles from the AP clear line of site. the client is a Senao CB3 the AP is a WAR Metro using 3 sr2 radios. This is the only customer on this radio, there are 10 on the other radios but I have no problem with them.
The signal strenth has been around -76 db but the quality has been the problem. On 1.1.13 the quality bounced betwen 0 and 10%, When I was trying to setup the link I upgraded to 1.2.3b-2333 the quality went up to 90% and everthing was working fine. I upgraded this morning to 1.3.0 and the quality went back to 0-10%. I switch back to 1.2.3b-2333 and the quality went back up to 90%.
Do you know any changes between the version that could explain this?
The detail for the AP radio config are:
CH 11
tx rate 11 mbs
link distance 12 miles
contry code us
tx power 16
cloaking 1x
antenna b
AP
Hide SSID
802.11b
wep enabled
everything else is unchecked

Thanks in Advance

[lonnie]

There were many changes but they were made to improve the connection between our units in managed mode in low signal conditions. We will take a look at the changes and see what can be tweaked without breaking the current system.

[pti-andy]

I have discovered that there are invalid frequencies in version 1.3.0 that should be valid.

Frequency 5760 and 5800 will not associate under any circumstances. They seem to be absent from the scan list. Even if using a custom scan list of say 5800-5800 the scan will jump down to 2407 even though I'm in 802.11a. Same goes for 5760-5760. All other channels from 5500 to 5830 seem to be ok.

This plays heck when trying to upgrade clients and took me the better part of a day to figure out what was going on.

[tony]

5760 and 5800 are both turbo channels, and cannot be used for 802.11a non-turbo operation. (Cloaking 2x and 4x will allow use of these channels however)

If you are not using Turbo, use 5765 or 5805 instead.

[pti-andy]

5760 and 5800 are both turbo channels, and cannot be used for 802.11a non-turbo operation. (Cloaking 2x and 4x will allow use of these channels however)

If you are not using Turbo, use 5765 or 5805 instead.

I am using cloaking. It does not work in either 2x or 4x mode. This is why it prevents the upgrade to 1.3.0 since it worked fine in 1.1.x.

[tony]

Strange, I will look into it. Thank you for the report.

[Bossman]

Any feedback from upgrades?

We have everything running on V1.1.13 b2080. We've done some bench testing, which seems fine, but as soon as we do it in the field it all falls apart and becomes almost unusable. We likely need to do things in a different order or via a different process but.... looking for answers.

One scenario:
- Small repeater with a war2 and V1.1.13 b2080.
- Radio 1 is the backhaul on 2447 US mode 4x cloaking, 6 Mbps, super A/G, short preamble. It gets decent performance. There is lots of 2.4 in the area, but we are managing. Quality is 100 and SS is -48dbm (with power at the radio at 0). Throughput varies from 5 Mbps to 1Mbps on a speed test.
- Radio 2 is for a few clients... 2412 US 1x cloaking (g)

- AP that this repeater connects to is running V1.1.13 b2080 as well. All the same settings with the exception of the power. It's a WAR4

When we do nothing else but upgrade the firmware on the client side (the repeater) to V1.3.0, we get qualities that bounce around from 0 to the 80s and the packet loss is high, latency is high etc. From the AP running V1.1.13 b2080 all the stats are great but from the client side you see all sorts of bad.

So.... should we be upgrading the tower then the clients or go from some other version than 1.1.13 or all at once or ???

Thanks for any input

[lonnie]

I try and do them all at once. I keep a bunch of ssh sessions and then just go one to the other and reboot after applying the upgrade. The AP is last.

[Bossman]

So what we are seeing is normal for the version differences? We're not just screwing something up? :-)

[lonnie]

I don't really know. This is the way I usually do it. I try and keep everything at the same version and out of habit I just do them all at once. It avoids any issues. I look upon an issue caused by a version change as something that can be cured by using the new verison.

This new release is particulary important to do them all, mostly because of the advances and enahancements with managed mode. If there is a problem with the previous release it is fixed easily. Upgrade.

[tog]

I have one 4x/11g client and it has been working perfectly using 1.3.0 as the AP and 1.1.13 as the client side. I have enough different 2x cloaked and non-cloaked 11a and 11g running 1.3.0 at the AP side that I can can confidently tell you that mixing 1.3.0 AP with 1.1.x clients has been working great. You can even use WDS on a 1.1.x client with a 1.3.0 AP if you want.

BUT, my personal experience with 1.3.0 as a client so far has been bad and I have mostly had to keep to using 1.1.x as my client-side for now.

If my experience across 6 different APs of differing types is any indication (1x/11a, 2x/11a, 2x/11g, 1x/11bg etc.) I can tell you that if you use shared-key WEP, 1.3.0 as a client will have some trouble seemingly with the transmitting-towards-the-AP part. Whenever the AP has one or more clients transmitting towards it consistently (even just 100-200kbit), the other 1.3.0 client(s) seem to start having troubles transmitting towards the AP and will even sometimes stop being able to communicate for up to 20-30s at a time, and sometimes repeatedly.

I just disabled WEP on some of my 11a backhauls in the last 16 hours and made that particular "micro-outage" problem go away where the 1.3.0 clients would lose the ability to pass traffic for up to 20-30s at a time so that's one problem down.

The second related issue using 1.3.0 as a client, even without WEP, a 1.3.0 client's ability to transmit towards an AP that is currently receiving traffic from other client stations is still not as strong as 1.1.x's. Under some conditions where the AP is receiving a decent amount of traffic from other clients, there may be some packet loss (upstream PL towards AP) with 1.3.0 as the client where there was none before when using 1.1.x as the client.

[valenti]

Its time to update the Ubuntu package and OpenBSD servers. We updated our client with this release. Also, people have reported that Layer7 rules mess with ntp.

I ignored my two upgraded units for 4 days. One of them had started working with NTP when I checked back with it. The other still didn't sync, but I restarted it and then it did sync.

I've been using OpenBSD's OpenNTP, it has worked in the past. (I'm running an 8 month old release). No layer 7 rules.

This is no biggie for me, for now. Eventually I would like central syslog working with consistent timestamps. If it doesn't settle down someday, I can try to trace packets, etc. (or if there is some ntpd on open source that is known to work, I can switch to that)

[tog]

My 1.3.0 systems tend not to get their time set at boot, but do an hour after (ntpdate runs once every hour to sync the clock). I'm using the usual ntp.org ntpd.

They probably don't suceed during boot because it takes a moment for the wireless links to establish and for olsrd to bring up their routes.

No big deal...

[go.fast]

I have to admit, I find it a bit annoying when I'm looking in the logs and the time is wrong. Wish there was a fix, we also use pool.ntp.org.

We used to use our own, not sure why we don't still have ntp.

[Stratolinks]

Just finished manually upgrading from 1.1.13 on everything to 1.3 on almost everything. Had one hiccup in the whole deal. I upgraded 64 WAR1 CPEs, 2 WAR4 Metros, 1 WAR4, 1 WAR2, 7 X86 PC, and 25 WRAPs.

So far everything seems to be workign just fine. Only one exception in the whole thing. One X86 upgrade will not work after installing 1.3. One radio card (CM9) does not link after the upgrade. Manual power levels are set on both ends of the link at 15dBm (has been for a long time), the speed is manually set at 48 in the 2x mode it is running.

With 1.3 installed it just keeps searching and never connects. The other end of that link is 5km away, and the distance has always been set at 10miles (hey I never bothered tweaking the distance lower because it always worked well).

Here is a screenshot of it with 1.3 installed.
http://stratolinks.com/forums/WF_1.3_Aug25.gif

A few minutes later after putting 1.1.14 back on it.
http://stratolinks.com/forums/WF_1.1.14_Aug25.gif

Anybody have any ideas?


I will probably replace the CM9 radio card with a new WLM54AG just to see what happens. Just didn't think it was a good idea to climb a 364ft tower during the lightning storm that was rolling through as I was doing all these software upgrades.

[handyman]

I try and do them all at once. I keep a bunch of ssh sessions and then just go one to the other and reboot after applying the upgrade. The AP is last.

Indeed...

I have PtP backhaul links running 1.1.13.

Once I upgraded just the client side with no issues. Link was 11a, 1x, open-system WEP.

Once I upgraded just the AP side and the client side would not reassociate. The client log showed: "wifi1 successfuly deauthenticated from ...; pingwd: Host: (IP) did not respond! ...". This link was 11a, 1x, open-system WEP, superAG, turbo. Downgrading the AP brought everything back.

[lonnie]

Startolinks, did you happen to do any reports before you took it down? The kernel is new and it would be a good idea to see if it handled your motherboard the same, ie did you have shared interrupts or something?

[Stratolinks]

After getting a few hours sleep, I was checking things over this morning and discovered I have a couple other issues since all the upgrades last night. Overall, we are seeing improved signal levels from the WAR1 CPEs to the V3 APs, and soem of the old CPE equipment is working better in this release than it was under 1.1.13.

We have a X2 cloaked sector feeding a few micropops that has been working fine. After the upgrades, one of the feeds from it will not change away from a 1Mbit transmit rate, despite the excellent signal level. The other pops that are linking back do, but not this one. I tried lowering the tx rate at the remote end from the 24 that has been working solidly before, down to 11, but it stays at 1 anyway.

This feed provides service for 5 clients from Brinsley, 5 clients in Carlisle, 2 in Nairn(will soon be moved to new unit in Nairn), 6 on the new Nairn unit, and 24 in Clandeboye (this will soon be getting a new 5GHz feed to it).

I can't see any reason why the Brinsley unit stays down at a 1Mbit tx rate.

Anyone with any suggestions?

http://stratolinks.com/forums/1.3_To-Brinsley.gif



Now on to the other last issue...

We have a War4Metro (been up for 4 months) feeding a 3ft dish that feeds 2 POPs that are directly in line from the feed. The closer one in BIRR (in a valley) has a 2ft parabolic with some fresnel zone encroachment (had been staying linked fixed at 36Mbits), the other unit at Bryanston is farther away, but at a higher elevation with a 3ft dish on it (was always at 54Mbits). The difference in signal between the 2 at the AP end has typically been about 6-8 dB. Since the upgrade, the levels at the WAR4 are down by about 9-12dB. All radio cards are either CM9 or WLM54AG.

http://stratolinks.com/forums/1.3_W4M-Birr-Bryanston.gif
Anybody have any suggestions?

[lonnie]

Indeed...

I have PtP backhaul links running 1.1.13.

Once I upgraded just the client side with no issues. Link was 11a, 1x, open-system WEP.

Once I upgraded just the AP side and the client side would not reassociate. The client log showed: "wifi1 successfuly deauthenticated from ...; pingwd: Host: (IP) did not respond! ...". This link was 11a, 1x, open-system WEP, superAG, turbo. Downgrading the AP brought everything back.

Did you have the same country codes set? Did you have a valid channel? Things changed between releases as we tighten the code and become compliant with regulatory agencies. What hardware?

We use all WAR4 for AP and backhaul and WAR1 for client. Some older clients use WAR2 for client. Never an issue and this latest release is probably going to be in place for 6 to 12 months.

[tony]

handyman, what is the name of the firmware file you upgraded your system with?

[handyman]

Did you have the same country codes set? Did you have a valid channel? Things changed between releases as we tighten the code and become compliant with regulatory agencies. What hardware?

We use all WAR4 for AP and backhaul and WAR1 for client. Some older clients use WAR2 for client. Never an issue and this latest release is probably going to be in place for 6 to 12 months.

Both units were WAR/4 (pre-Metro, Gateworks I guess they would be). Both set to 802.11a turbo, Outdoor, Short Preamble, SuperA/G, country code US, 1x, def power, auto rate, open-system WEP 40. AP distance set to 3.0, client to 4.0 (they are 1/2 mile apart). AP channel 5800, client channel auto. The SNR is above 30 and the link usually runs at 108. AP card is CM9, and client card is probably CM9 or possibly WLM54AG.

[handyman]

handyman, what is the name of the firmware file you upgraded your system with?

vncOs-1.3.0.v.fcc-2446.XSCALE-WAR.pkg

[tony]

Few changes for you to try:

1. Set your txpower of 18, and not 'def'. (always do this, so you can be sure as to the txpower being used)
2. can you try using channel 5805, and non-turbo and see if your client links up?

[Stratolinks]

Stratolinks, did you happen to do any reports before you took it down? The kernel is new and it would be a good idea to see if it handled your motherboard the same, ie did you have shared interrupts or something?

This link is the feed from the internet to the rest of the network, so I had to put 1.1.14 back on it. I just went and pulled the IRQ info from it.
---[ IRQ Information ]--------------------------------------
CPU0
0: 3072033 xT-PIC timer
2: 0 xT-PIC cascade
10: 17481818 xT-PIC wifi0
11: 19016372 xT-PIC wifi1
12: 942758 xT-PIC eth0
14: 3963061 xT-PIC wifi2
15: 11427 xT-PIC ide1
NMI: 0
ERR: 0 It has been at least 3 or 4 months since I upgraded it from V2 to V3. This site has been operational in it's current config for more than 2 years. After posting the initial message last night, I tried a few more things. I tried flipping the AP and station ends around. Either end when in station mode and performing a site survey would come back with report not available. The radio card in wpci2 at this site is a CM9 (so is the remote end).

The actual hardware (PCI single board industrial computer on a 4 slot backplane) is the same as the 8 other locations where the upgrade went smoothly. Several of those sites also have 3 radios, 2 have 4 radios.

I really must add in that the 1.3 release is working very well so far. We had a couple customes on one WAR4Metro AP that could never stay connected and we would generally see 10% loss when pinging them. I checked them this morning and ran 1000 pings to each with no losses. The rx rate from these clients was always jumping around, and now it sits steady at 11Mb (they have older hardware). So I must say that the low level signal performance is very much improved (both these clients are sitting at -80 at the AP). I really hope we can keep getting all the CPE units slowly upgraded to the WAR1s, since they are working fantastic.

I would certainly say, 1.3 is a job well done.

I have receommended to others:
If you want stellar performance, use Star-OS.

[handyman]

Few changes for you to try:

1. Set your txpower of 18, and not 'def'. (always do this, so you can be sure as to the txpower being used)
2. can you try using channel 5805, and non-turbo and see if your client links up?

1. It was my understanding from reading the forums that the correspondence between the txpower setting and the actual power depended on the card in ways that were either not known or not fully understood, and that 'def' gave you the power the card's manufacturer wanted you to use. Maybe that's not true, or no longer true.

Is it the case that txpower 18 means the card will send 18 dB of signal toward the antenna, no matter what kind of card it is?

2. OK, the next time I'm awake when it would be reasonable to trigger another 10-minute outage, I'll go to 5805 non-turbo and try the AP upgrade again, and I'll try it with txpower 18 on both ends. FWIW, when the link was out, a "site survey" on the client saw the signal from the AP with, as I recall, an implausibly fat signal like -39 or thereabouts.

[tony]

The 1.3.0 release requires a good, calibrated card for the 'def' option to work properly, however we have found that may card vendors never programmed the eeproms properly, so this information is invalid, or not present at all causing the 'def' option to sit at 0dBm output.

Yes, setting it to 18 will cause the cards to output at 18dBm, and is well within the capabilities of the CM9.

[handyman]

The 1.3.0 release requires a good, calibrated card for the 'def' option to work properly, however we have found that may card vendors never programmed the eeproms properly, so this information is invalid, or not present at all causing the 'def' option to sit at 0dBm output.

Yes, setting it to 18 will cause the cards to output at 18dBm, and is well within the capabilities of the CM9.

Interesting.

So that means, for example, if I use a 600 mW XR2, I should set txpower to 28, and if a 400 mW Senao 8602 I should set it to 26? (That's assuming I want to run the card at full power.)

But now I wonder about the different power levels in g- and a-mode...and if, say, I'm using an 8602 as an AP in mixed b/g mode, does the txpower setting refer to b-mode power or g-mode power? It's so confusing...

I guess I can always use trial-and-error...and choose the setting that gives the best ping behavior or throughput.

Actually, "def" power has always worked great for me, and is working great so far on the APs I've upgraded to 1.3.0. The cards involved are CM9, WLM54G, 8602, and DCMA-82. Maybe it's safe to go with "def" power when you see near-perfect connections to every client, as I often do. :)

[tony]

No, the UBN cards have an external amplifier which add power over and above what the card produces. You will most likely set the card somewhere between the 5 and 10 mark.

You will need to contact them for proper card values, as I do not believe they are provided with the cards themselves when you purchase them.

11b and 11g always share the same tx power support (normally 20dBm in modern cards), and 11a is typically a little lower, somewhere in the 17 to 18 range. You can look up these numbers from the mfg.

If you use 'def', you can look at your card's actual transmit level using snmp.

[vinezero]

Here are the power values for Ubiquiti SR and XR card from their site.
I assume they hold true with star-os.

http://www.5x.net/srxr.jpg

[tony]

That is perfect, thank you. I will copy your post into a sticky for reference by others.

[handyman]

No, the UBN cards have an external amplifier which add power over and above what the card produces. You will most likely set the card somewhere between the 5 and 10 mark.

You will need to contact them for proper card values, as I do not believe they are provided with the cards themselves when you purchase them.

11b and 11g always share the same tx power support (normally 20dBm in modern cards), and 11a is typically a little lower, somewhere in the 17 to 18 range. You can look up these numbers from the mfg.

If you use 'def', you can look at your card's actual transmit level using snmp.

OK, this confirms what I thought, that there is a complicated or mysterious relationship between the txpower setting and the actual TX power produced.

The snmp probe will be very useful. Thanks for the tip.

[billr]

Hi all,

Apologies if this has already been answered but here in the UK (and elsewhere in Eu) we use B channels 12 and 13, and licenced channels in 5.8 GHz...

I was looking forward to ## country code, but it is a real pity you have not allowed it. We need channels 12 and 13, and the extra channels in 5.8 GHz.

I am using V 1.3 (and am impressed with it) but we cannot deploy fully as it does not include channels we need.

We would really appreciate it if you could resolve this quickly.

As a licenced radio amateur, I know it is the responsibility of the user (not the supplier) to transmit only where permitted, so I feel you are being a little over-cautious with the 'World' release.

As I say, apologies if this has already been sorted out.

Cheers.

[tony]

We are working on the frequency licensing option, and should be available from the license-keys.com website as a license upgrade soon. (will operate much like a license renewal currently does).

We have since released the 1.1.14 version which does have the '##' available for those who require it.

[billr]

Ok, thanks for the information.

Some of our backhauls use channel 13 as it is less used here.

Cheers!

PS hopefully it won't be a paid upgrade?
Maybe anyone who requested it would be required to 'sign' that they would keep to their licenced bands in the appropriate country, thus absolving you of the responsibility.

[cephlon]

Just notes while upgrading one of my APs to 1.3.0. War4 with 24 clients. I should mention this is a StarOS/atheros only AP.

I upgraded the AP first, which I would not do again.

Had a bear of a time upgrading one client that was 1.1.0. I had to turn Super off, switch the AP to g only, turn off short preamble. Finally I was able to upload the new firmware. I would recommend turning these off while you upgrade all your clients. Once all your clients are upgraded, turn these features back on. Or upgrade your clients to 1.3.0 first, then upgrade your AP.

Also, as was mentioned before, make sure you do not lock your rate to 11. I had all my clients locked to this rate when I upgraded, and it caused some issues with quality dropping to 13-0%.

AP works so much better in G only mode then in b/g. I didn't need this AP in b/g mode since this AP only has Warboard connected in g mode. I didn't realize this made such a big difference. If you don't have any b clients on your AP, I recommend switching to g only.

Since the upgrade (earlier today) I haven't seen the quality of any of the clients drop below 100%, even when doing a throughput test. This may be due to switching everything to auto rate. The throughput seems to have gone up a good deal also.

Good Job guys, you continue to make me look good.
I'm going to upgrade a cloaked AP next.

Two questions: some of my clients don't have stars next to the Q and U. What does this mean? What exactly does the QOS do?

[tony]

QoS does packet prioritizing over the Wireless, so high-priority data (such as VoIP) is transmitted before other data, such as ICMP, and web downloads.

[go.fast]

If you use 'def', you can look at your card's actual transmit level using snmp.

Are you saying you can read the real time actual out put of the card with snmp?

[pti-andy]

If my experience across 6 different APs of differing types is any indication (1x/11a, 2x/11a, 2x/11g, 1x/11bg etc.) I can tell you that if you use shared-key WEP, 1.3.0 as a client will have some trouble seemingly with the transmitting-towards-the-AP part. Whenever the AP has one or more clients transmitting towards it consistently (even just 100-200kbit), the other 1.3.0 client(s) seem to start having troubles transmitting towards the AP and will even sometimes stop being able to communicate for up to 20-30s at a time, and sometimes repeatedly.

I just disabled WEP on some of my 11a backhauls in the last 16 hours and made that particular "micro-outage" problem go away where the 1.3.0 clients would lose the ability to pass traffic for up to 20-30s at a time so that's one problem down.

The second related issue using 1.3.0 as a client, even without WEP, a 1.3.0 client's ability to transmit towards an AP that is currently receiving traffic from other client stations is still not as strong as 1.1.x's. Under some conditions where the AP is receiving a decent amount of traffic from other clients, there may be some packet loss (upstream PL towards AP) with 1.3.0 as the client where there was none before when using 1.1.x as the client.

I have had a similar issue that Tog has been having with intermittent connectivity using WDS and 1.3.0 however it does not require traffic to the other client in order to drop packets.

About every 30 seconds I loose the connection to the router beyond the bridged client for about two seconds. I am not using WEP nor passing traffic other than continuous pings. Funny thing is I DON'T loose connection to the WAR-2 client itself, just the router behind it.

Downgrading to 1.1.x fixes the issue but I have been unable to get 1.1.14 to connect to a 1.3.0 AP with the client and AP bridged. The 1.1.14 client shows up in the connection list just for a blink and repeats every few seconds but never locks. After downgrading the AP it connects just fine. I think there is a big difference using WDS on a bridged AP vs routing at the AP with 1.3.0.

[lonnie]

Are you saying you can read the real time actual out put of the card with snmp?

SNMP will tell you what the power is actually set to. As I explained we do not ever exceed what the card says it can do and then we allow the country code to set for the legal output for your country.

Thus, if you set power to 23 and the card can only go to 17 dB and the country allows 20 dB, the card will be set to 17. The power will show 23 but the card will show 17 with SNMP.

If the card is capable of 26 dB and you set for 23 but the country allows 20 dB then driver will adjust the power to 20 dB and SNMP will show that setting.

[lonnie]

Andy, how many times are you going to post this? We are aware you have this problem but don't you think about 10 times in different threads is over doing the report?

If 1.1.x fixes it , then I say "problem solved". We will keep watching the Linux Kernel patches and perhaps they will get a fix to bridging.

Until then please use routing or 1.1.x.

I have had a similar issue that Tog has been having with intermittent connectivity using WDS and 1.3.0 however it does not require traffic to the other client in order to drop packets.

About every 30 seconds I loose the connection to the router beyond the bridged client for abou