v2.01.8-rc4 build 4669 is ready for testing

[tony]

Do not apply this update unless you have easy access to the system in question. Always backup your configuration before upgrading.

Read the previous release notes before applying this update.

Changes since v2.01.7:
*) core components have been updated
*) ssh server has been upgraded to openssh v4.2
*) ssh logging has been reduced.
*) syslog server no longer shows --MARK-- lines if redirected to a remote server.
*) small atheros update to resolve an optimization problem introduced in an earlier build.
*) zebra 0.95 (rip, ospf & bgp) has been replaced with quagga 0.98.5
*) rip, ospf and bgp are no longer disabled during 'activate changes' (problem was introduced in rc1)
*) iptables marking, layer-7 and connlimit features are available for use via the firewall passthrough
*) cbq now supports gre, esp, ah, and vpn protocols. (vpn will match any packet with gre, esp or ah protocols)
*) cbq 'all' protocol for shape, and qshape now catches all ipv4 protocols, and not just tcp, udp and icmp

Release Caveats:
*) none

[tony]

BETA downloads are now available.
Areas of focus while testing this release are:

*) ensure this release works on the same hardware as previous releases.
*) atheros stability and performance compared to the past 2.01.5+ releases.
*) rip, ospf and bgp testing.
*) iptables layer-7, mark and connlimit testing.
*) cbq gre, esp, ah and vpn protocol shaping options.
*) overal stability compared to previous releases.

Please post your results in this thread. Given the test results from the areas listed, either a new beta will be released, or this version will be renamed to 2.01.8 build 4669 and made public on our website downloads page.

Router WRAP Edition
http://www.star-os.com/downloads/oem-vnc/strrw-2.01.8-rc4-4669.bin
http://www.star-os.com/downloads/oem-vnc/strrw-2.01.8-rc4-4669.raw
http://www.star-os.com/downloads/oem-vnc/strrw-2.01.8-rc4-4669.iso

Router Desktop Edtion
http://www.star-os.com/downloads/oem-vnc/strr-2.01.8-rc4-4669.bin
http://www.star-os.com/downloads/oem-vnc/strr-2.01.8-rc4-4669.raw
http://www.star-os.com/downloads/oem-vnc/strr-2.01.8-rc4-4669.iso

Server Desktop Edition
http://www.star-os.com/downloads/oem-vnc/strs-2.01.8-rc4-4669.bin
http://www.star-os.com/downloads/oem-vnc/strs-2.01.8-rc4-4669.raw
http://www.star-os.com/downloads/oem-vnc/strs-2.01.8-rc4-4669.iso

Router Routerboard Edition
http://www.star-os.com/downloads/oem-vnc/strrb-2.01.8-rc4-4669.bin
http://www.star-os.com/downloads/oem-vnc/strrb-2.01.8-rc4-4669.raw
http://www.star-os.com/downloads/oem-vnc/strrb-2.01.8-rc4-4669.iso

Router Soekris Edition
http://www.star-os.com/downloads/oem-vnc/strrs-2.01.8-rc4-4669.bin
http://www.star-os.com/downloads/oem-vnc/strrs-2.01.8-rc4-4669.raw
http://www.star-os.com/downloads/oem-vnc/strrs-2.01.8-rc4-4669.iso

[oscarBravo]

*) zebra 0.95 (rip, ospf & bgp) has been replaced with quagga 0.98.5
*) rip, ospf and bgp are no longer disabled during 'activate changes' (problem was introduced in rc1) Cool. As a matter of interest, does 'activate changes' still restart the routing daemons?

[tony]

They are still restarted, and should behave like past releases.

[oscarBravo]

Hey, did you know it's a bad idea to upgrade a desktop system with a WRAP image? Whoda thunk... :) I hereby reiterate my feature request for a warning when you attempt to upgrade to an incompatible distro ;)

I'll have to remember to get more than four hours' sleep when reflashing StarOS routers. I even checked and double-checked that I was using the WRAP image, completely forgetting that the system in question runs on a mini-ITX board.

Leaving all that aside, it's now running rc4. Unfortunately, this is a standalone system that isn't running OSPF. I don't want to update any of our live boxes just yet, and Brendan is on a sailboat off the coast of Norway so I don't really have access to the test lab. I'll keep an eye on the stability of the system in general - Brad, have you updated to rc4 yet? If so, how's it behaving?

[bradg]

Brad, have you updated to rc4 yet? If so, how's it behaving?

I took a partial plunge last night and I can report that when I reboot/activate changes on a router in the middle of the network, huge chunks of the network no longer go wonky.

I do have one host that spoadically won't come back to life, but it's a Soekris net4801 that's running 2.01.7 with the Zebra OSPF core on it. I haven't had time to dig into that one quite yet, but probably going to do the deed and upgrade it on Monday and not bother digging for right now.

I'd upgrade that box right now, but it's got two Lucent COR's connected to it via crossover cables, and somehow in the reboot process the COR's (one is a WP II, the other is a WP IIe model) won't negotiate an ethernet link to the Soekris box again. I'm almost certain it's a 10/100Mbps full/half duplex issue, but as we don't have the ability to nail an ethernet port to a specific speed or duplex (yet), the fix is to reboot the COR's after the Soekris is rebooted. That's a royal PITA that I'm planning on fixing this fall by ditching the very last of the Karlnet gear (oh, I'm going to celebrate that day - Karlnet/YDI/Terabeam/Proxim screwed it's customer base so bad, it nearly makes my blood boil...).

Anyway, rant off. Short answer - so far, so good!


Brad

[ninedd]

Hey, did you know it's a bad idea to upgrade a desktop system with a WRAP image? Whoda thunk... :) I hereby reiterate my feature request for a warning when you attempt to upgrade to an incompatible distro ;)I agree. More than once, I've been doing mission critical things at the end of a 20 hour day (that itself is at the end of a 80 hour week) and a warning of some sort, in red.... bold... would be nice.

Perhaps even just when we select UPGRADE FIRMWARE, if it told us the existing and new 'types' and said something like...

Verifying uploaded firmware file:
[oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO] - 14811136 (14464K)

Old firmware v2.01.7 (Build: 4590) WRAP VERSION
New firmware v2.01.8-rc4 (Build: 4669) WRAP VERSION
New firmware size: 14464KB
Target flash size: 15872KB
Ready to flash server, do you wish to continue? [y/n]: Y

Do you wish to preserve your settings? [y/n]: Y
Flashing.. Settings will be saved.

[tony]

This is something we can look into for sure. I'll see about having this feature as part of a new BETA.

UPDATE: Feature has been implemented, and will be available in the next release (beta or final).

[oscarBravo]

*\o/*

[mmc1800]

I am going to go ahead and upgrade all the radios that I have running OSPF with this image and I will report on the differences.

Thanks for making these changes (I think this is a major step in the right direction for OSPF reliability). I will see if I can get any useful information back to you.

--MMc

[mmc1800]

I have only had 2.01.8-rc4 online for a few hours now, but I am already seeing some of the same behavior with OSPF.

I had a radio where OSPF was showing turned off (no yellow highlighted OSPF in the Service Summary list) and needed to have the "advanced routing" window opened so that OSPF would restart itself (don't need to click anything, just open the window and OSPF realizes it is off and restarts itself).

Also had several radios go into states where they showed OSPF on, but had no routes out to neighbors and turning OSPF off and on seemed to fix the problem (I did not wait to see if the ping watchdogs would have reset them).

If anything the problems seem a little more common now, but in all fairness I did just restart all the radios on the network a few hours ago while doing the firmware upgrades and that kind of thing has always set OSPF into fits, so it is possible they are just the same.

On the plus side, routes do seem to show up a few seconds faster when OSPF is first starting, and they do seem to respond sooner after "apply changes".

I played with the settings with the Zebra version for months to get them working as well as I could (still require a lot of baby sitting to keep things up), so possibly there are a few tweeks and twists to help this version as well.

I would really love to see some kind of watchdog that restarts OSPF. If that existed then it might be possible to use the combination of the ping watchdog and the OSPF watchdog to actually make sure the network is working automatically most of the time. Currently the ping watchdogs do part of the job, but eventually for some reason there always ends up being a radio that shows OSPF being off in the service summary, but can still ping through to a host that it should not be able to ping without OSPF routes and the ping watchdog doesn't reset the radio.

My strategy is to set the ping watchdogs to ping a host that is a couple of hops away that cannot be reached without OSPF then if for some reason OSPF stops working it should reset the box, but unfortunately this does not work all the time. The boxes with OSPF showing off can still ping out if a direct RF neighbor has OSPF working, but the radio no longer advertises its own routes so the subnets it is supposed to advertise are unreachable, and they stay that way until someone logs in and opens the advance routing control window and OSPF restarts.

The ping watchdog usually in general will reset the radios that have OSPF showing on, but seem to be in a confused state, but when they reset themselves they have a tendency to cause another radio to go into the OSPF off state somewhere close by. So I have the ping watchdogs set at 10 minutes and someone has to always be around to respond to the pages when the radios go offline before they reset themselves, or else more problems usually pop up. I have enough redundant routes on the network now that usually one or two radios having no routes will not bring down any customers, but of course eventually it is a radio that directly connects to customers that looses its routes, and that is a problem.

I of course have not had time to work the details of how the quagga version compares to the zebra version in frequency etc., but I have seen both behaviors already with the new beta (all of my finger crossing didn't help any I guess).

I am interested to hear how others are getting on with this beta, I am really happy to see this issue getting some attention. An OSPF watchdog might be very helpful.

*bows to Lonnie --

--MMc

[tony]

The Quagga watchdog for rip, ospf and bgp has been implemented, and will be in the next release.

[bairdc]

I have only had 2.01.8-rc4 online for a few hours now, but I am already seeing some of the same behavior with OSPF.


I'm disappointed to hear this. I was really hoping that our OSPF trouble would be fixed by a switch to Quagga. I've got the rc2 beta running on a couple of machines. It has worked fine, but I haven't yet put it in a spot where I can really see if the OSPF problems are resolved. I'll probably do this in the next few days. Based on what mmc1800 has said, it looks like the problems may be still there. I know that bradg posted some positive feedback on OSPF in the beta releases. Is there anyone else who can report results on OSPF stability in the beta?

Craig

[oscarBravo]

I have only had 2.01.8-rc4 online for a few hours now, but I am already seeing some of the same behavior with OSPF. Bummer :( I had a radio where OSPF was showing turned off (no yellow highlighted OSPF in the Service Summary list) and needed to have the "advanced routing" window opened so that OSPF would restart itself (don't need to click anything, just open the window and OSPF realizes it is off and restarts itself). Tony's inclusion of watchquagga should address these. From what I've seen of watchquagga, it generally restarts a daemon before the routes expire in the neighbours' routing tables, which should mean a fairly seamless restart. Also had several radios go into states where they showed OSPF on, but had no routes out to neighbors and turning OSPF off and on seemed to fix the problem (I did not wait to see if the ping watchdogs would have reset them). I'd like to see the OSPF state information for a router in one of those situations. I am interested to hear how others are getting on with this beta The timing is unfortunate. I'm really not in a position to experiment with this with Brendan out of the country. I am really happy to see this issue getting some attention. Likewise.

/applauds.

[tony]

The new rc5 release has been posted, please let me know how it works out.

[ninedd]

a warning of some sort, in red.... bold... would be nice.
Perhaps even just when we select UPGRADE FIRMWARE, if it told us the existing and new 'types' and said something like...

Old firmware v2.01.7 (Build: 4590) WRAP VERSION
New firmware v2.01.8-rc4 (Build: 4669) WRAP VERSION
This is something we can look into for sure. I'll see about having this feature as part of a new BETA.
UPDATE: Feature has been implemented, and will be available in the next release (beta or final).I gotta say Tony, this really impresses me. :) The responsiveness and willingness to incorporate ideas from the community is great. Frankly, that's exactly what this makes a guy feel like - like he's part of the StarOS community. Thank you for not only taking the time to read our bitching and moaning in the forums, but to understand what it's like to be hunched over a machine doing firmware upgrades. I've got a mixture of WRAP's and PC's and this little addition will help prevent me from making a mistake some day at 3 AM, and for that future now-not-never-gonna-happen mistake, I thank you in advance. :)

- Todd

[oscarBravo]

What Todd said, and what Michael said in the other thread. I know it must have been a bit like having a tired kid in the back of a car ("are we there yet?"), so after all my whining I'd like you to know we appreciate the work.

[ianek]

Hello,
please is it MIPS edition (RB532 ) or other RB edition ?
Thanks

Jan

[tony]

This is the Geode (x86) routerboard edition.

[tony]

Inet2000 / OscarBravo,

I really appreciate your feedback. The new release should be a large improvement over the previous 2.01.7, and should hopefuly clear up many of the problems people have been having.

Thanks!

[phendry]

The new release should be a large improvement over the previous 2.01.7
Are there performance improvements too? I haven't tried any of the betas as we don't have any issues at present however if there are speed or delay improvements to be had then I will ;)

[tony]

No, I do not believe any of the changes would result in a performance gain. The main focus with this release has been with Quagga, and the re-introduction of layer-7 and other missing features.