Saturday, March 27, 2010

Solutions to VPN Problems with Ubuntu Linux – vpnc, network-manager, “terminated by dead peer”, WICD

I have been successfully using the Linux vpnc client to connect into the corporate network for months. However, I recently gained access to a more secure VPN network at the company, and I had nothing but trouble. This blog post explains the solution for that, as well as some other random network issues I was having.

Will this blog post solve MY problem?

I don’t know if I can help you, but here are the symptoms I was having on my machine:

  • I could establish VPN, but something truncated my connection every 5 minutes
  • After establishing VPN from certain locations, I could not ssh to my target instance; it never resolved the IP address
  • As I moved around the building (particularly up and down stairs), I had trouble with re-establishing network
  • I found the network hanging every 2 minutes for a few seconds

Troubleshooting

The key to solving these problems is to look into /var/log/syslog. Do you see either of these entries?

"connection terminated by dead peer detection”

This will be noted when something terminates your VPN connection"

“Roamed from BSSID 00:0F:61:1B:A4:32 (ESSID) to (none) ((none))”, followed by “Roamed from BSSID (none) ((none)) to 00:0F:61:1B:A4:32 (ESSID)”

This will happen every 2 minutes, and will be associated with a pause in your network traffic.

network-manager was the problem for me

I believe the source of all the trouble was the second error noted above. Based on Google searches, this indicates that the network card is scanning for new wireless networks every 2 minutes. During this time (which lasts 6 seconds) no other network traffic can be sent. It makes sense that this would cause issues with a picky VPN.

See this Ubuntu bug report for a full explanation (and confusion as to the proper fix) related to this nasty problem. Some folks indicated the network-manager component to be the source of the problem. network-manager is the default network manager for GNOME Linux distros (like Ubuntu). The problem reported in the bug report does not affect everybody – only some network cards. I run on a Dell Latitude E6400 with an Dell 1510 network card.

Sadly, the network-manager folks didn’t agree that it was their problem. So I had to look elsewhere for a solution.

WICD was the solution for me

Following guidance from others posting on the bug report, I uninstalled network-manager and installed an alterative called WICD (pronounced “wicked”). I have been running WICD for a week, and I am sold. All of the issues that I reported are now gone.

WICD has much of the same functionality of network-manager, but is a bit simpler which perhaps is its strength. Here is a screen shot of the WICD applet:

wicd_applet

If you wish to go this route (highly recommended!), issue the following command. It will install wicd and remove network-manager:

sudo aptitude install wicd

Note that wicd doesn't currently (as of 1.6.1) have menu driven support for VPNs. It is supposed to come with version 2.0 though, so keep checking in on this. It simply means that to start a VPN connection, you will have to do it from the command line instead of from the applet. If you are using vpnc, that means you have to do this from a terminal:

sudo vpnc

WICD Pro Tip

One thing that should be the default in WICD, but isn’t, is to always show the wired network connection in the list. Choose this by checking the box in the UI here:

  • Preferences->General->Always show wired interface

Eclipse missing from JPS (Java Process Status) command results list

It has been a while since I have posted. I have been working on some interesting stuff, but somehow didn’t manage to post about it. I will start to correct that.

I had a lot of work to do leading up to this past week. I had a couple of demos due for a big trade show at work. I hit a lot of bumps in the road due to infrastructure problems. I made a list, and I am working through them now that the deadlines are over. The next few posts will probably be about solutions to those.

The one covered here is pretty lame, but I’ll post it anyway.

Java Process Status command

I use the Java Process Status command line tool enough to want it to work perfectly. But, by default, it doesn’t. After launching Eclipse, I would execute JPS and get results like this:

plaird@plaird-laptop:~$ jps
18589 Jps
18339

If I launched multiple copies of Eclipse with different workspaces, I would predictably get:

plaird@plaird-laptop:~$ jps
19369
18339
19388 Jps

This isn’t a big problem, but its annoying. I put it on the list, and looked into it tonight. The reason is simple, and so is the solution.

JPS only works when using the standard Java launcher

The clue comes from the JPS documentation. It states:

The jps command uses the java launcher to find the class name and arguments passed to the main method. If the target JVM is started with a custom launcher, the class name (or JAR file name) and the arguments to the main method will not be available.

Well, that explains it because as many people know…

Eclipse uses a custom (native) launcher

After installing Eclipse, you are provided with a handy executable in the Eclipse directory. Invoking this thing launches Eclipse. Under the hood, it uses platform specific code to make it happen. The main benefit for doing this is to ensure that Eclipse is contained within a single OS process. The native code launches the JVM within its same process using a custom launcher. This appears to be a problem, but…

There is a way to use the standard launcher for Eclipse

However, you can revert to using the standard launcher. As per the launcher docs, there are several ways to do this. The way I chose is to make sure my eclipse.ini has these lines:

-vm
/usr/lib/jvm/java-6-sun-1.6.0.16/bin/java

Since the path for the vm arg is the standard Java launcher, it uses that instead of the custom launcher. Now look at my JPS results:

plaird@plaird-laptop:~$ jps
19369 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
18339 org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
19388 Jps

Problem solved. Well…

Caveats

Sadly, this doesn’t solve the problem of identifying which workspace is in use by either. But as long as you remember the order in which you started them, in most cases the pids will be in order.

And the known downside of multiple processes is evident in a ps –ef command:

18325     1 /bin/sh /home/plaird/Apps/eclipse35/eclipse.sh
18326 18325 /home/plaird/Apps/eclipse35/eclipse
18339 18326 /usr/lib/jvm/java-6-sun-1.6.0.16/bin/java equinox.launcher.jar

20111     1 /bin/sh /home/plaird/Apps/eclipse35/eclipse.sh
20112 20111 /home/plaird/Apps/eclipse35/eclipse
20128 20112 /usr/lib/jvm/java-6-sun-1.6.0.16/bin/java equinox.launcher.jar

Which is worse – JPS not listing Eclipse or having more goo in a ps listing?

Random Footnote

I noticed this comment in the JPS docs:

The lvmid is typically, but not necessarily, the operating system's process identifier for the JVM process.

This means that the pid/lvmid reported by JPS cannot always be used in a kill command. Good to know.  

Technorati Tags: ,