Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#123 20071203-Snapshot -- ifconfig reports no networking


I downloaded http://www.henrynestler.com/colinux/testing/devel-0.8.0/20071203-Snapshot/devel-coLinux-20071203.exe (and the source).

When I tried to install devel-coLinux-20071203.exe on top of (in the same directory, saving a copy of my OLD vmlinux first) the prior snapshot (devel-coLinux-20070819.exe) it complained about API mismatches --- so I recompiled from source and built the installer.exe also. Now I can get coLinux to boot and login with everything working.

You might want to look into making coLinux upgrades easier. If a TINY portion of the interface was written in assembly then the daemon could actually TEST if it can run instead of assuming that GCC 4.1 and GCC 4.2 are not compatable ...

But that is my 'fancy' setup (bleeding edge compiler and (nearly) ALL xconfig options turned ON!).

After overcomming those troubles that "BUG" is this:

Where I am now is that I can run the installer that I compiled, or run devel-coLinux-20071203.exe and the networking is not correct.

If I type "ifconfig" Linux seems to think that my only interface is "lo" -- I no longer have "eth0" !

If I ONLY execute "devel-coLinux-20070819.exe" (in WinXP), change NOTHING, like my config file, (except for the line "kernel=vmlinux-1" to swap API versions)
or any scripts in the Linux and simply install "devel-coLinux-20070819.exe" on top of "devel-coLinux-20071203.exe" then my networking works fine.

My networking has worked for years, only the newest "devel-coLinux-20071203.exe" has caused a loss of interfaces.

Typing "/etc/init.d/networking restart" claims that the interfaces are gone. I can't cut and paste from the console but here is a bit of it:

eth0: ERROR while getting interface flags: No such device
SIOCSIFNETMASK: No such device
SIOCSIFBRDADDR: No such device
eth0: ERROR while getting interface flags: No such device
eth0: ERROR while getting interface flags: No such device
Failed to bring up eth0.
(same for eth1 and eth2).

Running from the DOS prompt ([START] 'run' "cmd") I get these sort of messages:

C:\colinux>colinux-daemon.exe -v 10 @coLinux.conf -t fltk
Cooperative Linux Daemon, 0.8.0
Compiled on Dec 3 2007 23:38:28

using 'vmlinux-29' as kernel image
configuring 1024 MB of virtual RAM
mapping cobd0 to \??\c:\coLinux\Debian-3.0r2.ext3-mit-backports.14gb
mapping cobd1 to \??\c:\colinux\swap_1024Mb
mapping cobd3 to \??\c:\colinux\drive_1.ext3.14GB
mapping cobd4 to \??\c:\colinux\drive_2.ext3.14GB
mapping cobd5 to \??\c:\coLinux\drive_spare.ext3.2GB
configured TAP at '' device as eth0
MAC address: auto generated
configured PCAP bridge at '' device as eth1
MAC address: auto generated
configured Slirp as eth2
MAC address: auto generated
mapping cofs1 to \??\E:\ mapping cofs0 to \??\c:\ using 'initrd.gz' as initrd image
mapping cofs31 to \??\C:\colinux
kernel boot parameters: 'root=/dev/cobd0 ro apic=debug lapic dvd=:cobd2 profile=2'
creating monitor
reading initrd from (initrd.gz)
initrd size: 415873 bytes
PID: 5736
colinux: launching console
executing: colinux-console-fltk -a 5736
launching daemon for conet0
executing: colinux-net-daemon -i 5736 -u 0
launching daemon for conet1
executing: colinux-bridged-net-daemon -i 5736 -u 1 -mac 00:ff:99:e0:52:60 -p 1
launching daemon for conet2
executing: colinux-slirp-net-daemon -i 5736 -u 2
colinux: booting
colinux-net-daemon: auto selecting TAP
colinux-net-daemon: found TAP device named "Local Area Connection 3"
colinux-net-daemon: opening TAP: "Local Area Connection 3"
colinux-net-daemon: TAP driver version 8.4
colinux-net-daemon: enabling TAP...
conet-slirp-daemon: running
Linux version 2.6.22-co-0.8.0 (root@colinux) (gcc version 4.2.2 20070804 (prerelease)) #1 PREEMPT Tu
e Jan 1 02:51:41 PST 2008
1000MB LOWMEM available.
initrd enabled: start: 0xfe79a000 size: 0x00065881
(Here is something I have not seen previously)
conet-bridged-daemon: Auto selecting name for bridged interface
conet-bridged-daemon: adapter Adapter for generic dialup and VPN capture doesn't have a connection
conet-bridged-daemon: checking connection: Local Area Connection
conet-bridged-daemon: checking connection: Local Area Connection 2
conet-bridged-daemon: checking connection: Local Area Connection 3
conet-bridged-daemon: listening on: TAP-Win32 Adapter V8 (coLinux) (Microsoft's Packet Scheduler) ...
conet-bridged-daemon: listening for: (ether dst 00:ff:99:e0:52:60) or (ether broadcast or multicast) or (ip broadcast or multicast)
.... (more lines deleted)
: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
sit0: Disabled Privacy Extensions
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (8000 buckets, 64000 max)
.... (more lines deleted)

It ends up that "ipconfig" finds "lo" (and "sit0" which I never did finish writing the configure script for -- but it is detected ;( ).

It is "as if" the 'conet-bridged-daemon' will NOT properly read my 'network methods' in my coLinux.conf file.

The end of my coLinux.conf is:


So I have had no trouble with "devel-coLinux-20070819.exe" and earlier but can't use "devel-coLinux-20071203.exe" (as far as 'seeing' my network interfaces). Other than this one issue everything seems OK.

Since I don't have networking I can't use X11 (and don't way to fiddle with the tiny console) so I am going back to the prior version.



  • Logged In: NO

    I tried running "devel-coLinux-20071203.exe" again (and letting it overwrite C:\coLinux).

    I then used these (minimal) commands from the DOS prompt:

    cd C:\coLinux
    colinux-daemon kernel=vmlinux-29 cobd0=Debian-3.0r2.ext3-mit-backports.14gb hda1=:cobd0 root=/dev/cobd0 eth0=tuntap

    After coLinux boots and I sign in I can type "ifconfig" and here is what it says:

    eth16 Link encap:Ethernet HWaddr 00:...
    lo Link encap:Local Loopback

    So it does not start at eth0 but it should. Normally (for my setup) I would start at eth0 and have eth1, eth2, sit0, and lo too. I wonder if there is a patch issue.

  • Logged In: NO

    The problem is: Debian is *trying* to be smart.
    Every time CoLinux starts up, it automatically generates a new MAC address for each adapter, seen here in your log:

    configured TAP at '' device as eth0
    MAC address: auto generated
    configured PCAP bridge at '' device as eth1
    MAC address: auto generated
    configured Slirp as eth2
    MAC address: auto generated

    Every time a new MAC address is generated, debian will rename your ethX device.
    Set a MAC address for each adapter in your CoLinux config file and clear out debian's previous failed network connections.

    -- Kamilion

  • Logged In: NO

    That's no problem of CoLinux but debian.
    Debian assigns a new etherdevice for every new MAC.
    If you don't tell CoLinux to use a specific AM it will
    choose a random on every start...
    eth16 indicates, you have tried 16 times ,-)

    See thread "No network anmore?" Dec 8th., 2007

    #cat /proc/net/dev
    shows an eth device number greater eth0, incremented with each boot.

    The effect is (currently) only seen o


    1st step:
    Assign a fixed MAC address in the colinux config:

    For example:
    eth0=pcap-bridge,,0A:C0:71:65:08:00, (implicit ethernet device is not recommanded)
    eth0=tuntap,LAN-TAP Vqe8(colinux),0A:C0:71:65:08:00,

    The "second" nibble (from left) should/must have only the values 2,6,A or E.
    The remainder does not matter as long as it is unique in your LAN.

    2nd step:
    remove all entries in


    like these:
    SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:ff:06:be:41:00", NAME="eth0"

    # PCI device 0x1a55:0x0005 (conet)
    SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:ff:25:e6:00:00",NAME="eth1"

    (Typically the file is empty except the comment header)


  • Henry N.
    Henry N.

    Logged In: YES
    Originator: NO

    I'm sorry for the pain with eth counts, and thanks for reporting. I'm think about saving the random numbers after the first creation somethere in registry.

    The name for pcap-bridge should never be empty! In some cases the pcap-bridge would detect the TAP-Win32 as outgoing interface, if the tap interface would be faster enabled as the pcap-bridge - and this would no work.

    The name for tuntap can be empty, if have only one TAP-Win32 installed (typically).

    Your problem with GCC 4.1 and GCC 4.2 I not understand. The current devel allows both compilers to compile your kernel. We checking the GCC-ABI. If you have an old kernel without ABI-check, then we check the GCC version. This is perhaps, you have.

    You should not start an old kernel binary with new daemons. Linux kernel (vmlinux) and the Linux driver have dependencies. This, we try to manage with ABI- and API- check. But, we have no backports to old versions. So, the linux kernel should build with a recent kernel patch from same source of windows driver and daemons.

    To solve this:
    Rebuild the Linux kernel with fresh patch set, your kernel config and your favorite gcc (3.3.1 ... 4.2.x).
    Than the devel-coLinux-20071203.exe should also be usable for you.

  • Henry N.
    Henry N.

    Logged In: YES
    Originator: NO

    http://www.colinux.org/snapshots/ build 20080112 saves automatic generated MAC address into windows registry now.
    Please test it and report usability.


  • Henry N.
    Henry N.

    Logged In: YES
    Originator: NO

    If a user change colinux version from 0.7.x to 0.8.0, any time must remove the lines in
    That means if you starts 0.8.x, than 0.7.x and 0.8.x later, than the promlems comes again.

    If you switching more often between coLinux version 0.7.x and 0.8.x, should set a MAC in your colinux.conf, or yust kill the file on every startup by adding such line into the network startup script (near /etc/initd.d/network...):
    echo "#dummy" > /etc/udev/rules.d/z25_persistent-net.rules

  • Henry N.
    Henry N.

    • priority: 5 --> 7
  • Henry N.
    Henry N.

    To allow dual boot, you can bypass the rename only for coLinux by adding a
    line with DRIVER "conet" to the file net_persistent_names.rules some there
    in top of file where other skips exist:

    # ignore "conet" interfaces
    DRIVERS=="conet" GOTO="persistent_net_generator_end"

    This also fixes the problem on changing between different coLinux version (0.7.3 and newer) and the problem between starts from command line and as service (different Windows user).

    For Debian 4.0 insert the '+' marked lines into file
    /etc/udev/rules.d/z45_persistent-net-generator.rules near line 15:

    # ignore "secondary" raw interfaces of the madwifi driver
    KERNEL=="ath*", ATTRS{type}=="802", GOTO="persistent_net_generator_end"
    +# ignore "conet" interfaces
    +DRIVERS=="conet", GOTO="persistent_net_generator_end"
    # provide nice comments for the generated rules
    SUBSYSTEMS=="pci", \ ENV{COMMENT}="PCI device $attr{vendor}:$attr{device}"

    For Ubuntu 8.1 insert '+' marked lines into file
    /etc/udev/rules.d/75-persistent-net-generator.rules at line 26:

    # ignore Xen virtual interfaces
    SUBSYSTEMS=="xen", GOTO="persistent_net_generator_end"
    +# Do not rename coLinux network devices
    +DRIVERS=="conet", GOTO="persistent_net_generator_end"
    # read MAC address