v2.01.8-rc3 build 4668 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
*) 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 4668 and made public on our website downloads page.

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

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

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

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

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

[luka]

Surfing around I was found some openbsd modifications for wrap, announcing lm77 temperature sensor support. Can similar be built in staros in some of further versions?

[tony]

This could be a possibility, will have to look into it.

[bradg]

Well, I upgraded 4 WRAP's in a "chain" out to a key site, and OSPF came up and worked just fine.

What I did was upgrade them all, then used a shell script with starutil to reboot each one of them, beginning with the furthest out and working all the way back to the main site, with a 5 second delay between reboots. That appeared to work perfectly, the network converged (OSPF), and data flowed fine. In fact, it could be my imagination, but it appeared to converge quicker than it did before.

However, when I do an "activate changes" on the second from the end unit (which will be hosting another link to another new site going live this week), that unit and everything behind it goes dead, and that WRAP cannot be reached over the "full" network from either side on the ethernet or wireless interface IP's (Atheros radios).

However, I can SSH into a WRAP unit "next" to it via wireless or ethernet, use the Star-OS SSH client to go across the network to the unresponsive unit, and login fine. I then go to Routing - Advanced Routing, and "Enable OSPFv2" is checked, but it shows up as "STOPPED" for about 1/2 to 1 second, then it goes to "STARTED", and within 15 seconds data starts to flow again.

It's acts like an "activate changes" doesn't properly restart the Quagga process(es), and when I go to look, the system realizes it *should* be running (and isn't) and then starts it properly.

I have seen similar behaviour in previous (Zebra) releases as well. But this one is perfectly repeatable, happens every single time I do it, and all I have to do is "look at it" (literally), and it's magically fixed :)

Let me know if you want access to that set of systems, and I'll privately email access info to you.


Brad

[tony]

Thank you for the update. I will have that issue you mentioned resolved right away, with an update posted later today.

[oscarBravo]

Potentially related to this issue, there's a daemon that can accompany the quagga daemons, called "watchquagga". It tries periodically to connect to each of the quagga daemons through the vty interface - if two consecutive connection attempts fail, it restarts the daemon.

I'm guessing there's a fairly simple explanation and fix for the problem Brad describes (and yes, we had seen similar behaviour in the past ourselves), but something like watchquagga could be a useful tool to include also.

On the subject of Brad's problem, we more or less figured out what was happening before. We had a situation where both Brendan and I were logging onto routers trying to work out configuration issues. One of us would open the "advanced routing" dialog, start ospfd, and enter the configuration terminal. Then the other would come along and open the dialog again - because changes hadn't been saved, the "Enable OSPF" checkbox would be unchecked, and the daemon would be killed by the UI.

We still see situations from time to time where the daemon has died, but opening the advanced routing dialog restarts it.

[tony]

Thank you for the information.

[i20access]

Today I upgraded a Desktop Server with the .bin image, but had to hard reboot it after the upgrade. It is working fine now. Upgraded a soekris unit next, after it wrote 2.01.8-rc3 to the flash and I rebooted - it never came back up. I went to the site and hard rebooted it, with no luck. To resolve this, a tower climb with a flash card containing 2.01.7 on it was necessary. Soekris users, you've been warned.

Best of luck,
Mark

[tony]

What soekris board are you using? (processor, and the number of pci / pcmcia sockets)

[i20access]

The board in question is a net4521 with 2 pcmcia slots and 1 mini pci. Processor is a 133 Mhz AMD ElanSC520. Unfortunately I am not sure I can afford the downtime of trying another image (and having it fail), but I will happily try again one once we replace it with a WAR board.