StarV3 v1.2.10b build 2412 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.9b build 2407
*) Better all-round interoperability between 1.2.x and 1.1.x releases, including Cloaking and SuperA/G updates.
*) Client-side WDS bridging improvements.
*) PPPoE server will now properly use radius assigned static routes.
*) Layer-7 support should be operational once again.

Some operational differences include (mainly related to regulatory requirements):
*) Atheros channel and country code list no longer contains an 'All Channel' setting (## and #!).
*) U1 country code (US + FCC3) no longer contains the FCC3 channels, however country UZ can be used in it's place for systems that require them.
*) Due to the nature of our unique rate control, the rate specified is now a MAX rate, and not a FIXED rate.
*) The upcoming 1.3.0 release will contain both a World and FCC version. The World version will support the 'all channel' option.

For best operation, please ensure your client and AP use the same country code.

For those wanting to try the live upgrade feature via starutil, simply add the -a (apply) flag to the command line when uploading the firmware.
This requires that your system is using build 2321 or newer, and starutil 1.16.

HotSpot notes:

The HotSpot offered is vastly different from the version offered in V2.

To configure the HotSpot, there is a new 'hotspot' pull-down menu entry. The configuration script should be self explanitory.

The website users log into is now hosted on your own webserver, and not on the StarV3 box itself. We have offered a login webpage template on our files website, though any ChilliSpot login portal will work just as well.

While in the SSH interface, you can press ALT-H to view the on-line hotspot users. If there is a star (*) next to the IP address, that means the user has authenticated. The rest of the screen should be explanatory.

The hotspot user manipulation support via utilistar is also supported.

Sample HotSpot configuration steps:

Remove all IPs from wpci1 (this will be the AP the users log into)
Make sure your DNS server listed in "advanced->dns server list" is valid, as the hotspot service will require it.
Update RIP and OSPF (if used) to only advertise the Ethernet interface, as to not propagate the hotspot's private IP range.
Enter the HotSpot configuration script and enter the following commands:
hotspot enabled
interface wpci1
radius 1.2.3.4 <-- change to your radius server
radius_secret MySecret <-- change
login_server http://my-auth.server.com/ <-- change to the url where you installed the login script.
login_server_secret 5d8cp1fr9ua <-- change to match the one specified in your login script
dhcp_network 192.168.57.0/24
dhcp_dns 1.2.3.4 <-- change to your DNS server
Enter this in your NAT script: masq from 192.168.57.0/24 to dev ether1
Activate Changes, and you are done.If you use the default domain (hotspot.star-os.com), and default IP range of 192.168.57.0/24, then your customers can use the "exit" keyword in the Internet Explorer address bar to go to the logout page, if the popup window is closed. You can setup similar keywords for your own network if you do not use the default settings.


Notes regarding the Login script:

This is the web-based login prompt your HotSpot users will see when they try to access the Internet.

The system requirements needed for the Login script is a webserver and a stock install of PHP. (Perl login scripts are also available).

The only purpose of the login script is to collect a username and password from the user, and forward it back to the V3 hotspot system for authentication and can be hosted anywhere.

[pti-andy]

I have upgraded from v1.1.4 to 1.2.10b and have discovered a couple of bugs.

1. Using WDS the IP of the client is not reachable from anywhere on the AP side of the network until the AP itself pings the address of the client from an SSH login.

2. The Ethernet duplex setting no longer works. A setting of 10M Full duplex stays at half duplex. This feature worked correctly on the standard release version.

3. Not sure if this is a bug but I have also noticed that the signal strength of the client as reported by the AP varies drastically when no traffic is moving. This didn't appear to be the case with the release version.

I also crashed an AP on my bench just by running a speed test through the Ethernet to another test unit on the bench and pinging the AP with a router on the same LAN. In this case there are no clients attached and no wireless functionality is being used. Just Ethernet traffic out a single port. The result is that the AP locked up and will not come back until power cycled. I'm wondering if this is related to the duplex issue since the local Ethernet port seems to behave differently than the release version does.

-Andy
PTI Wireless

[pti-andy]

When the AP is using 1.1.13 and the clients are running 1.2.10b there is a very noticable speed improvement between a client and the AP Network however, when having sustained traffic the connectivity to the other client becomes intermitent. It will simply drop packets to other clients while servicing the one with the high traffic.

Upgrading the AP to the same beta version fixes this problem about 90% (I still can get some packet loss but it is minimal) but then the speed improvement dissapears and it now runs at the same perforance level obtained when using 1.1.13 on the AP and clients.

This is not a huge deal since I plan on not using a mixed environment but it will be an issue for those that are upgrading a large network and will run mixed for a while.

-Andy
PTI Wireless

[tony]

(In reference to post #2 (http://forums.star-os.com/showpost.php?p=46213&postcount=2))

1. Does 'client' represent a customer behind the CPE, or the CPE itself?

2. The ethernet duplex settings should be identical to 2080. There are massive driver and other enhancements between the 1.1.x release, and 1.2.x so more information about your system will be needed.

3. The clients will need to pass traffic before the signals level out.

The system you are using on the bench.. What is it? The BETAs should be quite reliable at this stage.

[eoinok]

Hi Tony, just want to report that we have upgraded a WRAP & a metro with this and have had no issues.

Eoin

[pti-andy]

(In reference to post #2 (http://forums.star-os.com/showpost.php?p=46213&postcount=2))

1. Does 'client' represent a customer behind the CPE, or the CPE itself?

2. The ethernet duplex settings should be identical to 2080. There are massive driver and other enhancements between the 1.1.x release, and 1.2.x so more information about your system will be needed.

3. The clients will need to pass traffic before the signals level out.

The system you are using on the bench.. What is it? The BETAs should be quite reliable at this stage.


1. The client in this case is the CPE itself. I can't ping the IP assigned to the Ethernet interface of the WAR-2 from anywhere on the network until the AP it is attached to pings it first.

2. I can duplicate this issue with any WAR-2 running the beta. It is attached to a Cisco switch with the appropriate manual setting to match the WAR-2. Changing the setting on the WAR-2 to 10M full duplex has no effect and continues to run half duplex with massive dropped packets to the interface. It will run half duplex correctly however. Simply downgrading back to 1.1.4 fixes the issue and the manual setting will work in both full and half duplex matching the manual setting of the switch.

3. The erratic signal strength does stabilize after running traffic but then goes back to erratic after the traffic is idle again.

The systems on the bench are straight out of the box and then upgraded to 1.2.10b. One is set as an AP and the other a client with no wireless attachements. I will try to duplicate the issue and provide more info on this.

Hope this helps. Let me know if there are any other details I can provide.

-Andy
PTI Wireless

[tony]

"The systems on the bench are straight out of the box".

If you can tell me what the systems are, that you took out of the box that would be wonderful. :) I need to know if it's a WAR-1, 2, 4, METRO, or X86 class system.

Also, let us know what power source you are using to power the systems on the bench.

[Mark]

Does layer 7 filtering / cbq work in this version?

[tony]

Yes, layer-7 should be fully operational in this release.

[Mark]

I am totally fuzzy on pre and post routing, but I cannot get ANYTHING to "hit" in the cbq reports, except my overall traffic limitations.

Yet, someone's running something wide open.

Yes, I have searched the forums and found examples, but for the life of me the use of prerouting and postrouting and then the "in" and "out" cbq rules make no sense at all. And all the examples are for some entirely different setup than I am doing.

I want to implement this on the client end, rather than some central point. Can someone point me to a WORKING client end (to put in a cpe) example of firewall and cbq rules?

Thanks

[Beebe]

Hiding the SSID still seems to not work on 1.2.10b. I upgraded that link I was having trouble with on Friday. It didn't link up until I turned off Hidden SSID. I think the link is ok now. I was getting ready to go to the other end of the link when I remembered I had this same problem before.

I had uncloaked it as someone suggested (tog I think?) and it seems to have solved the problem. I think what was happening is the link was becoming saturated and the ospf traffic couldn't pass properly so the routing would drop out.

Thanks,
Roger

[tog]

Are you using a country code/frequency selection where DFS is enabled?

[Beebe]

I'm using channel 157 (5785Mhz) in US country code.

It's not a big deal now that I know about it of course :) I don't personaly need it fixing or anything (if it's broke), but people need to be aware of it.

Thanks,
Roger

[Stratolinks]

I am totally fuzzy on pre and post routing, but I cannot get ANYTHING to "hit" in the cbq reports, except my overall traffic limitations.

Yet, someone's running something wide open.

Yes, I have searched the forums and found examples, but for the life of me the use of prerouting and postrouting and then the "in" and "out" cbq rules make no sense at all. And all the examples are for some entirely different setup than I am doing.

I want to implement this on the client end, rather than some central point. Can someone point me to a WORKING client end (to put in a cpe) example of firewall and cbq rules?

Thanks

On our WAR1 CPE units, I am assigning the WPCI card with a routed public IP, and the Ethernet serves out DHCP address to the client machines via the DHCP AutoAuth, handing out addresses starting at .20 up to .200. Since the public IP is assigned by our servers I came up with rules that don't care what the actual destination address is so we don't have to change the customer firewall rules if we change their public IP address.


CBQ:
# Shape all the client's IPs to one queue.
qshape client 100 bw 768k 256k 192.168.1.0/24 on ether1

NAT:
# NAT all traffic from the public subnet
masq from 192.168.1.0/24 to dev wpci1

Firewall Rules:
#Block all SMTP mail from clients except to our servers
allow tcp from any 25 to (Our servers IP/mask) in via ether1
deny tcp from any 25 to any 25 in via ether1
# Sample Forward rule for firewall
# To forward traffic coming in on port 1234 to 192.168.1.19 port 1234
#forward tcp to 192.168.1.19 1234 from any to any 1234 in via wpci1

Hope these help you out a bit.

[lonnie]

Many clues to technical terms are given by their standard dictionary meanings. Pre means "before" and post means "after". Combine this with routing and you get before routing decisions and after routing decisions. Once the packet has gone through routing it might have changed the device of exit, so your rules have to be cognizant of where in and out is in relation to the device your traffic comes and goes from.

Always be sure to use the virtual names we give the device, as in eth0 is ether1. eth0 is the Linux device name and ether1 is the name we use, and is the name you must use in our scripting.

I am totally fuzzy on pre and post routing, but I cannot get ANYTHING to "hit" in the cbq reports, except my overall traffic limitations.

Yet, someone's running something wide open.

Yes, I have searched the forums and found examples, but for the life of me the use of prerouting and postrouting and then the "in" and "out" cbq rules make no sense at all. And all the examples are for some entirely different setup than I am doing.

I want to implement this on the client end, rather than some central point. Can someone point me to a WORKING client end (to put in a cpe) example of firewall and cbq rules?

Thanks

[Mark]

What should the following do?


iptables -A POSTROUTING -t mangle -m layer7 --l7proto applejuice -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto ares -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto audiogalaxy -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto bittorrent -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto directconnect -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto edonkey -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto fasttrack -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto freenet -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto gnucleuslan -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto gnutella -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto goboogy -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto hotline -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto imesh -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto kugoo -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto mute -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto napster -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto openft -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto poco -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto soribada -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto soulseek -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto tesla -j DROP
iptables -A POSTROUTING -t mangle -m layer7 --l7proto thecircle -j DROP



I cannot find that it is having any effect on the P2P file sharing going on.

I have put in both pre and post listings and it doesn't do anything.

Yes, activated script changes, even restarted cpe. No effect.

[lonnie]

Is this the latest release? Do you have connection tracking enabled? What hardware?

[Mark]

Many clues to technical terms are given by their standard dictionary meanings. Pre means "before" and post means "after". Combine this with routing and you get before routing decisions and after routing decisions. Once the packet has gone through routing it might have changed the device of exit, so your rules have to be cognizant of where in and out is in relation to the device your traffic comes and goes from.

Always be sure to use the virtual names we give the device, as in eth0 is ether1. eth0 is the Linux device name and ether1 is the name we use, and is the name you must use in our scripting.


Yes, but when I follow the logic, write it all, and nothing happens, obviously something is wrong. I have used your examples from a while back, and they have no effect, either.

Possibly L7 filtering can't stop or affect this guy's traffic, or it's a pattern not addressed in the post above. But school is out, and I have a whole bunch of kids who, in spite of parental orders not to, continue to crank various P2P programs at full speed and i'm having trouble with performance.

So, what I need is a KNOWN good setup so I can dig through it item by item first to make sure I'm not just overlooking something.

[Mark]

Is this the latest release? Do you have connection tracking enabled? What hardware?


This is 2412 on a WAR 1.


Edit: update... sort of. After recopying everything after the last rewrite yet again, it "appears" that I may have it working...at least to drop some of the traffic. Some is still going, but after the umpteenth time I suddenly have the appearance of the P2P program searching for open ports now.

Typo somewhere? I dunno. At least now I can drop the c onnections, which is better than letting it run, though I'd prefer to throttle with CBQ, instead.

[tony]

WAR-1 does not have layer-7 or ipp2p support (due to space, and lack of processing power). I would suggest placing this rule on the AP this client connects to, and narrow down the rule set a bit to only effect their IP address.

[Mark]

I can't shape at the AP, it's a WRAP ( V2 ), and the the version of V2 all my backhauls and AP's use don't have functional l7 filtering, and I can't figure out what, if any, version of X86 V2 has working DNS and L7 filtering. I tried later versions of X86 V2, but DNS fails, which customers view as a network outage....

[tony]

For your needs, I think ipp2p should do everything you need, especially if you are intending to simply block the protocols in question.

For example, to block most p2p traffic, you can issue a statement such as:
iptables -A FORWARD -m ipp2p --ipp2p -j DROP

[Mark]

For your needs, I think ipp2p should do everything you need, especially if you are intending to simply block the protocols in question.

For example, to block most p2p traffic, you can issue a statement such as:
iptables -A FORWARD -m ipp2p --ipp2p -j DROP

That's a bandaid.

I can use it to block some specific clients from using P2P, but I'd rather just shape it through a defined pipe. I'll see what it does on this guy's traffic.

[Mark]

For your needs, I think ipp2p should do everything you need, especially if you are intending to simply block the protocols in question.

For example, to block most p2p traffic, you can issue a statement such as:
iptables -A FORWARD -m ipp2p --ipp2p -j DROP

That has no effect.

At least none that I can find.

[tony]

With ipp2p you can shape is, instead of blocking the same way as you do via layer-7 (set a MARK, and shape it).

What V2 version are you running on your AP? If it's recent, it should support ipp2p and/or layer-7.

[Mark]

With ipp2p you can shape is, instead of blocking the same way as you do via layer-7 (set a MARK, and shape it).

What V2 version are you running on your AP? If it's recent, it should support ipp2p and/or layer-7.

AP is a WRAP running build 4759.

I just set things to drop, but nothing appears to be dropped.

[pti-andy]

"The systems on the bench are straight out of the box".

If you can tell me what the systems are, that you took out of the box that would be wonderful. :) I need to know if it's a WAR-1, 2, 4, METRO, or X86 class system.

Also, let us know what power source you are using to power the systems on the bench.

Sorry, I didn't mention the platform because it is the same batch of WAR-2 boards that I've reported the other issues with. The power is 24V 1.5A on the bench and 48V POE. I test with both. Since then I have not been able to duplicate the lockup issue. It might be related to the lower voltage, not sure. I will keep you posted.

Update: Before I mentioned not being able to reach the IP address of the WAR-2 running WDS until the AP itself pinged it. I now have a scenario where I can't reach a WAR-1 v1.2.10b IP address from the AP side no matter what. Downgrading the AP to 1.1.13 fixes it. It seems that in both of these cases having the AP on 1.2.10b prevents the client radio's IP address from being reached.

Second Update: If using a DFS freq with 1.2.10b for client and AP the client will not associate when powered up even when "hide ssid" is off. Changing the freq to a non DFS one will allow the association and then changing back to the DFS freq will also associate again. I can even turn on "hide ssid" at this point and it still will associate until the next reboot where it all starts over again. I'm using WDS but have not tested it any other way. It appears to be a DFS issue though.

-Andy
PTI Wireless

[lonnie]

Andy, we'll probably have to get a login so we can see this. Sorry, but I have many AP and Clients using 1.2.10b and this is the best release yet. We'll have to see what your precise situation is.

And for everyone else: when you have a trouble report we do need to know the precise setup. We cannot assume and most importantly we cannot be expected to remember what the setup was on another posting. Help us out with information.

[lonnie]

As you know the p2p authors are playing a game of keep ahead and continually change their techniques to get the traffic through. This means that v2 does NOT have layer7. It USED to have it, but that was almost 2 years, so the code and definitions are so out of date that for all practical purposes it does not exist. V3 seems to be pretty stable and complete. Maybe it is time to update a few AP units to gain the newer kernel and features.

The other way, and it is the way I would do it, is run a V3 server on a medium to gamer system. This where I would run layer7 and firewall code. I would do basic CBQ at the client and for sure it would be all Atheros with advanced features enabled.

AP is a WRAP running build 4759.

I just set things to drop, but nothing appears to be dropped.

[Mark]

As you know the p2p authors are playing a game of keep ahead and continually change their techniques to get the traffic through. This means that v2 does NOT have layer7. It USED to have it, but that was almost 2 years, so the code and definitions are so out of date that for all practical purposes it does not exist. V3 seems to be pretty stable and complete. Maybe it is time to update a few AP units to gain the newer kernel and features.

The other way, and it is the way I would do it, is run a V3 server on a medium to gamer system. This where I would run layer7 and firewall code. I would do basic CBQ at the client and for sure it would be all Atheros with advanced features enabled.


For all practical purposes, it is pointless to try to use V3 AP's and V2 clients in 11B mode.

All you'll have is huge latency and data loss.

The best I've ever gotten between a V2 and V3 system in 11b mode is 480KB. Nothing like the 1100KB that's common between V2 and V2.

Every V3 client I add to the V2 AP horribly degrades the AP's performance, as well.

And no way can I afford to upgrade at least 60 clients at once. Not even the 27 on the AP in question. I simply don't have it now.

I have a pure wireless network. I have no location where I can just "add" another machine as a P2P filtering machine. The gateway to my provider runs by POE, and is at least 100 feet from power. I have lease solely for antennas and one sealed box (already full).

BTW, I tried to run the L7 rules on the WRAP. Works. But the CPU is hammered too hard. The CPU was already at 15 to 50% as it was.

[lonnie]

The solution is V3, Atheros radios, G mode, cloaking, compression and other advanced features. You are resisting all things V3 and are slowly ending up with a mix of units and if you keep adding odd lots to the mix you'll never get to use the best features we have. You know, the ones that others report as saving their business.

V3 has much better interference handling and way better low signal level performance. I'm sorry you cannot make the change. I know of no way to make your v2 and odd lot mix work better (except upgrading to V3), so good luck.

[Mark]

The solution is V3, Atheros radios, G mode, cloaking, compression and other advanced features. You are resisting all things V3 and are slowly ending up with a mix of units and if you keep adding odd lots to the mix you'll never get to use the best features we have. You know, the ones that others report as saving their business.

V3 has much better interference handling and way better low signal level performance. I'm sorry you cannot make the change. I know of no way to make your v2 and odd lot mix work better (except upgrading to V3), so good luck.

Resisting?

Again, I have not installed ANYTHING other than V3 since the time I was able to buy WAR1's, and I have a few WAR2's as clients.

This isn't "resisting". I get burned EVERY time I move upward lately. I don't recall a single critical problem other than DNS stopping, and I generally used BETA's all through V2. And yes, the other day, I actually noticed I had a V2 so old it was back when it scanned all frequencies as a client. It was updated promptly.

I so sorely miss the "install and forget" reliability and st ability of V2. Would you not be hesitant to commit to thousands of dollars to upgrade to versions that have continued to cost me days of fight and frustration?

[lonnie]

Our entire network is ALL V3. It has been from the very first V3 release. This a shot of a repeater and 1.2.10b which has been running since I did the upgrade. I feel I can pretty much forget about this system.

Things get fixed and we are better now than we have ever been, and you like the ancient v2. I'm sorry we can't help you. Imagine how much better things would be with X4 cloaking.

[Peanut]

BTW, I tried to run the L7 rules on the WRAP. Works. But the CPU is hammered too hard. The CPU was already at 15 to 50% as it was.
Did you double-check that you had an efficient ruleset in the firewall config?

You wanted to shape the p2p traffic, but if you can drop some unwanted packets at the start of the chain, accept 'known good ones', and/or only use the l7 filters that are most relevant to you, then you might be able to reduce CPU usage significantly.

[Stratolinks]

I so sorely miss the "install and forget" reliability and stability of V2. Would you not be hesitant to commit to thousands of dollars to upgrade to versions that have continued to cost me days of fight and frustration?

Over the last few months I have upgraded all our backhaul and access points to V3. Initially we had a couple of issues where the connection quality to customers was very low, but that pointed out the problem clients and we have since been able to rectify those issues with the clients. Some we had to change to another channel on the AP and a few we had to go and install a higher gain antenna to bring the signal level up.

Our newest sites are set up as V3 with 2x cloaking only (since we didn't have to support existing clients) and are WAR1 clients. These sites are working extremely well without any glitches at all.

Most of our older APs we have out there have a wide mix of clients on them. We still have a small number of WET11 bridges out there, a fair number of Realtek clients, some WRAP/V2 clients, and the rest are all WAR1 clients (ALL new installs are WAR1 clients). Even with this diverse mix of CPE hardware, V3 on WRAP for our APs is working very well.

This AP has a X2 cloaked 2.4GHz feed to it and also feeds a couple of other POPs as well (although we are soon going to replace it with a WAR4 with a 5GHz feed and dedicated 5GHz feeds out to 2 of the POPs which have 23 and 10 clients each respectively).
http://stratolinks.com/forums/Beechwood-2007-08-07.gif

This AP has 41 Clients on it, and a feeds micro POP with 6 clients on it. We are planning out a multi sector upgrade with a new WAR4 to allow it to continue to grow with even more customers on it.
http://stratolinks.com/forums/WonderFan-2007-08-07.gif

This is one of our V3 backhaul links.
http://stratolinks.com/forums/Sylvan-2007-08-07.gif

You will note that the uptime on all these units is in excess of 100 days since we did the V3 upgrades (all remotely). Seems pretty darn reliable to me.


YMMV

[pti-andy]

Here are some more details on the unreachable IP address issue with WDS and a seperate DFS problem.

The scenario is a WAR-2 AP and two WAR-2 clients running 1.2.10b with the radio card bridged to Ether1 and IP address assigned only to the Ether1. The radio parameters on all units are 802.11a, superA/G, Short Preamble, InterBSS Relay, and 2X cloaking. Signal is very strong -58 to -63 and the SSID is not hidden. The frequency doesn’t matter.

1. Boot up AP and both clients, then start a ping to the address of one client WAR-2 from a workstation behind either the AP or one of the clients.
2. Now go to the AP wireless configuration but don’t make any changes. Just hit OK.
3. At this point all clients will disassociate from the AP and take about a minute to establish a new WDS connection.
4. The ping now running to the second client will not come back. This WAR-2 is now unreachable from anywhere behind the AP or other clients.
5. To make it reachable again, ping the non-responding client from the AP’s advanced utility menu and now the unit becomes reachable again from everywhere.

Second case DFS association issue: All parameters are the same as above but using a DFS freq, say 5500. The clients will only associate with SSID hidden after the have connected first without SSID hidden. Making the change to hidden and non hidden will always bring them back until the client is rebooted in which case it will not associate again with the AP if hiding the SSID.

In using DFS frequencies there are random frequency changes as well as occasional erratic ping times to the client radios. Doing an “activate changes” will bring the ping response times to normal. The freq change only occurs while booting the AP, activating changes, or doing ping/throughput tests and will always jump to freqs outside the DFS range even if not in the custom list. If you leave the AP alone and just pass traffic through the connection with a workstation the freq will stay locked and not drift.

All in all DFS seems to be very unstable. Both the WDS and DFS issues are not present in v1.1.13 and simply downgrading only the AP fixes these issues.

Hope this is more helpful.

-Andy
PTI Wireless

[tony]

Thank you for your results.

Regarding the DFS / Hidden SSID issue you are seeing. This is caused by the fact that you cannot use Hidded SSIDs on a DFS channel (or any other passive channel that is marked with a '*').

With passive channels, the clients are not allowed to probe the AP to verify the SSID match, if the AP is hiding it's SSID. This is by design, and not a bug.

Now, if you first change the AP to show it's SSID, all your clients will cache the name the AP has advertised, so when the AP hides it again later, the clients will still know the name without having to probe the AP. (until the cached entry expires, or the client reboots anyhow).

With DFS, there is a chance of a false-positive on occasion when there is interference in the area, however all clients that support 802.11H (such as a 1.2.x WAR client) should follow the channel changes without interruption. Having the AP jump to a channel outside of your ACL is of interest, and will be investigated.

We will look into the WDS issue you are seeing.

[Mark]

I am seeing packet loss issues with 2412, in 11a mode.

I have updated my gateway to 2412, which has two backhaul links off from it.

The signal levels are not real high (one is 11 miles, one is 21 miles), but the far sides are running V2. The 2412 side will continually jump upward in speed to 48 and even sometimes 54 rate, which, at 54, loses packets badly, and 48 is slow. Thus, forcing the speed to some lower speed, like 24 dramatically improves throughput, and also stops the packet loss, which was running around 10% ping loss on the link.

If the rate control was just a "max" I could limit it to 36 and it would still pick up the link quickly and still maintain during times of fade.

It appears to be forced to a single speed, though. If I set the rate to 36, the link takes a long time to reassociate, it seems. I hate to experiment too much... this IS my main gateway, and every change results in a good chunk of my customers going offline for up to 20 seconds.

[tony]

The upcoming release should help quite a bit in regards to the packet loss.

[tony]

I have verified our 1.2.10b WDS support, and it is operating as expected.

When you activate changes on your AP, it loses knowledge of previously learned MAC addresses from the WDS client you are pinging, causing your pings to stop. What you need to do is simply do an ARP flush in your PC to force it to do another ARP request, and everything will resume normally.

When you ping the workstation from the AP itself, the AP will issue an ARP request, and when the workstation relies, the bridge will learn it it's address and allow unicast traffic through once again. This is the normal behavior of the WDS bridge and should not be a cause for concern.

If you leave the original ping going, you would find that it will start pinging again after 10 - 20 seconds once the workstation does an ARP refresh.

1. Boot up AP and both clients, then start a ping to the address of one client WAR-2 from a workstation behind either the AP or one of the clients.
2. Now go to the AP wireless configuration but don’t make any changes. Just hit OK.
3. At this point all clients will disassociate from the AP and take about a minute to establish a new WDS connection.
4. The ping now running to the second client will not come back. This WAR-2 is now unreachable from anywhere behind the AP or other clients.
5. To make it reachable again, ping the non-responding client from the AP’s advanced utility menu and now the unit becomes reachable again from everywhere.

[pti-andy]

Thanks for the quick response.

I have been testing even more and have found the WDS ping issue happen even without "activating changes". I understand what you are saying about ARP but that is not what is happening here. The CPE's will stop responding from any location behind the AP (router, workstation etc.) and never come back hour after hour until the AP pings it. Clearing the ARP has no effect. It also goes back to unreachable after a time all by itself.

The result here is that I can't access or manage the radios remotely at any time. As I said before, version 1.1.13 does not have this problem.

Will the DFS work with hidden SSID in later versions? If not I think this will be a huge drawback. I would prefer that my competition not learn my ID's with their StarV3 units. I just installed a bunch of 5.6Ghz antennas on our towers and have had great success with 1.1.13. I'd hate to be stuck at that version because I really like the enhancements on the beta.

Also, the DFS freq jump only happens during reboot, or activity testing with the SSH console. It will never jump if I stay out of the SSH util and just pass traffic through the unit. Even if the ACL is set to only one freq it still jumps out when speed testing or booting. It would be nice if it obeyed the ACL no matter what so we could lock in a freq for debugging if we had to.

-Andy
PTI Wireless

[mimbach]

ospf stopped working with no changes or no one logging in to the board after running for 24hours. I stopped and restarted ospf and all was well.
Ideas?

Mimbach

[tony]

Are you possibly getting into a bridge loop during your testing? If your workstation's traffic is heard by the AP without going through the CPE, that may cause issues with the learning bridge.

There will be no Hidden SSID support with passive channels, not because it cannot be done, but rather because it is not allowed.

When you say the AP's channel jumps during a reboot, can you elaborate? The only reason the AP would choose a random channel is if the channel you selected in the configuration is not valid.

Thanks for the quick response.

I have been testing even more and have found the WDS ping issue happen even without "activating changes". I understand what you are saying about ARP but that is not what is happening here. The CPE's will stop responding from any location behind the AP (router, workstation etc.) and never come back hour after hour until the AP pings it. Clearing the ARP has no effect. It also goes back to unreachable after a time all by itself.

The result here is that I can't access or manage the radios remotely at any time. As I said before, version 1.1.13 does not have this problem.

Will the DFS work with hidden SSID in later versions? If not I think this will be a huge drawback. I would prefer that my competition not learn my ID's with their StarV3 units. I just installed a bunch of 5.6Ghz antennas on our towers and have had great success with 1.1.13. I'd hate to be stuck at that version because I really like the enhancements on the beta.

Also, the DFS freq jump only happens during reboot, or activity testing with the SSH console. It will never jump if I stay out of the SSH util and just pass traffic through the unit. Even if the ACL is set to only one freq it still jumps out when speed testing or booting. It would be nice if it obeyed the ACL no matter what so we could lock in a freq for debugging if we had to.

-Andy
PTI Wireless

[lonnie]

You are missing the point about DFS. The client CANNOT probe the AP on a DFS channel. It is not our decision to make. It is the way it is due to requirements from people way over our heads. That means the AP must advertise. So, to answer your question, no, the DFS channels will not be using hidden ESSID.

Thanks for the quick response.

I have been testing even more and have found the WDS ping issue happen even without "activating changes". I understand what you are saying about ARP but that is not what is happening here. The CPE's will stop responding from any location behind the AP (router, workstation etc.) and never come back hour after hour until the AP pings it. Clearing the ARP has no effect. It also goes back to unreachable after a time all by itself.

The result here is that I can't access or manage the radios remotely at any time. As I said before, version 1.1.13 does not have this problem.

Will the DFS work with hidden SSID in later versions? If not I think this will be a huge drawback. I would prefer that my competition not learn my ID's with their StarV3 units. I just installed a bunch of 5.6Ghz antennas on our towers and have had great success with 1.1.13. I'd hate to be stuck at that version because I really like the enhancements on the beta.

Also, the DFS freq jump only happens during reboot, or activity testing with the SSH console. It will never jump if I stay out of the SSH util and just pass traffic through the unit. Even if the ACL is set to only one freq it still jumps out when speed testing or booting. It would be nice if it obeyed the ACL no matter what so we could lock in a freq for debugging if we had to.

-Andy
PTI Wireless

[pti-andy]

Are you possibly getting into a bridge loop during your testing? If your workstation's traffic is heard by the AP without going through the CPE, that may cause issues with the learning bridge.

There will be no Hidden SSID support with passive channels, not because it cannot be done, but rather because it is not allowed.

When you say the AP's channel jumps during a reboot, can you elaborate? The only reason the AP would choose a random channel is if the channel you selected in the configuration is not valid.

There is no bridge loop. Both CPE's are only attached to workstations and routers with no other connections. This was an upgrade of an existing and working 1.1.13 environment. As I said, simply downgrading the AP fixes it. Also keep in mind that it is not just workstations that can't reach the client but also Cisco routers on each end.

I understand now about the Hidden SSID. It just was a surprise since 1.1.13 did not behave this way and neither does some other products on the market. Does that mean that 1.1.x does not impliment DFS correctly? The unfortunant result is that I have designed a portion of my network around how 1.1.x behaves and now I will have to tear down my antennas on my 250ft tower and start over.

I have an idea. Can a manual BSSID (MAC address) entry in the client be used to attach to the AP with a hidden ID so that it does not have to probe? This would get around this problem and allow the use of this feature that so may WISP's have depended on.

The channel jumps about one out of 5 times that the AP is rebooted and the clients will attach with a sig qual of 13% until I activate changes to make it obey the channel I have picked. When the channel jumps (for any reason) it always jumps to a freq above 5745. It will never jump to another DFS channel that is specified in the ACL. I have also had this jump happen on a different AP at a different tower with a WAR-1 client and it was also out of the DFS ACL. It doesn't seem to matter what freq I start with. It just doesn't want to stay locked.

-Andy
PTI Wireless

[lonnie]

The 1.1.x series implemeted DFS per the older specs but as you know things have changed recently and we are simply meeting new requirements. That is why the driver is a complete rewrite.

[soulmata]

I decided to move 2 of my units at home over to V3 on the beta series to test their performance

Both of them are on EPIA 533MHz boards. With V2, the performance was really good - though, I wanted true bridging and have just been waiting for WPA support on V3.

I have to say, I am way beyond impressed. The following came from an epia board running v3 in my living room, going through 2 walls and a metal door, to my AP in another room then to my file server (wired to the AP):

bi-directional test, 2 CM9s, both AP and Client are "bridges", TurboA

Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
------------------------------------------------------------
Client connecting to 192.168.0.4, TCP port 5001
TCP window size: 221 KByte (default)
------------------------------------------------------------
[ 21] local 192.168.0.91 port 57229 connected with 192.168.0.4 port 5001
[ 21] 0.0-10.0 sec 112 MBytes 94.0 Mbits/sec
[ 20] local 192.168.0.91 port 5001 connected with 192.168.0.4 port 51641
[ 20] 0.0-10.0 sec 112 MBytes 94.0 Mbits/secWhen copying across the bridge, from a machine wired onto the remote side, copying encrypted data (SSH, actually), I can hit 10MByte/sec.

This is a significant upgrade from what V2 was giving me, where I was hitting a peak of about 5MByte/sec.



The only thing I noticed is that a Turbo A connection shows the sync rate as 54, rather than 108. Is this intentional?

[eoinok]

Hi guys, it just dawned on me there, there is an issue with the current stable release of uploading a config onto a board from a saved config.

I was wondering has this been addressed in this beta stream...

Eoin

[tony]

soulmata, thank you for the update. Yes, the rates will continue to show 54M during turbo, and cloaking modes. Once we start the new interface, the rates will most likely be scaled to represent the operating mode.

eoinok, this problem is known in the 1.1.x, and has been resolved in the betas.

Thanks!

[eoinok]

sound tony. will test when i get home later this evening.

[Mark]

In 2412, and previous build to that, I am seeing above 100 percent ping return, it is improved by unchecking "short preamble".

this is client ping to ap, and the ap's are generally V2.

[soulmata]

Bridging is not working for me if WPA is enabled.

Using 2 Metros, with wpci1 in bridge group 1 and ether1 in bridge group 1, the bridge works - until I enable WPA. As soon as WPA is enabled, I can only reach IPs on the "far side" of the Metro, but nothing else on its LAN side.

[lonnie]

The most common cause of ping dups is having your distance set too low.

I appreciate the reports BUT when a v2 unit is involved there is little we can do. Do yourself a favour and take advantage of the $10 upgrade sale and get rid of all those v2 systems.

In 2412, and previous build to that, I am seeing above 100 percent ping return, it is improved by unchecking "short preamble".

this is client ping to ap, and the ap's are generally V2.

[Mark]

The most common cause of ping dups is having your distance set too low.

I appreciate the reports BUT when a v2 unit is involved there is little we can do. Do yourself a favour and take advantage of the $10 upgrade sale and get rid of all those v2 systems.


So, because MOST of this is seen between V2 and V3 and some is not, you'll do nothing about the phenomenon.

The worst site for this has ap and client just about a mile apart and the distances are set to 10 miles. And both are V3.

But, like you said... Any excuse to ignore a problem will do.

[tony]

Please keep the insulting jests off the forums, they will no longer be tolerated.

You have been in wireless for some time now, and should know what causes dups (ie. reflections). While the systems do all they can to reduce the impact (dup detection), some inevitably get through. This in general will not impact your system, as they are processed either way.

The best thing you can do is try to re-align your antennas or upgrade to a system that has the benefit of new technology and techniques (as Lonnie is pointing out).

[Mark]

The best thing you can do is try to re-align your antennas or upgrade to a system that has the benefit of new technology and techniques (as Lonnie is pointing out).

The system in question is a WAR1 and WRAP, both running V3 2412.

To what "new technology" should I upgrade?

[tony]

This is where you try the other suggestion, and re-align your antennas to try and reduce the reflections.

[lonnie]

So, because MOST of this is seen between V2 and V3 and some is not, you'll do nothing about the phenomenon.

The worst site for this has ap and client just about a mile apart and the distances are set to 10 miles. And both are V3.

But, like you said... Any excuse to ignore a problem will do.

Mark, Mark, Mark. Always looking for a fight. I did not say any such thing, so better watch it. I'll not tolerate any more of this.

Rather than spending the evening doing something constructive like upgrading all those v2 systems with our $10 upgade special, you continue to complain about the EOL v2. Unbelievable.

v2 will never have another release. Accept that simple fact and get on with your life.

[lonnie]

The system in question is a WAR1 and WRAP, both running V3 2412.

To what "new technology" should I upgrade?

I'm done. There was a time I enjoyed your questions and suggestions but that was a long time ago. We do not need this here.

Please consider that you are alienating the support people. Is that really what you want?

[robert]

Tony,
I want to purchase 4 of the upgrade licenses, but there is no way that I going to get the V3 firmware loaded on my AP's before the timeout tomorrow noon. Is there any way that I can give you the AP keys and get the license for future installs?

Robert

[lonnie]

Sorry. Load the crossover, get the request key and obtain the license. You do not actually have to load V3 until you are ready.

[robert]

Ok, I'm feeling braindead ( doing fedora upgrades at the same time...) where/what is the crossover?

Sorry,
Robert

[tog]

Perhaps this will help you with both questions:
http://staros.tog.net/wiki/Upgrading_to_V3

The crossover is special version of StarOS v2 (fully functional still!) which has the licensing and flash updating bits tweaked to allow you to license and flash to StarV3 over the network.

[robert]

Thanks
Got it all done (obvious from my four purchases... )
Muchly appreciate this deal, I was seriously considering going in another direction...

Robert

[tony]

Hmm, strange. I will investigate this, thanks.

Bridging is not working for me if WPA is enabled.

Using 2 Metros, with wpci1 in bridge group 1 and ether1 in bridge group 1, the bridge works - until I enable WPA. As soon as WPA is enabled, I can only reach IPs on the "far side" of the Metro, but nothing else on its LAN side.

[soulmata]

Hmm, strange. I will investigate this, thanks.


This is only showing up on the Metros - not my X86 based systems. I'm flashing them to latest beta in a few minutes and wiping their config, and will try again.

[tony]

Thank you for the update.