sfink's questions

I am constructing a list of network interfaces to monitor based on the contents of /proc/net/dev. But I am getting some bogus interfaces in the list:

__tmp1104705027
__tmp974528607

Where do those come from?

They also show up in /sys/class/net/:

# ls -1 /sys/class/net/
eth0
eth1
eth2
eth3
lo
sit0
__tmp1104705027
__tmp974528607

For now, I think I'll just ignore anything starting with __tmp, but I'd like to know what they are and where they come from.

This is on a recompiled CentOS 5.3 kernel: 2.6.18-128.7.1.el5.tvh.7PAE #1 SMP PREEMPT

I have somehow managed to mangle my computer so that any time I attempt to use something that uses ptrace to trace another process (eg strace, gdb), I get an immediate segmentation fault.

For example:

# strace /bin/true
execve("/bin/true", ["/bin/true"], [/* 27 vars */]) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

or with gdb:

# gdb /bin/true
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
(gdb) run
Starting program: /bin/true 

Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
You can't do that without a process to debug.

rpm -V comes up clean on strace, gdb, and glibc. I do not have any LD_* variables set, and PATH has nothing special in it.

Update: problem is in the kernel-2.6.18-128 kernel when recompiled with PREEMPT. That kernel emulates ptrace with the utrace infrastructure, and it seems to disagree with preemption. kernel-2.6.18-164 seems to fix it.

I use vpnc on Linux, and with our corporate VPN setup (it's a Cisco something or other router), it's not exactly rock-solid. I run most things inside screen, so it's not a huge deal, but isn't there some way of maintaining connections across VPN restarts?

It seems like if I had a separate router box running vpnc, I would get it for free just by setting that box as my gateway. How can I emulate the same behavior with a single box?

When the VPN restarts, I get a different IP address and MAC address on the tun0 or tap0 device.

I tried playing games by using tap0 for the tunnel and then bridging it to various things (dummy devices, loopbacks, etc.), but couldn't get anything working.

I am using arping -D to detect duplicate IP addresses within a network when setting up servers. (The network is controlled by someone else, and we have had many issues with IP allocation in the past.) It works fine as long as my host has a single NIC on a given VLAN, but when my host has more than one (I have one with 9 NICs on one VLAN and 1 on the other), arping -D always returns false collisions.

The problem is that all 9 of my NICs respond to an ARP request for any of the IPs on those NICs. (These are real physical NICs, not aliases or anything.) I send out one ARP request packet, and get 9 ARP is-at ARP replies, one for each MAC address.

I could implement my own solution by sniffing packets and checking for any replies with a MAC address other than the local NICs', but it seems like there ought to be an easier way.