Mar 01

IPSec VPN Between PIX and SonicWall

This post is mainly so there is a record of these error messages and what they might indicate. It’s also to help out others so they don’t shoot themselves in the foot as I did. I found no matching pages on Google when I tried to search for the errors I was seeing; now there should be at least one.

I was following along with this nice Cisco document that does a good job of explaining how to get a PIX and a SonicWall to talk IPSec back and forth. I’ll leave out the details of how I configured both sides as that document gets into more detail than most people need, and I’d rather not repeat things unnecessarily. Even though the SonicWall I was using was considerably older, the settings were similar. I did stray from the document in one way: I used 3DES/SHA. Due to the age of the SonicWall it did not support the newer/stronger methods.

When it was all said and done, the VPN appeared to work for a bit but then stopped, and I was getting errors on both sides. On the PIX side I saw (from “debug crypto isakmp”):

ISAKMP (0): retransmitting phase 2 (0/0)… mess_id 0x1eefa9e
ISAKMP: error, msg not encrypted

In the SonicWall log, I saw:

IKE Responder: IPSec proposal not acceptable

It turns out that I had made a typo in the subnet mask for the LAN side of the SonicWall when I entered it into an ACL on the PIX side. Gun, meet foot. Foot, meet gun. I noticed that on the PIX there were two SAs being created (“show crypto ipsec sa”) one for the proper subnet mask, as given by the SonicWall side, and one for the improper subnet mask as desired by the PIX. After I fixed the ACL and re-entered each of the lines that contained a reference to it, everything was copasetic.

Feb 17

Daylight Saving Time Strikes Again! Well, almost.

We lucky folks in Indiana have had a rough two years dealing with time. As I wrote about last year, Indiana just started observing Daylight Saving Time (DST) in 2006. Now, for 2007 we also have to change the dates on which DST starts and ends. DST now begins on the second Sunday in March, and ends on the first Sunday in November — This year it’s March 11th and Nov 4th. Why on earth we didn’t just wait to start along with the new rules is anyone’s guess. <rant>I don’t think we should be using DST at all, but that’s a story for another time</rant>

Here I was, all set for another round of server updates, reboots, etc. Turns out that I didn’t need to worry quite so much. When I updated all of the time zone files on our servers last year for Indiana’s initial DST switch, they had already made the changes with the new start and end dates for 2007 and beyond. You can confirm this on most UNIX systems as follows:

# zdump -v /etc/localtime | grep 2007
/etc/localtime  Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
/etc/localtime  Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime  Sun Nov  4 05:59:59 2007 UTC = Sun Nov  4 01:59:59 2007 EDT isdst=1 gmtoff=-14400
/etc/localtime  Sun Nov  4 06:00:00 2007 UTC = Sun Nov  4 01:00:00 2007 EST isdst=0 gmtoff=-18000

If it says “Mar 11” and “Nov 4” you’re good. If it says “Apr 1” and “Oct 28” you need to update your time zone definitions. On FreeBSD, this can be as simple as downloading new zoneinfo files, recompiling them, and re-selecting the timezones:

  1. Download:
  2. Exctact the contents to /usr/src/share/zoneinfo
  3. cd /usr/src/share/zoneinfo; make install
  4. tzsetup
  5. Choose your time zone again.

A reboot may be necessary to ensure that all running programs are on the same time zone. Currently running programs may not pick up the change. You could also update FreeBSD to a recent version, which includes these changes. If you choose to do the OS update, be sure to run “tzsetup” afterward to be absolutely certain that a new tz file gets installed to /etc/localtime. After you’re done, re-run the zdump command above to be check that you now have the proper DST change dates for 2007.

If you are running any Cisco gear (or other IOS-alike devices) this should work to make the change:

clock timezone EST -5
clock summer-time EDT recurring 2 Sun Mar 2:00 1 Sun Nov 2:00

Adjust the time zone to yours, of course.

There may be other programs that handle time zone data internally (such as Java and Outlook) so you’ll have to be sure there are no loose ends in that department. Those of us in Indiana have some practice with this, so at least for us it may not be that bad.

I am aware that many of these problems could be avoided by using UTC on all our server clocks. While that may be preferable, we like to have everything in local time. It’s a choice, and we deal with the consequences. One of which is we never schedule jobs to run overnight between 1-3am — they could be run twice or not at all.

UPDATE: 3/1/07: I have also been informed that you can copy the “/etc/localtime” file from an updated system to any other system that needs it. This could be especially useful if you are unable to update all of the Time Zone definitions for any particular reason.

Oct 18

PHP Crashes Caused By Extensions

Once again when faced with updating PHP on a few servers, I encountered my favorite of all PHP quirks: After rebuilding extensions, PHP crashes and/or takes Apache down with it. Here are the errors that tend to show up:

  • exited on signal 11 (core dumped)
  • exited on signal 6 (core dumped)
  • seg fault or similar nasty error detected in the parent process

And my personal favorite:

  • httpd in free(): error: junk pointer, too high to make sense

I have seen this on PHP4 and PHP5, and with Apache 1.3 and 2.x. I’m not sure if it’s a problem inherent to how the FreeBSD ports system builds and installs the modules or if it’s just a problem in general. I had read once upon a time that rebuilding extensions in a certain order would fix it, and it did. I never got around to figuring out why this worked. Turns out, rebuilding them doesn’t really matter, but the order of the extensions being loaded does. Rebuilding fixed it because when a php extension port is rebuilt, it gets placed at the end of extensions.ini. I solved the problem by editing /usr/local/etc/php/extensions.ini and placing the lines for mysql, imap, and sockets at the end and in that order:


I’m not sure if the conflict is only with those three, or with others as well, but that fixes it on my servers. I tried it on three different setups, and before the change they all crashed and after the change they’re all running OK.

Hopefully if anyone else runs across this, it will help. If I get more time, I’ll dig into it more later.

Update (11/25/06):
There has been some more discussion of this on the FreeBSD-Ports mailing list and the FreeBSD-STABLE mailing list. Apparently at least part of this is due to the PHP recode, MySQL, and IMAP extension ordering. These extensions rely on c-client libraries with different overloaded hash functions. So the “magic” order at the end of extensions.ini should be:


There is also talk of building some logic into the PHP extension ports to ensure the ordering of the extensions so as to avoid this bug. Best of luck to those working on it!

Edit 8/25/07: I wrote a very hackish shell script that gets the job done keeping the extensions in this order. It’s not pretty, but it works. It can be found here: Read the full post here.

Edit 11/21/07: Lately pspell has also become picky about ordering. I recommend placing it at the end (or at least anywhere after


Sep 05

FreeBSD On The Desktop (Part IV: A New Hope)

Due to my recent bad luck with electricity, I was using my home server as a desktop all last week. As a result, I have some more notes to add about using FreeBSD as a Desktop machine, which I hope others may find useful.

Read on for more about Printing, Firefox and Thunderbird interoperability, mounting a USB mass storage device, CD burning with K3B, and Video playback.

Continue reading

Sep 04

Magical Exploding Laptop

So a week ago I had a rather nasty shock. I was watching a TV show that I was playing on my laptop, which was hooked up to my DVD Recorder via S-Video and composite audio cables. Nothing I hadn’t done a few dozen times before. The difference was: I realized that I had not plugged in the laptop’s power cord. When I proceeded to plug in the laptop — *poof* — sparks flew and smoke rolled out of the laptop from under the headphone jacks. It’s an Acer not a Dell so this was truly a surprise :)

After some minor panicing, I found that the laptop would still boot (thankfully) but the audio was dead. I presume the S-Video port was also dead, but I was not about to test it. Sadly, my DirecTivo was also fried (also connected to the DVD Recorder via S-Video) but the DVD recorder is just fine. The jolt also fried a segment of coax cable between the Tivo and the Satellite dish: Specifically it was the segment that goes from the inside of the house to the grounding block outside.

Read on for all of the gruesome details…
Continue reading

May 11

Key Bindings in Bash and Vi

So I was typing away in an ssh window today when for the billionth time I had hit the END key expecting the cursor to jump to the end of the line, and it just printed a ~. As always, I just erased the character and then held down the arrow until I was at the end of the line. However, seeing as it was the billionth time I decided to figure out how to make it actually do what I want.

Not that I didn’t really know how to make it do what I want, I’ve just always been too lazy to actually look up the escape codes and such for the home and end keys, and then actually create the entries to fix it. So for the benefit of any other fellow lazy people, here’s what you need to do:

Create ~/.inputrc and put this in it:

“\e[1~”: beginning-of-line
“\e[4~”: end-of-line
“\eOH”: beginning-of-line
“\eOF”: end-of-line
“\e[H”: beginning-of-line
“\e[F”: end-of-line
That should cover most of the bases terminal-wise.

And to make sure that home/end work in Vi, this is what I added to .exrc:
map [CTRL-V] [HOME] ^
map [CTRL-V] [END] $

When I say [CTRL-V] I mean actually press the keys ctrl and v, not type that out, of course.

There are probably better ways to accomplish this, but this worked for me. Feel free to suggest a more elegant solution.

Apr 11

Getting Poptop to run under FreeBSD 5 & 6

I spent a day or so tinkering with poptop on both FreeBSD 5.x and 6.x, and I figured others might benefit from knowing what I found.

First of all, a little background: Poptop is a Point-to-Point Tunneling Protocol (PPTP) server. It lets you easily and securely establish a VPN tunnel to a server from any computer that has a PPTP client (Windows XP has one built in, as do others.) I wanted to be able to tunnel back into a machine that is on a LAN at a remote location. Using poptop looked like it might be easier than some of the other methods.

Read on if you want to know the details

Continue reading

Apr 02

The Horrors of Daylight Saving Time

So as a resident of Indiana, today is my first day of Daylight Saving Time and I am not happy at all. In addition to having to reset all of the clocks, I also had to change the time zones on all of the computers — Easy enough on Windows, you can just change the time zone to Eastern. However, all my FreeBSD servers required a download and recompile of new time zone definitions. Not just that, but most programs that were started before the time zone switch will not pick up the change until they are restarted. In some cases, it’s safer to just reboot the whole server to make sure everything is running on the same clock. And I hate having to reboot servers.

The reasoning behind the FreeBSD time zone updates is explained in this link. The gist of it is that past file dates can be miscomputed if the time zone is simply switched to Eastern.

Many users of calendaring programs will be bitten by similar problems, causing appointments set before the change to exhibit all kinds of odd behavior.

Personally, I have not seen enough compelling evidence to show that the clock changing business actually saves any energy. It does, however, mess with people’s internal clocks and cause many traffic accidents. Most of the figures done showing that it saves energy seem to be from the 1970’s. I doubt the governer thought about the thousands of man-hours lost in actually changing the clocks, on computers and servers especially – but he sure was sympathetic about the possible loss of an hours worth of drinking at bars!

The only positive effect is that the Indiana legislature will now debate over things that actually matter, instead of over DST.

I’m sure that come Monday I will have to deal with quite a few calls from people who, rather than changing the time zone on their PC, have simply run the clock ahead an hour – only to find out that the clock resets when the Internet Time function resyncs.

Mar 25

FreeBSD on the Desktop (Part III)

I spent a week booted into only FreeBSD, and met with a lot of problems. Many of them could be overcome, but the fact of the matter is that I was simply less productive under FreeBSD than I was under Windows, mainly because of little issues. Things such as keyboard bindings and interface issues that were not consistent between applications, the file associations mechanism was almost working as it should, but it wasn’t obeyed by all applications.

As much as I love, it was simply not able to properly handle all of our work-related doucments. It will take some more investigating as to why, but on Windows formatted the documents properly, most of the time, but on FreeBSD they were mangled.

I’m going to try putting together another PC and retasking an unused KVM so that I might have a FreeBSD box and Windows box at my desk. Perhaps that way I can have the best of both worlds, and do some more experimenting while not losing any productivity…