Thursday, December 19, 2013

n2n: Simple VPN on Debian Wheezy

If you are looking for a way to connect two or more computers over the internet, there are tons of articles available on how to do this with OpenVPN. However, if you are looking for a way to achieve this with something other than OpenVPN, then you might want to try to use n2n

According to its website (http://www.ntop.org/products/n2n/), n2n is a layer-two peer-to-peer virtual private network (VPN) which allows users to exploit features typical of P2P applications at network instead of application level. An n2n VPN network consists of two (2) components.
  1. Edge nodes: the computers which you want to connect over the internet.
  2. A supernode: a computer which helps to connect edge nodes, especially if the edge nodes are connected to the internet behind NAT. This can be your own computer or someone else's computer (public supernode).
n2n VPN Network (taken from official n2n website)

For example, we want to connect these two computers.
  1. Alice's computer: located on Alice's home and connected to the internet behind a NAT.
  2. Bob's computer: located on Bob's home and also connected to the internet behind a NAT.
Both Alice and Bob have Debian Wheezy running on their computers and they have a typical home internet connection with no static IP.

The n2n VPN network we are going to build is as the following.
  1. The community name is casper and the N2N_KEY is bS3MU9quxD.
  2. The VPN IP assignments are:
    1. Alice's computer: 10.10.10.10
    2. Bob's computer: 10.10.10.11
  3. We are going to use public supernode provided by remoteqth.com (78.111.124.210:82).
The community name, N2N_KEY, and VPN IP assignments are arbitrary. You can set them to whatever which works for you.

Here is what needs to be done.
  1. Install n2n on both computers: run # apt-get install n2n
  2. Run n2n edge on each computer:
    1. On Alice's computer: run # N2N_KEY=bS3MU9quxD edge -d n2n0 -a 10.10.10.10 -c casper -u $(id -u nobody) -g $(id -g nobody) -f -l 78.111.124.210:82 -b
    2. On Bob's computer: run # N2N_KEY=bS3MU9quxD edge -d n2n0 -a 10.10.10.11 -c casper -u $(id -u nobody) -g $(id -g nobody) -f -l 78.111.124.210:82 -b
  3. Test the VPN connection:
    1. On Alice's computer: run $ ping 10.10.10.11
    2. On Bob's computer: run $ ping 10.10.10.10
  4. Done.
You can use the the above VPN connection for almost anything. Additionally, if you have avahi-daemon set up on both computers, you can access each computer by using its .local hostname e.g. alice.local or bob.local.

Saturday, October 26, 2013

Workaround for USB Drive is Mounted Again After "Safely Remove" on Debian Wheezy

Some of you might experience this issue whereby after performing "Safely Remove" on a USB disk, it gets mounted again after a few seconds and you have to perform "Safely Remove" once again. Some people found that only nvidia chipsets are affected by this issue.

The details of this issue can be found here:


My laptop which is affected by this issue is an Acer Aspire 4530.

Acer Aspire 4530

00:00.0 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a2)
00:01.0 ISA bridge: NVIDIA Corporation Device 075e (rev a2)
00:01.1 SMBus: NVIDIA Corporation MCP78S [GeForce 8200] SMBus (rev a1)
00:01.3 Co-processor: NVIDIA Corporation MCP78S [GeForce 8200] Co-Processor (rev a2)
00:01.4 RAM memory: NVIDIA Corporation MCP78S [GeForce 8200] Memory Controller (rev a1)
00:02.0 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:02.1 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:04.0 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] OHCI USB 1.1 Controller (rev a1)
00:04.1 USB controller: NVIDIA Corporation MCP78S [GeForce 8200] EHCI USB 2.0 Controller (rev a1)
00:07.0 Audio device: NVIDIA Corporation MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio (rev a1)
00:08.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:09.0 SATA controller: NVIDIA Corporation Device 0ad5 (rev a2)
00:0b.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Express Bridge (rev a1)
00:13.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:14.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:15.0 PCI bridge: NVIDIA Corporation MCP78S [GeForce 8200] PCI Bridge (rev a1)
00:18.0 Host bridge: Advanced Micro Devices [AMD] Family 11h Processor HyperTransport Configuration (rev 40)
00:18.1 Host bridge: Advanced Micro Devices [AMD] Family 11h Processor Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] Family 11h Processor DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] Family 11h Processor Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] Family 11h Processor Link Control
02:00.0 VGA compatible controller: NVIDIA Corporation C77 [GeForce 9100M G] (rev a2)
08:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5764M Gigabit Ethernet PCIe (rev 10)
0b:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01)

If my memory serves my right, this issue did not exist on the original Debian Squeeze release 6.0. However, it is introduced in one of Debian Squeeze release update 6.0.X. Until Debian Wheezy release 7.0, this issue has not been fixed yet.

After dissecting changes on Debian Squeeze release updates and a lot of trial and error, I managed to find that this issue occurs after the following linux kernel commit.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=253e05724f9230910344357b1142ad8642ff9f5a

So, it works like this. When "Safely Remove" is clicked, GNOME (or some other window manager) calls udisks. Udisks will then check whether the running linux kernel has "remove" attribute which was introduced on the linux kernel commit above. If "remove" attribute is found, udisks will then poke it to tell linux kernel to perform safely remove on the USB disk.

My conclusion is this issue might be caused by a bug in the linux kernel. However, since I am no expert, I am unable to debug or provide a fix for this. I can only think of some workarounds for this issue until it is fixed.
  1. Revert the above linux kernel commit and recompile the kernel, or
  2. Patch udisks so that it does not poke the "remove" attribute.
Since recompiling kernel will take a lot of time, I ended up choosing to patch udisks instead.

I have moved on to Jessie. You can get the patched udisks here (i386 build + source): Dropbox

Tuesday, October 1, 2013

D-Link DWM-156 on Debian Linux Wheezy with NetworkManager

In this post, I will attempt to explain how I managed to get D-Link DWM-156 working on Debian Linux Wheezy with NetworkManager (without wvdial).

NOTE: For those who want to skip the details and try this right away, you can find download links at the end of this post.

D-Link DWM-156 (Front)

D-Link DWM-156 (Back)

This broadband modem has a lot of variants. The one that I am using is the following.

dhanar10@aspire-4530:~$ lsusb | grep D-Link
Bus 002 Device 003: ID 07d1:7e11 D-Link System

This particular broadband modem does not work reliably out-of-the-box with NetworkManager. The symptoms are described nicely in this blog. This issue is due to ModemManager guesses the wrong ttyUSBx port.

After a lot of tinkering, I have managed to produce a patch and recompile ModemManager.

The patch consists of two (2) parts.

1. An additional udev rules to mark the wrong ttyUSBx ports.
# do not edit this file, it will be overwritten on update 
ACTION!="add|change", GOTO="mm_generic_port_blacklist_end" 
SUBSYSTEM!="tty", GOTO="mm_generic_port_blacklist_end"
SUBSYSTEMS=="usb", GOTO="mm_generic_port_blacklist_vendorcheck"
GOTO="mm_generic_port_blacklist_end"
 
LABEL="mm_generic_port_blacklist_vendorcheck"
SUBSYSTEMS=="usb", ATTRS{bInterfaceNumber}=="?*", ENV{.MM_USBIFNUM}="$attr{bInterfaceNumber}"
 
# D-Link DWM-156 HSUPA 3.75G USB Modem
ATTRS{idVendor}=="07d1", ATTRS{idProduct}=="7e11", ENV{.MM_USBIFNUM}=="00", ENV{ID_MM_PORT_IGNORE}="1"
ATTRS{idVendor}=="07d1", ATTRS{idProduct}=="7e11", ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_PORT_IGNORE}="1"
LABEL="mm_generic_port_blacklist_end"
2. A logic which allows ModemManager to ignore the wrong ttyUSBx ports which has been marked by udev.
diff -Naur ModemManager-0.5.2.0.orig/plugins/mm-plugin-generic.c ModemManager-0.5.2.0/plugins/mm-plugin-generic.c
--- ModemManager-0.5.2.0.orig/plugins/mm-plugin-generic.c 2012-03-14 03:06:11.000000000 +0800
+++ ModemManager-0.5.2.0/plugins/mm-plugin-generic.c 2013-05-09 08:42:10.872596000 +0800
@@ -87,6 +87,10 @@
if (strcmp (g_udev_device_get_subsystem (port), "tty"))
return MM_PLUGIN_SUPPORTS_PORT_UNSUPPORTED;
+ if (g_udev_device_get_property_as_boolean (port, "ID_MM_PORT_IGNORE"))
+ return MM_PLUGIN_SUPPORTS_PORT_UNSUPPORTED;
+
+
if (mm_plugin_base_get_cached_port_capabilities (base, port, &cached)) {
level = get_level_for_capabilities (cached);
         if (level) {
The full patch can be found in the source package inside modemmanager_0.5.2.0-2obs1.debian.tar.gz under debian/patches/dlink-dwm-156.patch.

You can get the patched ModemManager here (yes, they are on OpenSUSE Build Service):
The patched ModemManager files are moved to Dropbox: here.