NetworkManager, broadband network connection and VPN
I described in a previous post how to use the NetworkManager in Fedora 8 to connect to a broadband network provider, with the Huawei-E172 USB 3G+ key. The next step is naturally to use this wireless link to setup a VPN connection over this unsecure network. The cherry on the cake will be the integration of this VPN client into the NetworkManager, with a single applet to manage all the magic.
An openvpn plugin is available for NetworkManager, so the client configuration is basically limited to just a few clicks in the GUI. The server config file looks like that (/etc/openvpn/server.conf) :
port 1194 dev tuntls-server ca ca.crt cert server.crt key server.key # This file should be kept secret dh dh1024.pem
mode server ifconfig 192.168.129.1 192.168.129.2 ifconfig-pool 192.168.129.4 192.168.129.255
push "route 192.168.129.1 255.255.255.255" push "route 192.168.128.0 255.255.255.0" push "dhcp-option DOMAIN example.com" push "dhcp-option DNS 192.168.128.1"
keepalive 10 60 inactive 600 route 192.168.129.0 255.255.255.0 user openvpn group openvpn persist-tun persist-key
verb 3
This configuration is basically the same than the roadwarrior-server.conf example provided in the documentation directory of the Fedora openvpn package. In this file, the openvpn server is configured for a tun-style tunnel (instead of an ethernet tunnel using ethernet bridging), it provides routes for the internal local network 192.168.128.0/24, it advertizes the local DNS. The clients are allocated in the subnet 192.168.129.0/24, where are also assigned the addresses of the virtual endpoints of the tunnel. The certificates are generated with the easy-rsa scripts, many details on certificates generation is available on the web.
Some iptables rules are needed (eth0 is the outgoing interface of the VPN server box) :
echo 1 > /proc/sys/net/ipv4/ip_forwardiptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A INPUT -i tun0 -j ACCEPT iptables -A FORWARD -i tun0 -j ACCEPT iptables -A FORWARD -i eth0 -o tun0 -d 192.168.129.0/24 -j ACCEPT iptables -A INPUT -p udp -i eth0 --dport openvpn -j ACCEPT
If you use Fedora-8, and NetworkManager version 0.7.0-0.6.7.svn3370 from the updates-testing repository, this supplementary patch is also needed:
--- NetworkManager-0.7.0.orig/src/NetworkManagerSystem.c 2008-01-21 16:21:00.000000000 +0100
+++ NetworkManager-0.7.0/src/NetworkManagerSystem.c 2008-04-13 23:18:03.000000000 +0200
@@ -347,7 +347,7 @@
/* Set up a route to the VPN gateway through the real network device */
if (active_device && (ad_config = nm_device_get_ip4_config (active_device))) {
- nm_system_device_set_ip4_route (nm_device_get_iface (active_device),
+ nm_system_device_set_ip4_route (nm_device_get_ip_iface (active_device),
ad_config,
nm_ip4_config_get_gateway (ad_config),
nm_ip4_config_get_gateway (config),
--- NetworkManager-0.7.0.orig/src/nm-device.h 2008-01-09 19:10:15.000000000 +0100
+++ NetworkManager-0.7.0/src/nm-device.h 2008-04-14 00:20:53.000000000 +0200
@@ -122,6 +122,7 @@
const char * nm_device_get_udi (NMDevice *dev);
const char * nm_device_get_iface (NMDevice *dev);
+const char * nm_device_get_ip_iface (NMDevice *dev);
const char * nm_device_get_driver (NMDevice *dev);
NMDeviceType nm_device_get_device_type (NMDevice *dev);
--- NetworkManager-0.7.0.orig/src/nm-device.c 2008-02-21 04:16:11.000000000 +0100
+++ NetworkManager-0.7.0/src/nm-device.c 2008-04-13 23:22:25.000000000 +0200
@@ -248,7 +248,7 @@
}
-static const char *
+const char *
nm_device_get_ip_iface (NMDevice *self)
{
g_return_val_if_fail (self != NULL, NULL);
This patch appearead later in upstream, and is available in NetworkManager from rawhide, so you may prefer to rebuild this more recent version for Fedora-8 instead.
The configuration of the VPN, with the GUI is very simple. Be sure to upload the client certificate, the client key, and the ca certificate from the server easy-rsa directory on the client. Enter these file paths in the nm-applet openvpn configuration, define the IP address of your openvpn server, and that's all. Advanced settings should be left to their default values. The openvpn client behaviour, as driven by NetworkManager, is to add a direct route to the openvpn gateway, via the existing network connection, and to add a default route for all other traffic through the tunnel of the VPN. So all the traffic will be crypted, except the traffic directed to the openvpn server itself.
12 Apr 2008 (updated 23 Apr 2008 at 12:16 UTC) »
Update on Huawei-E172 card and NetworkManager
Minor changes are required in NetworkManager on Fedora-8 to make it work fine with the Huawei-E172 card and the french mobile broadband network provider SFR.
install the latest version of hal-info from updates-testing repository.
if you don't want the usb storage stuff of the card to show up each time you plug it in, add an entry in hal, named /usr/share/hal/fdi/preprobe/20thirdparty/20-huawei.fdi and containing :
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="storage.bus" string="usb">
<match key="@storage.originating_device:usb.vendor_id" int="0x12d1">
<match key="@storage.originating_device:usb.product_id" int="0x1003">
<merge key="info.ignore" type="bool">true</merge>
</match>
</match>
</match>
</device>
</deviceinfo>
add an udev rule, that will send the PIN code the the card control device upon card insertion, in a file named /etc/udev/rules.d/99-huawei.rules
ACTION=="add", KERNEL=="ttyUSB1", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1003", RUN+="/usr/local/bin/huawei-e172-send-pin $env{DEVNAME}"
create the script file that will send the PIN code to the card, /usr/local/bin/huawei-e172-send-pin
#!/bin/bash if [ -n "$1" -a -c "$1" -a -w "$1" ]; then echo 'at+cpin="1234"' >gt; "$1" fi exit 0
the two previous steps can be replaced by creating a gconf key containing the pin value, system/networking/connections/*/gsm/pin, of type String. But this won't work on the first connection, because NM currently doesn't wait after setting the pin and before the card becomes available for dialing.
--- NetworkManager-0.7.0/src/nm-gsm-device.c.orig 2008-01-09 19:10:50.000000000 +0100
+++ NetworkManager-0.7.0/src/nm-gsm-device.c 2008-04-11 15:02:32.000000000 +0200
@@ -169,7 +169,7 @@
setting = NM_SETTING_GSM (gsm_device_get_setting (NM_GSM_DEVICE (device), NM_TYPE_SETTING_GSM));
- command = g_strdup_printf ("AT+COPS=1,2,\"%s\"", setting->network_id);
+ command = g_strdup ("AT+CGDCONT=1,\"IP\",\"slsfr\"");
nm_serial_device_send_command_string (device, command);
g_free (command);
@@ -268,10 +268,7 @@
setting = NM_SETTING_GSM (gsm_device_get_setting (NM_GSM_DEVICE (device), NM_TYPE_SETTING_GSM));
- if (setting->network_id)
- manual_registration (device);
- else
- automatic_registration (device);
+ manual_registration (device);
}
static void
@@ -440,7 +437,7 @@
guint id;
char *responses[] = { "OK", "ERR", NULL };
- nm_serial_device_send_command_string (device, "ATZ E0");
+ nm_serial_device_send_command_string (device, "ATZ Q0V1E0S0=0&C1&D2");
id = nm_serial_device_wait_for_reply (device, 10, responses, init_done, NULL);
if (id)
with gconf-editor, go to the system/networking/connections/*/ppp entries related to your gsm connection, and toggle the noauth key to true.
restart haldaemon, NetworkManager and the nm-applet, and you should be able to connect to your broadband provider, using NetworkManager.
Update:
It appears that the patch to nm-gsm-device.c above, that modifies the ATZ init string and fixes the SFR APN with AT+CGDCONT is not needed. Defaults values should work just fine.
10 Apr 2008 (updated 19 May 2010 at 20:52 UTC) »
Hardware geekeries
One of our telco here in France currently proposes a pack to access internet everywhere, using 3G+ technology. This pack includes a sub-notebook format computer, an Asus EeePC 4G, and a 3G+ huawei-E172 USB key. Why is this pack more interesting imo than other ones, especially for linux geeks ?
In mobile world, unlimited offers are often subject to small footnotes(*) where the reader learns that the word unlimited in fact means limited to a given amount of traffic, or to a to restrictive time range, where the offer is available, or whatever other restriction you may imagine. In case of restriction override, the bill often becomes prohibitive, and easily uncontrolled.
This pack is different because it proposes an 1GB monthly traffic quota, and once the limit is reached, the bandwidth is limited to 128Kbits, but the customer won't have to pay extra cost. So this is clearly an offer, where the customer knows in advance the cost of his subscribtion, whatever his traffic profile may be. This is a good point.
Currently in France, the 3G+ coverage is mainly limited to big cities and touristic area for all telco operators. Providing an online up-to-date coverage map is mandatory in France, so the customer can compare the network quality before subscribing. Here is the coverage map for Orange, and for SFR for example. It appears that 3G+ coverage is noticeably better for Orange than for SFR, at least considering the surface of territory covered.
This pack is interesting, because each item can be used separately, and moreover each item works fine with free software.
Asus EeePC
This laptop has subnotebook format, with a screen resolution of 800x480, powered by an Intel graphic chipset, so perfectly supported by the free linux driver. The processor is an Intel Celeron, with 512MB RAM, and a 4GB SSD drive. Except the processor fan, there's no moving parts in the box.
The EeePC is shipped with a Xandros Linux distro, but it can also run most other linux distro without trouble. I installed Eeedora, a Fedora 8 live cd/usbstick tailored to the machine, with a light desktop (xfce), a reduced package set, and some customizations related to ACPI hotkeys, and to the wifi driver. Starting from this Fedora 8, I upgraded to Rawhide, rebuilt the madwifi driver for the newer kernel, the asus acpi kernel module for the hot keys, and installed gnome as the default desktop.
And now, I have a nice little box fully supported with Fedora 9, even if disk space is a bit low after this update, with 1.5GB free space remaining on the 4GB disk.
3G+ USB HSPA modem
The usb key contains a huawei-E172 modem, which is well supported with a recent Fedora kernel (>= 2.6.24). The connection is established with usual ppp protocol. This page provides the basic ppp setup (ignore the part about udev rules, that's not needed with Fedora). The particularity of the modem is that two devices are created when inserting the key. /dev/ttyUSB0 is the regular modem, and /dev/ttyUSB1 is the control channel. The later one is typically needed to send the pin value value to the card, before connecting with the first one. When pin value has been successfully accepted by the modem, the light color of the key will change from green to blue.
The next step will be proper integration of the ppp connection stuff into the NetworkManager. Dan is working hard on it for version 0.7.0, but support is not yet available in rawhide at the time of this writing (regular ppp is possible, but extra steps specific to a gsm modem, like pin and APN settings are not yet implemented).
An alternate free software application allows to manage the key. The project is developped by Vodafone and provides a nice gui that handle connection settings, signal quality display, traffic accounting and some other goodies.
Conclusion
I said that this pack is interesting because each element can be used separately, without loosing functionnalities. The 3G+ USB key can work on any linux box, and the EeePC can be used independantly of the key (100Mbits ethernet and 802.11 wifi), running your favorite linux distro.
Finally I can give up using my old pcmcia modem card, on analog phone lines, and connect everywhere wirelessly, at a honest price : 199 euros for the EeePc, and 35 euros/month for one year subscription to 3G+ service.
Building GNOME with jhbuild
Here are few notes and patches about building current GNOME codebase from scratch with jhbuild on Fedora 8.
Doing a BIOS update on recent Dell computers running linux is becoming really really easy, and is well integrated to the standard way to update software on linux distros using RPM and YUM. See this wiki page that helps to setup the dell yum repo. Do an initial invocation of bootstrap_firmware that'll enumerate the hardware of the machine that can possibly be updated through this method, pass the result of this command to yum, so the necessary firmware files will be downloaded, update the firmware, reboot, and voila! BIOS is up-to-date. No more proprietary MS-DOS executables, no more need to seek for an old bootable floppy with and even older copy of MS-DOS 6.22 on it.
[root@lxorgfr ~]# yum -y update
Loading "skip-broken" plugin
Loading "dellsysidplugin" plugin
fwupdate 100% |=========================| 1.9 kB 00:00
dell-software 100% |=========================| 1.9 kB 00:00
fedora 100% |=========================| 2.1 kB 00:00
updates 100% |=========================| 2.3 kB 00:00
bellet 100% |=========================| 2.1 kB 00:00
Excluding Packages in global exclude list
Finished
Setting up Update Process
Resolving Dependencies
---> Running transaction check
---> Package openldap.i386 0:2.3.39-3.fc8 set to be updated
---> Package control-center-filesystem.i386 1:2.20.3-2.fc8 set to be updated
---> Package yum-utils.noarch 0:1.1.11-1.fc8 set to be updated
---> Package mesa-libGLU.i386 0:7.0.2-3.fc8 set to be updated
---> Package spamassassin.i386 0:3.2.4-1.fc8 set to be updated
---> Package shared-mime-info.i386 0:0.22-4.fc8 set to be updated
---> Package yum-skip-broken.noarch 0:1.1.11-1.fc8 set to be updated
---> Package system_bios_ven_0x1028_dev_0x0211.noarch 50:a07-20 set to be updated
---> Package xterm.i386 0:232-1.fc8 set to be updated
---> Package util-linux-ng.i386 0:2.13.1-1.fc8 set to be updated
---> Package mesa-libGL.i386 0:7.0.2-3.fc8 set to be updated
[...]
[root@lxorgfr ~]# update_firmware --yes
Searching storage directory for available BIOS updates...
Checking System BIOS for OptiPlex 755 - a05
Available: system_bios(ven_0x1028_dev_0x0211) - a07
Found Update: system_bios(ven_0x1028_dev_0x0211) - a07
Found firmware which needs to be updated.
Running updates...
100% Installing system_bios(ven_0x1028_dev_0x0211) - a07
Done: Update complete. You must perform a warm reboot for the update to take effect.
[root@lxorgfr ~]# reboot
Broadcast message from root (pts/0) (Wed Feb 13 15:14:19 2008):
The system is going down for reboot NOW!
[root@lxorgfr ~]#
(et voila)
A couple of weeks ago, I finally bought some new hardware, to benefit of all the new Linux bells-and-whistles on the desktop, also of decent performances in current applications, and of virtualization-capable processors.
When I frequently read that a slow old PC is good enough to browse the web, I think this is blatantly false nowadays. My old Pentium 4, clocked at 2.4 GHz was regularly using 100% CPU at peaks, when rendering some complex web pages. I don't know exactly who is to blame. The complexity of the said web pages, the complexity of the firefox browser, the habit to put hardware intensive flash stuff everywhere [1], also the increasing use of ajax effects. Maybe a cumulative effect of all these reasons. But trust me, an old PC is just too slow to browse todays web. And I don't even speak about performance needed for gaming...
[1] even with the flashblock mozilla extension, so only selected flash are active.
What can be underlined about the hardware evolution since four years years:
My router stays up 24/7, and serves as my web browser, my mail server, and a few other public services. The machine I use for this is a Dell optiplex 755, with a Core 2 E6550 processor. I removed the pci-express video card, as this box is basically head-less, and if I really need to display output, I still can use the Intel onboard graphic card. This machine is really quiet, the processor only consumes 65 Watts. This is a good choice for a router. I'm also very satisfied by the purchase of one a the only PCI modem card, that is supported with linux, because it is a real hardware modem, and not a cheap winmodem.
My main desktop machine is a Dell precision T3400, with a Core 2 Quad Q6700 CPU. Four cores in a single socket is rather impressive, and remains me the old times, around 1996, when I installed my first Linux on a dual Pentium 90. I opted for a 30 inches flat panel screen, that advantageously replaces two 21 inches screens, with a wide resolution of 2560x1600 pixels. This kind of resolution requires a special dual-link DVI card. Initially, I had bought an nvidia quadro fx 1700. I thought this choice was a good balance between performance, and power consumption/noise (peak at 42 Watts). When I first started to play with the card, I have been quickly deceived by the amount of noise emitted by its small fan. This card occupies a single slot on the motherboard.
After some investigation, I discovered another model, also powered by nvidia, but sold to the gamers with a geforce 8600GT chip. This card made by Asus has approximately the same performance, and the same power consumption than the quadro fx 1700, but it has the great advantage to be passively cooled, with a big heat sink that occupies a second slot in the mobo. The same power, less expensive, with more silence in my room, sweet experience! OK, the GPU is clearly hotter on the passively cooled card (65 C degrees), than on the quadro fx (40 C degrees), but this temperature is still far from the 105 degrees limit, advertised by the nvidia-settings program.
Another of my goals was cable bloatedness reduction, that's been partially achieved :
10 Oct 2007 (updated 10 Oct 2007 at 14:27 UTC) »
IBM customer service
Last week, the LCD panel of my thinkpad decided to fail to light up at boot time. I contacted the IBM customer service at 10am, they quickly made a diagnostic of the problem. As the VGA output of the graphic card was still usable, the faulty hardware was certainly the LCD panel. The next day, at 11am, a technician on-site just finished to replace the dead panel.
25 hours to resolve a case of a hardware problem on a laptop. I don't need to tell that I don't regret the money that my employer put in the extra 3-years warranty, with on-site intervention. And no, I wasn't wearing this tee-shirt :-)
10 Oct 2007 (updated 10 Oct 2007 at 13:43 UTC) »
Virtualization is a hot topic. For a lot of good reasons
Virtualization on Fedora
The virtualization in Fedora has been advertised early with the shipping of Xen. Xen requires that the host runs a specific kernel, that lags behind the most recent upstream kernel version. The Xen guys at RedHat made a terrific work to port the Xen changes to current kernel releases, but this looks like such a daunting task, that they have a hard time to follow upstream kernel.
A new solution has been developed, KVM, that has an invaluable advantage to be merged upstream, and to work with an unmodified kernel, just by loading a module into the system. KVM is an api exposed to userland via the /dev/kvm device, and that has been integrated into QEMU, so QEMU commands can work unmodified with KVM.
QEMU is an older emulator, not only for x86 architectures. Coupled with a kernel module (kqemu), it can provide a nice emulation speedup, compared to a pure userland emulation. This kernel module is not yet upstream. It was proprietary code until recently. Its license is now GPL.
RedHat also developed for Fedora an interesting framework, virt-manager and libvirt, that allows to manage virtual machines, in a way that is independent of the underlying virtualization technology available on the host. It can currently handle both Xen, and KVM.
QEMU features
QEMU simulates an HDD using a single disk partition or file on the host machine. It can use a disk image format allowing embedded snapshoted states of the virtual machine. Features include compressed storage, on-demand growing disk images. It is also possible to separate the disk image in two parts : a read-only disk image in one file (typically shared among several virtual machines), and a second writable disk image, specific to each virtual machine, that use the copy-on-write principle, to only store differences with the read-only base disk image.
QEMU networking is still a bit tricky to configure, if the virtual machine must be reachable on the real network. A bridge must be created, including the real network interface, and a tuntap virtual interface. This tuntap interface must be handled by a virtual network switch emulator, like vde2. Access to this virtual ethernet switch may be granted to a given user. This user can launch, and attach many QEMU instances to this switch. Each instance with a different MAC address, so that each one obtains a distinct IP address on the real network.
QEMU virtual machines management is easy if they are configured to launch a VNC server at startup.
aironet/cisco wifi driver and wpa
The airo driver, the linux driver for aironet and cisco wireless cards, gained recently support for WPA encryption. Source code is available on www.gna.org in the airo-wpa module. This feature is now a requirement for access to all wireless networks configured by a security conscious administrator.
Matthieu Castet did an amazing work reverse engineering the windows driver with a modified ndiswrapper kernel module on linux. As a side note, luckily, we both live, Matthieu and me, in the country, where doing this reverse engineering is still legal, precisely for interoperability reason. Matthieu modified the airo driver and added the bits needed to handle a card with a WPA-aware firmware, and to talk to the wireless-extensions API with these new authentication schemes.
I still own an old pcmcia aironet 4800 card (hey Benjamin, if you read me, this is your card!), so I could test this modified driver with it. The first step is to reflash the card with a newer firmware, that supports WPA. Of course, This hardware is no longer supported by its vendor (aironet and now cisco) for a long time, and the latest released firmware is several years old. But, thanks to a nice hardware design, all 350 series cisco cards share the same 4500 radio hardware. So with luck, a recent firmware for cisco 350 cards does happily apply to my prehistoric pcmcia card.
Now the moment of truth is to test if the card and its unsupported WPA-aware firmware will associate with a WPA-enabled access point, using PSK authentication. And the answer is yes. wpa-supplicant successfully associates with my access point. I also made a test with NetworkManager, but the connection alternates up and down states, when wpa_supplicant runs in this context.
I will probably try to debug the problem a bit further, but what adds a bit of difficulty to this task, is that my pcmcia card doesn't work with ndiswrapper and the original Windows driver. So replaying the same method than Matthieu did, is not currently possible for me.
22 May 2007 (updated 22 May 2007 at 12:01 UTC) »
Fedora activity
Since a few weeks, I'm now a fedora maintainer of the FlightGear package. This is an exciting activity, that Hans de Goede convinced me to have. FlightGear is a well mature and realistic flight simulator. I spent a large amount of time, playing with it in the past months, and I appreciate this game a lot.
The reasons why I like this simulator are multiple. First, the scenery files are rich, and cover the whole earth. So it's very easy to just download the scenery of the area where you live, and to practice flying from a nearby airport. Coasts have a fine level of details, cities are mapped, and mountains are realistic. The second reason why I appreciate FlightGear is the accuracy of the simulation of environmental factors : weather can be rendered live, by querying in real-time the real weather information from various airports. This has an impact on the visibility distance, the altitude of the clouds layers, and wind and so on. The sun position also defines the scene lightning, and flying at the same location early in the morning, and late in the evening is a completely different experience. Finally, a third reason is the large variety of aircrafts, which also completely modify the fly feeling.
FlightGear is available in the Extras repository for Fedora Core 6, and will be available in Fedora 7 where Core and Extras have merged.
