Bug#248061: some link detection code all ready there - Debian

This is a discussion on Bug#248061: some link detection code all ready there - Debian ; Where this bug was opened two and half year ago, there was yet only tagging information in this bugreport. netcfg has allready program code to detect if a network interface is live. A month ago I did an install on ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Bug#248061: some link detection code all ready there

  1. Bug#248061: some link detection code all ready there


    Where this bug was opened two and half year ago,
    there was yet only tagging information in this bugreport.

    netcfg has allready program code to detect
    if a network interface is live.

    A month ago I did an install on a computer with two NICs
    where only one was connected to a switch.

    I was surprised that I still was asked to choose which NIC to use.

    In the syslog came these entries (timestamp removed):

    | main-menu[867]: INFO: Menu item 'netcfg' selected
    | kernel: eth0: link down
    | netcfg[2298]: INFO: eth0 is disconnected. (MII)
    | netcfg[2298]: INFO: eth0 is not a wireless interface. Continuing.
    | netcfg[2298]: WARNING **: couldn't determine MII ioctl to use for eth1
    | netcfg[2298]: INFO: eth1 is not a wireless interface. Continuing.

    After some research, I found out that my eth1 indeed had no MII ioctl
    support. So the installer was right to ask for choosing a NIC.


    People with multiple NICs, that do have MII ioctl support,
    in their installed system and see that the live interface is detected,
    please be carefull with closing this bugreport, because it is merged
    with other bugreports.

    Confirming that "link detection" works is appreciated.


    Cheers
    Geert Stappers




    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Bug#248061: some link detection code all ready there

    On Fri, Nov 09, 2007 at 11:50:32AM +0100, Geert Stappers wrote:
    > After some research, I found out that my eth1 indeed had no MII ioctl
    > support. So the installer was right to ask for choosing a NIC.
    >
    > People with multiple NICs, that do have MII ioctl support,
    > in their installed system and see that the live interface is detected,
    > please be carefull with closing this bugreport, because it is merged
    > with other bugreports.
    >
    > Confirming that "link detection" works is appreciated.


    We have a number of Dell PowerEdge machines that do not indicate which
    interface has link when running d-i. dmesg(8) says the adapters are:

    eth0: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet
    eth1: Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet

    and mii-tool(8) does detect the presence or absence of link:

    eth0: negotiated 100baseTx-FD, link ok
    eth1: no link

    These interfaces take a while to negotiate a link, probably because spanning
    tree is enabled on the switch ports they're attached to, so it necessarily
    takes a while for the port to enter the forwarding state. Is there a way to
    have d-i/netcfg sleep for a longer (configurable?) period of time before
    assuming no link has been negotiated?

    john
    --
    John Morrissey _o /\ ---- __o
    jwm@horde.net _-< \_ / \ ---- < \,
    www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Bug#248061: some link detection code all ready there

    On Wednesday 27 February 2008, John Morrissey wrote:
    > These interfaces take a while to negotiate a link, probably because
    > spanning tree is enabled on the switch ports they're attached to, so it
    > necessarily takes a while for the port to enter the forwarding state. Is
    > there a way to have d-i/netcfg sleep for a longer (configurable?) period
    > of time before assuming no link has been negotiated?


    OK. One way to test this theory would be to run an installation with
    'install priority=medium' and wait for some time between the network
    hardware detection step and the network configuration step.
    And maybe check dmesg or VT4 in between for link detection messages.

    Does that result in reliable automatic selection of the connected NIC?

    If it does, how long is the delay between the driver being loaded and the
    link coming up (/var/log/syslog should be able to tell you)?

    Cheers,
    FJP



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Bug#248061: some link detection code all ready there

    On Sun, Mar 02, 2008 at 08:30:17PM +0100, Frans Pop wrote:
    > On Wednesday 27 February 2008, John Morrissey wrote:
    > > These interfaces take a while to negotiate a link, probably because
    > > spanning tree is enabled on the switch ports they're attached to, so it
    > > necessarily takes a while for the port to enter the forwarding state. Is
    > > there a way to have d-i/netcfg sleep for a longer (configurable?) period
    > > of time before assuming no link has been negotiated?

    >
    > OK. One way to test this theory would be to run an installation with
    > 'install priority=medium' and wait for some time between the network
    > hardware detection step and the network configuration step.
    > And maybe check dmesg or VT4 in between for link detection messages.
    >
    > Does that result in reliable automatic selection of the connected NIC?
    >
    > If it does, how long is the delay between the driver being loaded and the
    > link coming up (/var/log/syslog should be able to tell you)?


    According to the switch, the link comes up when the machine boots (we PXE
    boot for our installs), ascends to spanning-tree listening state, and
    remains up when d-i starts.

    When the module for the interfaces is loaded, the link stays up (on the
    switch side; d-i syslogs don't indicate anything about link, and ifconfig(8)
    shows them as down: i.e., they do not appear in 'ifconfig' output, but do
    appear in 'ifconfig -a' as 'BROADCAST MULTICAST' and not 'UP' or 'RUNNING').

    When I hit 'Configure network interfaces,' netcfg must throb the interface
    somehow, since it goes from forwarding state to listening state on the
    switch:

    sw06.roch.ny#sh int g0/31
    GigabitEthernet0/31 is up, line protocol is up (connected)
    [...]
    sw06.roch.ny#sh spanning-tree interface g0/31

    Vlan Role Sts Cost Prio.Nbr Type
    ---------------- ---- --- --------- -------- --------------------------------
    VLAN0090 Desg FWD 4 128.31 P2p

    [... select 'Configure Network Interfaces']

    sw06.roch.ny#sh spanning-tree interface g0/31

    Vlan Role Sts Cost Prio.Nbr Type
    ---------------- ---- --- --------- -------- --------------------------------
    VLAN0090 Desg LIS 19 128.31 P2p
    [... time goes by]
    sw06.roch.ny#sh spanning-tree interface g0/31

    Vlan Role Sts Cost Prio.Nbr Type
    ---------------- ---- --- --------- -------- --------------------------------
    VLAN0090 Desg FWD 4 128.31 P2p

    The interface list does not indicate that either interface has link, and the
    syslogs say:

    main-menu[1188]: INFO: Menu item 'netcfg' selected
    kernel: bnx2: eth0: using MSI
    netcfg[2842]: INFO: eth0 is disconnected. (MII)
    netcfg[2842]: INFO: eth0 is not a wireless interface. Continuing.

    Once I choose to use DHCP on the interface, dhclient starts and, two seconds
    later, the kernel shows that the device has link:

    kernel: bnx2: eth0: using MSI
    kernel: bnx2: eth0 NIC Link is Up, 1000Mbps full duplex

    However, something has again booted the switch port back into spanning-tree
    listening state and the port must again ascend to forwarding state. Because
    of this, dhclient spins for a while and successfully gets an IP address 37
    seconds after link is detected by the kernel.

    I don't know what the default timeout is OTTOMH, but without overriding it,
    network autoconfiguration fails every time.

    john
    --
    John Morrissey _o /\ ---- __o
    jwm@horde.net _-< \_ / \ ---- < \,
    www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__



    --
    To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread