Bug 249252

Does the network function if you specify an ip address by hand? (i.e., is the
failure specific to dhcp, or is the interface entirely non-functional)

I suspect the whole interface. Since I'm on a real dynamic Ip-area with the
laptop at the moment, I cannot manual configure until thursday.

$ git log v2.6.21..v2.6.22 drivers/net/sis900.*
commit dc5a144991ba803bc8afded105c9db1dea0e57ab
Author: Neil Horman <nhorman>
Date:   Thu Apr 26 13:47:36 2007 -0400

    sis900: Allocate rx replacement buffer before rx operation

    Just found a hole in my last patch.  It was reported to me that shortly 
after we
    integrated this patch.  The report was of an oops that took place inside 
of
    netif_rx when using the sis900 driver.  Looking at my origional patch I 
noted
    that there was a spot between the new skb_alloc and the refill_rx_ring 
label
    where skb got reassigned to the pointer currently held in the rx_ring for 
the
    purposes of receiveing the frame.  The result of this is however that the 
buffer
    that gets passed to netif_rx (if it is called), then gets placed right 
back into
    the rx_ring.  So if you receive frames fast enough the skb being processed 
by
    the network stack can get corrupted.  The reporter is testing out the fix 
I've
    written for this below (I'm not near my hardware at the moment to test 
myself),
    but I wanted to post it for review ASAP.  I'll post test results when I 
hear
    them, but I think this is a pretty straightforward fix.  It just uses a 
separate
    pointer to do the rx operation, so that we don't improperly reassign the 
pointer
    that we use to refill the rx ring.

    Signed-off-by: Neil Horman <nhorman>
    Signed-off-by: Jeff Garzik <jeff>

commit 4c13eb6657fe9ef7b4dc8f1a405c902e9e5234e0
Author: Arnaldo Carvalho de Melo <acme>
Date:   Wed Apr 25 17:40:23 2007 -0700

    [ETH]: Make eth_type_trans set skb->dev like the other *_type_trans

    One less thing for drivers writers to worry about.

    Signed-off-by: Arnaldo Carvalho de Melo <acme>
    Signed-off-by: David S. Miller <davem>

I'll build you an F7 kernel with my patch included and post it to my people page

scratch that, it appears both above commits are already in this kernel.  so an
answer to Jardons question would be usefull here, as well as a tcpdump from the
dhcp server while this laptop tries to dhcp, along with the mac address of the
card in question.

I manually configured the network on the laptop and that works.

So getting info from a DHCP is definitely the problem.
Unfortunately I do not have access to the machine running the DHCP server.
What other tests can be done?

                     Jouk

P.S. I'm still present to do some tests today till 17.00 (MET) and tommorow from
8.00-17.00 (MET). After that I will be away from the laptop for over a month.
For quick contact you can also call me at 31-15-2782272.

Hmm.. this strange:
 When using the DHCP
    1) network does not work after boot
    2) logon and start the Network-configuration tool
    3) Deactivate the network
    4) Activate the network. A window pops up with the message
            "Cannot activate network device eth0"
    5) exit the Network-configuration tool
    6) Now the network WORKS

As we say in the Netherlands: I cannot make chocolate out of this.

If you can't tcpdump frome the dhcp server, you can use a hub or switch with
port mirroring features and an extra machine to capture the tcpdump:

                        ==================
Laptop ------------------   Hub/Switch   ----------------Network to DHCP server
                        ==================
                                |
                                | - mirrored switch port/alt. hub port
                                |
                                |
                             2nd laptop

Use the 2nd laptop to capture all traffic.  If you have set everything up right,
you should see traffic to/from the first laptop.  That will let you capture the
traffic we need.

Alternatively, we can try a more simple test.  It sounds from what you are
describing like the admins running the network at your site may be using
spanning tree.  That means that when you enable the link on your machine, there
may be up to two minutes when you cannot send traffic while the network
re-determines its topology.  Try this test:
1) edit /etc/sysconfig/network-scripts/ifcfg-eth<#>.  Set ONBOOT=no
2) reboot your machine
3) as root issue this command: /sbin/ifconfig eth<#> up
4) Wait two minutes
5) as root issue this command: /sbin/dhclient eth<#>

If you get an address and are able to use the network, you likely have a
spanning tree enabled network.  You can talk to your network admins to see what
option are available to you to reduce the amount of time it takes before your
port is useable.

If the above does not work, then if you could provide a sysreport of your
system, as well as the above tcpdump, that would be helpful.

I do not have the hardware for the first option and I cannot bother the network
managers with this problem (they just allow me to run a "non standard" system
sigh...)

I tried the second option. and what happened :
I only did step 1) and 2) and loged on as normal user. The network was
functioning properly. Probably NetManager is interfering and starts the network
anyway (in a correct way)

I got similar problem booth with a 3com eternet and a rt61pci based wireless card.

Jul 26 14:20:05 localhost kernel: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Jul 26 14:20:05 localhost kernel: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Jul 26 14:20:05 localhost kernel: wlan0: duplicate address detected!
Jul 26 14:20:05 localhost dhclient: Internet Systems Consortium DHCP Client
V3.0.5-RedHat
Jul 26 14:20:05 localhost dhclient: Copyright 2004-2006 Internet Systems Consortium.
Jul 26 14:20:05 localhost dhclient: All rights reserved.
Jul 26 14:20:05 localhost dhclient: For info, please visit
http://www.isc.org/sw/dhcp/
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: wmaster0: unknown hardware address type 801
Jul 26 14:20:05 localhost dhclient: wmaster0: unknown hardware address type 801
Jul 26 14:20:05 localhost dhclient: Listening on LPF/wlan0/00:08:a1:94:88:7e
Jul 26 14:20:05 localhost dhclient: Sending on   LPF/wlan0/00:08:a1:94:88:7e
Jul 26 14:20:05 localhost dhclient: Sending on   Socket/fallback
Jul 26 14:20:05 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255
port 67 interval 6
Jul 26 14:20:05 localhost dhclient: DHCPOFFER from 10.0.0.1
Jul 26 14:20:05 localhost dhclient: Internet Systems Consortium DHCP Client
V3.0.5-RedHat
Jul 26 14:20:05 localhost dhclient: Copyright 2004-2006 Internet Systems Consortium.
Jul 26 14:20:05 localhost dhclient: All rights reserved.
Jul 26 14:20:05 localhost dhclient: For info, please visit
http://www.isc.org/sw/dhcp/
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: wmaster0: unknown hardware address type 801
Jul 26 14:20:05 localhost dhclient: wmaster0: unknown hardware address type 801
Jul 26 14:20:05 localhost dhclient: Listening on LPF/wlan0/00:08:a1:94:88:7e
Jul 26 14:20:05 localhost dhclient: Sending on   LPF/wlan0/00:08:a1:94:88:7e
Jul 26 14:20:05 localhost dhclient: Sending on   Socket/fallback
Jul 26 14:20:05 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255
port 67 interval 6
Jul 26 14:20:05 localhost dhclient: DHCPOFFER from 10.0.0.1
Jul 26 14:20:05 localhost dhclient: Internet Systems Consortium DHCP Client
V3.0.5-RedHat
Jul 26 14:20:05 localhost dhclient: Copyright 2004-2006 Internet Systems Consortium.
Jul 26 14:20:05 localhost dhclient: All rights reserved.
Jul 26 14:20:05 localhost dhclient: For info, please visit
http://www.isc.org/sw/dhcp/
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: wmaster0: unknown hardware address type 801
Jul 26 14:20:05 localhost dhclient: wmaster0: unknown hardware address type 801
Jul 26 14:20:05 localhost dhclient: Listening on LPF/wlan0/00:08:a1:94:88:7e
Jul 26 14:20:05 localhost dhclient: Sending on   LPF/wlan0/00:08:a1:94:88:7e
Jul 26 14:20:05 localhost dhclient: Sending on   Socket/fallback
Jul 26 14:20:05 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255
port 67 interval 6
Jul 26 14:20:05 localhost dhclient: DHCPOFFER from 10.0.0.1
Jul 26 14:20:05 localhost kernel: eth0:  setting full-duplex.
Jul 26 14:20:05 localhost avahi-daemon[2295]: Joining mDNS multicast group on
interface eth0.IPv6 with address fe80::250:4ff:fe56:ce87.
Jul 26 14:20:05 localhost avahi-daemon[2295]: New relevant interface eth0.IPv6
for mDNS.
Jul 26 14:20:05 localhost avahi-daemon[2295]: Registering new address record for
fe80::250:4ff:fe56:ce87 on eth0.*.
Jul 26 14:20:05 localhost dhclient: dhclient(3688) is already running - exiting. 
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: This version of ISC DHCP is based on the
release available
Jul 26 14:20:05 localhost dhclient: on ftp.isc.org.  Features have been added
and other changes
Jul 26 14:20:05 localhost dhclient: have been made to the base software release
in order to make
Jul 26 14:20:05 localhost dhclient: it work better with this distribution.
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: Please report for this software via the Red
Hat Bugzilla site:
Jul 26 14:20:05 localhost dhclient:     http://bugzilla.redhat.com
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: exiting.
Jul 26 14:20:05 localhost dhclient: dhclient(3688) is already running - exiting. 
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: This version of ISC DHCP is based on the
release available
Jul 26 14:20:05 localhost dhclient: on ftp.isc.org.  Features have been added
and other changes
Jul 26 14:20:05 localhost dhclient: have been made to the base software release
in order to make
Jul 26 14:20:05 localhost dhclient: it work better with this distribution.
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: Please report for this software via the Red
Hat Bugzilla site:
Jul 26 14:20:05 localhost dhclient:     http://bugzilla.redhat.com
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: exiting.
Jul 26 14:20:05 localhost dhclient: dhclient(3688) is already running - exiting. 
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: This version of ISC DHCP is based on the
release available
Jul 26 14:20:05 localhost dhclient: on ftp.isc.org.  Features have been added
and other changes
Jul 26 14:20:05 localhost dhclient: have been made to the base software release
in order to make
Jul 26 14:20:05 localhost dhclient: it work better with this distribution.
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: Please report for this software via the Red
Hat Bugzilla site:
Jul 26 14:20:05 localhost dhclient:     http://bugzilla.redhat.com
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: exiting.
Jul 26 14:20:05 localhost dhclient: dhclient(3688) is already running - exiting. 
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: This version of ISC DHCP is based on the
release available
Jul 26 14:20:05 localhost dhclient: on ftp.isc.org.  Features have been added
and other changes
Jul 26 14:20:05 localhost dhclient: have been made to the base software release
in order to make
Jul 26 14:20:05 localhost dhclient: it work better with this distribution.
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: Please report for this software via the Red
Hat Bugzilla site:
Jul 26 14:20:05 localhost dhclient:     http://bugzilla.redhat.com
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: exiting.
Jul 26 14:20:05 localhost dhclient: Internet Systems Consortium DHCP Client
V3.0.5-RedHat
Jul 26 14:20:05 localhost dhclient: Copyright 2004-2006 Internet Systems Consortium.
Jul 26 14:20:05 localhost dhclient: All rights reserved.
Jul 26 14:20:05 localhost dhclient: For info, please visit
http://www.isc.org/sw/dhcp/
Jul 26 14:20:05 localhost dhclient: 
Jul 26 14:20:05 localhost dhclient: wmaster0: unknown hardware address type 801
Jul 26 14:20:05 localhost dhclient: wmaster0: unknown hardware address type 801
Jul 26 14:20:05 localhost dhclient: Listening on LPF/eth0/00:50:04:56:ce:87
Jul 26 14:20:05 localhost dhclient: Sending on   LPF/eth0/00:50:04:56:ce:87
Jul 26 14:20:05 localhost dhclient: Listening on LPF/wlan0/00:08:a1:94:88:7e
Jul 26 14:20:05 localhost dhclient: Sending on   LPF/wlan0/00:08:a1:94:88:7e
Jul 26 14:20:05 localhost dhclient: Sending on   Socket/fallback
Jul 26 14:20:05 localhost dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port
67 interval 3
Jul 26 14:20:05 localhost dhclient: DHCPDISCOVER on wlan0 to 255.255.255.255
port 67 interval 5
Jul 26 14:20:05 localhost dhclient: DHCPOFFER from 10.0.0.1
Jul 26 14:20:05 localhost dhclient: DHCPOFFER from 10.0.0.1

To summarize, what I see you saying is:

1) You're unable to preform any tests that aren't localized to your machine.

2) If you modify your configuration such that NetworkManager handles your
network interfaces, you don't have a problem

3) This really doesn't have anything to do with the sis900 card.

You don't have a bug, you have a configuration issue.  Something about your most
recent upgrade has altered your system in such a way that your previous
configuration is in some way broken.  I would suggest just letting
NetworkManager handle your network configuration for you.  If you would prefer,
you can disable NetworkManager and try to resolve your static configuration
issue.  I can help you if you like, but to do so, you need to send me that
sysreport which I requested in comment #8.  Looking at your output above, it
appears that you have several errors, specifically a duplicate address on wlan0
which may indicate a bad configuration on your system, as well as several
dhclient errors indicating duplicate copies, which indicate you are trying to
manually configure interfaces while NetworkManager is running.  Let me know what
you want to do, and I'll either look over your sysreport, or close this as
NOTABUG.  Thanks!

Agreed, The only weird thing is that the same configuration does not give a
problem with the 2.6.21 kernels.
For me everything is fine now.