Shallow Thoughts : tags : net

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: net, linux, networking, cmdline
[ 11:28 Mar 24, 2012    More linux | permalink to this entry | comments ]

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, net
[ 17:28 Mar 11, 2009    More linux/install | permalink to this entry | comments ]

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, laptops, net
[ 09:51 Feb 27, 2009    More linux/laptop | permalink to this entry | comments ]

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, net
[ 13:41 Apr 04, 2008    More linux | permalink to this entry | comments ]

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, net
[ 18:02 Dec 23, 2007    More linux | permalink to this entry | comments ]

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, net, debian, ubuntu
[ 14:44 Aug 18, 2007    More linux | permalink to this entry | comments ]

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, net
[ 18:10 May 15, 2007    More linux | permalink to this entry | comments ]

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, net
[ 14:22 Mar 15, 2006    More linux | permalink to this entry | comments ]

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, net
[ 12:52 Aug 01, 2005    More linux | permalink to this entry | comments ]

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, net, hotplug
[ 22:06 Mar 02, 2005    More linux | permalink to this entry | comments ]

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, net
[ 12:51 Aug 10, 2004    More linux | permalink to this entry | comments ]