using 2nd network interface - won't try to TX anything - Networking

This is a discussion on using 2nd network interface - won't try to TX anything - Networking ; I'm trying to make use of a 2nd ethernet interface. The basic steps seem to work OK. But nothing gets transmitted out the 2nd interface. Yet it does see packets coming back the other way on that interface. Here's what ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: using 2nd network interface - won't try to TX anything

  1. using 2nd network interface - won't try to TX anything

    I'm trying to make use of a 2nd ethernet interface. The basic steps seem
    to work OK. But nothing gets transmitted out the 2nd interface. Yet it
    does see packets coming back the other way on that interface.

    Here's what ifconfig shows:

    ================================================== ===========================
    -bash-2.05b# ifconfig
    ixp1 Link encap:Ethernet HWaddr 00:02:B3:02:02:02
    inet addr:172.30.1.3 Bcast:172.30.1.255 Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:21049 errors:0 dropped:0 overruns:0 frame:0
    TX packets:16493 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:256
    RX bytes:17841196 (17.0 Mb) TX bytes:2523518 (2.4 Mb)

    ixp2 Link encap:Ethernet HWaddr 00:02:B3:03:03:03
    inet addr:172.30.2.3 Bcast:172.30.2.255 Mask:255.255.255.0
    UP BROADCAST MULTICAST MTU:1500 Metric:1
    RX packets:222 errors:0 dropped:0 overruns:0 frame:0
    TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:256
    RX bytes:13320 (13.0 Kb) TX bytes:0 (0.0 b)

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:8 errors:0 dropped:0 overruns:0 frame:0
    TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:560 (560.0 b) TX bytes:560 (560.0 b)

    -bash-2.05b#
    ================================================== ===========================

    One thing I notice here that might be an issue is that the status RUNNING
    is not included in ixp2. Could that be related to the problem? How would
    I fix this if so?

    TX bytes is 0 for ixp2 despite attempts to ping the other host on that LAN
    segment. I'd think that if it were bad hardware, it would at least show
    what it it tried to transmit. But there is 0 there as if it never tried
    to send anything over ixp2 at all.

    Here's what route shows:

    ================================================== ===========================
    -bash-2.05b# route
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    172.30.1.0 * 255.255.255.0 U 0 0 0 ixp1
    172.30.2.0 * 255.255.255.0 U 0 0 0 ixp2
    169.254.0.0 * 255.255.0.0 U 0 0 0 lo
    -bash-2.05b#
    ================================================== ===========================

    The topology is that ixp1 is connected via a switch to eth1 on a PC, and
    ixp2 is connected via a different switch to eth2 on the same PC. There are
    not other hosts connected on these segments. There is no default gateway
    as this test machine is not to be able to reach the internet.

    Notice for ixp2 in the ifconfig output, there are some RX bytes tallied.
    This goes up when I ping that IP address from the PC. During such ping
    attempts, the PC attempts to get the MAC address, but is unsuccessful.
    The tcpdump output from the PC looks like lots of:

    ================================================== ===========================
    ....
    17:39:11.723759 arp who-has 172.30.2.3 tell 172.30.2.1
    17:39:13.723775 arp who-has 172.30.2.3 tell 172.30.2.1
    17:39:14.723782 arp who-has 172.30.2.3 tell 172.30.2.1
    17:39:15.723790 arp who-has 172.30.2.3 tell 172.30.2.1
    ....
    ================================================== ===========================

    So I suspect the RX bytes tally is for the ARP request broadcasts received.
    The ARP table on the PC shows the ping target as incomplete. But the ARP
    table on the machine under test does show the corresponding PC MAC address.
    So it apparently sent an ARP request and got and answer, but did not count
    it, or sent it via the other interface.

    ================================================== ===========================
    -bash-2.05b# arp
    Address HWtype HWaddress Flags Mask Iface
    172.30.2.1 ether 00:50:FC:4A:C2:1C C ixp2
    172.30.1.1 ether 00:07:40:8E:56:A4 C ixp1
    -bash-2.05b# ping 172.30.2.1
    PING 172.30.2.1 (172.30.2.1) 56(84) bytes of data.

    --- 172.30.2.1 ping statistics ---
    96 packets transmitted, 0 received, 100% packet loss, time 95007ms

    -bash-2.05b# arp
    Address HWtype HWaddress Flags Mask Iface
    172.30.2.1 ether 00:50:FC:4A:C2:1C C ixp2
    172.30.1.1 ether 00:07:40:8E:56:A4 C ixp1
    -bash-2.05b#
    ================================================== ===========================

    The PC doing the testing has the following:

    ================================================== ===========================
    root@tanith:/root 82# ifconfig
    eth0 Link encap:Ethernet HWaddr 00:50:FC:B3:5F:26
    inet addr:172.30.0.1 Bcast:172.30.0.255 Mask:255.255.255.0
    inet6 addr: fe80::250:fcff:feb3:5f26/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:3623 errors:0 dropped:0 overruns:0 frame:0
    TX packets:3603 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:224207 (218.9 KiB) TX bytes:1998944 (1.9 MiB)
    Interrupt:201 Base address:0x6000

    eth1 Link encap:Ethernet HWaddr 00:07:40:8E:56:A4
    inet addr:172.30.1.1 Bcast:172.30.1.255 Mask:255.255.255.0
    inet6 addr: fe80::207:40ff:fe8e:56a4/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:152725 errors:0 dropped:0 overruns:0 frame:0
    TX packets:193340 errors:0 dropped:0 overruns:0 carrier:0
    collisions:32254 txqueuelen:1000
    RX bytes:19980287 (19.0 MiB) TX bytes:176632964 (168.4 MiB)
    Interrupt:209 Base address:0x8000

    eth2 Link encap:Ethernet HWaddr 00:50:FC:4A:C2:1C
    inet addr:172.30.2.1 Bcast:172.30.2.255 Mask:255.255.255.0
    inet6 addr: fe80::250:fcff:fe4a:c21c/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:28685 errors:0 dropped:0 overruns:0 frame:0
    TX packets:29568 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:1728314 (1.6 MiB) TX bytes:16021972 (15.2 MiB)
    Interrupt:217 Base address:0x4000

    eth3 Link encap:Ethernet HWaddr 00:0D:61:4D:C9:3A
    inet addr:192.168.2.27 Bcast:192.168.2.255 Mask:255.255.255.0
    inet6 addr: fe80::20d:61ff:fe4d:c93a/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:8068633 errors:0 dropped:0 overruns:0 frame:0
    TX packets:5464124 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:3225398207 (3.0 GiB) TX bytes:371598322 (354.3 MiB)
    Interrupt:201 Base address:0xd000

    lo Link encap:Local Loopback
    inet addr:127.0.0.1 Mask:255.0.0.0
    inet6 addr: ::1/128 Scope:Host
    UP LOOPBACK RUNNING MTU:16436 Metric:1
    RX packets:224639 errors:0 dropped:0 overruns:0 frame:0
    TX packets:224639 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:1748770581 (1.6 GiB) TX bytes:1748770581 (1.6 GiB)

    root@tanith:/root 83# route
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref Use Iface
    172.30.1.0 * 255.255.255.0 U 0 0 0 eth1
    192.168.2.0 * 255.255.255.0 U 0 0 0 eth3
    172.30.0.0 * 255.255.255.0 U 0 0 0 eth0
    172.30.2.0 * 255.255.255.0 U 0 0 0 eth2
    169.254.0.0 * 255.255.0.0 U 0 0 0 eth3
    default 192.168.2.2 0.0.0.0 UG 0 0 0 eth3
    root@tanith:/root 84# arp
    Address HWtype HWaddress Flags Mask Iface
    172.30.2.3 (incomplete) eth2
    192.168.2.241 ether 00:0E:2E:53:3E:CA C eth3
    192.168.2.23 ether 00:12:3F:2A4:86 C eth3
    172.30.1.3 ether 00:02:B3:02:02:02 C eth1
    192.168.2.2 ether 00:06:B1:34:AD:B0 C eth3
    192.168.2.12 ether 00:14:22:7B:5D:38 C eth3
    192.168.2.231 ether 00:01:02:9B:3C:A9 C eth3
    ================================================== ===========================

    Interface eth3 on the PC is the connection to the office LAN using a different
    private IP space.

    Interface eth0 is currently not connected on the PC.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-05-10-1632@ipal.net |
    |------------------------------------/-------------------------------------|

  2. Re: using 2nd network interface - won't try to TX anything

    On the first machine, it seems lack a record for default route. you
    must add a default route to the interface what you want to use.

    Your origin config:
    ================================================== ===========================
    -bash-2.05b# route
    Kernel IP routing table
    Destination Gateway Genmask Flags Metric Ref
    Use Iface
    172.30.1.0 * 255.255.255.0 U 0 0
    0 ixp1
    172.30.2.0 * 255.255.255.0 U 0 0
    0 ixp2
    169.254.0.0 * 255.255.0.0 U 0 0
    0 lo
    -bash-2.05b#
    ================================================== ===========================


  3. Re: using 2nd network interface - won't try to TX anything

    On 11 May 2007 07:15:05 -0700 linarin wrote:

    | On the first machine, it seems lack a record for default route. you
    | must add a default route to the interface what you want to use.
    |
    | Your origin config:
    | ================================================== ===========================
    | -bash-2.05b# route
    | Kernel IP routing table
    | Destination Gateway Genmask Flags Metric Ref
    | Use Iface
    | 172.30.1.0 * 255.255.255.0 U 0 0
    | 0 ixp1
    | 172.30.2.0 * 255.255.255.0 U 0 0
    | 0 ixp2
    | 169.254.0.0 * 255.255.0.0 U 0 0
    | 0 lo
    | -bash-2.05b#
    | ================================================== ===========================

    There is nowhere that machine needs to go to other than 172.30.1.0/24 and
    172.30.2.0/24 and those are specifically already routed.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-05-11-1135@ipal.net |
    |------------------------------------/-------------------------------------|

  4. Re: using 2nd network interface - won't try to TX anything

    phil-news-nospam@ipal.net wrote:
    > I'm trying to make use of a 2nd ethernet interface. The basic steps seem
    > to work OK. But nothing gets transmitted out the 2nd interface. Yet it
    > does see packets coming back the other way on that interface.
    >
    > Here's what ifconfig shows:
    >
    > ================================================== ===========================
    > -bash-2.05b# ifconfig
    > ixp1 Link encap:Ethernet HWaddr 00:02:B3:02:02:02
    > inet addr:172.30.1.3 Bcast:172.30.1.255 Mask:255.255.255.0
    > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    > RX packets:21049 errors:0 dropped:0 overruns:0 frame:0
    > TX packets:16493 errors:0 dropped:0 overruns:0 carrier:0
    > collisions:0 txqueuelen:256
    > RX bytes:17841196 (17.0 Mb) TX bytes:2523518 (2.4 Mb)
    >
    > ixp2 Link encap:Ethernet HWaddr 00:02:B3:03:03:03
    > inet addr:172.30.2.3 Bcast:172.30.2.255 Mask:255.255.255.0
    > UP BROADCAST MULTICAST MTU:1500 Metric:1
    > RX packets:222 errors:0 dropped:0 overruns:0 frame:0
    > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    > collisions:0 txqueuelen:256
    > RX bytes:13320 (13.0 Kb) TX bytes:0 (0.0 b)
    >
    > lo Link encap:Local Loopback
    > inet addr:127.0.0.1 Mask:255.0.0.0
    > UP LOOPBACK RUNNING MTU:16436 Metric:1
    > RX packets:8 errors:0 dropped:0 overruns:0 frame:0
    > TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
    > collisions:0 txqueuelen:0
    > RX bytes:560 (560.0 b) TX bytes:560 (560.0 b)
    >
    > -bash-2.05b#
    > ================================================== ===========================
    >
    > One thing I notice here that might be an issue is that the status RUNNING
    > is not included in ixp2. Could that be related to the problem? How would
    > I fix this if so?


    Try taking the interface down and bringing it back up again?

    When I'm trying to debug this sort of thing, I find it really helps to
    run multiple instances of tcpdump -n. Each instance captures from a
    single interface at each end. (And limit pinging to 3 or 4 packets so
    important stuff doesn't scroll away.) That way you can troubleshoot
    things like hubs and switches that don't forward ARPs properly.

    Oh, and it might help those of us in need of an afternoon siesta :-) to
    label your machines A and B or something. I found the phrase "the
    machine under test" a tad ambiguous.

  5. Re: using 2nd network interface - won't try to TX anything

    On 10 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    , phil-news-nospam@ipal.net wrote:

    >I'm trying to make use of a 2nd ethernet interface. The basic steps
    >seem to work OK. But nothing gets transmitted out the 2nd interface.


    When you try, what (if any) error messages does your application give?

    The real question is WTF Is this? "ixp1' shows up on google as a
    very uncommon device name - one page which google says is at
    http://www.nslu2-linux.org/wiki/FAQ/...tworkInterface says:

    What is the ixp1 interface, and can it be used for anything useful?

    The IXP420 has two network interfaces built in, ixp0 and ixp1. ixp0 is
    wired to the ethernet socket on the back through the RealTek PHY chip.
    ixp1 however is not connected to anything at all and the lines aren't
    brought out anywhere on the PCB. This means that it is not possible to
    use ixp1 at all.

    I also find it interesting that your ifconfig output gives

    >lo Link encap:Local Loopback
    > inet addr:127.0.0.1 Mask:255.0.0.0


    as expected, but the routing table says

    >169.254.0.0 * 255.255.0.0 U 0 0 0 lo


    Sorry, Phil, that don't compute.

    Also, the MAC addresses in the ifconfig output:

    >ixp1 Link encap:Ethernet HWaddr 00:02:B3:02:02:02


    >ixp2 Link encap:Ethernet HWaddr 00:02:B3:03:03:03


    [compton ~]$ etherwhois 00:02:B3
    00-02-B3 (hex) Intel Corporation
    0002B3 (base 16) Intel Corporation
    M/S: JF3-420
    2111 N.E. 25th Ave.
    Hillsboro OR 97124
    UNITED STATES
    [compton ~]$

    but those last six chars are stretching probability as serial numbers
    from someone like Intel.

    >The topology is that ixp1 is connected via a switch to eth1 on a PC, and
    >ixp2 is connected via a different switch to eth2 on the same PC. There are
    >not other hosts connected on these segments. There is no default gateway
    >as this test machine is not to be able to reach the internet.


    On that PC - does a packet sniffer show anything coming from this "ixp2"
    interface?

    Old guy

  6. Re: using 2nd network interface - won't try to TX anything

    On 11 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    <1178892905.423366.242550@u30g2000hsc.googlegroups. com>, linarin wrote:

    >On the first machine, it seems lack a record for default route. you
    >must add a default route to the interface what you want to use.


    I guess you missed the line where Phil wrote:

    There is no default gateway as this test machine is not to be able
    to reach the internet.

    A default route is ONLY needed to reach places not described by other
    entries in the routing table.

    >Your origin config:
    >================================================== ==========================
    >-bash-2.05b# route
    >Kernel IP routing table
    >Destination Gateway Genmask Flags Metric Ref Use Iface
    >172.30.1.0 * 255.255.255.0 U 0 0 0 ixp1
    >172.30.2.0 * 255.255.255.0 U 0 0 0 ixp2
    >169.254.0.0 * 255.255.0.0 U 0 0 0 lo
    >-bash-2.05b#
    >================================================== ==========================


    The table says that he has 172.30.1.0/24 _directly_ reachable on ixp1, and
    172.30.2.0/24 _directly_ reachable on ixp1. "directly" means that no
    gateway is involved. However I do find it interesting that the loopback
    is using LinkLocal addresses instead of 127.0.0.0/8.

    Old guy

  7. Re: using 2nd network interface - won't try to TX anything

    Moe Trin wrote:
    > On 10 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    > , phil-news-nospam@ipal.net wrote:

    ....
    > I also find it interesting that your ifconfig output gives
    >> lo Link encap:Local Loopback
    >> inet addr:127.0.0.1 Mask:255.0.0.0

    > as expected, but the routing table says
    >> 169.254.0.0 * 255.255.0.0 U 0 0 0 lo

    > Sorry, Phil, that don't compute.


    Fedora seems hang 169.254.0.0 on a random interface.

    > ixp1 however is not connected to anything at all and the lines
    > aren't brought out anywhere on the PCB.
    > On that PC - does a packet sniffer show anything coming from this "ixp2"
    > interface?


    Wasn't this the interface that was not running?

  8. Re: using 2nd network interface - won't try to TX anything

    phil-news-nospam@ipal.net wrote:

    X bytes:17841196 (17.0 Mb) TX bytes:2523518 (2.4 Mb)
    >
    >ixp2 Link encap:Ethernet HWaddr 00:02:B3:03:03:03
    > inet addr:172.30.2.3 Bcast:172.30.2.255 Mask:255.255.255.0
    > UP BROADCAST MULTICAST MTU:1500 Metric:1


    >One thing I notice here that might be an issue is that the status RUNNING
    >is not included in ixp2. Could that be related to the problem? How would
    >I fix this if so?


    I think that's exactly your problem. What could cause it? Could be
    several things. Hardware issues can cause this. Is Linux properly
    detecting the card? Is it configuring it properly? Driver issue?
    Anything in syslog? Boot messages? I'd start there. Doesn't look like
    a routing issue. Your setup otherwise looks OK, but for whatever
    reason, that network card/driver isn't initializing properly.

  9. Re: using 2nd network interface - won't try to TX anything

    On Fri, 11 May 2007 19:24:07 -0500 Moe Trin wrote:
    | On 11 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    | <1178892905.423366.242550@u30g2000hsc.googlegroups. com>, linarin wrote:
    |
    |>On the first machine, it seems lack a record for default route. you
    |>must add a default route to the interface what you want to use.
    |
    | I guess you missed the line where Phil wrote:
    |
    | There is no default gateway as this test machine is not to be able
    | to reach the internet.
    |
    | A default route is ONLY needed to reach places not described by other
    | entries in the routing table.
    |
    |>Your origin config:
    |>================================================== ==========================
    |>-bash-2.05b# route
    |>Kernel IP routing table
    |>Destination Gateway Genmask Flags Metric Ref Use Iface
    |>172.30.1.0 * 255.255.255.0 U 0 0 0 ixp1
    |>172.30.2.0 * 255.255.255.0 U 0 0 0 ixp2
    |>169.254.0.0 * 255.255.0.0 U 0 0 0 lo
    |>-bash-2.05b#
    |>================================================== ==========================
    |
    | The table says that he has 172.30.1.0/24 _directly_ reachable on ixp1, and
    | 172.30.2.0/24 _directly_ reachable on ixp1. "directly" means that no
    | gateway is involved. However I do find it interesting that the loopback
    | is using LinkLocal addresses instead of 127.0.0.0/8.

    It's running Fedora Core 2 and for some reason the network scripts do set
    that up. I don't know why, but I don't see why that would impact what I
    am doing. I guess someone developing FC way back then didn't understand
    what "link local" really meant.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-05-12-1408@ipal.net |
    |------------------------------------/-------------------------------------|

  10. Re: using 2nd network interface - won't try to TX anything

    On Fri, 11 May 2007 14:09:00 -0400 Allen McIntosh wrote:
    | phil-news-nospam@ipal.net wrote:
    |> I'm trying to make use of a 2nd ethernet interface. The basic steps seem
    |> to work OK. But nothing gets transmitted out the 2nd interface. Yet it
    |> does see packets coming back the other way on that interface.
    |>
    |> Here's what ifconfig shows:
    |>
    |> ================================================== ===========================
    |> -bash-2.05b# ifconfig
    |> ixp1 Link encap:Ethernet HWaddr 00:02:B3:02:02:02
    |> inet addr:172.30.1.3 Bcast:172.30.1.255 Mask:255.255.255.0
    |> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    |> RX packets:21049 errors:0 dropped:0 overruns:0 frame:0
    |> TX packets:16493 errors:0 dropped:0 overruns:0 carrier:0
    |> collisions:0 txqueuelen:256
    |> RX bytes:17841196 (17.0 Mb) TX bytes:2523518 (2.4 Mb)
    |>
    |> ixp2 Link encap:Ethernet HWaddr 00:02:B3:03:03:03
    |> inet addr:172.30.2.3 Bcast:172.30.2.255 Mask:255.255.255.0
    |> UP BROADCAST MULTICAST MTU:1500 Metric:1
    |> RX packets:222 errors:0 dropped:0 overruns:0 frame:0
    |> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    |> collisions:0 txqueuelen:256
    |> RX bytes:13320 (13.0 Kb) TX bytes:0 (0.0 b)
    |>
    |> lo Link encap:Local Loopback
    |> inet addr:127.0.0.1 Mask:255.0.0.0
    |> UP LOOPBACK RUNNING MTU:16436 Metric:1
    |> RX packets:8 errors:0 dropped:0 overruns:0 frame:0
    |> TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
    |> collisions:0 txqueuelen:0
    |> RX bytes:560 (560.0 b) TX bytes:560 (560.0 b)
    |>
    |> -bash-2.05b#
    |> ================================================== ===========================
    |>
    |> One thing I notice here that might be an issue is that the status RUNNING
    |> is not included in ixp2. Could that be related to the problem? How would
    |> I fix this if so?
    |
    | Try taking the interface down and bringing it back up again?

    I've done that many times in many combinations. No change.


    | When I'm trying to debug this sort of thing, I find it really helps to
    | run multiple instances of tcpdump -n. Each instance captures from a
    | single interface at each end. (And limit pinging to 3 or 4 packets so
    | important stuff doesn't scroll away.) That way you can troubleshoot
    | things like hubs and switches that don't forward ARPs properly.
    |
    | Oh, and it might help those of us in need of an afternoon siesta :-) to
    | label your machines A and B or something. I found the phrase "the
    | machine under test" a tad ambiguous.

    Is "machine A" and "machine PC" good enough. I actually have two of the
    machines being tested (both identical, both have the same issue), so I
    may end up also having to refer to "machine B".

    I need to get some crossover cables and see if by some remote chance the
    switches between these machines is playing a part.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-05-12-1409@ipal.net |
    |------------------------------------/-------------------------------------|

  11. Re: using 2nd network interface - won't try to TX anything

    On Fri, 11 May 2007 19:22:53 -0500 Moe Trin wrote:
    | On 10 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    | , phil-news-nospam@ipal.net wrote:
    |
    |>I'm trying to make use of a 2nd ethernet interface. The basic steps
    |>seem to work OK. But nothing gets transmitted out the 2nd interface.
    |
    | When you try, what (if any) error messages does your application give?

    No error messages are produced either by tools or the kernel.


    | The real question is WTF Is this? "ixp1' shows up on google as a
    | very uncommon device name - one page which google says is at
    | http://www.nslu2-linux.org/wiki/FAQ/...tworkInterface says:
    |
    | What is the ixp1 interface, and can it be used for anything useful?
    |
    | The IXP420 has two network interfaces built in, ixp0 and ixp1. ixp0 is
    | wired to the ethernet socket on the back through the RealTek PHY chip.
    | ixp1 however is not connected to anything at all and the lines aren't
    | brought out anywhere on the PCB. This means that it is not possible to
    | use ixp1 at all.

    It is a related device.


    | I also find it interesting that your ifconfig output gives
    |
    |>lo Link encap:Local Loopback
    |> inet addr:127.0.0.1 Mask:255.0.0.0
    |
    | as expected, but the routing table says
    |
    |>169.254.0.0 * 255.255.0.0 U 0 0 0 lo
    |
    | Sorry, Phil, that don't compute.

    No it doesn't. But it is not something I would expect to affect this.
    It is on by default in Fedora Core 2, which is what I am using.


    | Also, the MAC addresses in the ifconfig output:
    |
    |>ixp1 Link encap:Ethernet HWaddr 00:02:B3:02:02:02
    |
    |>ixp2 Link encap:Ethernet HWaddr 00:02:B3:03:03:03
    |
    | [compton ~]$ etherwhois 00:02:B3
    | 00-02-B3 (hex) Intel Corporation
    | 0002B3 (base 16) Intel Corporation
    | M/S: JF3-420
    | 2111 N.E. 25th Ave.
    | Hillsboro OR 97124
    | UNITED STATES
    | [compton ~]$
    |
    | but those last six chars are stretching probability as serial numbers
    | from someone like Intel.

    I did notice that oddity.


    |>The topology is that ixp1 is connected via a switch to eth1 on a PC, and
    |>ixp2 is connected via a different switch to eth2 on the same PC. There are
    |>not other hosts connected on these segments. There is no default gateway
    |>as this test machine is not to be able to reach the internet.
    |
    | On that PC - does a packet sniffer show anything coming from this "ixp2"
    | interface?

    Nothing coming from it at all.

    It's like the kernel thinks "that interface does not have a RUNNING status
    so I am not actually going to send anything out through it".

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-05-12-1412@ipal.net |
    |------------------------------------/-------------------------------------|

  12. Re: using 2nd network interface - won't try to TX anything

    On Fri, 11 May 2007 20:49:16 -0400 Allen McIntosh wrote:
    | Moe Trin wrote:
    |> On 10 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    |> , phil-news-nospam@ipal.net wrote:
    | ...
    |> I also find it interesting that your ifconfig output gives
    |>> lo Link encap:Local Loopback
    |>> inet addr:127.0.0.1 Mask:255.0.0.0
    |> as expected, but the routing table says
    |>> 169.254.0.0 * 255.255.0.0 U 0 0 0 lo
    |> Sorry, Phil, that don't compute.
    |
    | Fedora seems hang 169.254.0.0 on a random interface.

    Later versions of Fedora don't do this oddity. It was annoying early on
    because I was trying to use subnets of 169.254.0.0/16 on the ethernet
    interfaces, and Fedora was messing it up badly. So I switched over to
    private IP space different from the office LAN.


    | > ixp1 however is not connected to anything at all and the lines
    | > aren't brought out anywhere on the PCB.
    |> On that PC - does a packet sniffer show anything coming from this "ixp2"
    |> interface?
    |
    | Wasn't this the interface that was not running?

    Correct. Nothing comes from it.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-05-12-1416@ipal.net |
    |------------------------------------/-------------------------------------|

  13. Re: using 2nd network interface - won't try to TX anything

    On Sat, 12 May 2007 03:45:05 GMT Longtime Lurker wrote:
    | phil-news-nospam@ipal.net wrote:
    |
    | X bytes:17841196 (17.0 Mb) TX bytes:2523518 (2.4 Mb)
    |>
    |>ixp2 Link encap:Ethernet HWaddr 00:02:B3:03:03:03
    |> inet addr:172.30.2.3 Bcast:172.30.2.255 Mask:255.255.255.0
    |> UP BROADCAST MULTICAST MTU:1500 Metric:1
    |
    |>One thing I notice here that might be an issue is that the status RUNNING
    |>is not included in ixp2. Could that be related to the problem? How would
    |>I fix this if so?
    |
    | I think that's exactly your problem. What could cause it? Could be
    | several things. Hardware issues can cause this. Is Linux properly
    | detecting the card? Is it configuring it properly? Driver issue?
    | Anything in syslog? Boot messages? I'd start there. Doesn't look like
    | a routing issue. Your setup otherwise looks OK, but for whatever
    | reason, that network card/driver isn't initializing properly.

    OK, so I'll focus on that for now. I'll research what "RUNNING" means.
    I suppose ifconfig is testing a one-bit flag somewhere so I'll have to
    see the ifconfig source first to get the name of the flag.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-05-12-1418@ipal.net |
    |------------------------------------/-------------------------------------|

  14. Re: using 2nd network interface - won't try to TX anything

    On 12 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    , phil-news-nospam@ipal.net wrote:

    >Moe Trin wrote:


    >| When you try, what (if any) error messages does your application give?
    >
    >No error messages are produced either by tools or the kernel.


    Unusual - I'd expect it to eventually timeout with a 'Host Unreachable'

    >| The real question is WTF Is this? "ixp1' shows up on google as a
    >| very uncommon device name - one page which google says is at
    >| http://www.nslu2-linux.org/wiki/FAQ/...tworkInterface says:


    >It is a related device.


    Well, that web page says that the interface isn't wired. Is that the
    same case with your unspecified device?

    >| I also find it interesting that your ifconfig output gives
    >|
    >|>lo Link encap:Local Loopback
    >|> inet addr:127.0.0.1 Mask:255.0.0.0
    >|
    >| as expected, but the routing table says
    >|
    >|>169.254.0.0 * 255.255.0.0 U 0 0 0 lo
    >|
    >| Sorry, Phil, that don't compute.
    >
    >No it doesn't. But it is not something I would expect to affect this.


    That's true, but I wonder what else is hosed with the networking scripts.

    >It is on by default in Fedora Core 2, which is what I am using.


    FC2 hasn't been officially supported for two years, and the last
    backported errata at fedoralegacy.org was eleven months ago. I assume
    you have some compelling reason for using such an old distribution.

    If you look inside /etc/sysconfig/network-scripts/ifup you'll find:

    ----------
    # Add Zeroconf route.
    if [ -z "${NOZEROCONF}" -a "${ISALIAS}" = "no" ]; then
    ip route replace 169.254.0.0/16 dev ${REALDEVICE}
    fi
    ----------
    So if you set NOZEROCONF=yes in the /etc/sysconfig/network configuration
    file, this "feature" will be disabled.

    >| Also, the MAC addresses in the ifconfig output:
    >|
    >|>ixp1 Link encap:Ethernet HWaddr 00:02:B3:02:02:02
    >|
    >|>ixp2 Link encap:Ethernet HWaddr 00:02:B3:03:03:03


    >| but those last six chars are stretching probability as serial numbers
    >| from someone like Intel.
    >
    >I did notice that oddity.


    >Nothing coming from it at all.
    >
    >It's like the kernel thinks "that interface does not have a RUNNING
    >status so I am not actually going to send anything out through it".


    That would fit with there being no wiring to the interface.

    In another post you mention wanting to use 169.254.0.0/16 as a
    non-public IP address range. (Doesn't the 17,891,328 addresses from
    RFC1918 provide enough space? If not, see RFC3330 and you can also
    use 192.0.2.* and 198.18.0.0/15 - RFC2544 documentation addresses as
    well.) In theory, setting "NOZEROCONF=yes" in /etc/sysconfig/network
    should allow you to use that /16 as well. This assumes that whoever
    configured your perimeter router knows to drop RFC3330 packets in or
    outbound. See RFC2827 and RFC3704 for additional hints.

    Old guy

  15. Re: using 2nd network interface - won't try to TX anything

    On Fri, 11 May 2007, in the Usenet newsgroup comp.os.linux.networking, in
    article , Allen McIntosh wrote:

    >Moe Trin wrote:


    >> phil-news-nospam@ipal.net wrote:


    >> I also find it interesting that your ifconfig output gives
    >>> lo Link encap:Local Loopback
    >>> inet addr:127.0.0.1 Mask:255.0.0.0

    >> as expected, but the routing table says
    >>> 169.254.0.0 * 255.255.0.0 U 0 0 0 lo

    >
    >Fedora seems hang 169.254.0.0 on a random interface.


    If Fedora is so brain-dead as to add a LinkLocal/ZeroConf route to the
    loopback interface, then someone need to tell the stock-holders of Red
    Hat that all the people with clue have left, and it's time to fold the
    tents and bail.

    A "LinkLocal" or "ZeroConf" address started out as the Apple "Bonjour"
    or "Rendezvous" service - a mechanism to allow two sales weasels meeting
    in an airport waiting area to trade pr0n^H^H^H^Hsales information by
    connecting two computers with a network cable or wireless, but absolutely
    no knowledge of networks, IP addresses, or anything like that. Microsoft
    discovered the service, and incorporated it into win98 so that when the
    MSCE has so fscked up the configuration of the DHCP server that even
    windoze won't work, the computers will grab a random address out of
    their a$$ and use that to establish a local network connection. It took
    seven years to get this massive security hole past the IETF (RFC3927),
    but the intent is that when your system (configured for DHCP) can't find
    a DHCP _server_ to get an address, it will use an address in the range
    169.254.0.0/16. The RFC recommends not having "routable" IP addresses
    (which it defines as anything OTHER THAN 169.254.0.0/16 and 127.0.0.0/8)
    and ZeroConf or LinkLocal addresses on the same interface. The only
    reason I can see to have a "routable" and "LinkLocal" or "ZeroConf"
    address range in the routing table on the same interface is to prevent
    "Martian" source error messages, which to me makes no sense at all.
    But then too, I really have never seen a loopback interface using DHCP,
    though I'm sure some MSCE has tried. If you have a box using the
    169.254.0.0/16 address range on your _network_, FIX THE DHCP CRAP rather
    than hiding the symptoms. Actually at work (where everything uses
    static addresses), we monitor for 169.254.0.0/16 addresses to detect
    intruders on the network.

    >> ixp1 however is not connected to anything at all and the lines
    >> aren't brought out anywhere on the PCB.
    >> On that PC - does a packet sniffer show anything coming from this "ixp2"
    >> interface?

    >
    >Wasn't this the interface that was not running?


    Yes, but is this the system that the O/P is using?

    Old guy


  16. Re: using 2nd network interface - won't try to TX anything

    On Sat, 12 May 2007 18:54:01 -0500 Moe Trin wrote:

    | If Fedora is so brain-dead as to add a LinkLocal/ZeroConf route to the
    | loopback interface, then someone need to tell the stock-holders of Red
    | Hat that all the people with clue have left, and it's time to fold the
    | tents and bail.

    That was in FC2, which for various reasons is the one I'm stuck with for
    this particular project. In defense of Fedora (not something I usually
    do), it is fixed by FC5 and FC6.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-05-15-0838@ipal.net |
    |------------------------------------/-------------------------------------|

  17. Re: using 2nd network interface - won't try to TX anything

    On Sat, 12 May 2007 18:54:01 -0500 Moe Trin wrote:

    | A "LinkLocal" or "ZeroConf" address started out as the Apple "Bonjour"
    | or "Rendezvous" service - a mechanism to allow two sales weasels meeting
    | in an airport waiting area to trade pr0n^H^H^H^Hsales information by
    | connecting two computers with a network cable or wireless, but absolutely
    | no knowledge of networks, IP addresses, or anything like that. Microsoft
    | discovered the service, and incorporated it into win98 so that when the
    | MSCE has so fscked up the configuration of the DHCP server that even
    | windoze won't work, the computers will grab a random address out of
    | their a$$ and use that to establish a local network connection. It took
    | seven years to get this massive security hole past the IETF (RFC3927),
    | but the intent is that when your system (configured for DHCP) can't find
    | a DHCP _server_ to get an address, it will use an address in the range
    | 169.254.0.0/16. The RFC recommends not having "routable" IP addresses
    | (which it defines as anything OTHER THAN 169.254.0.0/16 and 127.0.0.0/8)
    | and ZeroConf or LinkLocal addresses on the same interface. The only
    | reason I can see to have a "routable" and "LinkLocal" or "ZeroConf"
    | address range in the routing table on the same interface is to prevent
    | "Martian" source error messages, which to me makes no sense at all.
    | But then too, I really have never seen a loopback interface using DHCP,
    | though I'm sure some MSCE has tried. If you have a box using the
    | 169.254.0.0/16 address range on your _network_, FIX THE DHCP CRAP rather
    | than hiding the symptoms. Actually at work (where everything uses
    | static addresses), we monitor for 169.254.0.0/16 addresses to detect
    | intruders on the network.

    As far as I can see, Fedora did not put that address on "lo" by DHCP.
    It did so directly.

    Combined with proxy ARP (which Linux seems to do even if you turn it off)
    having that address on "lo" makes it respond on all interfaces. It would
    do the job for the sales people you described as long as it didn't happen
    to pick exactly the same IP address for each.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-05-15-0841@ipal.net |
    |------------------------------------/-------------------------------------|

  18. Re: using 2nd network interface - won't try to TX anything

    On Sat, 12 May 2007 18:52:03 -0500 Moe Trin wrote:
    | On 12 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    | , phil-news-nospam@ipal.net wrote:
    |
    |>Moe Trin wrote:
    |
    |>| When you try, what (if any) error messages does your application give?
    |>
    |>No error messages are produced either by tools or the kernel.
    |
    | Unusual - I'd expect it to eventually timeout with a 'Host Unreachable'

    I was using ifconfig, as well as ipconfig inside initramfs from klibc.
    The tools I speak of were tools to configure it. When I do ping to test
    it then I do get errors.


    |>| The real question is WTF Is this? "ixp1' shows up on google as a
    |>| very uncommon device name - one page which google says is at
    |>| http://www.nslu2-linux.org/wiki/FAQ/...tworkInterface says:
    |
    |>It is a related device.
    |
    | Well, that web page says that the interface isn't wired. Is that the
    | same case with your unspecified device?

    It is supposed to be wired. It gets detected as an existing device.


    |>| Sorry, Phil, that don't compute.
    |>
    |>No it doesn't. But it is not something I would expect to affect this.
    |
    | That's true, but I wonder what else is hosed with the networking scripts.

    Perhaps much. I'm trying to work around them. I run a script I wrote
    called /init in initramfs to start it up, with the ipconfig command from
    klibc, and that does the same. I just don't have easy means to do much
    testing during the run of /init.


    |>It is on by default in Fedora Core 2, which is what I am using.
    |
    | FC2 hasn't been officially supported for two years, and the last
    | backported errata at fedoralegacy.org was eleven months ago. I assume
    | you have some compelling reason for using such an old distribution.

    Someone else does. Not my choice. A shift now would put things way
    behind schedule.


    | If you look inside /etc/sysconfig/network-scripts/ifup you'll find:
    |
    | ----------
    | # Add Zeroconf route.
    | if [ -z "${NOZEROCONF}" -a "${ISALIAS}" = "no" ]; then
    | ip route replace 169.254.0.0/16 dev ${REALDEVICE}
    | fi
    | ----------
    | So if you set NOZEROCONF=yes in the /etc/sysconfig/network configuration
    | file, this "feature" will be disabled.

    But I don't think that has any relevance to the problem being seen,
    which is that ixp2 is non-functional. Do you ahve any plausible reason
    to believe otherwise?


    |>It's like the kernel thinks "that interface does not have a RUNNING
    |>status so I am not actually going to send anything out through it".
    |
    | That would fit with there being no wiring to the interface.

    I would think it would just find no such interface in that case.
    It does _receive_ packets and counts them. I can't tell where they
    end up.


    | In another post you mention wanting to use 169.254.0.0/16 as a
    | non-public IP address range. (Doesn't the 17,891,328 addresses from
    | RFC1918 provide enough space? If not, see RFC3330 and you can also
    | use 192.0.2.* and 198.18.0.0/15 - RFC2544 documentation addresses as
    | well.) In theory, setting "NOZEROCONF=yes" in /etc/sysconfig/network
    | should allow you to use that /16 as well. This assumes that whoever
    | configured your perimeter router knows to drop RFC3330 packets in or
    | outbound. See RFC2827 and RFC3704 for additional hints.

    I wanted to use 169.254.0.0/16 as my isolated LAN segment for testing.
    Because of the FC drainbamage I could not, so I opted for 172.30.0.0/16.

    --
    |---------------------------------------/----------------------------------|
    | Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
    | first name lower case at ipal.net / spamtrap-2007-05-15-0843@ipal.net |
    |------------------------------------/-------------------------------------|

  19. Re: using 2nd network interface - won't try to TX anything

    On 15 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
    , phil-news-nospam@ipal.net wrote:

    >|>| The real question is WTF Is this? "ixp1' shows up on google as a
    >|>| very uncommon device name - one page which google says is at
    >|>| http://www.nslu2-linux.org/wiki/FAQ/...tworkInterface says:
    >|
    >|>It is a related device.


    That webpage says it's a RealTek PHY chip which should respond to
    mii-tools. Have you tried those?

    >| Well, that web page says that the interface isn't wired. Is that the
    >| same case with your unspecified device?
    >
    >It is supposed to be wired. It gets detected as an existing device.


    If the PHY chip is wired to the system, but not to the Ethernet
    connector on the box, you may seem similar results. Normally, I'd
    expect to see 'carrier' errors if this were the case. This might
    explain the lack of the "RUNNING" flag.

    >| That would fit with there being no wiring to the interface.
    >
    >I would think it would just find no such interface in that case.
    >It does _receive_ packets and counts them. I can't tell where they
    >end up.


    Depends entirely on how this unidentified card is wired. No transmit
    does not mean no receive except on coaxial networks, and even that is
    a function of the Ethernet media driver. Have you tried to contact
    the supplier of the card?

    Old guy

+ Reply to Thread