Applets failing to load

Now the Monitor applet is failing to load in the browser. There's no error message in the Tools->Error Console and the Java console doesn't load, presumably because no applet is loaded. At this stage I have no idea what the problem is. It works in Applet Viewer, so maybe the signing is faulty. Running any applet in the current browser gives the message that it is simply ignoring applets.

Apparently the reason was that I had openjdk AND sun6 jdk installed. So I had two incompatible versions of java. So I guess the plugin called the wrong java and failed to load the applet.

Although it took ages to load on the testbed (probably because of all the machines it had to detect) it eventually came up and monitored the network.

Running Java Console in Firefox 3.x

There used to be a plugin for the java console. Now you just enable it by running ControlPanel, which is a program in $JRE_HOME/bin. Set "Show Console" to true and you'll get it whenever an applet is loaded in the browser.

Smartflow Demo

The only Smartbits application that came with the Spirent SmartBits 600 was a demo copy of Smartflow. Indeed, if this worked, it would be an excellent way to measure frame loss and throughput of our Vyatta router. However, I can only get it to report 20% packet loss on the first iteration and 100% loss for all subsequent iterations whether you step the load down or up and regardless of the initial loading. That doesn't make sense, unless there is a limitation on the demo copy. So I have given up for now. This program is not marketed any more. It is part of a new SmartBits module which we don't have. And the test methods in SmartWindow don't work either. Too bad.

Connecting together two Spirent Smartbits 600s

In the manual it says to turn on slaves before primary controllers, but that doesn't apply to two controllers, a primary and a secondary. When you connect via the RJ45 expansion ports (OUT to IN) you have to power up the primary first, wait for its status light to come on and then power up the secondary. Then the link light comes on but no trace of the connection in the SmartWindow application. Hmmm.

The Debug Console, which is supposed to show it just comes up blank, with a blank dropdown menu. My guess is that it doesn't work correctly in Windows XP.

Maybe it doesn't matter. If one port of the Spirent 600 can spew out 1GB of data flat out then that should be enough to saturate a 1GB port on any router.

Spirent Smartbits

We have obtained on loan two old Spirent SmartBits traffic generators. They are configured with two 1GB ports on the front, presumably for sending and receiving data. We assigned them IP-numbers successfully but I can't get them to work in a master-slave relationship with the supplied ethernet cable. Maybe that is not he right cable. I will try a straight through cable (don't know about the one I am using but it's not cross-over). There is only one application that comes with it to do anything. It is rather out of date, but it is also not made any more by Spirent. It is a 30 day trial license, which should be enough. SmartFlow sends traffic through the Device Under Test or DUT and measure the latency and frame loss. The flows are variable to some extent but the way it works is that it packages up the packets with sequence numbers, time sent etc, so it can see (in the UDP case at least) how many packets got dropped, and in all cases how long they took to come back. I don't know how to do it yet but it would be a good way to test the maximum throughput of the testbed. We need to write down the results because it should become part of a paper. The only problem may be that the modern equipment we are using won't be able to be outpaced by the SmartBits generators. If so, then we can't get it to drop packets, and won't be able to measure maximum throughput.

The manual keeps warning you not to connect cables without Ferrite Blocks. I bought one for $3.00 from Dick Smiths at Buranda, but it seems we need perhaps two more to actually do the tests. (One is needed for the monitoring cable). Otherwise there is a risk of blowing out the ports. Hmmm.

Resizing Applets to Fit a Portlet

If the user resizes a window, or if he/she has a big enough screen, then the graph applet that does most of the monitoring won't look very good. To make it resizeable automatically requires some Javascript:

function resizeApplets()
{
    var i = 0;
    var applets = document.getElementsByTagName("applet");
    for ( ;i!=applets.length;i++ )
    {
        var width = applets[i].parentNode.offsetWidth;
        var height = applets[i].getHeight();
            applets[i].setSize( width, height );
        applets[i].width = width;
        applets[i].height = height;
    }
}

In this routine I look for all the applets on the page, and get the height and width of their immediate parents. Then I set the applet width and height to those values. Note also that I have to set the width and height in the HTML independently, so that the browser will know that the Applet is actually of a different size to what it was originally. (An Applet inherits all the public methods of the Java Applet class by the way). The disadvantage of this approach is that the height won't get changed, but perhaps we could feed in a new height from a form in the portlet. Hmm. I'll think about it. What we do with this is call it using the onresize and onload attributes for the body element. Then it gets called at the right times.

So it works on 64 bit Linux

So it all works also on 64 bit Linux. Tomcat is still 32bit and it works but I had to recompile the monitor applet for 64bit (not sure if it was really necessary) using the 64 bit version of Eclipse, and also install the java plugin explicitly. Just installing the jdk is not enough using Synaptic. Now for adding SNMP!

Differences between AppletViewer and the browser

Applet Viewer and the browser provide different JAVA environments for the applet, and as such they render differently. For example, in AppletViewer I get higher buttons and menus and no contents on the menu, but it works fine in the browser. Sometimes I hate swing.

Handling non-functional protocols

If a particular protocol/host combination is inactive, for example, if you choose HTTP but there is no web-server at that address, then the graph should clear and display an error message on itself. Then when the user chooses a working combination it should restart and adjust the top and bottom limits of the vertical scale, which it is not currently doing. The result is that when you change from PING to HTTP and it works, then the trace is off the bottom of the scale, because HTTP is less responsive in packets per second. I'll fix that after lunch, and try to add SNMP today.

Loading applets into portlets

There used to be an old JavaAppletPortlet in Jetspeed 1 but it fell into disuse and hasn't been updated. After trying to resurrect it for a while I realised that all you needed was an instance of FilePortlet, and then point it to a bit of HTML containing an applet. All a portlet does at the end of the day is generate a bit of HTML. So where do you put the applet to make it see it? I eventually got it to work out of an applets folder that I added to the root directory of the dostf webapp. Then I can refer to it as codebase="http://localhost:8080/dostf/applets/". That wasn't intuitively obvious, but it worked. Now the problem is just that I am defaulting back to PING when HTML probing fails, but silently. In reality not many hosts will support HTTP, and I ought to display nothing or a message saying that the host doesn't support that protocol, not revert to PING and pretend that it is really HTTP. But I'll fix that tomorrow.

Running dosTF within Jetspeed 2

OK, now it's working fairly well. I have customised the Jetspeed theme, giving it some more readable fonts and different colours. Next step will be to actually wrap my Monitor applet in the Applet portlet. Then the website will need a bit of structure.

Reconfiguring Tomcat for Jetspeed

One modification of Tomcat made by Jetspeed, which perhaps it shouldn't make, is the adding of the following lines to server.xml in the conf directory:

<!-- deployed Apache Portals Jetspeed/APA listener to initialize logging directory system property -->
<Listener className="org.apache.portals.applications.logging.tomcat .LoggingPropertiesServerListener"/>

Without this line the variable org.apache.portals.logdir is unset and as a result it tries to access jetspeed-specific log files located at <blank>/, or /, aka rootdir, which it can't.

There is another modification in conf/Catalina/localhost/dostf.xml (of course the 'dostf' and 'localhost' components may vary), which specifies where the jetspeed database is located. Unfortunately it won't load the database I created after customisation of dostf, nor the working copy of dv's database. These files really shouldn't hold any information about the customised application. Also there are libraries added to the lib directory of tomcat by jetspeed. Presumably because they are needed for all jetspeed applications. Copying this to a commercial webserver would thus be impossible.

At the moment it objects that the 'Table/View PORTLET_APPLICATION doesn't exist'. No idea yet what that means. It seems to find the database itself, but not a specific table within it. However, when I swapped my dosTF database with that provided by another Jetspeed application, it worked.

NICs in Optiplex 960s (Small Form Factor)

Since the dos testbed requires both an attack network and a monitoring network, which are wholly separate, we need a second NIC in each of the four Optiplex workstations. The problem is that the PCIe slot is already taken up by the DVI graphics card. Dell recommend that we use a Broadcomm gigabit card in the PCIe slot, and don't say what to do with the remaining PCI one. We tried a low profile DLINK card, of which Gleb found four examples, but the machine won't then boot. A full size Intel card though did work, but then we can't close the case. We're going to try an Intel Pro 1000 GT low profile card, at $40 a go. If one works we can buy another three.

Non-drawing (J)Panels in Applets

I rewrote the Monitor applet, which displays a graph updated every second. This displays the performance of a particular machine in a convenient applet that can be wrapped up as a portlet and rearranged by the user on a webpage. Unfortunately I couldn't get it to draw. It worked, but the paintComponent calls came in with a 'device clip' only 10 pixels high, so preventing most of the graph from drawing. The reason was that I had failed to override the getPreferredSize() method for my subclassed JPanel. I only overrode getSize(), getHeight() and getWidth(). From memory getPreferredSize() is the one Swing uses as the canonical size of the panel. Once I copied the getSize() code into getPreferredSize() it all worked. Doh!

NTLM Proxy

Since we use an NTLM proxy I can't use Maven, because it can't work through it. Damn!

Applet Portlet

There's already a portlet for Jetspeed that displays an applet. No work to do there, I hope. Just configure it :).

Plan of work

So the idea is to add SNMP querying to the Monitor application so it can dynamically retrieve and display information using SNMP or whatever in the browser. Then, make it into a portlet and display it in Jetspeed. Cool, what?

Transparency of the SNMP interface

We could have the SNMP calls hidden from the user. For example, a request for memory utilisation on a machine could be sent over SNMP and a request for HTTP load would not. Either way the user just perceives it as a request for information about a machine through a graphical Java interface. All that is required is for a machine to have the SNMP daemon or service installed in the testbed, then the information is simply available.

Writing an SNMP Java Client

I was surprised on Friday to discover that NSClient++, which collects private information from Windows PCs for Nagios, is essentially useless. You can already install a free SNMP service that can provide any information you might need to know about a machine. The Nagios author claimed that SNMP was 'anything but simple', but it seems that he just didn't consider the possibility of integrating it into Nagios at an early stage. Now he has support for SNMP traps, whatever they are. But he doesn't need NSClient++ – it's redundant. What a waste of time for me to write my own service to supplant NSClient++ for the dos monitoring! I feel deflated but I need to have something working soon, and the good news is that writing an SNMP client in Java should be easy.

Strange how I was hired to write C code with no mention of Java but I am finding it difficult to justify the writing of any C code :). It seems that all the necessary C parts are already written. If they had hired someone else with just C skills they would be washed up now. Luckily I know quite a lot about Java.

JetSpeed 2

The possibility exists for porting the dosTF application to Jetspeed 2. It would be a neat container for dosTF because it would allow me to create and configure the layout of multiple instances of the one portlet, say the public monitoring portlet, with the graphical interface. The users could even do that. The alternative is to develop a usable interface by response with users. I kinda prefer leaving it to them. The scenario file could also be rewritten as another portlet. Then the whole application could be a collection of custom portlets, which is what I had in mind at the start but didn't have the infrastructure for. I also get login and customisation of the interface appearance for free.