Shallow Thoughts : tags : networking

Raspberry Pi Zero as Ethernet Gadget Part 3: An Automated Script

Continuing the discussion of USB networking from a Raspberry Pi Zero or Zero W (Part 1: Configuring an Ethernet Gadget and Part 2: Routing to the Outside World): You've connected your Pi Zero to another Linux computer, which I'll call the gateway computer, via a micro-USB cable. Configuring the Pi end is easy. Configuring the gateway end is easy as long as you know the interface name that corresponds to the gadget.

ip link gave a list of several networking devices; on my laptop right now they include lo, enp3s0, wlp2s0 and enp0s20u1. How do you tell which one is the Pi Gadget? When I tested it on another machine, it showed up as enp0s26u1u1i1. Even aside from my wanting to script it, it's tough for a beginner to guess which interface is the right one.

Try dmesg

Sometimes you can tell by inspecting the output of dmesg | tail. If you run dmesg shortly after you initialized the gadget (either by plugging the USB cable into the gateway computer, you'll see some lines like:

[  639.301065] cdc_ether 3-1:1.0 enp0s20u1: renamed from usb0
[ 9458.218049] usb 3-1: USB disconnect, device number 3
[ 9458.218169] cdc_ether 3-1:1.0 enp0s20u1: unregister 'cdc_ether' usb-0000:00:14.0-1, CDC Ethernet Device
[ 9462.363485] usb 3-1: new high-speed USB device number 4 using xhci_hcd
[ 9462.504635] usb 3-1: New USB device found, idVendor=0525, idProduct=a4a2
[ 9462.504642] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 9462.504647] usb 3-1: Product: RNDIS/Ethernet Gadget
[ 9462.504660] usb 3-1: Manufacturer: Linux 4.14.50+ with 20980000.usb
[ 9462.506242] cdc_ether 3-1:1.0 usb0: register 'cdc_ether' at usb-0000:00:14.0-1, CDC Ethernet Device, f2:df:cf:71:b9:92
[ 9462.523189] cdc_ether 3-1:1.0 enp0s20u1: renamed from usb0

(Aside: whose bright idea was it that it would be a good idea to rename usb0 to enp0s26u1u1i1, or wlan0 to wlp2s0? I'm curious exactly who finds their task easier with the name enp0s26u1u1i1 than with usb0. It certainly complicated all sorts of network scripts and howtos when the name wlan0 went away.)

Anyway, from inspecting that dmesg output you can probably figure out the name of your gadget interface. But it would be nice to have something more deterministic, something that could be used from a script. My goal was to have a shell function in my .zshrc, so I could type pigadget and have it set everything up automatically. How to do that?

A More Deterministic Way

First, the name starts with en, meaning it's an ethernet interface, as opposed to wi-fi, loopback, or various other types of networking interface. My laptop also has a built-in ethernet interface, enp3s0, as well as lo0, the loopback or "localhost" interface, and wlp2s0, the wi-fi chip, the one that used to be called wlan0.

Second, it has a 'u' in the name. USB ethernet interfaces start with en and then add suffixes to enumerate all the hubs involved. So the number of 'u's in the name tells you how many hubs are involved; that enp0s26u1u1i1 I saw on my desktop had two hubs in the way, the computer's internal USB hub plus the external one sitting on my desk.

So if you have no USB ethernet interfaces on your computer, looking for an interface name that starts with 'en' and has at least one 'u' would be enough. But if you have USB ethernet, that won't work so well.

Using the MAC Address

You can get some useful information from the MAC address, called "link/ether" in the ip link output. In this case, it's f2:df:cf:71:b9:92, but -- whoops! -- the next time I rebooted the Pi, it became ba:d9:9c:79:c0:ea. The address turns out to be randomly generated and will be different every time. It is possible to set it to a fixed value, and that thread has some suggestions on how, but I think they're out of date, since they reference a kernel module called g_ether whereas the module on my updated Raspbian Stretch is called cdc_ether. I haven't tried.

Anyway, random or not, the MAC address also has one useful property: the first octet (f2 in my first example) will always have the '2' bit set, as an indicator that it's a "locally administered" MAC address rather than one that's globally unique. See the Wikipedia page on MAC addressing for details on the structure of MAC addresses. Both f2 (11110010 in binary) and ba (10111010 binary) have the 2 (00000010) bit set.

No physical networking device, like a USB ethernet dongle, should have that bit set; physical devices have MAC addresses that indicate what company makes them. For instance, Raspberry Pis with networking, like the Pi 3 or Pi Zero W, have interfaces that start with b8:27:eb. Note the 2 bit isn't set in b8.

Most people won't have any USB ethernet devices connected that have the "locally administered" bit set. So it's a fairly good test for a USB ethernet gadget.

Turning That Into a Shell Script

So how do we package that into a pipeline so the shell -- zsh, bash or whatever -- can check whether that 2 bit is set?

First, use ip -o link to print out information about all network interfaces on the system. But really you only need the ones starting with en and containing a u. Splitting out the u isn't easy at this point -- you can check for it later -- but you can at least limit it to lines that have en after a colon-space. That gives output like:

$ ip -o link | grep ": en"
5: enp3s0:  mtu 1500 qdisc pfifo_fast state DOWN mode DEFAULT group default qlen 1000\    link/ether 74:d0:2b:71:7a:3e brd ff:ff:ff:ff:ff:ff
8: enp0s20u1:  mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000\    link/ether f2:df:cf:71:b9:92 brd ff:ff:ff:ff:ff:ff

Within that, you only need two pieces: the interface name (the second word) and the MAC address (the 17th word). Awk is a good tool for picking particular words out of an output line:

$ ip -o link | grep ': en' | awk '{print $2, $17}'
enp3s0: 74:d0:2b:71:7a:3e
enp0s20u1: f2:df:cf:71:b9:92

The next part is harder: you have to get the shell to loop over those output lines, split them into the interface name and the MAC address, then split off the second character of the MAC address and test it as a hexadecimal number to see if the '2' bit is set. I suspected that this would be the time to give up and write a Python script, but no, it turns out zsh and even bash can test bits:

ip -o link | grep en | awk '{print $2, $17}' | \
    while read -r iff mac; do
        # LON is a numeric variable containing the digit we care about.
        # The "let" is required so LON will be a numeric variable,
        # otherwise it's a string and the bitwise test fails.
        let LON=0x$(echo $mac | sed -e 's/:.*//' -e 's/.//')

        # Is the 2 bit set? Meaning it's a locally administered MAC
        if ((($LON & 0x2) != 0)); then
            echo "Bit is set, $iff is the interface"
        fi
    done

Pretty neat! So now we just need to package it up into a shell function and do something useful with $iff when you find one with the bit set: namely, break out of the loop, call ip a add and ip link set to enable networking to the Raspberry Pi gadget, and enable routing so the Pi will be able to get to networks outside this one. Here's the final function:

# Set up a Linux box to talk to a Pi0 using USB gadget on 192.168.0.7:
pigadget() {
    iface=''

    ip -o link | grep en | awk '{print $2, $17}' | \
        while read -r iff mac; do
            # LON is a numeric variable containing the digit we care about.
            # The "let" is required so zsh will know it's numeric,
            # otherwise the bitwise test will fail.
            let LON=0x$(echo $mac | sed -e 's/:.*//' -e 's/.//')

            # Is the 2 bit set? Meaning it's a locally administered MAC
            if ((($LON & 0x2) != 0)); then
                iface=$(echo $iff | sed 's/:.*//')
                break
            fi
        done

    if [[ x$iface == x ]]; then
        echo "No locally administered en interface:"
        ip a | egrep '^[0-9]:'
        echo Bailing.
        return
    fi

    sudo ip a add 192.168.7.1/24 dev $iface
    sudo ip link set dev $iface up

    # Enable routing so the gadget can get to the outside world:
    sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
    sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
}

Tags: raspberry pi, linux, networking
[ 18:41 Sep 03, 2018    More linux | permalink to this entry | ]

Raspberry Pi Zero as Ethernet Gadget Part 2: Routing to the Outside World

I wrote some time ago about how to use a Raspberry Pi over USB as an "Ethernet Gadget". It's a handy way to talk to a headless Pi Zero or Zero W if you're somewhere where it doesn't already have a wi-fi network configured.

However, the setup I gave in that article doesn't offer a way for the Pi Zero to talk to the outside world. The Pi is set up to use the machine on the other end of the USB cable for routing and DNS, but that doesn't help if the machine on the other end isn't acting as a router or a DNS host.

A lot of the ethernet gadget tutorials I found online explain how to do this on Mac and Windows, but it was tough to find an example for Linux. The best I found was for Slackware, How to connect to the internet over USB from the Raspberry Pi Zero, which should work on any Linux, not just Slackware.

Let's assume you have the Pi running as a gadget and you can talk to it, as discussed in the previous article, so you've run:

sudo ip a add 192.168.7.1/24 dev enp0s20u1
sudo ip link set dev enp0s20u1 up

substituting your network number and the interface name that the Pi created on your Linux machine, which you can find in dmesg | tail or ip link. (In Part 3 I'll talk more about how to find the right interface name if it isn't obvious.)

At this point, the network is up and you should be able to ping the Pi with the address you gave it, assuming you used a static IP: ping 192.168.7.2 If that works, you can ssh to it, assuming you've enabled ssh. But from the Pi's end, all it can see is your machine; it can't get out to the wider world.

For that, you need to enable IP forwarding and masquerading:

sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Now the Pi can route to the outside world, but it still doesn't have DNS so it can't get any domain names. To test that, on the gateway machine try pinging some well-known host:

$ ping -c 2 google.com
PING google.com (216.58.219.110) 56(84) bytes of data.
64 bytes from mia07s25-in-f14.1e100.net (216.58.219.110): icmp_seq=1 ttl=56 time=78.6 ms
64 bytes from mia07s25-in-f14.1e100.net (216.58.219.110): icmp_seq=2 ttl=56 time=78.7 ms

--- google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 78.646/78.678/78.710/0.032 ms

Take the IP address from that -- e.g. 216.58.219.110 -- then go to a shell on the Pi and try ping -c 2 216.58.219.110, and you should see a response.

DNS with a Public DNS Server

Now all you need is DNS. The easy way is to use one of the free DNS services, like Google's 8.8.8.8. Edit /etc/resolv.conf and add a line like

nameserver 8.8.8.8

and then try pinging some well-known hostname.

If it works, you can make that permanent by editing /etc/resolv.conf, and adding this line:

name_servers=8.8.8.8

Otherwise you'll have to do it every time you boot.

Your Own DNS Server

But not everyone wants to use public nameservers like 8.8.8.8. For one thing, there are privacy implications: it means you're telling Google about every site you ever use for any reason.

Fortunately, there's an easy way around that, and you don't even have to figure out how to configure bind/named. On the gateway box, install dnsmasq, available through your distro's repositories. It will use whatever nameserver you're already using on that machine, and relay it to other machines like your Pi that need the information. I didn't need to configure it at all; it worked right out of the box.

In the next article, Part 3: more about those crazy interface names (why is it enp0s20u1 on my laptop but enp0s26u1u1i1 on my desktop?), how to identify which interface is the gadget by using its MAC, and how to put it all together into a shell function so you can set it up with one command.

Tags: raspberry pi, linux, networking
[ 15:25 Aug 31, 2018    More linux | permalink to this entry | ]

Raspberry Pi Console over USB: Configuring an Ethernet Gadget

When I work with a Raspberry Pi from anywhere other than home, I want to make sure I can do what I need to do without a network.

With a Pi model B, you can use an ethernet cable. But that doesn't work with a Pi Zero, at least not without an adapter. The lowest common denominator is a serial cable, and I always recommend that people working with headless Pis get one of these; but there are a lot of things that are difficult or impossible over a serial cable, like file transfer, X forwarding, and running any sort of browser or other network-aware application on the Pi.

Recently I learned how to configure a Pi Zero as a USB ethernet gadget, which lets you network between the Pi and your laptop using only a USB cable. It requires a bit of setup, but it's definitely worth it. (This apparently only works with Zero and Zero W, not with a Pi 3.)

The Cable

The first step is getting the cable. For a Pi Zero or Zero W, you can use a standard micro-USB cable: you probably have a bunch of them for charging phones (if you're not an Apple person) and other devices.

Set up the Pi

Setting up the Raspberry Pi end requires editing two files in /boot, which you can do either on the Pi itself, or by mounting the first SD card partition on another machine.

In /boot/config.txt add this at the end:

dtoverlay=dwc2

In /boot/cmdline.txt, at the end of the long list of options but on the same line, add a space, followed by: modules-load=dwc2,g_ether

Set a static IP address

This step is optional. In theory you're supposed to use some kind of .local address that Bonjour (the Apple protocol that used to be called zeroconf, and before that was called Rendezvous, and on Linux machines is called Avahi). That doesn't work on my Linux machine. If you don't use Bonjour, finding the Pi over the ethernet link will be much easier if you set it up to use a static IP address. And since there will be nobody else on your USB network besides the Pi and the computer on the other end of the cable, there's no reason not to have a static address: you're not going to collide with anybody else.

You could configure a static IP in /etc/network/interfaces, but that interferes with the way Raspbian handles wi-fi via wpa_supplicant and dhcpcd; so you'd have USB networking but your wi-fi won't work any more.

Instead, configure your address in Raspbian via dhcpcd. Edit /etc/dhcpcd.conf and add this:

interface usb0
static ip_address=192.168.7.2
static routers=192.168.7.1
static domain_name_servers=192.168.7.1

This will tell Raspbian to use address 192.168.7.2 for its USB interface. You'll set up your other computer to use 192.168.7.1.

Now your Pi should be ready to boot with USB networking enabled. Plug in a USB cable (if it's a model A or B) or a micro USB cable (if it's a Zero), plug the other end into your computer, then power up the Pi.

Setting up a Linux machine for USB networking

The final step is to configure your local computer's USB ethernet to use 192.168.7.1.

On Linux, find the name of the USB ethernet interface. This will only show up after you've booted the Pi with the ethernet cable plugged in to both machines.

ip a

The USB interface will probably start eith en and will probably be the last interface shown.

On my Debian machine, the USB network showed up as enp0s26u1u1. So I can configure it thusly (as root, of course):

ip a add 192.168.7.1/24 dev enp0s26u1u1
ip link set dev enp0s26u1u1 up

(You can also use the older ifconfig rather than ip: sudo ifconfig enp0s26u1u1 192.168.7.1 up)

You should now be able to ssh into your Raspberry Pi using the address 192.168.7.2, and you can make an appropriate entry in /etc/hosts, if you wish.

For a less hands-on solution, if you're using Mac or Windows, try Adafruit's USB gadget tutorial. It's possible that might also work for Linux machines running Avahi. If you're using Windows, you might prefer CircuitBasics' ethernet gadget tutorial.

Happy networking!

Update: there's now a Part 2: Routing to the Outside World and Part 3: an Automated Script.

Tags: raspberry pi, linux, networking
[ 14:53 Feb 02, 2018    More linux | permalink to this entry | ]

How to talk to your Rapsberry Pi over an ethernet crossover cable with IP masquerading

I've been using my Raspberry Pi mostly headless -- I'm interested in using it to control hardware. Most of my experimenting is at home, where I can plug the Pi's built-in ethernet directly into the wired net.

But what about when I venture away from home, perhaps to a group hacking session, or to give a talk? There's no wired net at most of these places, and although you can buy USB wi-fi dongles, wi-fi is so notoriously flaky that I'd never want to rely on it, especially as my only way of talking to the Pi.

Once or twice I've carried a router along, so I could set up my own subnet -- but that means an extra device, ten times as big as the Pi, and needing its own power supply in a place where power plugs may be scarce.

The real solution is a crossover ethernet cable. (My understanding is that you can't use a normal ethernet cable between two computers; the data send and receive lines will end up crossed. Though I may be wrong about that -- one person on #raspberrypi reported using a normal ethernet cable without trouble.)

Buying a crossover cable at Fry's was entertaining. After several minutes of staring at the dozens of bins of regular ethernet cables, I finally found the one marked crossover, and grabbed it. Immediately, a Fry's employee who had apparently been lurking in the wings rushed over to warn me that this wasn't a normal cable, this wasn't what I wanted, it was a weird special cable. I thanked him and assured him that was exactly what I'd come to buy.

Once home, with my laptop connected to wi-fi, I plugged one end into the Pi and the other end into my laptop ... and now what? How do I configure the network so I can talk to the Pi from the laptop, and the Pi can gateway through the laptop to the internet?

The answer is IP masquerading. Originally I'd hoped to give the Pi a network address on the same networking (192.168.1) as the laptop. When I use the Pi at home, it picks a network address on 192.168.1, and it would be nice not to have to change that when I travel elsewhere. But if that's possible, I couldn't find a way to do it.

Okay, plan B: the laptop is on 192.168.1 (or whatever network the wi-fi happens to assign), while the Pi is on a diffferent network, 192.168.0. That was relatively easy, with some help from the Masquerading Simple Howto.

Once I got it working, I wrote a script, since there are quite a few lines to type and I knew I wouldn't remember them all. Of course, the script has to be run as root. Here's the script, on github: masq.

I had to change one thing from the howto: at the end, when it sets up security, this line is supposed to enable incoming connections on all interfaces except wlan0:

iptables -A INPUT -m state --state NEW -i ! wlan0 -j ACCEPT

But that gave me an error, Bad argument `wlan0'. What worked instead was

iptables -A INPUT -m state --state NEW ! -i wlan0 -j ACCEPT

Only a tiny change: swap the order of -i and !. (I sent a correction to the howto authors but haven't heard back yet.)

All set! It's a nice compact way to talk to your Pi anywhere. Of course, don't forget to label your crossover cable, so you don't accidentally try to use it as a regular ethernet cable. Now please excuse me while I go label mine.

Update: Ed Davies has a great followup, Crossover Cables and Red Tape, that talks about how to set up a subnet if you don't need the full masquerading setup, why non-crossover cables might sometimes work, and a good convention for labeling crossover cables: use red tape. I'm going to adopt that convention too -- thanks, Ed!

Tags: raspberry pi, hardware, linux, networking, maker
[ 16:57 Nov 09, 2012    More hardware | permalink to this entry | ]

Find out what processes are making network connections

A thread on the Ubuntu-devel-discuss mailing list last month asked about how to find out what processes are making outgoing network connectsion on a Linux machine. It referenced Ubuntu bug 820895: Log File Viewer does not log "Process Name", which is specific to Ubuntu's iptables logging of apps that are already blocked in iptables ... but the question goes deeper.

Several years ago, my job required me to use a program -- never mind which one -- from a prominent closed-source company. This program was doing various annoying things in addition to its primary task -- operations that got around the window manager and left artifacts all over my screen, operations that potentially opened files other than the ones I asked it to open -- but in addition, I noticed that when I ran the program, the lights on the DSL modem started going crazy. It looked like the program was making network connections, when it had no reason to do that. Was it really doing that?

Unfortunately, at the time I couldn't find any Linux command that would tell me the answer. As mentioned in the above Ubuntu thread, there are programs for Mac and even Windows to tell you this sort of information, but there's no obvious way to find out on Linux.

The discussion ensuing in the ubuntu-devel-discuss thread tossed around suggestions like apparmor and selinux -- massive, complex ways of putting up fortifications your whole system. But nobody seemed to have a simple answer to how to find information about what apps are making network connections.

Well, it turns out there are a a couple ofsimple way to get that list. First, you can use ss:

$ ss -tp
State      Recv-Q Send-Q      Local Address:Port          Peer Address:Port   
ESTAB      0      0                     ::1:58466                  ::1:ircd     users:(("xchat",1063,43))
ESTAB      0      0             192.168.1.6:57526       140.211.166.64:ircd     users:(("xchat",1063,36))
ESTAB      0      0                     ::1:ircd                   ::1:58466    users:(("bitlbee",1076,10))
ESTAB      0      0             192.168.1.6:54253       94.125.182.252:ircd     users:(("xchat",1063,24))
ESTAB      0      0             192.168.1.6:52167       184.72.217.144:https
users:(("firefox-bin",1097,47))

Update: you might also want to add listening connections where programs are listening for incoming connections: ss -tpla
Though this may be less urgent if you have a firewall in place.

-t shows only TCP connections (so you won't see all the interprocess communication among programs running on your machine). -p prints the process associated with each connection.

ss can do some other useful things, too, like show all the programs connected to your X server right now, or show all your ssh connections. See man ss for examples.

Or you can use netstat:

$ netstat -A inet -p
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 imbrium.timochari:51800 linuxchix.osuosl.o:ircd ESTABLISHED 1063/xchat      
tcp        0      0 imbrium.timochari:59011 ec2-107-21-74-122.:ircd ESTABLISHED 1063/xchat      
tcp        0      0 imbrium.timochari:54253 adams.freenode.net:ircd ESTABLISHED 1063/xchat      
tcp        0      0 imbrium.timochari:58158 s3-1-w.amazonaws.:https ESTABLISHED
1097/firefox-bin

In both cases, the input is a bit crowded and hard to read. If all you want is a list of processes making connections, that's easy enough to do with the usual Unix utilities like grep and sed:

$ ss -tp | grep -v Recv-Q | sed -e 's/.*users:(("//' -e 's/".*$//' | sort | uniq
$ netstat -A inet -p | grep '^tcp' | grep '/' | sed 's_.*/__' | sort | uniq

Finally, you can keep an eye on what's going on by using watch to run one of these commands repeatedly:

watch ss -tp

Using watch with one of the pipelines to print only process names is possible, but harder since you have to escape a lot of quotation marks. If you want to do that, I recommend writing a script.

And back to the concerns expressed on the Ubuntu thread, you could also write a script to keep logs of which processes made connections over the course of a day. That's definitely a tool I'll keep in my arsenal.

Tags: networking, linux, networking, cmdline
[ 12:28 Mar 24, 2012    More linux | permalink to this entry | ]

Upgraded to Intrepid: X keyboard options and losing network after suspend

I finally got around to upgrading to the current Ubuntu, Intrepid Ibex. I know Intrepid has been out for months and Jaunty is just around the corner; but I was busy with the run-up to a couple of important conferences when Intrepid came out, and couldn't risk an upgrade. Better late than never, right?

The upgrade went smoothly, though with the usual amount of babysitting, watching messages scroll by for a couple of hours so that I could answer the questions that popped up every five or ten minutes. Question: Why, after all these years of software installs, hasn't anyone come up with a way to ask all the questions at the beginning, or at the end, so the user can go have dinner or watch a movie or sleep or do anything besides sit there for hours watching messages scroll by?

XKbOptions: getting Ctrl/Capslock back

The upgrade finished, I rebooted, everything seemed to work ... except my capslock key wasn't doing ctrl as it should. I checked /etc/X11/xorg.conf, where that's set ... and found the whole file commented out, preceded by the comment:

# commented out by update-manager, HAL is now used

Oh, great. And thanks for the tip on where to look to get my settings back. HAL, that really narrows it down.

Google led me to a forum thread on Intrepid xorg.conf - input section. The official recommendation is to run sudo dpkg-reconfigure console-setup ... but of course it doesn't allow for options like ctrl/capslock. (It does let you specify which key will act as the Compose key, which is thoughtful.)

Fortunately, the release notes give the crucial file name: /etc/default/console-setup. The XKBOPTIONS= line in that file is what I needed.

It also had the useful XKBOPTIONS="compose:menu" option left over from my dpkg-configure run. I hadn't known about that before; I'd been using xmodmap to set my multi key. So my XKBOPTIONS now looks like: "ctrl:nocaps,compose:menu".

Fixing the network after resume from suspend

Another problem I hit was suspending on my desktop machine. It still suspended, but after resuming, there was no network. The problem turned out to lie in /etc/acpi/suspend.d/55-down-interfaces.sh. It makes a list of interfaces which should be brought up and down like this:

IFDOWN_INTERFACES="`cat /etc/network/run/ifstate | sed 's/=.*//'`"
IFUP_INTERFACES="`cat /etc/network/run/ifstate`"

However, there is no file /etc/network/run/ifstate, so this always fails and so /etc/acpi/resume.d/62-ifup.sh fails to bring up the network.

Google to the rescue again. The bad thing about Ubuntu is that they change random stuff so things break from release to release. The good thing about Ubuntu is a zillion other people run it too, so whatever problem you find, someone has already written about. Turns out ifstate is actually in /var/run/network/ifstate now, so making that change in /etc/acpi/suspend.d/55-down-interfaces.sh fixes suspend/resume. It's bug 295544, fixed in Jaunty and nominated for Intrepid (I just learned about the "Nominate for release" button, which I'd completely missed in the past -- very useful!) Should be interesting to see if the fix gets pushed to Intrepid, since networking after resume is completely broken without it.

Otherwise, it was a very clean upgrade -- and now I can build the GIMP trunk again, which was really the point of the exercise.

Tags: ubuntu, linux, install, X11, networking
[ 18:28 Mar 11, 2009    More linux/install | permalink to this entry | ]

Updated Network Schemes page

I've used my simple network schemes setup for many years. No worries about how distros come up with a new network configuration GUI every release; no worries about all the bloat that NetworkManager insists on before it will run; no extra daemons running all the time polling my net just in case I might want to switch networks suddenly. It's all command-line based; if I'm at home, I type

netscheme home

and my network will be configured for that setup until I tell it otherwise. If I go to a cafe with an open wi-fi link, I type netscheme wifi; I have other schemes for places I go where I need a wireless essid or WEP key. It's all very easy and fast.

Last week for SCALE I decided it was silly to have to su and create a new scheme file for conferences where all I really needed was the name of the network (the essid), so I added a quick hack to my netscheme script so that typing netscheme foo, where there's no existing scheme by that name, will switch to a scheme using foo as the essid. Worked nicely, and that inspired me to update the "documentation".

I wrote an elaborate page on my network schemes back around 2003, but of course it's all changed since then and I haven't done much toward updating the page. So I've rewritten it completely, taking out most of the old cruft that doesn't seem to apply any more. It's here: Howto Set Up Multiple Network Schemes on a Linux Laptop.

Tags: linux, laptop, networking
[ 10:51 Feb 27, 2009    More linux/laptop | permalink to this entry | ]

Handling a network card automatically: Calling ifup from udev

I'm experimenting with Ubuntu's "Hardy Heron" beta on the laptop, and one problem I've hit is that it never configures my network card properly.

The card is a cardbus 3Com card that uses the 3c59x driver. When I plug it in, or when I boot or resume after a suspend, the card ends up in a state where it shows up in ifconfig eth0, but it isn't marked UP. ifup eth0 says it's already up; ifdown eth0 complains error: SIOCDELRT: No such process but afterward, I can run ifup eth0 and this time it works. I've made an alias, net, that does sudo ifdown eth0; sudo ifup eth0. That's silly -- I wanted to fix it so it happened automatically.

Unfortunately, there's nothing written anywhere on debugging udev. I fiddled a little with udevmonitor and udevtest /class/net/eth0 and it looked like udev was in fact running the ifup rule in /etc/udev/rules.d/85-ifupdown.rules, which calls: /sbin/start-stop-daemon --start --background --pid file /var/run/network/bogus --startas /sbin/ifup -- --allow auto $env{INTERFACE} So I tried running that by hand (with $env{INTERFACE} being eth0) and, indeed, it didn't bring the interface up.

But that suggested a fix: how about adding --force to that ifup line? I don't know why the card is already in a state where ifup doesn't want to handle it, but it is, and maybe --force would fix it. Sure enough: that worked fine, and it even works when resuming after a suspend.

I filed bug 211955 including a description of the fix. Maybe there's some reason for not wanting to use --force in 85-ifupdown (why wouldn't you always want to configure a network card when it's added and is specified as auto and allow-hotplug in /etc/network/interfaces?) but if so, maybe someone will suggest a better fix.

Tags: linux, ubuntu, udev, networking
[ 14:41 Apr 04, 2008    More linux | permalink to this entry | ]

Gutsy's persistent net rules don't persist

I use wireless so seldom that it seems like each time I need it, it's a brand new adventure finding out what has changed since the last time to make it break in a new and exciting way.

This week's wi-fi adventure involved Ubuntu's current "Gutsy Gibbon" release and my prism54 wireless card. I booted the machine, switched to the right (a href="http://shallowsky.com/linux/networkSchemes.html">network scheme, inserted the card, and ... no lights. ifconfig -a showed the card on eth1 rather than eth0.

After some fiddling, I ejected the card and re-inserted it; now ifconfig -a showed it on eth2. Each time I inserted it, the number incremented by one.

Ah, that's something I remembered from Debian Etch -- a problem with the udev "persistent net rules" file in /etc/udev.

Sure enough, /etc/udev/70-persistent-net.rules had two entries for the card, one on eth1 and the other on eth2. Ejecting and re-inserting added another one for eth3. Since my network scheme is set up to apply to eth0, this obviously wouldn't work.

A comment in that file says it's generated from 75-persistent-net-generator.rules. But unfortunately, the rules uesd by that file are undocumented and opaque -- I've never been able to figure out how to make a change in its behavior. I fiddled around for a bit, then gave up and chose the brute force solution:

• Remove /etc/udev/75-persistent-net-generator.rulesa
• Edit /etc/udev/70-persistent-net.rules to give the device the right name (eth1, eth0 or whatever).

And that worked fine. Without 75-persistent-net-generator.rules getting in the way, the name seen in 70-persistent-net.rules works fine and I'm able to use the network.

The weird thing about this is that I've been using Gutsy with my wired network card (a 3com) for at least a month now without this problem showing up. For some reason, the persistent net generator doesn't work for the Prism54 card though it works fine for the 3com. A scan of the Ubuntu bug repository reveals lots of other people hitting similar problems on an assortment of wireless cards; bug 153727 is a fairly typical report, but the older bug 31502 (marked as fixed) points to a likely reason this is apparently so common on wireless cards -- apparently some of them report the wrong MAC address before the firmware is loaded.

Tags: linux, ubuntu, udev, networking
[ 19:02 Dec 23, 2007    More linux | permalink to this entry | ]

The Importance of Being ESSID (simple Linux wi-fi troubleshooting)

I'm forever having problems connecting to wireless networks, especially with my Netgear Prism 54 card. The most common failure mode: I insert the card and run /etc/init.d/networking restart (udev is supposed to handle this, but that stopped working a month or so ago). The card looks like it's connecting, ifconfig eth0 says it has the right IP address and it's marked up -- but try to connect anywhere and it says "no route to host" or "Destination host unreachable".

I've seen this both on networks which require a WEP key and those that don't, and on nets where my older Prism2/Orinoco based card will connect fine.

Apparently, the root of the problem is that the Prism54 is more sensitive than the Prism2: it can see more nearby networks. The Prism2 (with the orinoco_cs driver) only sees the strongest network, and gloms onto it. But the Prism54 chooses an access point according to arcane wisdom only known to the driver developers. So even if you're sitting right next to your access point and the next one is half a block away and almost out of range, you need to specify which one you want. How do you do that? Use the ESSID.

Every wireless network has a short identifier called the ESSID to distinguish it from other nearby networks. You can list all the access points the card sees with:

iwlist eth0 scan

(I'll be assuming eth0 as the ethernet device throughout this article. Depending on your distro and hardware, you may need to substitute ath0 or eth1 or whatever your wireless card calls itself. Some cards don't support scanning, but details like that seem to be improving in recent kernels.)

You'll probably see a lot of ESSIDs like "linksys" or "default" or "OEM" -- the default values on typical low-cost consumer access points. Of course, you can set your own access point's ESSID to anything you want.

So what if you think your wireless card should be working, but it can't connect anywhere? Check the ESSID first. Start with iwconfig:

iwconfig eth0

iwconfig lists the access point associated with the card right now. If it's not the one you expect, there are two ways to change that.

First, change it temporarily to make sure you're choosing the right ESSID:

iwconfig eth0 essid MyESSID

If your accesspoint requires a key, add key nnnnnnnnnn to the end of that line. Then see if your network is working.

If that works, you can make it permanent. On Debian-derived distros, just add lines to the entry in /etc/network/interfaces:

wireless-essid MyESSID
wireless-key nnnnnnnnnn

Some older howtos may suggest an interfaces line that looks like this:
up iwconfig eth0 essid MyESSID
Don't get sucked in. This "up" syntax used to work (along with pre-up and post-up), but although man interfaces still mentions it, it doesn't work reliably in modern releases. Use wireless-essid instead.

Of course, you can also use a gooey tool like gnome-network-manager to set the essid and key. Not being a gnome user, some time ago I hacked up the beginnings of a standalone Python GTK tool to configure networks. During this week's wi-fi fiddlings, I dug it out and blew some of the dust off: wifi-picker.

You can choose from a list of known networks (including both essid and key) set up in your own configuration file, or from a list of essids currently visible to the card, and (assuming you run it as root) it can then set the essid and key to whatever you choose. For networks I use often, I prefer to set up a long-term network scheme, but it's fun to have something I can run once to show me the visible networks then let me set essid and key.

Tags: linux, networking, debian, ubuntu
[ 15:44 Aug 18, 2007    More linux | permalink to this entry | ]

Etch: Blacklisting Modules, Udev, and Firewire Networking

The new Debian Etch installation on my laptop was working pretty well. But it had one weirdness: the ethernet card was on eth1, not eth0. ifconfig -a revealed that eth0 was ... something else, with no IP address configured and a really long MAC address. What was it?

Poking around dmesg revealed that it was related to the IEEE 1394 and the eth1394 module. It was firewire networking.

This laptop, being a Vaio, does have a built-in firewire interface (Sony calls it i.Link). The Etch installer, when it detected no network present, had noted that it was "possible, though unlikely" that I might want to use firewire instead, and asked whether to enable it. I declined.

Yet the installed system ended up with firewire networking not only installed, but taking the first network slot, ahead of any network cards. It didn't get in the way of functionality, but it was annoying and clutters the output whenever I type ifconfig -a. Probably took up a little extra boot time and system resources, too. I wanted it gone.

Easier said than done, as it turns out.

I could see two possible approaches.

1. Figure out who was setting it to eth1, and tell it to ignore the device instead.
2. Blacklist the kernel module, so it couldn't load at all.

I begain with approach 1. The obvious culprit, of course, was udev. (I had already ruled out hal, by removing it, rebooting and observing that the bogus eth0 was still there.) Poking around /etc/udev/rules.d revealed the file where the naming was happening: z25_persistent-net.rules.

It looks like all you have to do is comment out the two lines for the firewire device in that file. Don't believe it. Upon reboot, udev sees the firewire devices and says "Oops! persistent-net.rules doesn't have a rule for this device. I'd better add one!" and you end up with both your commented-out line, plus a brand new uncommented line. No help.

Where is that controlled? From another file, z45_persistent-net-generator.rules. So all you have to do is edit that file and comment out the lines, right?

Well, no. The firewire lines in that file merely tell udev how to add a comment when it updates z25_persistent-net.rules. It still updates the file, it just doesn't comment it as clearly.

There are some lines in z45_persistent-net-generator.rules whose comments say they're disabling particular devices, by adding a rule GOTO="persistent_net_generator_end". But adding that in the firewire device lines caused the boot process to hang. There may be a way to ignore a device from this file, but I haven't found it, nor any documentation on how this system works.

Defeated, I switched to approach 2: prevent the module from loading at all. I never expect to use firewire networking, so it's no loss. And indeed, there are lots of other modules loaded I'd like to blacklist, since they represent hardware this machine doesn't have. So it would be nice to learn how.

I had a vague memory of there having been a file with a name like /etc/modules.blacklist some time back in the Pliocene. But apparently no such file exists any more. I did find /etc/modprobe.d/blacklist, which looked promising; but the comment at the beginning of that file says

# This file lists modules which will not be loaded as the result of
# alias expsnsion, with the purpose of preventing the hotplug subsystem
# to load them. It does not affect autoloading of modules by the kernel.

Okay, sounds like this file isn't what I wanted. (And ... hotplug? I thought that was long gone, replaced by udev scripts.) I tried it anyway. Sure enough, not what I wanted.

I fiddled with several other approaches before Debian diva Erinn Clark found this helpful page. I created a file called /etc/modprobe.d/00local and added this line to it:

install eth1394 /bin/true

and on the next boot, the module was no longer loaded, and no longer showed up as a bogus ethernet device. Hurray!

This /etc/modprobe.d/00local technique probably doesn't bear examining too closely. It has "hack" written all over it. But if that's the only way to blacklist problematic modules, I guess it's better than nothing.

Tags: linux, debian, kernel, networking
[ 19:10 May 15, 2007    More linux | permalink to this entry | ]

The Amazing Disappearing Nameservers

I updated my Ubuntu "dapper" yesterday. When I booted this morning, I couldn't get to any outside sites: no DNS. A quick look at /etc/resolv.conf revealed that it was empty -- my normal static nameservers were missing -- except for a comment indicating that the file is prone to be overwritten at any moment by a program called resolvconf.

man resolvconf provided no enlightenment. Clearly it's intended to work with packages such as PPP which get dynamic network information, but that offered no clue as to why it should be operating on a system with a static IP address and static nameservers.

The closest Ubuntu bug I found was bug 31057. The Ubuntu developer commenting in the bug asserts that resolvconf is indeed the program at fault. The bug reporter disputes this, saying that resolvconf isn't even installed on the machine. So the cause is still a mystery.

After editing /etc/resolv.conf to restore my nameservers, I uninstalled resolvconf along with some other packages that I clearly don't need on this machine, hoping to prevent the problem from happening again:

aptitude purge resolvconf ppp pppconfig pppoeconf ubuntu-standard wvdial

Meanwhile, I did some reading. It turns out that resolvconf depends on an undocumented bit of information added to the /etc/network/interfaces file: lines like

dns-nameservers 192.168.1.1 192.168.1.2

This is not documented under man interfaces, nor under man resolvconf; it turns out that you're supposed to find out about it from /usr/share/doc/resolvconf/README.gz. But of course, since it isn't a standard part of /etc/network/interfaces, no automatic configuration programs will add the DNS lines there for you. Hope you read the README!

resolvconf isn't inherently a bad idea, actually; it's supposed to replace any old "up" commands in interfaces that copy resolv.conf files into place. Having all the information in the interfaces file would be a better solution, if it were documented and supported.

Meanwhile, be careful about resolvconf, which you may have even if you never intentionally installed it. This thread on a Debian list discusses the problem briefly, and this reply quotes the relevant parts of the resolvconf README (in case you're curious but have already removed resolvconf in a fit of pique).

Tags: linux, ubuntu, networking
[ 15:22 Mar 15, 2006    More linux | permalink to this entry | ]

Enabling Remote X

Another in the series of "I keep forgetting how to do this and have to figure it out again each time, so this time I'm going to write it down!"

Enabling remote X in a distro that disables it by default:

Of course, you need xhost. For testing, xhost + enables access from any machine; once everything is working, you may want to be selective, xhost hostname for the hosts from which you're likely to want to connect.

If you log in to the console and start X, check /etc/X11/xinit/xserverrc and see if it starts X with the -nolisten flag. This is usually the problem, at least on Debian derivatives: remove the -nolisten tcp.

If you log in using gdm, gdmconfig has an option in the Security tab: "Always disallow TCP connections to X server (disables all remote connections)". Un-checking this solves the problem, but logging out won't be enough to see the change. You must restart X; Ctrl-Alt-Backspace will do that.

Update: If you use kdm, the configuration to change is in /etc/kde3/kdm/kdmrc

Tags: linux, X11, networking
[ 13:52 Aug 01, 2005    More linux | permalink to this entry | ]

Debian Networking and Hotplug Update; 2.6 Instability

I like to keep my laptop's boot sequence lean and mean, so it can boot very quickly. (Eventually I'll write about this in more detail.) Recently I made some tweaks, and then went through a couple of dist-upgrades (it's currently running Debian "sarge"), and had some glitches. Some of what I learned was interesting enough to be worth sharing.

First, apache stopped serving http://localhost/ -- not important for most machines, but on the laptop it's nice to be able to use a local web server when there's no network connected. Further investigation revealed that this had nothing to do with apache: it was localhost that wasn't working, for any port. I thought perhaps my recent install of 2.4.29 was at fault, since some configuration had changed, but that wasn't it either. Eventually I discovered that the lo interface was there, but wasn't being configured, because my boot-time tweaking had disabled the ifupdown boot-time script, normally called from /etc/rcS.d.

That's all straightforward, and I restored ifupdown to its rightful place using update-rc.d ifupdown start 39 S .
Dancer suggested apt-get install --reinstall ifupdown which sounds like a better way; I'll do that next time. But meanwhile, what's this ifupdown-clean script that gets installed as S18ifupdown-clean ?

I asked around, but nobody seemed to know, and googling doesn't make it any clearer. The script obviously cleans up something related to /etc/network/ifstate, which seems to be a text file holding the names of the currently configured network interfaces. Why? Wouldn't it be better to get this information from the kernel or from ifconfig? I remain unclear as to what the ifstate file is for or why ifupdown-clean is needed.

Now my loopback interface worked -- hurray!

But after another dist-upgrade, now eth0 stopped working. It turns out there's a new hotplug in town. (I knew this because apt-get asked me for permission to overwrite /etc/hotplug/net.agent; the changes were significant enough that I said yes, fully aware that this would likely break eth0.) The new net.agent comes with comments referencing NET_AGENT_POLICY in /etc/default/hotplug, and documentation in /usr/share/doc/hotplug/README.Debian. I found the documentation baffling -- did NET_AGENT_POLICY=all mean that it would try to configure all interfaces on boot, or only that it would try to configure them when they were hotplugged?

It turns out it means the latter. net.agent defaults to NET_AGENT_POLICY=hotplug, which doesn't do anything unless you edit /etc/network/interfaces and make a bunch of changes; but changing NET_AGENT_POLICY=all makes hotplug "just work". I didn't even have to excise LIFACE from the net.agent code, like I needed to in the previous release. And it still works fine with all my existing Network Schemes entries in /etc/network/interfaces.

This new hotplug looks like a win for laptop users. I haven't tried it with usb yet, but I have no reason to worry about that.

Speaking of usb, hotplug, and the laptop: I'm forever hoping to switch to the 2.6 kernel, because it handles usb hotplug so much better than 2.4; but so far, I've been prevented by PCMCIA hotplug issues and general instability when the laptop suspends and resumes. (2.6 works fine on the desktop, where PCMCIA and power management don't come into play.)

A few days ago, I built both 2.4.29 and 2.6.10, since I was behind on both branches. 2.4.29 works fine. 2.6.10, alas, is even less stable than 2.6.9 was. On the laptop's very first resume from BIOS suspend after the first 2.6.10 boot, it hung, in the same way I'd been seeing sporadically from 2.6.9: no keyboard lights blinking (so not a kernel "oops"), cpu fan sometimes spinning, and no keyboard response to ctl-alt-Fn or anything else. I suppose the next step is to hook up the "magic sysrq" key and see if it responds to the keyboard at all when in that state.

Tags: linux, debian, networking, hotplug
[ 23:06 Mar 02, 2005    More linux | permalink to this entry | ]

wvdial works better than kppp

Okay, that subject line isn't likely to surprise any veteran linux user. But here's the deal: wvdialconf in the past didn't support winmodems (it checked the four /dev/ttyN ports, but not /dev/modem or /dev/ttyHSF0 or anything like that) so in order to get it working on a laptop, you had to hand-edit the modem information in the file, or copy from another machine (if you have a machine with a real modem) and then edit that. Whereas kppp can use /dev/modem, and it's relatively easy to add new phone numbers. So I've been using kppp on the laptop (which has a winmodem, alas) for years.

But with the SBC switch to Yahoo, I haven't been able to dial up. "Access denied" and "Failed to authenticate ourselves to peer" right after it sends the username and password, with PAP or PAP/CHAP (with CHAP only, it fails earlier with a different error).

Just recently I discovered that wvdial now does check /dev/modem, and works fine on winmodems (assuming of course a driver is present). I tried it on sbc -- and it works. I'm still not entirely sure what's wrong with kppp. Perhaps SBC isn't actually using PAP, but their own script, and wvdial's intelligent "Try to guess how to log in" code is figuring it out (it's pretty simple, looking at the transcript in the log). I could probably use the transcript to make a login script that would work with kppp. But why bother? wvdial handles it excellently, and doesn't flood stdout with hundreds of lines of complaints about missing icons like kppp does.

Yay, wvdial!

Tags: linux, networking
[ 13:51 Aug 10, 2004    More linux | permalink to this entry | ]