Undirected Ramblings

Become One with the OBEX [Permalink]

Thu Dec 14 23:19:30 EST 2006
Category [Linux]

For some reason possibly related to the fact that I've just started traveling almost full time and didn't bring along a real camera, I decided to figure out how to wheedle files away from my RAZR onto my Linux laptop over the bluetooth airwaves. It's very simple:

obexftp -b 00:15:A87:82:E7 -l /picture|grep file \
  |awk -F \" ' {print "/picture\/"$2;}'|xargs obexftp -b 00:15:A87:82:E7 -g

What? That doesn't look simple? The "-b" option in both invocations of obexftp must be your phone's device ID. The "-l" option tells obexftp to list the files on the device, then we munge around the output to get the filenames, and ask obexftp to get them with a "-g" option. Yay! Now I can marvel at the impressively low quality photos produced by my phone.

Configuring the Logitech MX 5000 [Permalink]

Wed Jan 18 11:16:10 EST 2006
Category [Linux]

I bought a fancy new Logitech MX5000 the other day, and I thought I'd share my recent success in getting everything working with Linux. The bunndle includes an "MX 5000 keyboard for Bluetooth" and a Bluetooth version of the MX 1000 mouse. I've had the RF version of the MX 1000 working for months now, but the new hardware was just different enough that my old configuration didn't suffice to get everything working correctly. Though both the keyboard and mouse worked out of the box with basic functionality, the fancy buttons and tilt wheel weren't working on the mouse, and it was tracking too fast. I still haven't managed to have them recognized as actual Bluetooth devices (they just show up as USB HID devices), but now all the buttons and tracking are working flawlessly. My old configuration, used with my RF version of the MX1000, didn't recognize the new version of the mouse, yielding errors like "cannot register with evdev brain" in my Xorg log.

The key step in getting everything working was to use the new "evdev" driver, rather than using what appears to have been some sort of hack to include evdev support in older versions of X.org. Here's what my configuration for the RF mouse looked like:

Section "InputDevice"
 Identifier "MX1000"
 Driver     "mouse"
 Option     "CorePointer"
 Option     "Protocol"        "evdev"
 Option     "Dev Name"        "Logitech USB RECEIVER"
 Option     "Buttons"         "12"
 Option     "ZAxisMapping"    "11 12 10 9"
 Option     "Resolution"      "800"
 Option     "Emulate3Buttons" "false"
EndSection

Using the new driver required an upgrade to X.org 6.9.0, after which the configuration looks like this:

Section "InputDevice"
  Identifier    "MX1000"
  Driver        "evdev"
  Option        "CorePointer"
  Option        "Device"        "/dev/input/mx1000"
  Option        "Resolution"      "800"
EndSection

Before we can reference this new /dev/input/mx1000 device, however, we need to make sure that it gets created by udev. I put the following lines in a new file called /etc/udev/rules.d/010_local.rules. It's important that this file be called before any other "event" rules, and that it end with ".rules", so the name is significant. This covers both my RF mouse and the bluetooth version. The bluetooth version needs the extra idProduct specification, as the keyboard and the dongle get registered with the same manufacturer and product name.

KERNEL=="event*", SYSFS{manufacturer}=="Logitech", SYSFS{product}=="Logitech BT Mini-Receiver", \
    SYSFS{idProduct}=="0xc70a", NAME="input/mx1000", mode=="0644"
KERNEL=="event*", SYSFS{manufacturer}=="Logitech", SYSFS{product}=="USB RECEIVER", \
    NAME="input/mx1000", mode=="0644"

On one of my systems, the idProduct value is simply c70a (i.e. without the "0x" at the beginning, so you'll have to poke around in /sys to find out what it says on your system. find /sys -name idProduct|xargs cat should tell you which format it's in on your system.

With these new settings in place, I simply stop and start udev, do the same with Xorg, and everything works perfectly. All the mouse buttons are correctly detected, and vertical and horizontal scroll work flawlessly. To get my thumb buttons working as forward and back buttons in firefox, I added xbindkeys to my .Xclients file (which I've got setup as a startup program in Gnome) and added the following to .xbindkeysrc:

# Backward and Forward buttons
"xvkbd -no-jump-pointer -no-repeat -xsendevent -text "\[Alt_L]\[Left]""
  m:0x10 + b:8
"xvkbd -no-jump-pointer -no-repeat -xsendevent -text "\[Alt_L]\[Right]""
  m:0x10 + b:9

I was getting repeated events, where a single click would back or forward up until it hit the end of history (very annoying) until I found a suggestion to add the -no-jump-pointer -no-repeat -xsendevent part to the configuration I had before. Now the buttons seem to work perfectly. I love the ability to navigate around websites just by clicking the buttons on my mouse. It's friendly to my wrists!

In conclusion, the Logitech MX 1000 is a fabulous mouse. It tracks remarkably well, feels good in my hand, and has buttons in the right places that really make a difference in my everyday computing experience. I've gotten so used to it that I had to buy a second mouse to use at home (I had been using the first only at work), because I just couldn't live without my tilt wheel and back and forward buttons. My only complaint about the hardware is that Logitech doesn't currently sell the Bluetooth version of the MX 1000 without a keyboard (in the MX 5000 bundle), which I don't use (although it makes my girlfriend happy to have a keyboard she can type on...I can't live without my Kinesis Advantage). With just a few steps, the mouse is easy to setup in Linux and X.org, and every feature of the mouse works perfectly. Kudos to the X.org developers who have made this configuration so much easier over the years!

Fun With VLANs [Permalink]

Thu Jan 05 00:06:33 EST 2006
Category [Linux]

My friend and I were just playing around with a nifty little layer 3 switch and its VLAN configuration, trying to configure our two laptops (both running Linux) to be on 3 VLANs, alternately talking to each other on trunked ports and non-trunked ports. We got everything running, then decided that since my buddy didn't have his wireless interface up, I'd have to act as a router (so that he could get to my wireless router).

Fun facts:

ifconfig showed:

eth0      Link encap:Ethernet  HWaddr 00:03:93:57:5C:84
          inet addr:10.1.1.5  Bcast:10.255.255.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4886 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4502 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:547752 (534.9 KiB)  TX bytes:1566811 (1.4 MiB)
          Interrupt:41 Base address:0x8400

eth1      Link encap:Ethernet  HWaddr 00:30:65:15:4B:65
          inet addr:192.168.1.102  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2484 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3512 errors:5 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1964059 (1.8 MiB)  TX bytes:584380 (570.6 KiB)
          Interrupt:57

eth0.2    Link encap:Ethernet  HWaddr 00:03:93:57:5C:84
          inet addr:10.2.2.5  Bcast:10.255.255.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2612 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1968 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:279104 (272.5 KiB)  TX bytes:1317923 (1.2 MiB)

eth0.3    Link encap:Ethernet  HWaddr 00:03:93:57:5C:84
          inet addr:10.3.3.5  Bcast:10.255.255.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1682 errors:0 dropped:0 overruns:0 frame:0
          TX packets:976 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:153488 (149.8 KiB)  TX bytes:97704 (95.4 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3869 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3869 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:365617 (357.0 KiB)  TX bytes:365617 (357.0 KiB)

I was able to use my laptop as a NATing router by running the following routing command:

sudo iptables -t nat -A POSTROUTING -s 10.2.2.10/24 -j SNAT --to-source 192.168.1.102

Our most fabulous setup was laptop A communicating to laptop B over VLAN 2, with laptop B trunked to VLANs 1-3, then laptop B performing NAT and forwarding packets over its other (wireless) interface) in order to get to my wireless access point, which performed NAT in order for us both to get to the larger Internet. Worked like a charm.

As a final test, we trunked both laptops to VLAN 2 and 3, configured laptop A with static host routes to the two IP addresses on laptop B, on VLAN 2 and 3 respectively, and tried to send a packet from the VLAN 2 interface on laptop A to the VLAN 3 interface on laptop A, with laptop B routing from VLAN 2 to VLAN 3. We didn't get that one to work, I think because the Linux kernel wasn't about to be fooled into thinking that it couldn't get to its own interface. We got some interesting packet traces, though.

23:57:28.392630 vlan 2, p 0, IP 10.2.2.10 > 10.3.3.10: ICMP echo request, id 33361, seq 13, length 64
23:57:28.392673 vlan 3, p 0, IP 10.2.2.10 > 10.3.3.10: ICMP echo request, id 33361, seq 13, length 64
23:57:29.393694 vlan 2, p 0, IP 10.2.2.10 > 10.3.3.10: ICMP echo request, id 33361, seq 14, length 64
23:57:29.393762 vlan 3, p 0, IP 10.2.2.10 > 10.3.3.10: ICMP echo request, id 33361, seq 14, length 64

Good times.

slow scp [Permalink]

Mon Sep 26 14:38:21 EDT 2005
Category [Linux]

I've noticed a number of times in the past that scp speed has been very slow when copying files over a fast local network. Today I ran into this problem again, seeing transfer speeds around 150KB/s on a 100BaseT network. I tried a few things to diagnose it this time, and found that transfers in the other direction (this is between two Linux systems of slightly different vintage and comparable hardware; CPU usage was close to zero on both machines) were much more reasonable, around 5MB/s. I then tried FTP in both directions and got similar speeds, so I can no longer attribut the problem to scp. A bit later, I remembered that my network interface wasn't correctly autodetecting and setting itself to full duplex on this link, so I set the link manually ("ethtool -s eth0 autoneg off duplex full") and the speed went right up. Now it's 5MB/s in both directions. (It was formally fast transferring from the machine that was already set to full duplex to the machine set to half duplex, and slow in the opposite direction.)

So my problem is solved, but I am left confused. 5MB/s sounds about right for a 100Mbit link, but only 150KB/s (maybe more like 120KB/s) for the half duplex link? That seems like too much speed drop just for running at half duplex. I could understand speeds more like 2MB/s, or even 1MB/s to account for more collisions, but 150KB/s? This seems especially strange considering that this is a one way transfer, since the only traffic coming from the other end should be transmission control packets. I don't have time or easy access to the server closet to watch the collision light, etc., to find out what's going on, so for now this will remain a mystery. At least I can get decent transfer speeds now.

Relief for the Impatient [Permalink]

Tue Aug 09 16:29:55 EDT 2005
Category [Linux]

Since I noticed a few weeks back that there is a Debian package for the X.Org server in unstable, I've been impatiently trying to install it every other day or so, hoping that it (and, more importantly, the packages on which it depends) will make its way into testing. Often have I longed for a less crude way to find out whether or not a package has made it into testing, and better yet, why it hasn't.

Now, my search is over.

This handy page shows not only which packages are stalled on which other packages, but how much of the quarantine period is remaining on each package and sometimes a reason why the package is stalled. This might not actually tell me how long it will take for xserver-xorg and its dependencies to get into testing, but it will certainly provide relief for my impatience, much as the tortilla chip relieves the hunger of a diner waiting for a delicious enchilada.