when i upgraded to 2.6.28 today (don't know if it's related) i noticed that net.eth0 does start dhcpcd for the interface unconditionally, i.e. also when no cable is attached. Reproducible: Always Portage 2.2_rc20 (default/linux/amd64/2008.0, gcc-4.3.2, glibc-2.9_p20081201-r1, 2.6.28-gentoo x86_64) ================================================================= System uname: Linux-2.6.28-gentoo-x86_64-Intel-R-_Core-TM-2_CPU_T7200_@_2.00GHz-with-glibc2.2.5 Timestamp of tree: Sun, 04 Jan 2009 15:45:03 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p48 dev-java/java-config: 1.3.7-r1, 2.1.6-r1 dev-lang/python: 2.5.2-r8 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.2 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.1-r1 sys-apps/sandbox: 1.3.2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.28-r1 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=core2 -pipe -fomit-frame-pointer -mfpmath=sse" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=core2 -pipe -fomit-frame-pointer -mfpmath=sse" DISTDIR="/usr/portage/distfiles" FEATURES="buildpkg ccache distlocks fixpackages parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo" LANG="POSIX" LDFLAGS="-Wl,-O1" LINGUAS="de" MAKEOPTS="-j10 -l3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/portage/layman/gnash-cvs /usr/local/portage/layman/sunrise /usr/local/portage/layman/jokey /usr/local/portage/layman/java-overlay /usr/local/portage/layman/x11" SYNC="rsync://rsync1.de.gentoo.org/gentoo-portage" USE="X acl acpi ads alsa amd64 avahi bash-completion berkdb bzip2 cli cracklib crypt cups dbus dri fortran gdbm gpm hal iconv ipv6 isdnlog jpeg kerberos ldap midi mmx mudflap multilib ncurses nls nptl nptlonly opengl openmp pam pcre perl pic pppd python readline reflection sasl session spl sse sse2 ssl sysfs tcpd tiff truetype unicode vim-syntax xinerama xorg zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" USERLAND="GNU" VIDEO_CARDS="ati radeon radeonhd vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Could you please redefine that as a problem, i.e. what issue does arise from dhcpcd running (when you think it should not)?
well, the problem is, that dhcpcd tries permanently to get a lease and spams the syslog with the following stuff. normally this should only happen the moment i attach a cable to the port Jan 8 22:45:37 [dhcpcd] eth0: dhcpcd 4.0.7 starting Jan 8 22:45:37 [dhcpcd] eth0: broadcasting for a lease Jan 8 22:46:07 [dhcpcd] eth0: timed out Jan 8 22:46:07 [dhcpcd] eth0: trying to use old lease in `/var/lib/dhcpcd/dhcpcd-eth0.lease' Jan 8 22:46:07 [dhcpcd] eth0: probing for an IPV4LL address Jan 8 22:46:07 [dhcpcd] eth0: checking 169.254.166.254 is available on attached networks Jan 8 22:46:12 [dhcpcd] eth0: using IPv4LL address 0.0.0.0 Jan 8 22:46:12 [avahi-daemon] Joining mDNS multicast group on interface eth0.IPv4 with address 169.254.166.254. Jan 8 22:46:12 [avahi-daemon] New relevant interface eth0.IPv4 for mDNS. Jan 8 22:46:12 [avahi-daemon] Registering new address record for 169.254.166.254 on eth0.IPv4. Jan 8 22:46:12 [netplugd] eth0: state INNING pid 26176 exited status 0
If dhcpcd thinks the cable is plugged in, then the kernel has set IFF_RUNNING for the interface. So if the interface is marked with IFF_RUNNING and the cable is not plugged in then it's a driver issue in the kernel.
well, i switched to ifplugd which doesn't show this behavior, so it doesn't seem to be a driver issue, but you'd be welcome to prove me wrong.
(In reply to comment #4) > well, i switched to ifplugd which doesn't show this behavior, so it doesn't > seem to be a driver issue, but you'd be welcome to prove me wrong. ifplugd supports a lot of ways to detect cable in out. dhcpcd supports just one - the interface IFF_RUNNING flag. You can check this flag by comparing ifconfig output with the cable in/out. If the cable is in, ifconfig will report RUNNING, otherwise it won't.
I think this stuff about dhcp is a furphy. It's about netplugd incorrectly seeing the initial state of the cable. The problem is the first time netplugd runs, it executes "/etc/netplug.d/netplug in" even when there's no cable connected. Then the rc scripts go on to do dchp or whatever they're configured for. After that, the first time you plug in a cable, the interface is already up, and nothing changes. If you then go on to unplug the cable, netplug brings the interface down (THIS is what I'd expect to see as the initial state with no cable). Plug it in again, and everything works as expected. I switched to ifplugd too, it does the expected thing. No cable, interface down. Cable, interface up, as configured.
May I ask which kernel drivers you use for your network card? I'm asking because I have two laptops: The one that uses the sis900 module has the same problem as you describe, the one that uses 8139too works just fine.
(In reply to comment #7) I was wondering about this too. I'm using b44 (broadcom). I have the b44, mii, and broadcom (phy) module loaded before starting any networkings scripts. You can tell ifplugd to use different detection modes. The first time I tried let ifplugd decide for itself - syslog, first start with cable unplugged: ifplugd(eth1)[3779]: Using interface eth1/00:14:22:EC:EC:C3 with driver <b44> (version: 2.0) ifplugd(eth1)[3779]: Using detection mode: SIOCETHTOOL ifplugd(eth1)[3779]: Initialization complete, link beat not detected. I wanted to see if it worked with the kernel drivers, so in /etc/conf.d/net I set 'ifplugd_eth1="--api-mode=mii"'. It still worked: ifplugd(eth1)[3717]: ifplugd 0.28 initializing. ifplugd(eth1)[3717]: Using interface eth1/00:14:22:EC:EC:C3 with driver <b44> (version: 2.0) ifplugd(eth1)[3717]: Initialization complete, link beat not detected. I'm no expert in this area, but it's my hunch the driver is working. Maybe I should have checked out _all_ the ifplugd detection modes, that would probably make it more certain that netplugd is the problem. But I stopped there. If anyone wants me to do any further tests I will be happy to. It might be sensible to change the title of this bug to "sys-apps/netplug" doesn't detect initial link down state". Probably not etiquette for me to try that, but. BTW. Kernel is 2.6.30-gentoo-r6
(In reply to comment #3) > If dhcpcd thinks the cable is plugged in, then the kernel has set IFF_RUNNING > for the interface. So if the interface is marked with IFF_RUNNING and the cable > is not plugged in then it's a driver issue in the kernel. I set ifplugd to use "--api-mode=iff" sure enough, it says "link beat detected". So --api-mode ethtool and mii work, but iff doesn't. Where does that mean the bug is?
