[SJF Logo]
Steve Friedl's Weblog

April 28, 2003
Compiler author with sense of humor

I'm doing maintenance on a bit of customer software, and it's written in BASIC. We're using the PowerBASIC command line compiler - which supports Visual Basic with extensions. While browsing through the help file to figure out how to do something, I came across the #BLOAT keyword. Intrigued, I found that these guys were taking a shot at Microsoft as part of the language.

Gotta love a vendor with a good sense of humor. (click the image for the whole help file entry)

[#BLOAT keyword]

Posted by Steve at 12:48 PM
April 27, 2003
SpamAssassin patches: UNIX domain sockets

I'm a very happy user of SpamAssassin, having integrated it into Postfix. I am also using the spamc/spamd system, and it's been working great on my system and that of two customers. SpamAssassin just rocks.

I have made a couple of patches to version 2.60 (the development release) that I've been using for a couple of days now, and I'll be submitting them to the project once I have a bit more time on them.

Change #1 is to support UNIX domain sockets for spamc/spamd communiations. The current program uses TCP/IP to send the message from the client to the daemon, and to get the reply, but when the client and server are on the same machine, a faster version of IPC is available. UNIX domain sockets avoid all the TCP/IP overhead, and by my testing run 3-4 times faster than even IP via localhost. This IPC uses a filename for rendesvous (say, "/tmp/spamd.sock") instead of a port number, and running "netstat -an" will reveal several UNIX domain sockets.

Change #2 performs randomization of the list of IP addresses obtained from DNS when the client is talking to the server. A DNS name (say "spamserver") can contain multiple IP addresses, and it would be a kind of load balancing if a slow mail server is able to talk to several SpamAssassin servers. The -H command-line parameter to spamc will randomize the list of IP addresses and attempt to connect to them in order. This was suggested by Jeremy Zawodny, and it turns out that the changes for UNIX domain sockets meant this was easy.

All through the spamc code, the IP-related functions refer to hostname+port number, but I have replaced all these calls with a reference to a "transport" structure: this object contains either the list of IP addresses or the path to the UNIX domain socket. In the process, the code that dealt with making connections and fallback was much simplified: "doing fallback" is no longer a special case.

Those curious to apply this patch to version 2.60 (bleeding edge) can find the code here:

Posted by Steve at 08:26 PM
April 19, 2003
Netopia-to-Sonicwall VPN

I've long been a fan of Netopia routers and Sonicwall firewalls, and many moons ago I wrote a Tech Tip on setting up an IPSec VPN between them, but it used manual keys as that was all Netopia supported at the time.

Steve Gardiner has managed to get a Netopia on a dynamic IP address to talk to a Sonicwall using IKE shared secrets, and it was no small feat. Tons of trial and error, plus lots of wasted time with Netopia and Sonicwall tech support, and he finally figured it out. I've taken his extensive notes and turned them into a Tech Tip. The overwhelming amount of the hard work was done by him, I've simply formatted it nicely and taken some screen shots. But it works really well.

Dynamic Netopia-to-Sonicwall IPSec VPN using IKE

Thank you, Steve.

Posted by Steve at 08:43 PM
April 17, 2003
Tech Tip: Setting Windows CMD prompt properties

I have long found the default font properties for Windows CMD prompt to be hard to read, so we've taken to modifying the properties to make them more ot our liking. This can best be seen by this comparison of the default 8x12 raster font with 18 point Lucida Console bold:

comparison of screen fonts

The procedure for doing this doesn't seem to be widely known, so I've written up a Tech Tip that describes how they're configured.

Tech Tip: Setting Windows CMD prompt properties

Posted by Steve at 10:28 AM
April 15, 2003
Toot Toot: "Analyze This!"

Never shy to blow my own horn: The May 2003 issue of Linux Magazine has my feature article "Analyze This!" on doing network vulnerability testing. This includes information on , and the latest version of Nessus (version 2, which just came out). This will be posted in full to the L-M web site three months after the cover date.

Also in this issue is a great article on the Border Gateway Protocol by my friend Jeffrey Papen - I helped a bit editing this article. A great introduction.

Posted by Steve at 12:59 PM
April 09, 2003
Understanding 802.11b "channels"

While trying to get a handle on the insides of 802.11b wireless operations I turned my attention "channels" - just what are they? This technology uses spread spectrum, and each channel is a range of frequencies 22MHz wide, and the channels overlap each other. From the text tables that showed the channel center frequencies I was able to construct this diagram that shows their arrangement (click for larger image):

802.11b channel assignments

When picking a channel, first see what your "neighbors" are using> pick a channel that overlaps the least with them. Note that the US uses only channels 1-11, and other jurisdictions can use up to the 14 channels defined by the spec.

Posted by Steve at 10:26 AM
April 06, 2003
Wireless: enable power-saving mode!

Most PCMCIA wireless cards provide a "power saving" mode, and I was suspicious of just what could be done to save power this way, but it turns out to be a bona fide win. The 802.11b protocol itself designed in a kind of "polling" mechanism, so a card going into power-conservation mode wakes up periodically to listen for a "you have traffic" message from the wireless access point. This looks to be an integral part of the design, not a hack or an afterthought.

When the card sees that the WAP has traffic, it turns the radio on fulltime until all the buffered data has been received, at which time it goes back to power-saving mode. Some tests have shown a 1000% power saving, though I suspect this is only saving the power to the receiver, not the transmitter. But it's still something.

I enabled power-conservation mode on my Orinoco card, and it appears that these "Traffic Indication Map" polls happen a dozen or two times per second, and the radio is clearly off most of the time even when I have my streaming music on.

But I cannot see any performance difference - even secure shell to a remote Linux box has zero added latency: it's still totally crisp response. It may be that online gamers couldn't tolerate what I imagine are a few milliseconds of added latency, but I'm still getting <10msec ping times to my access point and cannot find a single downside to this.

Power-Conservation Mode really works.

Posted by Steve at 06:41 PM