v3 on final testing

[lonnie]

Well we now have the new code running on that 7 repeater 100 km backbone. It has 2 legs that are 43 km each. The other hops are 10 km and less, but it is still a lot of radios to go through. Also, three of them are 266 MHz dual boards. The radios are CM9. We use 3 foot dishes for the long shots and 2 foot dishes for medium, with 21 dB patches for the 4 mile shots

From one end to the other we get over 20 mbps of TCP throughput. I have not tested with UDP, but we know it will be higher. UDP is always higher, and that is why many companies test with UDP. We use TCP because most applications that most people use are TCP.

Things have been up for 4 hours now. This backbone runs ALL of our traffic between the 4 communities and ALL traffic to the various Internet feeds. It uses the same base Linux we have the previous tests, so we really are testing the new driver, and it is a fix over the previous tests, that ran for in excess of 13 days. I feel it is stable, and ready for release.

The next task is to get the conversion image to step people from StarVx to the v3. We also have to get the update procedure fine tuned. All in all we should be on target for the 21st. Testing will continue and I will update with any problems.

[simcor23]

AWESOME !!!!!http://forums.staros.com/images/smilies/icon_smile.gif

[peace2300]

that is good news

[j0n]

Excellent work, thanks!

[kbldawg]

Just in time for my new Water Tank WPOP. That's good to hear Lonnie, keep it up!!

[tog]

Great news, has it been tested at all as an AP in point to multipoint mode?

I'm looking forward to having v3/WAR replace v2/WRAP many places on my network, but I'll need PtMP to work at least as well as or hopefully better than v2 does. Aside from hanging periodically or going batty when a busy client disappears without disassociating, v2 performs in PtMP very well.

[lonnie]

We've had a few fixes over the last two days, but I am real pleased to report what I believe is the final driver release. We have the update mechanism fine tuned and we are making good progress for the StarVx transition image. That is the last piece.

I am sorry but the following will not be in the first release:
Client Bridge (WDS), 5 & 10 MHz spacing, DNS, DHCP, Hotspot, PPPoE, any sort of Authentication, any sort of Encryption, and long/short preamble.

The first release should be used for routed backhaul and we have several units with AP's, but only 5 or 6 customers. VDS is working great and the CPU speed really helps with a truly transparent bridge. I have a remote AP. 4 hops from the POP, brought in to the POP with VDS, and it is great. I do DHCP at the POP. The units have firewall, nat and CBQ, which all work. Layer 7 is not included, so do this at a larger v2 server at your POP.

We are able to sustain the 20+ mbps from end to end with WAR boards. The longest connection is 7 WAR boards plus 2 WRAP boards for about 15 mbps, and between each repeater we can sustain 40+ mbps.

I should add that this link is our main backbone and is in use by clients, thus the ping times vary a bit and depend on the network use at that point in time.

************************************************** *****
lon-home:~ # tracepath 10.10.32.254
1: 192.168.250.200 (192.168.250.200) 0.384ms pmtu 1500
1: 192.168.250.2 (192.168.250.2) 5.123ms
2: 192.168.250.10 (192.168.250.10) asymm 1 12.268ms
3: 10.10.48.254 (10.10.48.254) asymm 2 4.967ms
4: 10.10.227.254 (10.10.227.254) asymm 3 5.102ms
5: 10.10.12.4 (10.10.12.4) asymm 4 6.429ms
6: 10.10.47.253 (10.10.47.253) asymm 5 8.831ms
7: 10.10.51.254 (10.10.51.254) asymm 6 10.518ms
8: 10.14.99.254 (10.14.99.254) asymm 7 13.817ms
9: 10.10.29.254 (10.10.29.254) asymm 8 12.101ms
10: 10.10.32.254 (10.10.32.254) asymm 9 17.108ms reached
Resume: pmtu 1500 hops 10 back 9
************************************************** *****
lon-home:~ # ping 10.10.32.254
..
..
64 bytes from 10.10.32.254: icmp_seq=99 ttl=56 time=8.58 ms
64 bytes from 10.10.32.254: icmp_seq=100 ttl=56 time=8.28 ms
64 bytes from 10.10.32.254: icmp_seq=101 ttl=56 time=8.89 ms
64 bytes from 10.10.32.254: icmp_seq=102 ttl=56 time=8.66 ms

--- 10.10.32.254 ping statistics ---
102 packets transmitted, 102 received, 0% packet loss, time 101575ms
rtt min/avg/max/mdev = 7.966/9.635/20.884/1.849 ms
************************************************** *****
Just the WAR part of the link
lon-home:~ # ping 10.10.29.1
..

64 bytes from 10.10.29.1: icmp_seq=101 ttl=57 time=8.80 ms
64 bytes from 10.10.29.1: icmp_seq=102 ttl=57 time=15.3 ms
64 bytes from 10.10.29.1: icmp_seq=103 ttl=57 time=9.30 ms

--- 10.10.29.1 ping statistics ---
103 packets transmitted, 103 received, 0% packet loss, time 102608ms
rtt min/avg/max/mdev = 6.898/8.661/19.910/2.277 ms
************************************************** *****
Bandwidth test on longest segment

lon-home:~ # starutil-1.14 10.10.32.254 ***** -rx
rx rate: 1789 KB/sec (Press Ctrl-C to exit)
************************************************** *****
The link just before the WRAP boards gives a bit better
lon-home:~ # starutil-1.14 10.10.29.1 ****** -rx
rx rate: 2389 KB/sec (Press Ctrl-C to exit)
************************************************** *****
One of the intermediate links about 4 miles from 10.10.12.4.
war-platform / > starutil 10.10.227.254 ***** -rx
rx rate: 5505 KB/sec (Press Ctrl-C to exit)
************************************************** *****

The AP works fine with a mixture of bg clients, but as I said, the maximum tested at this time is about 6 clients.

Quagga 99.3 is there with rip and ospf. Static routes are available and you can bridge 2 or more devices and thus have multiple bridge groups.

The release is looking fine for the 21st. It should be a fun day.

[simcor23]

Just a couple of questions.

How many static routes are available?

Is there an expected time frame for 5 and 10 mhz spacing ?

[lonnie]

It is similar to the v2 interface which supports in the area of 200 manual routes. You do not want even 50 manual routes. Use RIPv2 or OSPF when you get a network gone big.

5 & 10 will be in an upcoming release. Surely you are not going to pester me to provide a date, are you? It is something we want, and it gave a couple of issues, so we pulled it. We had the option of delaying the v3 release or pulling some of things that need more work.

The goal is to get this driver out there and people can start with it. Use this for backhaul and p2p shots. The routing is there. It can firewall, bandwidth and nat.

With the framework in place the missing features will come at a rapid pace.

[simcor23]

Thats cool, not pestering just think it has been a cool feature on the wars no real rush for me. I was just wondering about the routes as my wars right now only have 5 slots for static routes

[luka]

Are there any particular driver enchantments which will be something "new" in field, except support for newer chipsets?

[tog]

That's great that you've had it up and running with 6 clients without it going crazy.

That's great that it's getting released, but I definitely need 40/104 WEP support. There are various reasons for it, and I'd rather wear a fig leaf than nothing at all.

Also most of my APs are fully routed nowadays so I have to run a DHCP server or relay or something on the AP itself.

I'm just keeping the chatter coming from my end about what my first and most important needs are.

I'm betting once the initial release is out more releases that add the most important missing parts will not be too far behind. I seem to remember StarVx was really quick about adding WEP after the initial release didn't have it.

[lonnie]

This driver will be stable and speedy. From that foundation we will add the "new" features.
Are there any particular driver enchantments which will be something "new" in field, except support for newer chipsets?

[lonnie]

Yes, the features will come fast and furious. The driver foundation was the key and now we can start expanding. The current system is ahead of the StarVx in most features and the driver goodies are not new so will not take all that much. We had to pick a date and release what we had on that date.

You can always do what I did for DHCP on my routed (of course) AP. I used a VDS tunnel back to a DHCP server at my POP.
WEP will likely make it in the release.

That's great that you've had it up and running with 6 clients without it going crazy.

That's great that it's getting released, but I definitely need 40/104 WEP support. There are various reasons for it, and I'd rather wear a fig leaf than nothing at all.

Also most of my APs are fully routed nowadays so I have to run a DHCP server or relay or something on the AP itself.

I'm just keeping the chatter coming from my end about what my first and most important needs are.

I'm betting once the initial release is out more releases that add the most important missing parts will not be too far behind. I seem to remember StarVx was really quick about adding WEP after the initial release didn't have it.

[tog]

Oh cool, WEP is like the bare basic minimum that I need to start getting going.

Great, I can do VDS temporarily and then later move that block of IPs over to the actual AP with its own DHCP server once we have a DHCP server available in v3.

Good call

[nelson05]

No problem on the DHCP server making a later appearance since we have the VDS workaround you mentioned.... how about a DHCP client? I've got ten WAR boards in Rootennas that I'd like to deploy as clients and a DHCP client a big piece of the puzzle. However, I'll live if it doesn't make it into the 1st release.

[lonnie]

The thing with WAR or WRAP in a Rootenna is that you can simply assign them a hard coded static, and when we get DHCP Client you simply upgrade the unit and remove the IP while enabling DHCP Client. It is not convenient, but it is not a show stopper either.

[tog]

Yeah, plus that's you logging into the unit and changing the settings instead of you calling the customer and talking them through changing something.

[lonnie]

Much easier and can be done at your liesure, since the hard coded IP is still working.

[go.fast]

Ok, so when is the final version that has 5 and 10MHz channel spacing as well as dhcp at the client going to be ready?

I need to have war boards that can be micro pop repeaters and handling dhcp as well as multiple routes.

What is the date for this?

The problem I'm having Lonnie, is I'm on hold, on hold in a big way because I either have to buy wrap gear, or wait and do war platform.

So I'm waiting, but it is killing me really bad.

It really is.

George

[lonnie]

Have you not learned from past postings of others? I cannot possibly give a date. This is software and sometimes it goes real well and is done in way less time than I hope for; and then you find something that requries a rewrite ot it just refuses to work, and takes way longer.

All I can possibly tell you is that we consider those items as essential. We brought 5 & 10 MHz to the market simply because it was needed and DHCP is rquired for AP use.

By the way, did you not read the other posts I made, where I described using a VDS tunnel to get to a DHCP Server?

You don't have to be on hold unless you choose to. The tools are there if you wish to use them. We are missing 5 & 10 but that will not be for long.

[lonnie]

A bit of an oops and I had to reboot all the units. It seems I was running with Connection Tracking enabled, which is only required for firewall and nat. In a backhaul router it is not required BUT it consumes CPU resources even when not performing anything useful. Unfortunately it needs a reboot for it to be removed, thus I had to sacrifice a longer runtime for increased speed. It was worth it though, adding almost 2 mbps on the backbone, end to end, or about 10% higher.

[nickwhite]

Just out of curiosity (I read it somewhere, but couldn't find it again?), how many of the WAR boards in your backhaul are 266MHz + dual-radio. We've got a DS3 feed (45Mbps), and want as much of that as possible, so I'm wondering if we should use the 533 (dual-radio) or the 266 for our backhaul. I guess 533+dual-radio would give us better throughput over the 266 WAR boards.

(DS3 --16miles-- HOP --8miles-- HOP --18miles-- (end)HOP -- Clients)


-Nick

[lonnie]

3 of them are 266 duals, just for testing. The plan is to have the backbone as all 533, but we had to see what would happen. They are OK, but no point compromising, especially if you want high speed. The other factor, if you can afford a 45 mbps feed you should be able to afford a 533 MHz as opposed to a 266 MHz. We like the 4 radios also. It is amazing the things you can connect if you have the radios sitting there and ready to go.

[lonnie]

v3 for WAR will release tomorrow. I want one more night of testing, and if all is OK in the morning, we'll upload and you guys can start using these systems.

As a caution, WDS is not available, so DO NOT upgrade your system if you depend on Client Bridge. AP Bridge will be fine. Disable Connection Tracking if you are not going to do NAT or Firewall and you'll have routed performance that equals the bridged performance of StarVx.

[simcor23]

Sorry if this is a stupid question.

I have a war ap on a water tower with a few clients, my internet is at say building A and the war is a wireless client bridge building B,C,D are wireless clients connecting to AP. I set building A as client bridge in order for the other clients to receive internet. If I upgrade can I send internet to the AP on the water tower and have B,C,D still get internet from building A???

[lonnie]

Is this a for real situation or a supposed situation? Building A should be set to AP mode and you connect to a client on the water tower, then another AP so that the other buildings should be set simply to client.

This is why we have multiple radios. You should never try and run a single radio as a repeater to save a few dollars. It is very poor design from a network standpoint and has less throughput as a result of the repeating nature. The only way to make it work is to enable interBSS relay and that means that customers can then connect to each other without you even seeing the traffic. Two guys sharing files will eat up ALL of your AP bandwidth and you'll be at a loss to figure out why performance is bad to the others since you'll not even see the traffic.

Use the multiple radios to do an AP at building A to a WAR client at the water tower. then use a second radio in the WAR to do the AP that actually connects customers to the net.

[simcor23]

The situation is real and basically all the buildings are part of one organization. Different subnets for the different departments. Not an ISP setup. This is for an internal network with 4 remote buildings. All the buildings have been working for 4-5 months. Originally building A was going to be the AP but had some LOS issues and alternately had to put an AP on the water tower. Currently have all 4 radios acting as individual APs on the water tower with 90 degree sectors. Right now there are only 4 remote stations (5 including building A) but they will want to expand in the future. I have been running it this way for the time being. I figured I could just leave it untill V3 and has been running fine with very acceptable throughput and not to many more buildings will join the network. every remote station is on its own subnet and they are just sharing a dsl connection and accpac type stuff as well as access to internal mail server. I am not to concerned with throughput as I am seeing around 2600- 2800 on every link wich is alot faster then the 3kb dialup they previously had. I originally had intrabss relay on and all buildings in client mode could talk to each other I could ping the gateway and dns and such but could not get internet traffic untill I switched building A to client bridge instead of client. Building A is plugged into switch. The weird thing I thought was I could ping gateway from every building but couldn't recieve internet traffic without building A in bridge mode. If this is bad design the please help I am starting to learn routing and subnetting and have a good handle on that part so far. If it is absolutely neccessary to add another war at the water tower I guess I will have no choice but would be nice if there was an alternative that still falls within good network design If at all possible. Thanks for your help Lonnie, It is much appreciated.

[ninedd]

v3 for WAR will release tomorrow.Any YSYL specials on WAR products to mark this event? :)

[lonnie]

I think it'll have to be called "Thanks For Your Patience" or TFYP. I think I'll wait a day or two so we can get some units reprogrammed and ready to ship.

Any YSYL specials on WAR products to mark this event? :)

[lonnie]

Enable intraBSS relay on the unit that has the share to Building A. Clients on that sector have the Building A IP as their gateway. All other clients, on the other sectors have their gateway as their AP. The default route for the water tower WAR is Building A client. You don't need bridging to make this work. We have done this many times to get a temporary connection.

The situation is real and basically all the buildings are part of one organization. Different subnets for the different departments. Not an ISP setup. This is for an internal network with 4 remote buildings. All the buildings have been working for 4-5 months. Originally building A was going to be the AP but had some LOS issues and alternately had to put an AP on the water tower. Currently have all 4 radios acting as individual APs on the water tower with 90 degree sectors. Right now there are only 4 remote stations (5 including building A) but they will want to expand in the future. I have been running it this way for the time being. I figured I could just leave it untill V3 and has been running fine with very acceptable throughput and not to many more buildings will join the network. every remote station is on its own subnet and they are just sharing a dsl connection and accpac type stuff as well as access to internal mail server. I am not to concerned with throughput as I am seeing around 2600- 2800 on every link wich is alot faster then the 3kb dialup they previously had. I originally had intrabss relay on and all buildings in client mode could talk to each other I could ping the gateway and dns and such but could not get internet traffic untill I switched building A to client bridge instead of client. Building A is plugged into switch. The weird thing I thought was I could ping gateway from every building but couldn't recieve internet traffic without building A in bridge mode. If this is bad design the please help I am starting to learn routing and subnetting and have a good handle on that part so far. If it is absolutely neccessary to add another war at the water tower I guess I will have no choice but would be nice if there was an alternative that still falls within good network design If at all possible. Thanks for your help Lonnie, It is much appreciated.

[simcor23]

Lonnie your frickin awesome! I totally see where I went wrong when I first tried that setup. Thanks a bunch it makes total sense now. I had wrong gateways before I tried the bridging. So this should work when I upgrade if I understand you correctly? If it helps at all the bridging did seem to work for the last couple of months, the bridge all interfaces was the only thing that caused problems originally. And for all the people out there if it wasn't for the problems with VX I never would have started learning proper network design and for that Lonnie I am very grateful for the problems you have had with this whole ordeal. I wouldn't have had any other way. WooHoo!!!!!

[tony]

The new beta is available. Please provide feedback where possible.

[kbldawg]

I know what I'm doing when I get to work in the morning, THANKS!!!!

[lonnie]

I have had one report of the unit requiring a power cycle to get a reboot after upgrading. Please be prepared for that. We have not seen it, but it is better to be ready to have someone ready to power cycle the unit than to scramble if it does not reboot properly.

[phendry]

Disable Connection Tracking if you are not going to do NAT or Firewall and you'll have routed performance that equals the bridged performance of StarVx. Does this apply to the 266 platform too? I've upgraded 3 devices so far but signal quality was never enough to be able to fully test the throughput.

[lonnie]

Especially for the 266 MHz. Connection tracking takes processor power even when not doing anything, so the lower the CPU speed the more critical it becomes.

Out of curiosity, are you saying the new release gets worse signal than the StarVx?

[phendry]

No, the link has never had a "great" signal so it's not V3 causing signal degrade. The reference to the 266MHz WAR was more aimed at the comment "you'll have routed performance that equals the bridged performance of StarVx". In our tests we where seeing the 266MHz board running StarVX was able to run the Atheros at full speed in standard mode with the CPU only becoming an issue when you switched on turbo. As we have no intention of running any links in turbo it meant that the 266MHz boards where more than enough for what we need.

Is VDS supposed to work in this release? Tried setting up a couple of VDS tunnels and although both end devices can ping each other the VDS link never comes up. The server end has the following error in the logs:

Can't create temp lock file /usr/local/var/lock/vtund/vds2

And the client has:

Connection denied by 2.2.2.2

[tony]

Thank you for the report. This has been corrected.

[ninedd]

I think it'll have to be called "Thanks For Your Patience" or TFYP. I think I'll wait a day or two so we can get some units reprogrammed and ready to ship.OK, great! Except now I'm impatient for the TFYP sale. :)

[tony]

beta-2 has been released, and addresses all problems noted so far.

[simcor23]

Just to let you know Lonnie, I changed that bridge with the right GW's today and it works great. No difference in throughput though but the signal levels improved, I thought that was cool not quite sure why but -77rssi to -71/72 rssi seem to be a fairly big difference. If the bridge was bridging a fairly large amount of broadcast, could that have hurt signal levels on the AP???

[peace2300]

Is anyone having problems with g/b in ap mode, just a thought, i have been having a problem with one war that i upgraded and now i am not seeing the ap, i have checked all settings and hardware

[tog]

No problems so far on the bench here in 802.11g mode. I've only tested 802.11g and not 11g turbo or 11b mode though.

Can you elaborate? What client are you using that isn't seeing it, what kind of radio is in the WAR board? Are you able to use 802.11g or 802.11a and see/associate to the card?

[lonnie]

Please, when you have questions like this, it is essential that provide us the information about your setup. You say AP, but what kind of AP? What kind of radio card in the AP? IS it a WAR AP or a WAR client? What kind of client? What kind of radio?

It saves me from having to ask this information and you will get an answer quicker.
Is anyone having problems with g/b in ap mode, just a thought, i have been having a problem with one war that i upgraded and now i am not seeing the ap, i have checked all settings and hardware

[peace2300]

don't worry about it now, i found my problem, it was a problem with power, i changed out of the power supply and it worked just fine

[tony]

Thank you for the update.

[tony]

beta-6 is now available.

[jasonmbeamer]

I have several APs i first started out several years ago with wrap, 133mhz, 32meg ram, v1.13 and i was never able to get the hotspot mode to work stable. so i went with just autorization through my radius server only. then a year or two passed and i bought 2 wraps at 233mhz, 64 meg ram, v2.10 now. and I gave up on the hotspot mode due to not being able to get it stable, however it was sooooooo much more stable then on v1.13. but i had issues with the status pages not refreshing correctly, login pages freezing etc... but not real often. mabye once a day per 10 client logins. but it was a pain with many clients. so this year i went with a server edition at my office. pentium 3, at 500 mhz, 512 meg ram, radius server disabled and cache disabled. I use vds for my AP repeaters. it works fine. But i know it is not a good design. routing is the best. but i cant count on hotspot at the APs.

Question: can v3 run on wrap 233mhz 64meg ram. I understand that at the moment there is no hotspot mode, dhcp or anything. but when it becomes avalible in the v3 could this be my solution ?

[lonnie]

v3 is just for the WAR boards at the moment. Once we get the system more complete we will port everything to the x86. That will happen anywhere from 4 weeks to 12 weeks, depending on what trouble we have getting things working on the IXP-420 base.