StarV3 v1.2.11b build 2426 is ready for testing

[tony]

The BETA has been released, and is available on http://files.star-os.com/

The Status of this BETA is stable, though use with caution and provide as much feedback as possible. Also, when upgrading to this release, ensure you make a configuration backup first. (starutil -d option)

While the change log is not complete at the moment, there are some changes listed on this thread http://forums.star-os.com/showthread.php?t=6714, and previous BETA postings (1.2.1b and newer)

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

Changes since v1.2.10b build 2412
*) Better rate manipulation support for non-managed connections, which should increase overall performance.
*) MAC-based authentication for hotspot w/ Radius assigned IP support. (see hotspot section below for script additions)
*) SNMP on a WAR-1 now restarts properly when the system configuration has changed.
*) SNMP now uses fixed indexes for Wireless devices in the experimental 802.11 mibs.

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 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.

[tog]

Well this isn't terribly useful because it doesn't involve any testing of the Atheros driver, but...

Going from v2 to StarV3 1.2.11b (2426) on some random decomissioned WRAP that I haven't climbed up and taken down yet, my jaw dropped at the throughput test I did over its ethernet.

Normally with v2 a WRAP could get around 3500K/sec on the rx throughput test via the ethernet.

With this build of v3 it's getting 6100K/sec. v3 is fast!

On another note; I encourage everybody to try auto-rate with this build on their 11a and cloaked links, even if they are used to forcing their tx rate like I am. (I still recommend forced tx rate 11 for non-cloaked PtMP 2.4GHz for most consistent performance though...)

The new auto-rate in this build of 1.2.x is the best auto-rate I've ever seen. Even if the Qual drops low suddenly due to a high number of collisions or something at the AP, it keeps its cool and stays up at a decently high tx rate instead of freaking out and dropping to 6.

[tony]

Impressive results.

[soulmata]

I'm seeing the same thing I mentioned in the previous thread. When I enable WPA on a Metro to Metro PTP link, it no longer bridges properly. Here's a more detailed description of the config:



[Workstation, 192.168.7.2] <--> [Metro, bridge on ether1/wpci1]

[wireless link]

[Metro, bridge on ether1/wpci1] <--> [Server 192.168.7.1]

With WPA disabled, bridging works properly and I can see the MAC address of the server

With WPA enabled, I can no longer reach 192.168.7.1 and vice versa. I can, however, reach the ethernet side of the remote Metro.


Can anyone replicate this to confirm if it is a bug or that it is my particular configuration?



I can provide remote access if wanted as well

[soulmata]

Strike that. I restored factory default settings on the units, then reconfigured them, and they work.

Great stuff. ~33mbps in either direction going across the link with WPA enabled, 5GHz, at -68.

[lonnie]

Great. Thanks for the update.

[tony]

Thank you for the update. If you can replicate the problem (find the option that was enabled) that was causing the issue you had, please let us know.

[pti-andy]

Here is an update to the WDS issue. All parameters are the same as before with a WAR-2 AP and two WAR-2 clients.

After upgrading to v1.2.11b and rebooting, the two clients were not reachable from the router or workstation behind the AP. Once the client WAR-2's are pinged from the AP itself they then become reachable again just as before however, the response times from the AP utility menu are between 100ms to 500ms yet the response times from the router or workstation behind the AP are still 4ms. Thus pinging through the AP is just fine once the radios are reachable but pinging with the AP is horrible.

This may have been the case with the previous beta as well but I'm not positive on that. I do recall that when I got one of the AP's to lock up a while back when running speed tests it was when the response time was erratic from the AP utility but not the attached routers.

Hope this helps.

-Andy
PTI-Wireless

[DLNoah]

Wanted to report in on an issue we had with one of our APs, in case it helps anyone else...

We had been testing 1.2.8b and 1.2.9b on a few production access points, and it had been working pretty well. When we went to put it on a third access point, however, many of the clients had extremely poor Q%, despite signals of -60 or better (most of the "problem children" were within 2 miles of the tower). Tinkered with distance settings, channels, etc. to no avail. Downgraded to 1.2.6b and found that the problems went away.

After 1.2.11b was released, we put it back on the problem AP to see if there had been some sort of issue that was fixed; the problem remained. I wanted to try to do my best to isolate what (if anything) could make the problem better or worse, so I kicked the antenna over to Antenna B, deliberately selecting the wrong antenna. This, of course, caused the signal to drop, but the Q% became useable for the links that were still better than -80. So I set the antenna back to Antenna A, changed the tx power from def to 10, and voila.

--

So far I have 90%+ of my access point backbone on 1.2.6b for 24-48 hours with no reported issues, all non-Star pure bridges that are 11b only clients. I'm working on testing 1.2.11b on a Star-to-Star PtP link that I had some issues with earlier, when I did the upgrade the WDS was created immediately; the issue with 1.2.9b did not repeat. We're still testing to see what type of performance the link will get.

[tony]

I am going to be away until next Monday. While I am away, keep the reports coming in. If you have a problem, please specify as much information about the issue as you can, as clear as you can.

If possible, try and come up with a reproducible test case (step by step instructions to duplicate the issue). Once we are able to duplicate your problem, we can get it fixed.

For those using WDS:
Only v1.2.10b+ work as expected. If you are using an earlier 1.2.x earlier releases, please consider upgrading them.

For those using Cloaking in 802.11g/bg mode:
If you decide to use fixed rates, please make sure you lock to an OFDM, not CCK rate. Cloaking will only use OFDM rates for data.

Please do not post any sensitive information regarding your system, PM me this information if needed.

Out side of a few isolated issues, this release is looking very good.

[tog]

This release is definitely pretty good, and the auto-rate is great and WDS so far is working quite impressively well with five 1.2.11b bridged WDS clients on my 1.2.11b AP. So far I am not seeing the same troubles that I was seeing with WDS in 1.1.x. This allowed me to quickly upgrade 5 WRAPs with v2 without changing customers' network settings.

I was wondering if anybody else had setup a 1.2.11b AP with one or more 1.2.11b clients and if they were using SuperAG. I am consistently having a problem: When SuperAG is enabled on the 1.2.11b AP I can't communicate with my 1.2.11b clients, though I can communicate with the 1.1.x clients fine. As soon as I disable SuperAG it's fine again.

One AP is 11b/g non-cloaked, the other is 11b/g 2x cloaked, both have the SuperAG problem.

Is anybody else having success or failure with 1.2.11b AP/client with SuperAG enabled?

[pops]

I updated a wrap to 1.2.11b and a war2 yesterday
the wrap is an remote ap with a 11a backhaul to the war2, it all seems to be working ok, when I enable 2x cloaking for the backhaul link the signal quality on the wrap drops from -73 to -81 but quality and thruput stay's good, the signal on the war2 does not change.
I am using short preamble & super ag, broadcasting ssid ch 5745

I am not sure how to setup wds but I do have a client that I plan to take down an 8186 bridge and I want to put up a war1 with 1.2.11b and would like to use it as a bridged client as this person has an in house router and I would like to put a public IP on that router, don't want to use double nat.

I have not seen a wds option in any of the dialogues on the war2 board mabe it is only on the war1, don't know.

Pops

[Mark]

While 2412 was too aggressive in jumping the rates up, and dropped them too fast, so the speed was always wildly fluctuating, this version is the opposite. Links that used to be rock solid at 36, are now dogging along at 12 and 18, with reduced throughput, even compared to V2.

I have a long link that runs 21 miles, with RXSL reported generally -78 to -74, and it used to sit at 36 for long periods of time, once in a while jumping a little when signals peaked and occaisionally dropping to 24 when fade occurrred.

Now it stays mostly at 12 or 18, and I see ping times going up when the traffic is only 300KB on the link, which it used to carry before without even noticing.

However, the packet loss that 2412 saw is gone.

I may go back to 2412, however, and just rate limit to reduce packet loss. This link SHOULD be able to carrry the load it has with X2 cloaking, but it can't. Star speed tests are awesome, but I see 450 KB traffic spike the pings to over 1000.

Just FYI.

Edit. I may have spoken too fast. I appear to have a few db loss of signal at present. That may account for what I see, rather than version change. I just went back and looked at what we're running and what we used to have and maybe we're experiencing some kind of atmospheric issues....

Edit again: Atmospherics cleared up and I'm back to normal signal levels. I moved back to 2412 and then forward to this version. What will stay at 36 and 48 in 2412, with a solid link is now stuck at 18.

Update: It does eventually move up in speed, but it's very slow. Or, at least it seems to move slowly. Or maybe it's just visual, where the interface dosn't show the changes as often.

[tog]

12, 18 or 24 are what I would expect from a -74 to -78 link. I would expect that forced to 36 you would see packet loss, 36 is too high a rate for that signal strength, 24 is as high as I would actually try to venture.

Yeah, 2426 has fixed the PL from 2412.

I'm starting to think I'm crazy, every 1.2.11b client to 1.2.11b AP I have tried cannot communicate with each other with SuperAG enabled, but they are fine without. Yet nobody else is having this problem?

I have not seen a wds option in any of the dialogues on the war2 board mabe it is only on the war1, don't know.

There isn't any option or setting to check, all you have to do is bridge wpci1/ether1 together at your client unit and it will use WDS to make it work. No settings or changes are necessary at your 1.2.x AP for it to support WDS clients.

[Mark]

Super AG works fine for me.

However, I had to remove "short preamble".

If you leave it on, only staros basd clients can talk to the AP.

Even the mikrotik boxes which are set to auto choose cannnot associate.

goooofigger.

Would you like to look at an AP to compare?

edit, just noticed you're talking about clients with the latest firmware. No, i'll try one, though. I have yet to upgrfade clients.

[Mark]

I upgraded a WAR1 client and it works fine with super enabled at both ends. got a speed test of 1007KB, in 11b mode.

[tog]

!@%*!@$!

I have 11a clients and 11g clients failing to communicate with two different APs if the client and AP are both 1.2.11b and SuperAG is enabled. As soon as I disable SuperAG it's fine. Tony said he can't reproduce it and so far others are saying it's working :P

WTF. SuperAG hates me.

BTW, if you're using 11b mode I thought SuperAG was disabled.

[Mark]

!@%*!@$!

I have 11a clients and 11g clients failing to communicate with two different APs if the client and AP are both 1.2.11b and SuperAG is enabled. As soon as I disable SuperAG it's fine. Tony said he can't reproduce it and so far others are saying it's working :P

WTF. SuperAG hates me.

BTW, if you're using 11b mode I thought SuperAG was disabled.

They quietly put it back somewhere in the beta.

Like I said, if you want to look at one that's working, maybe you can compare stuff side by side, just PM me, I'll get you a password. Did you try removing the "short preamble" tic in the box?

[tog]

I did indeed try without short preamble, and in 11g and 11b/g and with and without cloaking and with and without WDS. Only thing I can do to communicate with my 1.2.11b clients from my 1.2.11b APs is turn off SuperAG :)

[Mark]

BAAAH, I know what's wrong.

I had a card fail like this a while back.

Super AG features just died out of the blue. Turn them off, it communicates, turn them on, nada.

Wait, you said you had TWO sites do this?

Got any where it's working?

[soulmata]

!@%*!@$!

I have 11a clients and 11g clients failing to communicate with two different APs if the client and AP are both 1.2.11b and SuperAG is enabled. As soon as I disable SuperAG it's fine. Tony said he can't reproduce it and so far others are saying it's working :P

WTF. SuperAG hates me.

BTW, if you're using 11b mode I thought SuperAG was disabled.


I have a TurboA link using SuperAG, short preamable and all other performance features on, that is functioning normally. AP is 1.2.11b, 1 client is 1.2.11b, and 1 client is my laptop with madwifi-ng drivers (latest).


Not having any issues

[soulmata]

And the performance, as usual as it has been with V3, is simply blistering fantastic (533MHz VIA C3 cpus):

http://whatthebert.com/soulmata/images/staros/terarx.jpg

http://whatthebert.com/soulmata/images/staros/teratx.jpg

I'd have to have gigabit NICs in the AP and client to get it any faster !

[tog]

Impressive, I barely nosed it up around 10000K/sec with two EPIA 5000s (533MHz VIA EPIAs) running v2. Looks like v3 made it faster, just like I was noticing how v3 made my WRAP faster.

[soulmata]

Same boards here, 5000 series. Fantastic little buggers.

[pananix]

Tony,

This is 100% reproducible on a WRAP or WAR-4. It is also one of the dumbest things I have done in a while.

I had a site go down w/ 2 ea 2 card WRAPs on it. Had everything I needed including a programmed WRAP radio and an unprogrammed WAR-4.

When I got to the remote site (hiked, so left some things in the truck and took only what I needed as it was a long walk), I found animals had played havoc with one of the ethernet cables (and the cable box was in the truck).

Long story short: Pulled down the two WRAPs, put up the WAR4. Storm moving in so I was moving fast. Came down from the tower and started programming the WAR4. Programmed port 4 first and saw all my clients come up. Quickly programmed the interfaces (one IP, all 5 interfaces bridged) and started on the radio configurations.

UNFORTUNATELY, when I got to port 3, I put port 4's info in, but had it on station with port 4 on AP. I realized I had erred (that's an understatement) after I hit File->Activate. Cards 3 and 4 associated and the system went to 100% CPU usage and locked. I pulled power, but later found that the system would start to assign IPs and would lock up.

The fix if you do this: pull one radio card (or up to 3 if the problem is between the first two cards in a WAR-4), reboot, change the radio config, and you're good to go.

Lonnie/Tony: I suggest this be considered a bug. I realize what happened, but I goofed while in a hurry, I think it should not lock up the system/prevent bootup.

David-

[jeff]

Tony,

Programmed port 4 first and saw all my clients come up. Quickly programmed the interfaces (one IP, all 5 interfaces bridged) and started on the radio configurations.

UNFORTUNATELY, when I got to port 3, I put port 4's info in, but had it on station with port 4 on AP. I realized I had erred (that's an understatement) after I hit File->Activate. Cards 3 and 4 associated and the system went to 100% CPU usage and locked. I pulled power, but later found that the system would start to assign IPs and would lock up.

Lonnie/Tony: I suggest this be considered a bug. I realize what happened, but I goofed while in a hurry, I think it should not lock up the system/prevent bootup.

David-

You created a bridge loop. Was spanning tree enabled?

[Mark]

this is from 2412, but I think it probably applies to this version too...

I had a WAR2 as a client, ran something well back in 1.1.x before I upgraded, when I did that, I lost contact with the board, though it appeared to reconnect and I could see a small amount of traffic going to it.

I could not get in via SSH, could use starutil, nada.

Finally, I tried from the AP, daisychaining. I got in.

I could not ping the outside world from it.

This looked like a network config issue, so I started looking. Whenever I installed that board, I had neglected to remove the default IP.

My cpe all operate as dhcp clients, and the ap as the server. The client had connectivity, but the internal workings of the board now used the default IP, rather than the dhcp assigned one.

Yes, this client had been connected successfully to the internet and I had been able to upgrade the firmware before. Only with the recent version has DHCP not overridden the statically set IP settings, but ONLY for "internal" communications - processes within the OS itself, like ping and ssh.

Just an FYI to people who might make the same error as I had and wonder why they had seemingly booted and working CPE that became unreachable.

[David L. Vrablic]

Darn, I drug out a V2 PC that was using a USB nic.
(I figured that was added to V3 a long time ago when Tony was asking what chip sets we needed.)

I Upgraded the PC to the co version.
Requested a key.
Got it copied it and pasted it in the form and it was accepted.
Saved and rbooted the unit it came back up in co version everything fine.
Then I uploaded the beta V3 went through the process.
Did a reboot and "I made a brick"

When it rebooted it said it wasn't keyed and would come up in free mode.
The NIC port is dead and the radio doesn't show up.
The mouse doesn't work any more.

I'll have to play with this one a bit.
Maybe I should be glad I didn't attempt any of those in service back hauls
Is all this because the USB NIC drivers arn't in there yet?

[tog]

Yeah that's all it is. No USB drivers in v3.

[David L. Vrablic]

Thanks Tog,
I'll put it to one side and reflash the CF when it the drivers get here.
I made a txt copy of the key in notepad so I should be able to recover everything later. I hope.
The huge key was a suprise and I don't see anything in the upgrade instructions about just what to paste where or what to do after it is entered and accepted. I'll read the WIKI again.
It was for one of my super rugged testers.
They work great in V2 but I need V3 for all those features.
Thanks again.

[Mark]

It was for one of my super rugged testers.
They work great in V2 but I need V3 for all those features.
Thanks again.

I could swear I saw you referred to sometime back as "the man with all the toys".

Since we started putting a lot of our clients on 5 ghz, we've stopped doing RF site surveys and just depend on vision. That's going be tough come winter and fog... But I just can't work out a handy AND CHEAP mechanism for doing the surveys.

Besides, without the bucket truck to get me 25 feet in the air, it all seems mostly pointless :(

[ripv]

Mark,

For near'ish sites we use a war1 with v3 in a 20db panel antenna mounted on a telescopic bar. Farther out ones same except a 28gb grid again with war-1 mounted behind on the tele-pole. Long cat5 cable on both. I've a clamp on the side of my roof rack and a base from a sun umbrella which I put on the ground under the clamp. Arrive at site put the pole in the base & clamp - let it up - run the cat 5 into the van connect to POE & the laptop. Use a cig lighter inverter to power the 2 - putty to the war and do the survey. Works well and we can do most with just the 1 person...:cool:

[pti-andy]

!@%*!@$!

I have 11a clients and 11g clients failing to communicate with two different APs if the client and AP are both 1.2.11b and SuperAG is enabled. As soon as I disable SuperAG it's fine. Tony said he can't reproduce it and so far others are saying it's working :P

WTF. SuperAG hates me.

BTW, if you're using 11b mode I thought SuperAG was disabled.


Is this only with WDS or do you get this with routing as well?

When I use WDS with a WAR-2 client and v1.2.11b WAR-2 AP I can't reach the client radios at all until I ping from the AP itself. This wakes it up but only for a while. Also I get a lot of packet loss on the connection. Downgrading only the AP to v1.1.13 fixes both issues. I did not have this happen with a WAR-1 client but it is hard to say if it is because of the number of clients attached or if it was the WAR-1 since it is the only one connected to the other AP I have upgraded to beta.

So far my experience is that WDS is acting flaky with the new beta on the AP. Funny thing is that I can reproduce this issue all day long. v1.1.13 always works and v1.2.11b never works on the WAR-2 platform but I'm told that WDS is solid. It is rather agravating. I'll try disabling superA/G to see if it has an impact on it.

Oh BTW, manual 10M full duplex doesn't seem to work on the beta either. I have to run half duplex or downgrade the client to v1.1.13.

-Andy
PTI Wireless

[Mark]

Ok, this seems to hold for all version of V3, no matter what.

WHat happened to "def" power?

if I leave anything at default power, it appears to put out about 1 or 2 dbm, if that. I'll have a RXSL at the CPE of -70, and the AP sees it at -86. If I enter, say, 11 into the power instead of "def", the difference between the ap and client become 1-3 db.

This seems to be true on WRAP, WAR 2 and WAR 1.

[tog]

I am having the SuperAG issue without WDS on routed-only links (but also with WDS).

I have not yet found a combination of settings with 1.2.11b AP to 1.2.11b client that allow me to keep SuperAG enabled and still communicate with the 1.2.11b client. I have a few more things to try I suppose... country code, 11b only, etc. I have very consistently reproduced an inability to communicate with my 1.2.11b clients (11a and 11b/g and 11g only!) so long as I keep SuperAG enabled at the AP. But so far it seems I'm the only one who can reproduce this and I have to figure out why.

WDS has been working well for me with 1.2.11b, I am testing it on at least five 1.2.11b clients and it has been solid so far. I always use the ping watchdog so all five of those clients' units are keeping themselves "awake" by constantly having ping watchdog traffic across the link, though. I have not yet tested to see if WDS has any side-effects if a link is left idle for, say, 5 or 10 minutes.

I have not had any problems with the ping watchdogs on the 1.2.11b client units bringing their own links back up without having the AP ping them or do anything to them. In fact, it's really kind of cool, I can see the ping watchdog passing traffic to and from the AP and no "W" lights up yet. As soon as the first packet comes from or goes to the client unit's ethernet side across the bridge, only then does the "W" light up. Apparently I am able to communicate directly with the client unit itself without WDS and it only turns it on the first time it is needed.

I just re-tested all that I stated above by resetting my 1.2.11b AP with those five 1.2.11b WDS clients on it. All came right back up immediately and passed traffic without any special intervention or traffic coming towards them first. They definitely initiated the first traffic themselves using the ping watchdog.

Is this only with WDS or do you get this with routing as well?

When I use WDS with a WAR-2 client and v1.2.11b WAR-2 AP I can't reach the client radios at all until I ping from the AP itself. This wakes it up but only for a while. Also I get a lot of packet loss on the connection. Downgrading only the AP to v1.1.13 fixes both issues. I did not have this happen with a WAR-1 client but it is hard to say if it is because of the number of clients attached or if it was the WAR-1 since it is the only one connected to the other AP I have upgraded to beta.

So far my experience is that WDS is acting flaky with the new beta on the AP. Funny thing is that I can reproduce this issue all day long. v1.1.13 always works and v1.2.11b never works on the WAR-2 platform but I'm told that WDS is solid. It is rather agravating. I'll try disabling superA/G to see if it has an impact on it.

Oh BTW, manual 10M full duplex doesn't seem to work on the beta either. I have to run half duplex or downgrade the client to v1.1.13.

-Andy
PTI Wireless

Ok, this seems to hold for all version of V3, no matter what.

WHat happened to "def" power?

if I leave anything at default power, it appears to put out about 1 or 2 dbm, if that. I'll have a RXSL at the CPE of -70, and the AP sees it at -86. If I enter, say, 11 into the power instead of "def", the difference between the ap and client become 1-3 db.

This seems to be true on WRAP, WAR 2 and WAR 1.

I am also seeing this. I have to set a tx power for any 1.2.11b client, because anything left at "def" will be like setting tx power to 1.

Scratch that, I'm looking right at one WAR1/WLM54G client that is still at def who is most definitely transmitting at what one would expect for def power. It is not consistent, and I have yet to figure out the pattern. I also just logged into a WRAP/CM9 1.1.13 client who is connected to a 1.2.11b AP who was set to def and he was transmitting 20dB lower than he should have been! I set a tx power and he was fine again.

[Mark]

And i'm seeing the opposite. I had a situation where the client would not talk to the ap until I turned ON super ag, but this was an 11a link. I don't recall turning off super ag, it must have been a mouse glitch (been working via VNC from home), but I lost a backhaul that would not come up until I tic'd the "Super AG" box.

I am also seeing some oddness as I upgrade dealing with short and long preamble. 11a will MOSTLY be ok with short, but my compex based clients with compex firmware will not associate if I tic the "short preamble" box.

A routerboard will not associate to the AP in 11b mode until I changed it to "short and long" in the settings. Doesn't matter WHAT the AP is set to, it won't associate with any of the current or last 2 betas.

Now, wasn't there a while back, a setting in one of hte config files where you could force preamble or at least set it?

Is that overridden by the GUI now, if this is a formerly text based device?

Now, about the rf power issue. I have both WAR 2 and WAR 1 clients that I simply left as "def" for power. They worked FINE when I installed them. I have yet to upgrade some of them, and NOT A ONE of them has retained full output power over time. They were ALL 11a mode. not all of them were beta versions, either.

[pananix]

You created a bridge loop. Was spanning tree enabled?

I know _what_ I did. I did not check to see if STP was enabled or not (used to be enabled by default, but perhaps that's not the case anymore).

Just checked -- it _is_ enabled by default. I never turn this off as it is needed to prevent wireless loops.

I still have a hard time believing I did it, but the system was completely unforgiving of my lapse.

David-

[Ick]

Impressive, I barely nosed it up around 10000K/sec with two EPIA 5000s (533MHz VIA EPIAs) running v2. Looks like v3 made it faster, just like I was noticing how v3 made my WRAP faster.

Are these the boards you are using?

http://www.shentech.com/viaeped53ddf.html

[tog]

Hehe no, that's actually newer than what I am using. That one is all fancy and newfangled and takes DDR, mine was PC133.

http://www.via.com.tw/en/products/mainboards/motherboards.jsp?motherboard_id=21

[lonnie]

Here are a couple of screenshots. This is a small tower that has an omni and connects a few close people.

AP and client are latest firmware, with WLM54SG cards. Mostly WAR1 clients.

[tog]

All I can say at the moment is that I am jealous of your fully lit-up AQUE CF M :)

[pti-andy]

I am having the SuperAG issue without WDS on routed-only links (but also with WDS).

I have not yet found a combination of settings with 1.2.11b AP to 1.2.11b client that allow me to keep SuperAG enabled and still communicate with the 1.2.11b client. I have a few more things to try I suppose... country code, 11b only, etc. I have very consistently reproduced an inability to communicate with my 1.2.11b clients (11a and 11b/g and 11g only!) so long as I keep SuperAG enabled at the AP. But so far it seems I'm the only one who can reproduce this and I have to figure out why.

WDS has been working well for me with 1.2.11b, I am testing it on at least five 1.2.11b clients and it has been solid so far. I always use the ping watchdog so all five of those clients' units are keeping themselves "awake" by constantly having ping watchdog traffic across the link, though. I have not yet tested to see if WDS has any side-effects if a link is left idle for, say, 5 or 10 minutes.

I have not had any problems with the ping watchdogs on the 1.2.11b client units bringing their own links back up without having the AP ping them or do anything to them. In fact, it's really kind of cool, I can see the ping watchdog passing traffic to and from the AP and no "W" lights up yet. As soon as the first packet comes from or goes to the client unit's ethernet side across the bridge, only then does the "W" light up. Apparently I am able to communicate directly with the client unit itself without WDS and it only turns it on the first time it is needed.

I just re-tested all that I stated above by resetting my 1.2.11b AP with those five 1.2.11b WDS clients on it. All came right back up immediately and passed traffic without any special intervention or traffic coming towards them first. They definitely initiated the first traffic themselves using the ping watchdog.


Are your clients WAR-1 or WAR-2? What radio cards are you using?

I've found different behavior from WAR-1 and WAR-2. I still can't find any combination of variables that will allow me to reach a WAR-2 client without pinging it from the AP first. I think your ping watchdog is keeping it alive. I have also found that connectivity is unstable when using more than one WDS client on the beta. If I run a speed test from one client it will make the other client drop packets.

I also get the AP to lock up when running speed tests from either a WAR-2 client or AP. It doesn't even have to be associated with anything. Just run a speed test over and over out the Ethernet and it locks up. Only a power cycle will bring it back.

All of this combined with a lack of 10M full duplex is keeping me on v1.1.13 where none of these issues exist. The problem is that I now have a live customer with a WAR-1 and downgrading to v1.1.13 keeps the client radio from being reached when using WDS. Is there any way this bug can be fixed on the release version so that I can get my WAR-1 customers online without fighting these beta issues?

-Andy
PTI Wireless

[tog]

Affected clients/APs are WAR1s, WAR2s and WRAPs. WLM54G and CM9. 11a and 11g. No matter what platform/radio combo, I cannot get 1.2.11b AP <--> 1.2.11b client talking with SuperAG on so far.

I have not had any stability issues with 1.2.x, I've been running 1.2.x APs for a few days now (more than a few days on my home client unit) and it has been quite solid stability-wise. Also I'm afraid I haven't seen the same WDS issues that you have. I put 5 1.2.11b WDS clients on my AP and all have been solid, even when one has crap quality, the other 4 WDS clients still seem to work just as well as the routed clients.

For your particular issue with the WAR-1, if you have to use 1.1.x for now because of problems you're having with 1.2, you're going to have to bite the bullet and re-configure your WAR-1 client unit to use NAT or route a /30 instead of using WDS. You really don't want to be using WDS in 1.1.x in a PtMP environment.

Any particular reason you have to force your ethernet port to 10/Half? I never use any ethernet port setting but auto-negotiate and it always works fine for me.

[pti-andy]

Affected clients/APs are WAR1s, WAR2s and WRAPs. WLM54G and CM9. 11a and 11g. No matter what platform/radio combo, I cannot get 1.2.11b AP <--> 1.2.11b client talking with SuperAG on so far.

I have not had any stability issues with 1.2.x, I've been running 1.2.x APs for a few days now (more than a few days on my home client unit) and it has been quite solid stability-wise. Also I'm afraid I haven't seen the same WDS issues that you have. I put 5 1.2.11b WDS clients on my AP and all have been solid, even when one has crap quality, the other 4 WDS clients still seem to work just as well as the routed clients.

For your particular issue with the WAR-1, if you have to use 1.1.x for now because of problems you're having with 1.2, you're going to have to bite the bullet and re-configure your WAR-1 client unit to use NAT or route a /30 instead of using WDS. You really don't want to be using WDS in 1.1.x in a PtMP environment.

Any particular reason you have to force your ethernet port to 10/Half? I never use any ethernet port setting but auto-negotiate and it always works fine for me.

This is really strange. Both of us are having completely different issues with the beta and we can duplicate it among multiple AP's and clients. I'm using mostly the WAR-2 with CM-9's and SR-5's with 802.11a, InterBSS relay, Short Preamble, and of course SuperA/G. My data rates are fixed at 36Mbps. They always show an association but it's getting data to pass reliably that is the issue. There just has to be a combination of settings that will shed light on this. I can't think of any other info to provide that may be relevant.

Right now my WAR-1 client is on a newly installed POP so they are the only ones on. That's one reason (besides that it is a WAR-1) that I think I'm not seeing the same WDS issues that I do on the WAR-2 with multiple clients.

I have some Cisco managed switches that I use at my remote POPs for SNMP and only the uplink is 100M. Everything else is 10M full duplex.

-Andy
PTI Wireless

[om]

Affected clients/APs are WAR1s, WAR2s and WRAPs. WLM54G and CM9. 11a and 11g. No matter what platform/radio combo, I cannot get 1.2.11b AP <--> 1.2.11b client talking with SuperAG on so far.


I was able to associate 1.2.11b WAR1 CPE with 1.2.11b AP (WAR-metro with WLM54SG) using SuperA/G initially but after some playing around with "Sync" feature the WAR1 all of a sudden stopped associating. Then I removed both SuperA/G and short preamble at AP, which allowed the CPE to associate. After that, I again tested by enabling SuperA/G and short preamble one by one, each time the CPE associated just fine. Now, the WAR1 is associating fine regardless of Super features and short preamble. It is strange and maybe needs some more testing and investigation.

One more thing I noticed is that order of miniPCI slot numbering in Metro has reversed in this new beta. In earlier stable release 1.1.13 2080, it was consistent with the numbering on the board (pci0, pci1, pci2 and pci3).

Om.

[go.fast]

One more thing I noticed is that order of miniPCI slot numbering in Metro has reversed in this new beta. In earlier stable release 1.1.13 2080, it was consistent with the numbering on the board (pci0, pci1, pci2 and pci3).

Om.

the 24 volt metro's I just bought are running 1.1.13 2080 and they are the opposite of the boards markings.

[tony]

The PCI ordering should be the same between the 1.2.x and 1.1.x releases. The PCI numbering as silk screened on the METRO is reverse to what the actual detection order is.

[tog]

BTW, I finally figured out the details of the bug. 104-bit shared-key WEP + SuperAG is not working in 1.2.11b when it's 1.2.11b <--> 1.2.11b. You can turn WEP off or you can turn SuperAG off.

It does actually work if it's 1.1.x <--> 1.2.11b.

It's reported to Tony already so all is (or will be) well.

[soulmata]

No wonder I couldn't reproduce your bug. I went to beta on all these newer units soley for the WPA support!

[tony]

There does seem to be something with SuperA/G while using Shared-key WEP. There does not appear to be an issue with Open-system WEP, or WPA however.

[soulmata]

I'm pretty much completely unable to use the beta series on my 900MHz POP.

Currently, the 12 associated clients and the tower are using 1.1.13, all with the SR9. They are all set to RX and TX of 11mbs, short preamble turned off, G only, power def, link distance as needed.

They all remain in the 90 to 100% quality range, and performance of the tower is very decent.

I'm seeing the same thing on my other V3 tower when attempting to use OFDM rates: Quality dips down to near nothing and often the units fail to respond at all.

When upgrading the tower or a client to 1.2.11b, communication is spotty at best and the tower can only communicate with those clients who have extremely good signal levels (50s to 60s). Anyone in the high 60s or 70s is more or less unreachable.

Moving back to 1.1.13, the clients all return to 100% quality @ 11mbps.

On 1.1.13 and 1.2.11b, most of the clients cannot even use 6mbps.

[tony]

Never lock your AP or Clients to a CCK rate when using G-Only, or 11g Cloaking. Also, set a tx power of 18 (or lower) for the SR9, and not default.

If you must use CCK data rates, use 802.11b/g mode and Cloaking 1x.

[soulmata]

I am saying that even with OFDM rates, they are more or less unusable. I tried setting the tower to auto, to 6M, to 9M, to 12M, to 18M.

I tried setting clients to 6M, to 9M, to 12M, to 18M. A few (2 or 3) will function, the majority will have insane packet loss or just not pass data at all.

I will set them to power 18

[lonnie]

I have ALWAYS said to set rate to 18 mbps for the SR9. Why did you not follow my instructions? Further, why did you choose a B rate for G only?

I hate to put you on the spot but I would really like to know the reasoning that went into this so we can try and figure out what to tell others.

[lonnie]

I am saying that even with OFDM rates, they are more or less unusable. I tried setting the tower to auto, to 6M, to 9M, to 12M, to 18M.

I tried setting clients to 6M, to 9M, to 12M, to 18M. A few (2 or 3) will function, the majority will have insane packet loss or just not pass data at all.

I will set them to power 18

I'm not sure what you are doing but ALL of our SR9 customers are using the latest 1.2.11b release. Most of them have low signal and this release has made them very usable and for the most part happy. Are you using clients and AP with the same 1.2.11b or do you have a mix? It works as I describe with them all at 1.2.11b.

[soulmata]

As of right now, all the SR9 clients (12) and the tower are 1.1.13.

I cannot use OFDM rates. If I enable OFDM rates, the majority of the clients do not function. If CCK rates are being used, everyone works at 90% quality or higher. I asked about this a few weeks ago on another tower with V3 and V2 clients. My goal is to switch to OFDM.

My goal was to upgrade them to 1.2.11b to see if it made a difference. It does make a difference, it makes them completely unusable.

I'm not sure what to tell you. CCK works, OFDM does not. I can pass, say, 7mbps bi-directional with 0% packet loss using large or small packets to an SR9 client with 1.1.13. With 1.2.11b, they cannot even function.

I'll give it another shot tomorrow.

[tog]

Set your APs and clients to "802.11b/g" instead of "802.11g" if you want to try using CCK with 1.2.11b.

Also, be warned, using cloaking with 1.2.11b, 11 will show up as "1" even though it is actually 11 :)

Also, like Lonnie said, try turning the tx power down to 18 or lower.

[tony]

Rate requirements for 1.1.x and 1.2.x while using 802.11g:
1.1.x clients set to 802.11g-only /or/ 802.11b/g can lock to 11M, but not 6M or 9M.
1.2.x clients set to 802.11g-only can not lock to 11M, but can lock to 6M or 9M. 802.11b/g mode operates like 1.1.x, with the same requirements.

What are the average signal levels from your clients?

[soulmata]

they were formerly all at 17. I set them to def today on an experimental basis. I'll have to toggle them back.

I will try that tomorrow. Thanks for the advice.


edit: Signal levels vary greatly, because this is a heavily wooded area and most of them do not have physical line of site. A few are in the high 50s or low 60s, due to them being very close or having LoS, the rest are in the 70s to low 80s.

[David L. Vrablic]

The PCI ordering should be the same between the 1.2.x and 1.1.x releases. The PCI numbering as silk screened on the METRO is reverse to what the actual detection order is.
Tony, you just put me in a round room and told me to go stand in the corner.

I just built this SP damn thing and I am having problems with signal showing up on the right ports .
I think it has something to do with your post.

The board is marked like so:
(Use my picture here guys radios on top connectors to the bottom.)


http://vrablic.com/xfer_hold/metro4_ttbox.jpg

Upper left PCI 2 -------------Upper right PCI 1

Lower left PCI 3--------------Lower right PCI 0

Now who is on first ? (or where is WPCI 1,2,3,4)

and I don't care who is playing the outfield.

[tog]

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

I am unable to confirm the information myself, but there is the best information I have.

[tony]

I will verify the METRO ordering (in case I'm wrong). Will post back in a few minutes.

[David L. Vrablic]

Whew no wonder I was chasing my tail.
I just relabeled the ports I don't want to mess with the connectors again these are the last of my new pigtails.
I am trying to get this thing on the air by midnight and it is fighting me every bit of the way.
At least I hung on to some old TT boxes and they work great.
Thanks Tog,

[Mark]

I have also experienced the following a couple of times now:

This is a backhaul link, so there's one client and one ap, only.

The ap is X86 machine. Client is a WRAP. Both run latest beta.

After several changes using the sync button (looking for a clear or the clearest channel) I suddenly started having ping times in the 40 to 70 range. Very steady, but very long, only pinging across the link.

I was able both times, to get to the far side of the link (slowly) and log in and do an 'apply changes' which fixed the long ping times. Well, if memory serves, it actually disconnected the link, but changing back to previous configuration at the AP caused it to suddenly come back up and work fine.

Changes included cloaking and channel that were forced.

[David L. Vrablic]

OK guys I really have to go install this thing.
Here is what I worked out the hard way.
One port at a time to verify that the pigtails were good.
The ports I have connected were exactly reversed so I just relabeled them.

I am sure this is right now.
I hope it helps someone because it was one hell of a surprise to me.

http://vrablic.com/xfer_hold/metro4_layout.jpg

[lonnie]

Did you have BOTH ends upgraded? The way I do a change like that is to upgrade them all but not reboot until they are all upgraded, and then I simply click the reboot, doing the AP last, of course.

[Beebe]

Is there a reason you are using the "b" antenna connector?

Thanks,
Roger

[ripv]

Is there a reason you are using the "b" antenna connector?

Thanks,
Roger

Roger,

The radio's are WLM54AG's and the pigtails are connected to the main ("A") connector.
I reckon you're thinking the radio's are CM9's which have the "A" connector on the outer edge. ;)

[David L. Vrablic]

Ahhh because that is the one marked Main and works when I select "A".
Looks like that got fixed somewhere along the way.
At least on This board with these cards and the FW version.

I did not mean to hijack Lonnie.
Maybe you can move this mess over where it should be.with all the other layout discussion.

[tony]

D'oh! I forgot to post my METRO PCI ordering results. I do not have access to that information right now, but will post it first thing tomorrow.

[DrLove73]

I'v found Metro bords (2 we got) have reversed ordering:

PORT in StarV3
pci0 wpci4
pci1 wpci3
pci2 wpci2 (even broken analog watch shows exact time 2 times per day :-D)
pci3 wpci1

[DrLove73]

WHAT!!!!
And what do we do then? Go to EVERY site?
Do NOT do that on 1.2.x!!!!!!!!!!!!
Do it with 1.3.x!
Can you at least do some config changes when upgrading upward to that new version? question when doing firmware, or automated conversion of configurations? wpci1 -> wpci4, wpci2 -> wpci3, wpci3 -> wpci2, wpci4 -> wpci1,
No CARE will help, just swaping cards if they are not ALL the same.

Edit: best is to do it in 1.3.x AND automatic conversion from 1.2.x to 1.3.x.

[bobbyc]

WHAT!!!!
And what do we do then? Go to EVERY site?
Do NOT do that on 1.2.x!!!!!!!!!!!!
Do it with 1.3.x!
Can you at least do some config changes when upgrading upward to that new version? question when doing firmware, or automated conversion of configurations? wpci1 -> wpci4, wpci2 -> wpci3, wpci3 -> wpci2, wpci4 -> wpci1,
No CARE will help, just swaping cards if they are not ALL the same.

Edit: best is to do it in 1.3.x AND automatic conversion from 1.2.x to 1.3.x.

This is beta firmware you know...
Bob C

[tony]

The next release is 1.3.0.

If there is an issue, I will provide a special step-up release for the METRO after the 1.3.x series is released, that will swap things around for you.

There doesn't appear to be any ordering issues though more hands-on testing is in order.

[kbldawg]

Tony,

I've used only 1.1.13 on the Metros and this is the layout I found to be accurate, can you verify whether this is correct or not?

http://forums.star-os.com/showthread.php?p=46687#post46687


Will 1.3 be different from this layout?

[tony]

Plans are to have the 1.3.x release match the 1.1.x layout.

UPDATE: Looking over the releases, it appears as though 1.1.x, 1.2.x and 1.3.x all share a common ordering with the METRO. There is in fact no re-ordering issues that I can find however I will do more testing later this morning.

[tony]

I have posted a sticky with the proper METRO PCI ordering.

[Mark]

Ok... I am STILL seeing the runaway speed thing. I have a 21 mile link, and the speed was still hitting 48, where it simply wouldn't reliably pass data. It was jumping back and forth, giving me a ping pattern that looked like this: 5 7 60 10 12 90 3 6 70 4 8 44 10 6 35 7 9 88 roughly. (1400 byte ping)

I hopped on the manage side and forced 36 and now it looks like this:

66.29.148.10 : [938], 1428 bytes, 1.28 ms (7.95 avg, 0% loss) ^
66.29.148.10 : [939], 1428 bytes, 1.28 ms (7.94 avg, 0% loss)
66.29.148.10 : [940], 1428 bytes, 17.1 ms (7.95 avg, 0% loss)
66.29.148.10 : [941], 1428 bytes, 6.86 ms (7.95 avg, 0% loss)
66.29.148.10 : [942], 1428 bytes, 1.91 ms (7.94 avg, 0% loss)
66.29.148.10 : [943], 1428 bytes, 1.21 ms (7.94 avg, 0% loss)
66.29.148.10 : [944], 1428 bytes, 3.22 ms (7.93 avg, 0% loss)
66.29.148.10 : [945], 1428 bytes, 4.91 ms (7.93 avg, 0% loss)
66.29.148.10 : [946], 1428 bytes, 1.23 ms (7.92 avg, 0% loss)
66.29.148.10 : [947], 1428 bytes, 1.23 ms (7.91 avg, 0% loss)
66.29.148.10 : [948], 1428 bytes, 1.22 ms (7.91 avg, 0% loss)
66.29.148.10 : [949], 1428 bytes, 1.23 ms (7.90 avg, 0% loss)
66.29.148.10 : [950], 1428 bytes, 1.31 ms (7.89 avg, 0% loss)
66.29.148.10 : [951], 1428 bytes, 1.72 ms (7.88 avg, 0% loss)
66.29.148.10 : [952], 1428 bytes, 2.10 ms (7.88 avg, 0% loss)
66.29.148.10 : [953], 1428 bytes, 1.20 ms (7.87 avg, 0% loss) *

And it went from the wildly uneven and erratic to that immediately with the click.

The other backhaul link is rock stable and no speed runaway.

The uneven one has a RXSL roughly -69 reported. The stable one has -75 or so.


update: The Sync button changed the channel, but the far side did not adopt the speed limiting.

I thought it was supposed to?

[Mark]

Update yet again

AP side consistently reported -67 to -69, client end consistently ran -75.

I restarted AP side of backhaul and it now reports -75 or so.

No more runaway speed behavior.

BTW, All radios involved are CM9's.

[tony]

The clients will adopt the channel, cloaking mode, and distance options. The rate options are not adopted as many people like to adjust this manually.

update: The Sync button changed the channel, but the far side did not adopt the speed limiting.

I thought it was supposed to?

[bobbyc]

possible bug: switching from antenna a to diversity, and activating changes kills the link on a WRAP. Tested with CM9 and SR2 client.

Bob C

[lonnie]

The tx function always uses a particular antenna but the rx uses the best signal. It would seem your radios are wired to use b for tx.

I know this puts you on the spot, but, why would you select diversity with only a single antenna?

[bobbyc]

I was just overconfident from sucessfully upgrading two different V2 WRAPs to V3...

that and from reading this recently:
http://forums.star-os.com/showthread.php?t=6346&highlight=diversity

Bob C

[tony]

The Antenna diversity option should work properly. Are you able to duplicate the odd behavior?

[bobbyc]

Yeah. It seems to only affect the CM9 client card on the WRAP. I set diversity on the AP card, and activated changes, and the clients came right back up on the AP.

I set diversity on the client backhaul card, and activate changes without saving, and the WRAP will dissassociate from the AP it's connected to; and eventually reboot when the ping watchdog kicks in 60 seconds later.

Bob C

[nickwhite]

Here's something I've noticed in this release on WRAP and WAR4's. Setting distance to 16, saving, and then going back to wireless interface, it shows it as 15.99. It obviously doesn't affect performance, and seems only cosmetic.

But... y'know... it's still a bug... I guess?

Meh. :)

Very impressed with this release guys. The manage feature is quite amazing - I waited until this beta to upgrade from stable. I've got 60 miles of backhaul, about 6 different hops+repeaters, running on this beta. It's been fairly solid.

-Nick

[DrLove73]

This is beta firmware you know...
Bob C

Yes I know. That was my point. I thought they will release maybe another beta, and if they would switch it in beta, there would be trouble switching back and forth, like in any beta testing, etc...

That's why I sugessted to switch only on 1.3.0, not before, and automatic change (tony's step-up release idea is perfect).

tony, if needed, think of two-way step-up release (to be possible to revert ordering in case of any unwanted bug in 1.3.0, or somebody for any reason wants/needs to revert to betas.

[tony]

This is normal, and is part of the distance tuning feature. All values entered are rounded to the nearest valid distance unit. Lonnie--distance units are binary for the card and floating point for humans, thus some numbers cannot be represented.

Here's something I've noticed in this release on WRAP and WAR4's. Setting distance to 16, saving, and then going back to wireless interface, it shows it as 15.99. It obviously doesn't affect performance, and seems only cosmetic.

But... y'know... it's still a bug... I guess?

Meh. :)

Very impressed with this release guys. The manage feature is quite amazing - I waited until this beta to upgrade from stable. I've got 60 miles of backhaul, about 6 different hops+repeaters, running on this beta. It's been fairly solid.

-Nick

[tony]

There is no need fora step-up release, as there is no ordering issues between the various releases. The PCI ordering for the metros are posted in a sticky.

tony, if needed, think of two-way step-up release (to be possible to revert ordering in case of any unwanted bug in 1.3.0, or somebody for any reason wants/needs to revert to betas.

[oscarBravo]

Something I've been meaning to point out: a minor nuisance crept in at some point in the beta cycle. Under the "wireless configuration" sub-menu of the "interfaces" menu, there are two entries with the "l" (lowercase L) shortcut: "tls/ttls/peap certificate for ap use (pem format)" and "association list".

I use the keyboard shortcuts a lot, and in particular it was useful to be able to hit (say) alt-I, 3, w, l to get to an association list. Would it be possible to get this sorted before the 1.3.0 release?

[tony]

Thank you, I will get it corrected.

As for the association lists, the quickest way around is to use the Function keys (F1 - F4 or ALT-1 - ALT-4) to open the various association windows.

The fix will not make it into 1.3.0 as it is scheduled for release later today.

[oscarBravo]

F2-F4 work, but F1 opens help in gnome-terminal. Alt 1-4 switches between terminal tabs.

[tony]

Ahh, I see, thanks.

[Stratolinks]

Something I've been meaning to point out: a minor nuisance crept in at some point in the beta cycle. Under the "wireless configuration" sub-menu of the "interfaces" menu, there are two entries with the "l" (lowercase L) shortcut: "tls/ttls/peap certificate for ap use (pem format)" and "association list".

I use the keyboard shortcuts a lot, and in particular it was useful to be able to hit (say) alt-I, 3, w, l to get to an association list. Would it be possible to get this sorted before the 1.3.0 release?

I also find keyboard shortcuts useful.

Try these...
F1 Associationlist of first wpci card
F2 Association list of second wpci card
F3...

edit.. Oops, got distracted while doing the response. Now I see it was already answered...

[paulmacp]

What is the status on bridging ? Is it working and if so what is the process to implememnt it. I have several war1's and I they don't work with my Ver 2 ap's or ver 3 ap's.

[tony]

StarV3 1.3.0 (and 1.2.9b+) has a very functional WDS implementation that works quite a bit better than it's predecessor in v1.1.x.

Pseudo client bridging will arrive after the web interface is implemented due to space constraints.

[tog]

I have had 5 1.2.11b WDS clients on a 1.2.11b AP, it has been going well so far, though not enough time has passed to ferret out all possible problems. I just did basic forced testing for the types of problems I had in 1.1.x and found them resolved.

[paulmacp]

1. Does a V3 war1 work with a v2 ap in WDS bridge mode ?

2. How or where do I get info on the setup of WDS ?

3. What is a rough timeline web interface ?

Thanks

[lonnie]

The timeline for the gui is --> we are working on it. It is a complete, from the ground up development and with that sort of rewrite I am unable to even estimate the date when it will be finished. Things take longer than expected and other things come up.

As always we will do our best.

[lonnie]

V3 WDS is a special implementation and is not going to work with v2. My advice is to convert the AP to V3, taking advantage of the low upgrade price.

[paulmacp]

Thanks.... No prob on the update from V2 to 3... The 2 Server AP's have been so reliable there has been no need to upgrade.

If I do upgrade to V3 will I loose the existing bridging feature I have ?
Anything else I should watch out for ?
Rack Server box
Cel 1 Ghz
256 Mem
Ornico cards in a PCI adapter
?

Also Please any info on how to implement the WDS... I don't have a clue what it is about...

Thanks

[lonnie]

Yikes. V3 only supports Atheros PCI cards. There is no prism, Orinoco nor PCMCIA. You would lose bridging until you had the AP and Client both changed, but since your radios are not compatible, don't even think of it.

[Mark]

I am still seeing an issue on my x86 pc based systems, where the radios begin to show RXSL betwen 7 and 10 db HIGHER than it really is. The radios then continue to attempt to run at the speeds that would be appropriate for this RXSL resulting in dropped packets, long pings, low and unsteady throughput.

I thought one time was a fluke. I have now seen it three times in the last week. Today's was bad enough my customers started calling me complaining that they could not make a VOIP call over the link. It would literally drop all packet flow for a second or two now and then. Restart or change something and activate, the RXSL returns to where it should be.

[paulmacp]

The V2 stuff is working fine....

That aside Lets say I get a V3 AP Setup how do I implement WDS ?

What are the ap & client settings ?

Thanks

[tog]

If AP and client are running 1.2.x (or soon-to-be 1.3.x), nothing needs to be done at the AP. The client just bridges wpci1 to ether1 and WDS will enable itself automatically.

[tony]

What version (and mode) is your X86 system running, and what verion is the peer system running?

I am still seeing an issue on my x86 pc based systems, where the radios begin to show RXSL betwen 7 and 10 db HIGHER than it really is. The radios then continue to attempt to run at the speeds that would be appropriate for this RXSL resulting in dropped packets, long pings, low and unsteady throughput.

I thought one time was a fluke. I have now seen it three times in the last week. Today's was bad enough my customers started calling me complaining that they could not make a VOIP call over the link. It would literally drop all packet flow for a second or two now and then. Restart or change something and activate, the RXSL returns to where it should be.

[paulmacp]

If AP and client are running 1.2.x (or soon-to-be 1.3.x), nothing needs to be done at the AP. The client just bridges wpci1 to ether1 and WDS will enable itself automatically.

So the
AP with ether1 just set with a public/private ip
AP wpci1 nothing set

client wpci1 nothing set'
client ether1 public/private ip

Does the client have to have it's ether1 bridged ?

Thanks

[tony]

With 1.2.x+, WDS is used if the client's ethernet is bridged with the wireless card.

Unlike 1.1.x, the 1.2.x+ APs do not need their interfaces bridged for WDS to function.

[Mark]

What version (and mode) is your X86 system running, and what verion is the peer system running?


All are 2426.

I have seen this from X86 as ap to both wrap and x86 pc as clients.

Have seen it in X2 cloaking and no cloaking. The Q numbers tend to run rather low when it does this, too, but only after performance suffers.

All cards are cm9's. So far, I have only seen the "off" numbers at the AP end.

[soulmata]

To Lonnie and others re: OFDM

I gave it another shot today. I got a lot more success out of it. Initially, it was pretty terrible: Switching to OFDM maybe 7 of the clients drop to 0 or 13% quality, a lot of "N" associations and a large amount of packet loss.

I waited, however.

It took about 12 minutes before all the clients re-associated and stabilized. Now it is looking at lot better:

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

This is a 900MHz, x4 cloaked POP. I am pretty sure I won't have any issues upgrading to 1.3 now.

[lonnie]

It is my experience that you should waste NO time in upgrading the AP and cleints. As you do each client the old system seems to just get better and then when the last one is done you should see a huge improvement, and so should they.

The new 1.3.0 has way better low signal and cloaks better. The rate control is smoother and managed mode is pretty cool. You have a couple of users at worse than -80 dB signal and they will be real bad on the older release.