StarV3 1.0.0(beta-16) build 980 (WAR Edition) is ready for testing

[tony]

The new release is on-line and ready for public testing. Please download it from the www.star-os.com/starvx (http://www.star-os.com/starvx) website.

Any and all comments are welcome.

Changes since the last beta:
*) atheros updates to better handle noisy environments when in 802.11g mode.
*) atheros updates to resolve the 'N' association issue some have been seeing.
*) option has been added to disable AP power saving features.
*) configuration backup / restore option is now available through starutil.

Release Caveats:
*) read the release notes.

[tog]

All right, first question:
Can you backup a configuration from v2 and restore it to v3 and vice-versa?

[tony]

No, the configuration methods differ, and are not compatible. The same starutil can be used for both platforms however.

I will look at making a v2 -> v3 config conversion tool for this purpose.

[tog]

Ok, thanks for the clarification.

That sounds like a nice idea, but you definitely have better things to do at the moment. :)

Here are the features I care about next, in order of my priority:
WMM/WME QoS
Client Bridging
ISC dhcpd if it's possible to fit it (sorry, I don't like udhcpd)

[lonnie]

ISC DHCP is too big. It will not be put in the WAR platform.
Client bridging is handled rather nicely with VDS.
QOS will find its way, but other things are more important.

Ok, thanks for the clarification.

That sounds like a nice idea, but you definitely have better things to do at the moment. :)

Here are the features I care about next, in order of my priority:
WMM/WME QoS
Client Bridging
ISC dhcpd if it's possible to fit it (sorry, I don't like udhcpd)

[greg]

No, the configuration methods differ, and are not compatible. The same starutil can be used for both platforms however.

I will look at making a v2 -> v3 config conversion tool for this purpose.I need this tool soon. Thanks!

[tog]

ISC DHCP is too big. It will not be put in the WAR platform.
Client bridging is handled rather nicely with VDS.
QOS will find its way, but other things are more important.

ISC dhcpd should be around 200K stripped and compressed. Compared to the rest of the software packages, I suppose that's pretty bloated.

How do you suggest one sets up client bridging with VDS? VDS tunnel from the client unit to the AP, bridge the vds interface to wpci1? (assuming wpci1 has my block of public IPs and dhcpd)

At the moment I am just routing individual /30s to clients temporarily. This configuration also allows for WMM/WME QoS whereas the VDS tunnel setup does not.

QoS is extremely important to me which is why it's at the top of my list. I can make more money and grow my business if I can sell hosted PBX service over my network and from the testing I've done I can tell you that WMM/WME works and makes voip (more) reliable. Despite proper CBQ shaping and minimal load on each AP and everything (everybody on AP shaped, voip traffic shaped to its own 9999k pipe) I still need WMM/WME. I need this extra major hook to attract and retain business clients.

Oh, the other thing I forgot to add to my list:
Ability to enable and adjust CTS/RTS for v3 clients.

I realize you have a lot going on right now, I'm just displaying my personal priority list. Feedback for you. I don't expect it this week. I care far more about working on the core driver stability than these additional features.

1. WMM/WME QoS
2. Client Bridging
3. CTS/RTS

[wwalcher]

QoS is extremely important to me which is why it's at the top of my list. I can make more money and grow my business if I can sell hosted PBX service over my network and from the testing I've done I can tell you that WMM/WME works and makes voip (more) reliable. Despite proper CBQ shaping and minimal load on each AP and everything (everybody on AP shaped, voip traffic shaped to its own 9999k pipe) I still need WMM/WME. I need this extra major hook to attract and retain business clients.


How do you determine what is VOIP traffic in order to shape it? I have a couple of customers wanting to do Vonage, and I would also like to sell VOIP services, but don't know how to prioritize the VOIP traffic.

[tog]

That's not really prioritizing it, that is just giving it its own cbq pipe to make sure voip traffic isn't included with all the other traffic in the smaller CBQ pipe to the client.

I shape traffic based on the IP address of the SIP proxy my voip clients connect to. I run it so I know its IP address.

With WMM/WME QoS, the RTP packets are prioritized based on "type of service" information set in the headers.

[go.fast]

*) option has been added to disable AP power saving features.



Can you explain the power saving feature. How it works, has it been working all along and the benefits?

Thanks

George

[greg]

I flashed 5 working Warboards last night with this and they all rebooted without issues. I'm just now working with the config save and load.

[lonnie]

Laptop clients need will shut the radio down to save power, but they wish for the AP to still consider them as alive and connected. The AP is thus buffering data for the sleeping laptop until it comes out of sleep mode at which time the AP shoots all the buffered packets to the laptop.

If you think about it, it is not such a good feature unless the client wakes up frequently. It also should not go into sleep mode if it is getting lots of data sent to it.

In our type of application it is not required except for some laptops that might hook up.

Can you explain the power saving feature. How it works, has it been working all along and the benefits?

Thanks

George

[tony]

The AP power saving feature has been in star-v3 from the start, however we have found that some clients (more notably, non-windows clients) perform power saving in order to do background scanning, however they do not notify the AP that they are able to receive data again, thus causing the client to stop passing traffic. We have provided the option to disable AP power saving, which will allow these clients to continue working uninterrupted.

If you are using star-v3, and windows clients only then you can safely leave this option enabled. If you are using star-os clients, or other hardware-cpe systems then it is best if you leave this option disabled for best compatibility.

With this option enabled, it will allow the clients to perform background scans (or sight surveys) without loosing any data. With this option disabled, the clients will still be able to perform background scans however you may experience a lost packet on occasion as the AP will no longer buffer this data on the client's behalf.

[go.fast]

Ok, thanks for the detailed explanation.

Helps a lot.

So to summerize, hot spot type aps leave enabled, all war only systems disable it.
Thanks

George

[nelson05]

I feel like I might be tempting fate posting this, but so far beta-16 seems to be running very well. I started off with beta-15 with similar results though I gradually increased the number of clients after deploying the AP so it wasn't pushed as hard from the beginning as beta-16 has been.


However, at my current load (60 clients), it was getting where I wasn't able to even get a full day of runtime before the AP would stop passing traffic on beta-15. We're now at 1 day and 7 hours on 16 without a hiccup. I'm still watching the AP every couple of minutes, but so far so good.

Now that it looks like the stability has been ironed out, I'll chime in with my feature requests as well.

0. Factory reset- assign an IP of 192.168.2.1 to ethernet 2
1. Ping watchdog
2. DHCP/Radius authentication- some mechanism of assigning static IP leases
3. WMM/WME
4. Beacon interval adjustment
4. CTS/RTS adjustment

I also agree that the v2 to v3 conversion tool should take a backseat for the time being.

[tog]

0. Factory reset- assign an IP of 192.168.2.1 to ethernet 2
1. Ping watchdog
2. DHCP/Radius authentication- some mechanism of assigning static IP leases
3. WMM/WME
4. Beacon interval adjustment
4. CTS/RTS adjustment


I think 192.168.2.1 has been assigned to ether2 in the factory defaults as of the last couple of v3 releases.

Beacon interval adjustment? What makes you care about that setting?

[tony]

As of beta-16, the factory settings place new IPs on both ethernets, and the first Wireless card.
ether1: 192.168.1.1
ether2: 192.168.2.1
wpci1: 192.168.3.1

[lonnie]

WAR only can leave it enabled since our driver properly handles things. We use the mode for site survey to avoid data loss.

Ok, thanks for the detailed explanation.

Helps a lot.

So to summerize, hot spot type aps leave enabled, all war only systems disable it.
Thanks

George

[nelson05]

Good to know... I have only loaded beta 16 on a production AP so far and obviously wasn't able to reset to factory defaults to verify the addition. Thanks.

We've adjusted the beacon interval (and RTS/CTS settings) on our Cisco APs for years and have found that we are able to measurably increase performance and the number of clients we can put on one AP by reducing the overhead associated with beacon transmissions (by increasing the beacon interval). Increasing it really offers no downside in a fixed wireless environment where clients are not roaming from location to location. You wouldn't want to touch it for a card serving as a hotspot with mobile clients.

We have ours set to 2500 on our Cisco APs and while V2 can associate with no problem, V3 cannot as Tony explained it handles the setting in hardware and the Atheros cards only support a range of 20-1000. We've adjusted our Cisco APs down to 1000 and have no problem since we've relieved some of their load with the addition of our V3 APs. I'd just like to be able to eke a little more performance out of the V3 AP as well.

[go.fast]

What is QXCF?

and does HC stand for host client?

George

[nelson05]

http://www.staros.com/downloads/athAssocDesc.pdf

What is QXCF?

and does HC stand for host client?

George

[lonnie]

Quality of Service
Xr
Compression
Fast frames

Host
Client
Not connected

[dc2005]

I feel like I might be tempting fate posting this, but so far beta-16 seems to be running very well. I started off with beta-15 with similar results though I gradually increased the number of clients after deploying the AP so it wasn't pushed as hard from the beginning as beta-16 has been.

Are we still looking good on beta-16? I have a couple of WARs that I want to use on a remote site as client facing APs and was waiting until there was a definite concensus on the stability of V3 before taking the plunge. Thanks for the feedback.

[lonnie]

Beta16 is in full use here. There are reports of AP units with 60 associations and no issues. It is a definite release candidate to remove the beta label.

[nelson05]

I'm the guy with 60 associations (62 clients in g mode on one radio to be exact) and can confirm that beta-16 is solid. We just passed 4 days and 3 hours without a hiccup. This is the longest we've been able to run under v3 without having to reboot the board. Speed is great, latency is great.... we are VERY happy and if we make it through the weekend with no issues, are ready to start deploying the rest of our Quad WARs.

We would feel a bit more comfortable if the ping watchdog made it into v3 soon. And while we're on the subject of watchdogs, I notice that the hardware-watchdog is still greyed out in beta-16.

These feature requests are a good thing.....I'm glad that I can go back to even thinking about pestering Valemount for the features I'd like to see make it into v3- it means that the issue of stability has been put to bed as it was the only thing on my mind for the last couple of months. I have a feeling we're about to see v3 development really take off.

Thanks again Lonnie and Tony for getting everything running so well with this release. Happy Easter to everyone.

[tony]

I am very pleased to hear you are running good. This new release has shown to be quite reliable.

The ping watchdog is almost complete, and should show up soon, hopefully in beta-17. The hardware-watchdog being greyed out has been corrected for the next release.

Thanks!

[mrmike]

Now I have a board that has 1 AP and 2 links. On the Ap, I have 2 wraps, and 2 HGA2400 radios. I seem to have to reset the sysem every day for all four to allow traffic. The links are fine. Is this because there isn't that much traffic on the AP?

[tog]

Could you be more specific about your problem?

The two backhaul links always work fine but your 802.11b/g AP stops passing traffic? What version/build are you using, StarV3 beta-16 build 980?

Is there anything interesting in the system log, anything to note about the behavior other than it stops passing traffic to your four 802.11b/g clients? Do the clients show associated but in N state or anything like that?

Did you disable power saving on the 802.11b/g AP?

[jeff]

watch out for the hga2400. We had 15 or so and over a 3 month period they have now all flaked out.

[mrmike]

There isn't anything checked off in the configuration for that card. The olny log statement that I don't understand is 'Unable to load interpreter /lib/ld-uClibc/so.0' The one HGA2400 spent the morning associating and disassociating every 5 minutes, until I reset the system. The system showd association, but in N state

Version Beta 16, build 980

Thanks

[peace2300]

i have upgraded most of my war boards to beta 16 and now twice i have run into the N issue, first time was a war ap no cloaking in g mode with one client that went N after a day of uptime. the second time was a War ap no cloaking g mode again except this was a hotspot with only 4 people connected. both times it was in B/G mode with no cloaking.

[lonnie]

Did you disable power savings on the AP?

[peace2300]

yes that is what mode it was in when it dropped

[lonnie]

What sort of client was it that dropped off?

[go.fast]

Well there is 2 ap's that did this.
One is one we just set up and had 1 client. which is a war client.
The other is an existing ap that is open for occasional wifi users but also has 3 fixed prism B clients and a war G client.

George

[lonnie]

We have an AP with 6 WAR G clients that has 8 days of runtime. Noise could be the culprit, so maybe try the system in cloaked mode.
Well there is 2 ap's that did this.
One is one we just set up and had 1 client. which is a war client.
The other is an existing ap that is open for occasional wifi users but also has 3 fixed prism B clients and a war G client.

George

[nelson05]

7 days and 16 hours of uptime on beta-16 here. Things look great with 62 clients [61 Star OS v2 WRAPs (2.11.0 build 4759) plus the first WAR we have deployed for customer use] associated to one CM9. The thing hasn't skipped a beat.

[go.fast]

We have an AP with 6 WAR G clients that has 8 days of runtime. Noise could be the culprit, so maybe try the system in cloaked mode.


Can't use cloaking for the open hotspot.

I looked and I have power saving turned on for the open hotspot ap and turned off for the war ap that only has one client, another war cpe.

I'm wondering if idle time could be a reason for this.

The single customer ap prbably has a customer who may only use it a couple times a day, if that.

The other ap which is open and has a mix of clients is not a terribly busy ap.

I'm wondering if Nelson has ping watch dog turned on his wrap clients pinging the war ap...

George

And all my wars are beta16

[nelson05]

I do have the ping watchdog activated for all of our v2 clients where the WRAPs are set to ping our DNS server every 20 seconds. It is not enabled on our single WAR client, obviously, since v3 does not yet have the feature. Once it makes it in, I'll enable it on the WAR as well.

[go.fast]

I do have the ping watchdog activated for all of our v2 clients where the WRAPs are set to ping our DNS server every 20 seconds.

I wonder if this is a clue. Maybe idyle time, no customers passing traffic.

I have a lot of 5gig war ap's and cpe's that don't do this as well as a war 2gig PtP shot that does not do this either. The 2 gig PtP shot is feeding a small 20 customer pop and I'm sure it too has ping watchdog pinging my dns.

I just don't have many 2gig war ap's yet.

George

[bminish]

I have 2 x 4 radio war boards which we have begun evaluating and have come across the following issues.

1/ BGP, where's it gone? we are using this to hand off to a couple of other community wireless projects that we provide wholesale connectivity for. Is BGP support coming along later, it's important to us?

2/ OSPF BUG
Although I only have 2 boards to play with I have already on one occasion seen a situation occurring where OSPF on one board 'lost awareness' of an interface even though it was reporting a state of full DR with the neighbour on this interface. This is identical in presentation to the OSPF issues we are seeing in V2. I can't do much more debugging on this until I have more than 2 routers running V3 but I will be looking out very closely for this.

3/ OSPF the version that the war boards arrived with (beta 11?) had ospf compiled without ipv6 support. when compiled this way you can abbreviate commands with single letters as follows
show IP ospf routes = s i o r

beta 16 has ipv6 support enabled at compile time
when ipv6 is compiled in this becomes
s ip o r
My vote is to not compile in ipv6 support unless the underlying OS also supports ipv6

3/ Radio support, seems that antenna socket B may not always be supported on the 5Ghz band. I could not get an association going ob b in diversity or set to B until I moved the pigtail to antenna A. Antenna B had worked fine with the same card in a WRAP on the same link. this makes no difference on WAR but would be an issue for us upgrading V2 wraps when v3 for WRAP eventually arrives.

4/ Radio support, BUG :-(
In tests I set a client end to G only, Turbo. Now that war board will not boot with a radio installed.
How do I factory reset and more importantly why did the board lock up so hard?
The regulatory domain was set to ## at the time

5/ Warranty void stickers, if you are going to insist on placing these stickers on each M-pci slot then please place a backing card between the back of the slots and the board.
The gunk on the stickers sticks well to the PCB, is hard to remove and may well have long term negative effects on the board after the board has been in use in an uncontrolled environment for a period of time. I have seen sticker goo turn into weird semi-conducting gunk after environmental exposure. Not what you want on a PCB you are trying to run your business on


.brendan

[bminish]

4/ Radio support, BUG :-(
In tests I set a client end to G only, Turbo. Now that war board will not boot with a radio installed.
How do I factory reset and more importantly why did the board lock up so hard?
The regulatory domain was set to ## at the time


How do I factory reset please? I have one WAR board that is currently no use to me

[tony]

You can use the serial port, or ssh to restore factory settings. Enter the system console, and type: "/system factory" then "Y".

The system will automatically reboot, using the new settings.

[bminish]

You can use the serial port, or ssh to restore factory settings. Enter the system console, and type: "/system factory" then "Y".

The system will automatically reboot, using the new settings.

Is the serial cable a Null modem (cross over) or straight though and what baudrate?
.brendan

[bobbyc]

According to this thread, it's a staight through and baud rate is 115200.
http://forums.star-os.com/showthread.php?t=5236
Bob C

[pti-andy]

Not to change the subject, but now that beta-16 is proving to be so stable is there any chance that bridging or WDS will be implemented before it becomes a release candidate? I really have no plans of removing my Cisco's from our network and can't replace StarVX with V3 until transparent bridging is supported. How far is this on the feature list?


-Andy
PTI Networks

[tony]

WDS is something that we are working on, and are hoping to have it complete before we do a 1.0.0 final release.

[lonnie]

1/ BGP was never there for the WAR. It does not make sense for an AP and takes more than 64 MB ram, at least so we were told.

2/ The OSPF problem would point to an issue with Quagga. This is a new kernel, new driver and same Quagga. There is very little chance we have some common StarOS issue between v2 and V3. It is all standard glue. The driver was a from the ground port of VxWorks code and believe me, it does even remotely resemble the v2 driver. The kernel is 2.6 and thus is not even close to the same as the 2.4 kernel in v2.

3/ Update to beta16. beta16 has many tweaks and fixes is the one that people report with stability plus it has the incremental activate.

3 (second one)/ What kind of cards are showing this behaviour? Our CM9 radios do not have that issue.

4/ How did you determine it had not booted? ## has a lot of channels and thus it could be real busy with lots of noise. If you have not upgraded to beta16 then noise could be a factor which had been shown to put the unit at 100% and thus it was running but not responding.

5/ We are confident the sticker goo is harmless.

I have 2 x 4 radio war boards which we have begun evaluating and have come across the following issues.

1/ BGP, where's it gone? we are using this to hand off to a couple of other community wireless projects that we provide wholesale connectivity for. Is BGP support coming along later, it's important to us?

2/ OSPF BUG
Although I only have 2 boards to play with I have already on one occasion seen a situation occurring where OSPF on one board 'lost awareness' of an interface even though it was reporting a state of full DR with the neighbour on this interface. This is identical in presentation to the OSPF issues we are seeing in V2. I can't do much more debugging on this until I have more than 2 routers running V3 but I will be looking out very closely for this.

3/ OSPF the version that the war boards arrived with (beta 11?) had ospf compiled without ipv6 support. when compiled this way you can abbreviate commands with single letters as follows
show IP ospf routes = s i o r

beta 16 has ipv6 support enabled at compile time
when ipv6 is compiled in this becomes
s ip o r
My vote is to not compile in ipv6 support unless the underlying OS also supports ipv6

3/ Radio support, seems that antenna socket B may not always be supported on the 5Ghz band. I could not get an association going ob b in diversity or set to B until I moved the pigtail to antenna A. Antenna B had worked fine with the same card in a WRAP on the same link. this makes no difference on WAR but would be an issue for us upgrading V2 wraps when v3 for WRAP eventually arrives.

4/ Radio support, BUG :-(
In tests I set a client end to G only, Turbo. Now that war board will not boot with a radio installed.
How do I factory reset and more importantly why did the board lock up so hard?
The regulatory domain was set to ## at the time

5/ Warranty void stickers, if you are going to insist on placing these stickers on each M-pci slot then please place a backing card between the back of the slots and the board.
The gunk on the stickers sticks well to the PCB, is hard to remove and may well have long term negative effects on the board after the board has been in use in an uncontrolled environment for a period of time. I have seen sticker goo turn into weird semi-conducting gunk after environmental exposure. Not what you want on a PCB you are trying to run your business on


.brendan

[bminish]

1/ BGP was never there for the WAR. It does not make sense for an AP and takes more than 64 MB ram, at least so we were told.

Ok, Will BGP make the WRAP and PC versions when the time comes?


2/ The OSPF problem would point to an issue with Quagga. This is a new kernel, new driver and same Quagga. There is very little chance we have some common StarOS issue between v2 and V3. It is all standard glue. The driver was a from the ground port of VxWorks code and believe me, it does even remotely resemble the v2 driver. The kernel is 2.6 and thus is not even close to the same as the 2.4 kernel in v2.


It may well be a quagga problem, we just don't know. Quagga is opensource and if you can pin things down enough to file a meaningful bug report with the Quaga developers then I am sure we will be able to get a resolution to this issue.
However, I have never ever seen this issue on any other quagga platform I have used.
Microtik has a perfectly working and stable OSPF implementation with atheros support using quagga
Paul (OscarBravo) is on the quagga developers mailing list and has searched diligently for an existing bug report with similar symptoms, there aren't any similar reported bugs

it's in Valemont's interest to pin this one down and it's certainly in our interests to see it resolved. Our offer of assistance in this area still stands



3/ Update to beta16. beta16 has many tweaks and fixes is the one that people report with stability plus it has the incremental activate.

This is a nice feature, well done.


3 (second one)/ What kind of cards are showing this behaviour? Our CM9 radios do not have that issue.

CM9 cards


4/ How did you determine it had not booted? ## has a lot of channels and thus it could be real busy with lots of noise. If you have not upgraded to beta16 then noise could be a factor which had been shown to put the unit at 100% and thus it was running but not responding.

No ping and no SSH. it is on beta 16 and was not connected to an antenna that cound see much, just sitting here on the bench.
I have not connected to the serial interface nor will I until someone clarifies if it's a straight though cable or a Null modem cable, the previously linked thread states both, one is obviously incorrect and has the potentially for board damage


5/ We are confident the sticker goo is harmless.

I would like to see that clarified with gateworx. I have seen all sorts of damage done to PCB's due to sticker goo.
using a backing card would be another alternative ?
Why do you need them on each slot anyway? Do you not trust us at all?

.brendan

[go.fast]

I wonder if this is a clue. Maybe idyle time, no customers passing traffic.

I have a lot of 5gig war ap's and cpe's that don't do this as well as a war 2gig PtP shot that does not do this either. The 2 gig PtP shot is feeding a small 20 customer pop and I'm sure it too has ping watchdog pinging my dns.

I just don't have many 2gig war ap's yet.

George

Ok once again. I had to go back and reboot both of these AP's.
Both experiencing the same problem.

How soon is the next beta release coming out and will it have ping watchdog?

George

[bobbyc]

I switched a V2 prism 2.5 AP over to a v3 WAR4 SR2 AP this morning. It was the smallest AP we have on our system that I chose to swap for this test. So far it is doing great. I've had little success with the SR2 thus far on V2, but I concluded it was because of noisy areas and vertical sectors. I have a 400mw senao atheros card (based on the new 5006 but without super a/g) as a backup. A CM9 won't cut it because of the lower power output. But just as everyone else has mentioned, the SR2 is definetely not 400mw... isn't even 200mw... which is probably a good thing. No need to shout.

So things look great so far. My house is on this AP so it is getting very thorough testing. The AP has a mix of ethernet bridges such as CB3, hwba11, and even a orinoco USB client. All associations look great and are locked at 11mbps, except for the USB client. The few orinoco USB clients we have on our system all have the registry string that locks them at 11mbps, but for some reason on atheros APs they seem to sit idle at 2mbps on the r-rx column. I haven't decided if this is acceptable or if I should force my USB clients to upgrade to ethernet. The AP is setup as the following:
Transmit rate 11
Distance 8 miles
Country US
Power def
Cloaking 1x
Antenna A
Hide SSID
Outdoor only
Short Preamble
802.11b

Thanks,
Bob C

[dc2005]

1/ BGP was never there for the WAR. It does not make sense for an AP and takes more than 64 MB ram, at least so we were told.

I've beening running BGP for a few months between two Warp board with StarOS V2 and it only seems to use about 1MB of memory or, put another way, the reported free memory drops by this amount when BGP is turned on. Where is the 64MB coming from? You'll be happy to hear that BGP works well on V2. I don't see any reason not to include BGP as an option on the WAR, it's available in Quagga anyway and should be relatively easy to compile into StarV3?

I also agree with Brendan about the stickers on the boards - surely there's a better way to make your warranty restrictions clear rather than risking damage to the boards and annoying customers in the process?

[bminish]

I've beening running BGP for a few months between two Warp board with StarOS V2 and it only seems to use about 1MB of memory or, put another way, the reported free memory drops by this amount when BGP is turned on. Where is the 64MB coming from? You'll be happy to hear that BGP works well on V2. I don't see any reason not to include BGP as an option on the WAR, it's available in Quagga anyway and should be relatively easy to compile into StarV3?


I suspect that if you were using BGP on an Internet edge router with a public AS Number then the tables would get pretty big and you would need many MB of RAM to keep track of things. However when used internally with a private AS number or as the protocol to deal with routing to a downstream client connected in more than one location it's not going to need much RAM.

I doubt many of us plan on using WAR boards to deal directly with network edge routing so BGP will get by with less ram and may well fit comfortably onto a WAR platform.
Can we try it please ?
Certainly I hope BGP makes it to the x86 versions of V3 as we are using it very successfully in V2 and it would be sorely missed

.brendan

[Ick]

Are there plans to have the ACL active in the final release of 1.0.0?

[greg]

Couple of little things I've noticed using the War boards. One, the wheel on the mouse works (at least a little) when scrolling. Small thing and it still could be improved.

Another really nice improvement is that all the radios don't reset when changes are applied that don't impact that radio. If I change a route and apply changes, the clients don't get booted.

I had a pc server (2.4 Agere and 5.8 CM9) die this weekend and replaced it a long with a 2port war board with a 4port War. There are 38 clients on a 2.4 AP and they seem to be playing nicely so far. Many of the clients are Tranzeo but lots of cb3's and wet11 units too. To date, I've got about 75% of my entire backbone converted to War units. No more random reboots or lockups, life is definitely better.

[tog]

I suspect that if you were using BGP on an Internet edge router with a public AS Number then the tables would get pretty big and you would need many MB of RAM to keep track of things. However when used internally with a private AS number or as the protocol to deal with routing to a downstream client connected in more than one location it's not going to need much RAM.


I agree it makes sense to still include Quagga's bgpd even on a system with only 32M or 64M of RAM. It's up to us as the network engineers/designers to understand that we cannot use it as an eBGP edge router lest we exhaust our system resources, but it is certainly still useful for iBGP just as bminish says.

No ping and no SSH. it is on beta 16 and was not connected to an antenna that cound see much, just sitting here on the bench.
I have not connected to the serial interface nor will I until someone clarifies if it's a straight though cable or a Null modem cable, the previously linked thread states both, one is obviously incorrect and has the potentially for board damage

I believe it was determined it was a straight-through rather than a null-modem cable. It will not damage anything to try both of those pinouts, reversing your TX/RX is not really potentially harmful.

[bobbyc]

I've noticed on the association screen that sometimes clients will go idle for 5 minutes 58 seconds, and then go to 0 idle time.

Is this normal?

Unlike hermes/prism of V2, there isn't a 'sta removal' field in the atheros AP setup. We've set the sta removal to 4000 minutes or so in the past.

In v3, are my clients just going idle, disconnecting, and reconnecting? The syslog would indicate so.
Bob C

[lonnie]

Yes, that is what is happening.

I've noticed on the association screen that sometimes clients will go idle for 5 minutes 58 seconds, and then go to 0 idle time.

Is this normal?

Unlike hermes/prism of V2, there isn't a 'sta removal' field in the atheros AP setup. We've set the sta removal to 4000 minutes or so in the past.

In v3, are my clients just going idle, disconnecting, and reconnecting? The syslog would indicate so.
Bob C

[lonnie]

We had trouble and we found a solution, and that was the stickers.

I had to deal with guys using their own radios, and they were bottom shopping and expecting to get the results we get. I also got some burnt up boards and the guys admitted to using 4 high power cards. I have observed guys on one list talking of all the various power supplies and cards they were playing with, yet they tried to tell me the board was DOA, meaning they had never even used it. You can't call someone a liar even if you know they are. We had to eat the board. Now when they play around, we know it. Sure I lost some customers, but they were burners anyway. No profit in that type of customer.

If you use your own devices then you are responsible, not us. We have been through this. You know as well as I do that without the stickers nobody would have done anything. What would you suggest we do?

I've beening running BGP for a few months between two Warp board with StarOS V2 and it only seems to use about 1MB of memory or, put another way, the reported free memory drops by this amount when BGP is turned on. Where is the 64MB coming from? You'll be happy to hear that BGP works well on V2. I don't see any reason not to include BGP as an option on the WAR, it's available in Quagga anyway and should be relatively easy to compile into StarV3?

I also agree with Brendan about the stickers on the boards - surely there's a better way to make your warranty restrictions clear rather than risking damage to the boards and annoying customers in the process?

[lonnie]

Responses inline in RED
Ok, Will BGP make the WRAP and PC versions when the time comes?
It might. There will be a Server and Router version again. We figured BGP on a PC with lots of ram could handle it.

It may well be a quagga problem, we just don't know. I feel pretty sure it is a Quagga issue. As I said, we have a new kernel, new driver and the same Quagga, and the experience you have is the same. Quagga is opensource and if you can pin things down enough to file a meaningful bug report with the Quaga developers then I am sure we will be able to get a resolution to this issue. Open Source has little to do with it. Just file your bug report with the info you have gathered.

However, I have never ever seen this issue on any other quagga platform I have used. This obviously makes you feel good to be able say this. You have no apples to apples comparisons so your observation is pretty baseless.

Microtik has a perfectly working and stable OSPF implementation with atheros support using quagga Actually we have seen posts on various lists that indicates this is not exactly the case.
Paul (OscarBravo) is on the quagga developers mailing list and has searched diligently for an existing bug report with similar symptoms, there aren't any similar reported bugs Why have you guys not posted your issues? We don't use OSPF and we thus cannot really post problems. I feel it is best that you post what you are seeing. If I remember correctly, you said the exact issue you were seeing was fixed in .92 and you went to great lengths to get me to drop everything and do a release. You also said .93 had even more fixes for your issue. Now you say there are no reports.

it's in Valemont's interest to pin this one down and it's certainly in our interests to see it resolved. Our offer of assistance in this area still stands


This is a nice feature, well done.


CM9 cards


No ping and no SSH. it is on beta 16 and was not connected to an antenna that cound see much, just sitting here on the bench.
I have not connected to the serial interface nor will I until someone clarifies if it's a straight though cable or a Null modem cable, the previously linked thread states both, one is obviously incorrect and has the potentially for board damage Try a straight cable. You can't harm a serial port with the wrong cable.

I would like to see that clarified with gateworx. I have seen all sorts of damage done to PCB's due to sticker goo. All kinds of boards have all kinds of stickers, and it is not a problem, at least from my experience. You are welcome to ask anybody you wish and nobody is forcing you to buy the boards if you are uncomfortable.
using a backing card would be another alternative ? What is a backing card?
Why do you need them on each slot anyway? Do you not trust us at all? Not really. Let's just say we had some early experiences that prompted the solution. So far it has only been a big deal with a few guys. Most people understand our need to protect ourselves from to much risk.

.brendan

[lonnie]

My responses inline in RED
I agree it makes sense to still include Quagga's bgpd even on a system with only 32M or 64M of RAM. It's up to us as the network engineers/designers to understand that we cannot use it as an eBGP edge router lest we exhaust our system resources, but it is certainly still useful for iBGP just as bminish says. Nobody will misuse it and blame us? Sounds too perfect to me.


I believe it was determined it was a straight-through rather than a null-modem cable. It will not damage anything to try both of those pinouts, reversing your TX/RX is not really potentially harmful.

[bminish]

Lonnie

1/ BGP I am currently using this on my WRAPs in some locations, some of these wraps are 64Mb WRAP boards purchased from yourself. I have no problems running internal BGP.

2/ We never ever stated that a move Quagga v 0.92 would resolve the issue, just that it was a later version and that it was our best shot, It hasn't worked. Perhaps it's time you reread the postings Myself and OscarBravo have made in the OSPF forum in relation to this issue instead of misrepresenting us?

I am unable to file a meaningful bug report with the Quagga developers because Staros is a closed product and I am not able to test a potential fix or capture relevant information that the developers may require to assist in pinning down the problem. Valemont have access to the internals of staros and would the the correct source for this bug report. We will assist if required.

The fact that I have not seen this on other platforms is Very important because it potentially ties this bug down to something that is specific to the way in which staros does things. The previous issues we were able to duplicate on another platform (Bunch of virtual debian machines) and as a result we found a resolution to a number of the major issues in Zebra's OSPF implementation.
Perhaps Lonnie you are forgetting just how much time and effort we have put into this instead of just moving (as others have done) to another wireless router platform that has a working OSPF implementation.

3/ RS232 Cabling, No you won't break anything by getting TXD and RXD the wrong way around however you can break things if you get CTS & RTS mixed up, depending on how well protected the port is.
Is it a straight though cable pin2 to pin 2 , pin 3 to pin 3 etc? Surely Valemont know what the pin out on the port is ?

4/ Goo, I Studied Marine radio followed by electronics to degree level, I have spent around 17 years repairing RF stuff that has been used in similar environments to the places we WISP folks are expecting to deploy WAR boards.
I have seen quite a few instances of sticker goo related damage, generally on boards with wider track spacing and thicker tracks than those on the WAR board.
You generally do not find that OEM's will place stickers anywhere near areas with tracks or components, they place them on areas of no track or groundplane areas, Some Service engineers and systems integrators are not always so careful.
If you must use the stickers then place a rectangular piece of card under both slots so that the sticker only sticks to the slot and to the card.
That way the user still has to remove the sticker before being able to use the slot but the sticker never sticks to the PCB or the chips.
If I don't buy my WAR boards from you, valemont won't sell me V3 to run on them so I really have no choice, which is why I am asking you to consider an alternative to placing stickers directly on the board.

.brendan

[lonnie]

My responses inline in RED.
Lonnie

1/ BGP I am currently using this on my WRAPs in some locations, some of these wraps are 64Mb WRAP boards purchased from yourself. I have no problems running internal BGP.

2/ We never ever stated that a move Quagga v 0.92 would resolve the issue, just that it was a later version and that it was our best shot, It hasn't worked. Perhaps it's time you reread the postings Myself and OscarBravo have made in the OSPF forum in relation to this issue instead of misrepresenting us?
Taken from the Jan 20 thread OSPF bugs are showstoppers again Quote:
Originally Posted by lonnie
First off, you do even know if the new release will fix this

We've implemented 0.99.2 on our (Red Hat) network edge machine. It's completely stable, and has addressed bugs we were seeing with 0.98.5.

I am unable to file a meaningful bug report with the Quagga developers because Staros is a closed product and I am not able to test a potential fix or capture relevant information that the developers may require to assist in pinning down the problem. Valemont have access to the internals of staros and would the the correct source for this bug report. We will assist if required.

But here is what you said:
The Quagga version in question is the current development build, yes it's marked unstable however I have tested it to the extent that I can. We are also on the Quagga development list and will interact as required with the Quagga developers.

The 0.99.3 is tha latest release. Why can't you file a meaningful bug report?

The fact that I have not seen this on other platforms is Very important because it potentially ties this bug down to something that is specific to the way in which staros does things. The previous issues we were able to duplicate on another platform (Bunch of virtual debian machines) and as a result we found a resolution to a number of the major issues in Zebra's OSPF implementation.
Perhaps Lonnie you are forgetting just how much time and effort we have put into this instead of just moving (as others have done) to another wireless router platform that has a working OSPF implementation. Again this has been refuted by other users. The grass is always greener.

3/ RS232 Cabling, No you won't break anything by getting TXD and RXD the wrong way around however you can break things if you get CTS & RTS mixed up, depending on how well protected the port is.
Is it a straight though cable pin2 to pin 2 , pin 3 to pin 3 etc? Surely Valemont know what the pin out on the port is ? I said straight thru. CTS and RTS use the same level translators that the rx and tx do, so no harm can come. Just use rx, tx, and gnd. You really have an axe to grind and I am tired of it. I answer a question only to have you ignore and make some snide comment.

4/ Goo, I Studied Marine radio followed by electronics to degree level, I have spent around 17 years repairing RF stuff that has been used in similar environments to the places we WISP folks are expecting to deploy WAR boards. I have also studied Electronics and have built and repaired gear since 1978 when I graduated. I worked for MOT doing navaids and communcations at Airports. I maintained the very first Microwave Instrument Landing system in Canada and it was one of 12 worldwide. I have not seen the problems you speak of, and I have seen lots of stickers.
I have seen quite a few instances of sticker goo related damage, generally on boards with wider track spacing and thicker tracks than those on the WAR board.
You generally do not find that OEM's will place stickers anywhere near areas with tracks or components, they place them on areas of no track or groundplane areas, Some Service engineers and systems integrators are not always so careful.
If you must use the stickers then place a rectangular piece of card under both slots so that the sticker only sticks to the slot and to the card.
That way the user still has to remove the sticker before being able to use the slot but the sticker never sticks to the PCB or the chips.
If I don't buy my WAR boards from you, valemont won't sell me V3 to run on them so I really have no choice, which is why I am asking you to consider an alternative to placing stickers directly on the board.
The stickers will stay. One alternative is to buy radios already in the slots.

You do have choices for software on the Gateworks and WRAP boards. Roll your own and then you have your beloved Open Source solution with madwifi drivers or use Ikarus. Both of those have their very own driver so you should be quite happy, since you keep saying it is our driver.

.brendan

[bminish]

Taken from the Jan 20 thread OSPF bugs are showstoppers again Quote:
Originally Posted by lonnie
First off, you do even know if the new release will fix this

We've implemented 0.99.2 on our (Red Hat) network edge machine. It's completely stable, and has addressed bugs we were seeing with 0.98.5.



This quote is completely out of context and you know it. We never stated that it would resolve this issue (how could we since we have never seen it outside of staros)
99.3 resolved a number of other issues and dramatically improved convergence times.


The 0.99.3 is tha latest release. Why can't you file a meaningful bug report?

Because I have no access to the internals of Staros, have no idea how you are configuring your Quagga binary at build time and have no possibility of compiling in any suggested fixes.


Again this has been refuted by other users. The grass is always greener.



I know personally of a number of people who have dealt entirely successfully with the OSPF issues that they were seeing under staros by moving to another platform. Is this what you want us to do? In other regards we prefer your platform and have bought a lot of it.


You really have an axe to grind and I am tired of it. I answer a question only to have you ignore and make some snide comment.


I do not have an axe to grind, It was merely a request for clarification.
You can damage wraps this way and this explicitly mentioned in PCengine's own literature on page 9 of the WRAP manual (http://www.pcengines.ch/wrap1c.pdf). Would you replace my WAR board if I killed it this way?


... and I have seen lots of stickers.


Then perhaps you will also have noticed that they are not generally slapped on top of fine pitched PCB traces and SMT components. It's bad practise and could easily be avoided by the use of a small piece of card or heavy paper.

.brendan

[tony]

I was just looking through the Quagga CVS, and have noticed that they have several new OSPF fixes. The ones related to neighbors dropping out, and device up/down problems caught my eyes. The CVS version compiles cleanly, and will include it in the beta-17 release if it is deemed reliable.

For Quagga bug report purposes, the Quagga daemon is compiled with this configure line:
./configure --enable-opaque-lsa

Beta-17 will also include the --disable-ipv6 option.

I will do a release later today if things work out.

[bminish]

I was just looking through the Quagga CVS, and have noticed that they have several new OSPF fixes. The ones related to neighbors dropping out, and device up/down problems caught my eyes. The CVS version compiles cleanly, and will include it in the beta-17 release if it is deemed reliable.


Thank you Tony,
can this at some stage also make it's way back to V2? Our net is V2 except for the 2 WAR boards we are testing.


For Quagga bug report purposes, the Quagga daemon is compiled with this configure line:
./configure --enable-opaque-lsa

that's interesting. I have never built Quagga with this option enabled, it's disabled by default. looking at the Quagga docs it might be possible that a bug in this area of the code could produce symptoms similar to what we are seeing.
Are there currently good reasons for building with opaque-lsa support or could we try without it?
Is V2 built this way also?


Beta-17 will also include the --disable-ipv6 option.

thanks.

.brendan

[tony]

If the V3 testing is successful, we will also include this Quagga release in V2.

There was an issue with early Quagga releases that prevented it from compiling without the opaque-lsa option enabled. We will remove this for the beta-17 release.

[skyclimber]

I have also upgraded my WAR AP to STAROS V3 beta 16 and i have again the N issue. WAR AP radio is a SR2 card. My clients are cb3 NL-3054(prism3) and wrap CM9. They takes about 10 times more than it was with my WRAP AP STAROS V2 to reassociate when rebooting. New installations takes about 5 to 10 minutes to associate with the WAR AP. Some clients went N after few hours or days of uptime. Power Saving is disabled. Cloaking: 1x , Only Short Preamble and InterBSS relay are selected.

STAROS V3 on WAR board never crashed; 7 days uptime.

[tony]

You will get an 'N' on an association entry once in a while during normal operation. This is totally normal. All it means is the association has expired due to no traffic, or the client is currently in the process of authenticating & associating.

[lonnie]

No, I do not know it is out of context. You were trying to push us to do a release with 99.2 and you said it fixed the 98.5 issues. I did not say you said this about the currrent issues, I said that you assured me that 99.2 would fix the 98.5 issues. It is obvious it was not a fix, nor was 99.3. Tony has checked the CVS and lo and behold they have some ospf fixes that sound promising. Please test with V3 and let us know. v2 will not be done until we know for sure this fixes it. It is not a trivial task to do a v2 release. I believe I have said that several times. The system has too many things to break and too many types, all of which have to be tested.

The goo issue could also be resolved by ordering with a radio in the slot. I am not going to extend our cost base and workload to satisfy your fears of a goo problem. In other words, why should we pay extra and do more work just so you can add your own cards?

This quote is completely out of context and you know it. We never stated that it would resolve this issue (how could we since we have never seen it outside of staros)
99.3 resolved a number of other issues and dramatically improved convergence times.


Because I have no access to the internals of Staros, have no idea how you are configuring your Quagga binary at build time and have no possibility of compiling in any suggested fixes.

Then perhaps you will also have noticed that they are not generally slapped on top of fine pitched PCB traces and SMT components. It's bad practise and could easily be avoided by the use of a small piece of card or heavy paper.

.brendan

[skyclimber]

You will get an 'N' on an association entry once in a while during normal operation. This is totally normal. All it means is the association has expired due to no traffic, or the client is currently in the process of authenticating & associating.

Thanks Tony,

I have more customers calling and saying they are unable to surf. Maybe they were expired but it is an issue that i never got with StarOs V2 on Wrap. I have also a WRAP CM9 Client who is also a repeater. I'm unable to manage it when it goes to N state.

Thanks again for you good work.

Louis

[tony]

If you are using this as an AP with an assortment of clients, please ensure you have Short Preamble option disabled and disable Power Saving.

Thanks!

[bminish]

4/ How did you determine it had not booted? ## has a lot of channels and thus it could be real busy with lots of noise. If you have not upgraded to beta16 then noise could be a factor which had been shown to put the unit at 100% and thus it was running but not responding.



Firstly, serial cable.
It is a straight through (pin2 to pin 2 pin 3 to pin 3 etc) cable rather than the null modem cable needed with a WRAP serial port.
serial parameters 115200 8N1

This board boots normally with no radio installed

Here is the boot sequence with the radio installed as captured on the serial port, it hangs at Configuring atheros devices.
Do you want me to capture my settings using starutil before I factory reset this board
Hope this helps with debugging

Valemount Networks ROM BIOS build 184

Copyright(c) 2006, Valemount Networks Corporation.

Loading, please wait: done.

:: Welcome to StarV3 v1.0.0(beta-16) build 980
Enabling ixp4xx hardware watchdog [ OK ]
Initializing ixp42x npe ethernet devices [ OK ]
Initializing atheros (802.11a/b/g) interfaces [ OK ]
Initializing real-time traffic monitor [ OK ]
Initializing bandwidth management (CBQ) [ OK ]
Verifying system configuration [ OK ]

:: System Extensions
Loading vlan (802.1q) support [ OK ]
Loading connection tracking 'helpers' [ OK ]

:: Networking
Probing for ethernet & wireless devices [ OK ]
Configuring atheros devices


.brendan

[tony]

Beta-17 can be downloaded here: http://www.star-os.com/downloads/oem-vnc/vncOs-1.0.0(beta-17).zip

This release consists of the Quagga changes discussed in this thread. Other additions include the ability to assign the auto-auth dhcp server to bridged interfaces.

Please let me know how it works out.

Thanks!

[tony]

brendan, if you can capture the settings, that will be a great help. Please email them to networks@valemount.com

Thanks!

[go.fast]

Is this release just for ospf or does it hve the ping and hardware watchdogs as well?

[tony]

The archive has just been pulled due to a problem found in auto-auth, which has been corrected. The archive with a new beta-17 will be re-posted in a few minutes.

This release was released a little sooner than planned, so the ping watchdog has not been fully implemented yet. The hardware watchdog indicator on the desktop now shows as enabled as well.

This release primarily focuses on Quagga, and the new auto-auth behavior.

[tony]

The new beta-17 release has been uploaded.

[tog]

Nobody will misuse it and blame us? Sounds too perfect to me.

If someone misuses it and tries to use it for eBGP and then whines that they ran out of RAM you have my full permission to "LOLROFL" in their face.

[tony]

Brendan, thank you for sending me a configuration from your system before you restored factory settings to it. I have been able to duplicate your problem and will get it resolved for the next release.

Thanks!

[tony]

There is a new beta-17 (lucky build 1000) that has the '##' 802.11g/turboG fix.

[oscarBravo]

We are also on the Quagga development list and will interact as required with the Quagga developers.

The 0.99.3 is tha latest release. Why can't you file a meaningful bug report? Hi Lonnie - if you're on the quagga-dev mailing list, you'll see that I just posted a report on this subject. I don't know how long you've been subscribed to the list, but I posted a detailed mail on the subject on November 29 last year.

Andrew Schorr (one of the more active Quagga developers) has responded to my more recent mail. It would be great if you could engage in that conversation and fill in any of the stuff I'm not in a position to provide.

[Bossman]

I upgraded a b16 box to b17 with no problem.

Tried to do a b15 box up to b17 and as soon as I entered the password it locked up. Had to power cycle twice and it came up. I backed up the config (thanks for that guys) and tried again. This time from the Ether 1 interface... same deal. Try 3 via an ap connected to the Ether 2... same thing. Try 4 I attempted to do it via Ether 1... I logged into the box first.... uploaded the firmware and as soon as I hit "upgrade firmware" it locked again.

Then... I gave up. Anyone else see this?

[lonnie]

I'll join and see what I can add. As I've said we have very little knowledge of ospf, but I'll see what I can do.

Hi Lonnie - if you're on the quagga-dev mailing list, you'll see that I just posted a report on this subject. I don't know how long you've been subscribed to the list, but I posted a detailed mail on the subject on November 29 last year.

Andrew Schorr (one of the more active Quagga developers) has responded to my more recent mail. It would be great if you could engage in that conversation and fill in any of the stuff I'm not in a position to provide.

[lonnie]

What power supply and radios are you using? Was it in service? Did you kill the traffic through it? That version had trouble with writing the flash if the unit so make sure little or no traffic goes through the unit.

I upgraded a b16 box to b17 with no problem.

Tried to do a b15 box up to b17 and as soon as I entered the password it locked up. Had to power cycle twice and it came up. I backed up the config (thanks for that guys) and tried again. This time from the Ether 1 interface... same deal. Try 3 via an ap connected to the Ether 2... same thing. Try 4 I attempted to do it via Ether 1... I logged into the box first.... uploaded the firmware and as soon as I hit "upgrade firmware" it locked again.

Then... I gave up. Anyone else see this?

[Bossman]

What power supply and radios are you using? Was it in service? Did you kill the traffic through it? That version had trouble with writing the flash if the unit so make sure little or no traffic goes through the unit.

Solar site with the CM9's that it came with. It has been in service for some time without problems. I thought b14 had the traffic issues and that b15 fixed them. I'll try again with killing the traffic. Thanks

[lonnie]

Solar site? What voltage?

[mrmike]

Again, I have 1 client with a realtek chipset that will get into the N state, and stay there. This is a HGA 2400, one of the few I have left in my system. The AP is a small one with just a few cliens on it, but it does have a through link on it, so it isn't idle too long. I think I'll junk that 2400 also.
Anyone want bunch of HGA-2400 for book-ends? Just don't get them cold, they may not even hold up a book then, either.

[jeff]

Cold, hot, who cares. I wouldn't even trust them to hold up books. I'm sure they would find a way to do that intermitantly as well.

Again, I have 1 client with a realtek chipset that will get into the N state, and stay there. This is a HGA 2400, one of the few I have left in my system. The AP is a small one with just a few cliens on it, but it does have a through link on it, so it isn't idle too long. I think I'll junk that 2400 also.
Anyone want bunch of HGA-2400 for book-ends? Just don't get them cold, they may not even hold up a book then, either.

[tog]

Sounds just like the "Aeronaut" realtek thing.

[titan_wireless]

Sounds just like the "Aeronaut" realtek thing.

I can’t get a real feel for those devices. People either love em or hate em. Which is it?

[i20access]

Will beta18 still have ISC dhcp V3.0pl2? Maybe 3.0.4rc1 located @ http://www.isc.org/sw/dhcp/dhcp_dev.php ? Will dhcp-relay be included? When these features are added I will be able to deploy more WAR APs. I have all Prism 2.5 clients so I will be sure to report any compatibility issues I see. I currently have a WAR to WAR 6.5 mile 5.8ghz link with 23dbi antennas on each side (signal on each vaires between -65 to -67) It's running in 2x cloaking and pushes 20mbit+ using the built in v3 bandwidth test. Very impressive and stable, doesn't drop any packets while pushing that. Running lucky #1000 it's been up 5+ days! Hope that V3 continues to be improved.

Sincerely,

Mark Miles
Director of Network Operations
Interstate 20 Access

[go.fast]

I have a prerelease beta that I am testing in field. It has ISC dhcp.

Hope I'm not spilling any beans :)

George

[tony]

The official beta-18 has been released earlier today, and posted on our downloads page.

We do not use developer branches if all possible, and as such, are using isc-dhcp version 3.0.3 (official release).

dhcp relay is not included at this point, however it is something that will be added in the future.

Thanks!

[dc2005]

The official beta-18 has been released earlier today, and posted on our downloads page.

I see the new beta-18 has "added atheros dynamic wds support". I uploaded the beta to a WAR AP and don't seem to be able to find any new options related to WDS? On a positive note, so far I'm very happy with the WAR as a client facing AP, I have one running with a mix of both CM9 clients and a CB3 client and it hasn't missed a beat - uptime over 5 days. I also like the new option to be able to switch off a (temporarily) unused wireless card.

[tog]

tony will probably explain it... Since he just posted build 1061 late last night and then probably fell asleep on his keyboard, give him a little bit :)

Short and simple, though:
To enable WDS capability on your AP, put the AP's interface in a bridge, even if it's just a bridge group by itself.
For example, my AP is all routed so I just put my AP interface in bridge group 9 by itself.

Then on the client, bridge wpci1 and ether1. You should see your client showing up as a "W" instead of a "C" at your AP. You now have a real bridge that you can DHCP through and everything.

[dc2005]

tony will probably explain it... Since he just posted build 1061 late last night and then probably fell asleep on his keyboard, give him a little bit :)

It's the middle of the afternoon over here in Ireland - I think we're about 8 hours ahead of Valemount time so I wasn't expecting an immediate reply! Anyway, thanks for the WDS explanation.

[tony]

Thanks Tog,

Tog's explanation is correct. If you bridge your client, then it will establish a WDS connection with the AP. If you want your AP to accept dynamic WDS connections, it will need to be bridged, even if the AP's card is on a bridge group of it's own.

[kbldawg]

No, the configuration methods differ, and are not compatible. The same starutil can be used for both platforms however.

I will look at making a v2 -> v3 config conversion tool for this purpose.

Just wandering if you have had time to do this yet?

[lonnie]

No, since we do not yet have any v2 to convert to V3 yet. We typically do this in stride with a release.

Just wandering if you have had time to do this yet?

[jacalmeida]

quando realmente saira o star-os, pra pcs, tem alguma previsao, e que gostaria de usar algumas ag530 da dlink que comprei mais o sistema nao reconhece.

[lonnie]

Está indo ser muito logo. Nós começamos o processo de mover o excitador agora que os componentes principais estão completos. Eu não posso dizer quando, exceto aquele nós estamos trabalhando nele como nossa tarefa principal. http://translate.google.com/translate_t

quando realmente saira o star-os, pra pcs, tem alguma previsao, e que gostaria de usar algumas ag530 da dlink que comprei mais o sistema nao reconhece.