Monday Sep 03, 2007

Spirent Avalanche 2500

One of the unique and important pieces of network test equipment that we use is the Spirent Avalanche 2500.

From the FAQ:

What is Avalanche 2500?
Avalanche 2500 is an award-winning capacity assessment tool that challenges your networking infrastructure and applications to stand up to the load and complexity of real-world traffic. It delivers performance, realism, a wide range of protocols and ease of use in a single, easy-to-deploy appliance. Avalanche 2500 helps you determine the performance capabilities, bottlenecks and points of failure of a single device, a network or a complete end-to-end system.

Here's a good screenshot of the analyzer application that I got from this web site.

The Avalanche has been useful to us from a network stress testing perspective, especially to simulate FTP and HTTP scenarios. In conjunction with SmartBits, we're able to provide excellent network stress testing at the most critical portions of the networking stack, for relatively low engineering overhead.

Monday Aug 13, 2007

Tomato Firmware

One of my Solaris quality engineering team's responsibilities is to develop tests for x86 WiFi. Because of our involvement in WiFi, I recently learned about Tomato Firmware.

From the Tomato Firmware web site:

Tomato is a small, lean and simple replacement firmware for Linksys' WRT54G/GL/GS, Buffalo WHR-G54S/WHR-HP-G54 and other Broadcom-based routers. It features a new easy to use GUI, a new bandwidth usage monitor, more advanced QOS and access restrictions, enables new wireless features such as WDS and wireless client modes, raises the limits on maximum connections for P2P, allows you to run your custom scripts or telnet/ssh in and do all sorts of things like re-program the SES/AOSS button, adds wireless site survey to see your wifi neighbors, and more.

This wiki has a bunch of useful information on Tomato. I'd recommend for anyone interested in WiFi to take a look and try this firmware out.

Also be sure to check out Wireless Networking for OpenSolaris.

Monday Jul 02, 2007

Network Auto-Magic

One of the projects we recently started staffing in my Solaris networking Quality Engineering (QE) test development team is Network Auto-Magic. The concept is to provide an easy way to do network configuration, especially for machines that change frequently change their locations, like laptops.

After updating my laptop to the most recent Solaris Nevada build recently, I used the opportunity to install the Network Auto-Magic package from So far it has made using Solaris a lot easier. The user experience is much more straightforward.

Previously you'd have to do a manual ifconfig or use a Sun company-internal GUI-based network configuration tool every time you boot up and connect to the network. Now, things are done automatically by the Network Auto-Magic Service Management Framework (SMF) service. The laptop user experience that I've had so far is similar to Windows XP in that regard, you just plug into the network and you're connected. No more clunky ifconfig plumb commands.

So far the Network Auto-Magic project is still under development, but even at this early stage, I think this is a great way to increase our Solaris laptop user base.

The screenshot above is from this presentation.

Tuesday Jun 21, 2005

Gaining insight on IPFilter "block return-icmp" rules

Recently I needed to verify some "block return-rst" functionality in Solaris IPFilter. I learned of a way to easily test these type of rules using 2 servers. The procedure is as follows:

Equipment required:

2 servers, A and B, that area able to connect to each other.
Server A: any type of machine
Server B: running Solaris 10 and has IPFilter enabled for the active network interfaces. Its IPFilter rule file contains a line with "block return-icmp in on <interface name> proto tcp from any to any port = ssh flags S/FSRPAU". <interface> is the NIC that will be used for traffic to and from server A.

Steps to activate the rule:

1. On server A, connect to the SSH port with "telnet <server B> 22"

2. Server A will eventually time out due to the "block return-icmp" rule that was added.

Interesting live debugging:

1. On server B, run "ipstat -hi" to verify that the "block return-icmp" rule was activated by the SSH request.

2. Use tcpdump, Ethereal, or snoop to view the traffic exchange:

tcpdump -nXvvvi <interface name> -s 1536 tcp port 22

3. Use truss to view the callstack of the running pfild process: truss -p -t sendto -x sendto -v all -r -w -D <process number of pfild>

Examining the tcpdump and truss output should give you a good idea of how return-rst and return-icmp rules work and how your firewall configuration may benefit from them.


Oracle Solaris: Security, Networking, and Quality Engineering


« July 2016