Re: Ethernet issue: works one way but not another

From: John A. (johna9999_at_gmail.com)
Date: 03/19/05

  • Next message: Michael Collette: "Permissions for Linux apps via LDAP"
    Date: Fri, 18 Mar 2005 19:58:13 -0500
    To: freebsd-questions@freebsd.org
    
    

    OK, lets see if this helps...

    dmesg:

    Copyright (c) 1992-2004 The FreeBSD Project.
    Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
            The Regents of the University of California. All rights reserved.
    FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004
        root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
    Timecounter "i8254" frequency 1193182 Hz quality 0
    CPU: Pentium III/Pentium III Xeon/Celeron (451.02-MHz 686-class CPU)
      Origin = "GenuineIntel" Id = 0x673 Stepping = 3
      Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE>
    real memory = 134152192 (127 MB)
    avail memory = 121622528 (115 MB)
    npx0: [FAST]
    npx0: <math processor> on motherboard
    npx0: INT 16 interface
    acpi0: <XXXXXX AWRDACPI> on motherboard
    acpi0: Power Button (fixed)
    Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
    acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
    cpu0: <ACPI CPU (3 Cx states)> on acpi0
    acpi_button0: <Power Button> on acpi0
    pcib0: <ACPI Host-PCI bridge> port
    0x5000-0x500f,0x4000-0x4041,0xcf8-0xcff on acpi0
    pci0: <ACPI PCI bus> on pcib0
    agp0: <Intel 82443BX (440 BX) host to PCI bridge> mem
    0xd0000000-0xd3ffffff at device 0.0 on pci0
    pcib1: <PCI-PCI bridge> at device 1.0 on pci0
    pci1: <PCI bus> on pcib1
    pci1: <display, VGA> at device 0.0 (no driver attached)
    isab0: <PCI-ISA bridge> at device 7.0 on pci0
    isa0: <ISA bus> on isab0
    atapci0: <Intel PIIX4 UDMA33 controller> port
    0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on
    pci0
    ata0: channel #0 on atapci0
    ata1: channel #1 on atapci0
    uhci0: <Intel 82371AB/EB (PIIX4) USB controller> port 0xe000-0xe01f
    irq 11 at device 7.2 on pci0
    uhci0: [GIANT-LOCKED]
    usb0: <Intel 82371AB/EB (PIIX4) USB controller> on uhci0
    usb0: USB revision 1.0
    uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
    uhub0: 2 ports with 2 removable, self powered
    pci0: <bridge, PCI-unknown> at device 7.3 (no driver attached)
    ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xe400-0xe4ff mem
    0xd7000000-0xd7000fff irq 10 at device 9.0 on pci0
    ahc0: [GIANT-LOCKED]
    aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
    xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xe800-0xe87f mem
    0xd7001000-0xd700107f irq 5 at device 13.0 on pci0
    miibus0: <MII bus> on xl0
    xlphy0: <3Com internal media interface> on miibus0
    xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
    xl0: Ethernet address: 00:10:4b:7a:e4:ec
    fdc0: <floppy drive controller> port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0
    fdc0: [FAST]
    fd0: <1440-KB 3.5" drive> on fdc0 drive 0
    sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
    sio0: type 16550A
    sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
    sio1: type 16550A
    atkbdc0: <Keyboard controller (i8042)> port 0x64,0x60 irq 1 on acpi0
    atkbd0: <AT Keyboard> irq 1 on atkbdc0
    kbd0 at atkbd0
    atkbd0: [GIANT-LOCKED]
    psm0: <PS/2 Mouse> irq 12 on atkbdc0
    psm0: [GIANT-LOCKED]
    psm0: model IntelliMouse, device ID 3
    orm0: <ISA Option ROMs> at iomem 0xcc000-0xd07ff,0xc0000-0xcbfff on isa0
    pmtimer0 on isa0
    ppc0: parallel port not found.
    sc0: <System console> at flags 0x100 on isa0
    sc0: VGA <16 virtual consoles, flags=0x300>
    vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
    Timecounter "TSC" frequency 451024000 Hz quality 800
    Timecounters tick every 10.000 msec
    Waiting 15 seconds for SCSI devices to settle
    acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0%
    da0 at ahc0 bus 0 target 0 lun 0
    da0: <SEAGATE ST34501W 0017> Fixed Direct Access SCSI-2 device
    da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled
    da0: 4339MB (8887200 512 byte sectors: 255H 63S/T 553C)

    rc.conf: (names have been changed to protect the innocent/guilty)

    gateway_enable="NO"
    hostname="myhost.domain.com"
    nisdomainname="domain.com"
    ifconfig_xl0="inet 192.168.79.254/24"
    defaultrouter="192.168.79.1"
    linux_enable="YES"
    moused_enable="YES"
    sshd_enable="YES"
    usbd_enable="YES"

    ifconfig: (This is when connected to internal network through 3Com 100mb hub)

    xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
            options=9<RXCSUM,VLAN_MTU>
            inet6 fe80::210:4bff:fe7a:e4ec%xl0 prefixlen 64 scopeid 0x1
            inet 192.168.79.254 netmask 0xffffff00 broadcast 192.168.79.255
            ether 00:10:4b:7a:e4:ec
            media: Ethernet autoselect (100baseTX)
            status: active
    lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
            inet 127.0.0.1 netmask 0xff000000
            inet6 ::1 prefixlen 128
            inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2

    netstat -rn:

    Routing tables

    Internet:
    Destination Gateway Flags Refs Use Netif Expire
    127.0.0.1 127.0.0.1 UH 0 0 lo0
    192.168.79 link#1 UC 0 0 xl0
    192.168.79.1 00:30:48:41:dc:58 UHLW 0 4 xl0 1084

    Internet6:
    Destination Gateway Flags
        Netif Expire
    ::1 ::1 UH lo0
    fe80::%xl0/64 link#1 UC xl0
    fe80::210:4bff:fe7a:e4ec%xl0 00:10:4b:7a:e4:ec UHL lo0
    fe80::%lo0/64 fe80::1%lo0 U lo0
    fe80::1%lo0 link#2 UHL lo0
    ff01::/32 ::1 U lo0
    ff02::%xl0/32 link#1 UC xl0
    ff02::%lo0/32 ::1 UC lo0

    ping -c 5 192.168.79.1:

    PING 192.168.79.1 (192.168.79.1): 56 data bytes
    64 bytes from 192.168.79.1: icmp_seq=0 ttl=64 time=0.626 ms
    64 bytes from 192.168.79.1: icmp_seq=1 ttl=64 time=0.567 ms
    64 bytes from 192.168.79.1: icmp_seq=2 ttl=64 time=0.619 ms
    64 bytes from 192.168.79.1: icmp_seq=3 ttl=64 time=0.464 ms
    64 bytes from 192.168.79.1: icmp_seq=4 ttl=64 time=0.519 ms

    --- 192.168.79.1 ping statistics ---
    5 packets transmitted, 5 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 0.464/0.559/0.626/0.061 ms

    ifconfig xl0: (This is when connected directly to internet through
    wireless radio using a 3Com 10mb hub)

    xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
            options=9<RXCSUM,VLAN_MTU>
            inet6 fe80::210:4bff:fe7a:e4ec%xl0 prefixlen 64 scopeid 0x1
            inet XXX.XXX.75.254 netmask 0xffffff00 broadcast XXX.XXX.75.255
            ether 00:10:4b:7a:e4:ec
            media: Ethernet autoselect (10baseT/UTP)
            status: active
    Routing tables

    Internet:
    Destination Gateway Flags Refs Use Netif Expire
    127.0.0.1 127.0.0.1 UH 0 0 lo0
    XXX.XXX.75 link#1 UC 0 0 xl0

    Internet6:
    Destination Gateway Flags
        Netif Expire
    ::1 ::1 UH lo0
    fe80::%xl0/64 link#1 UC xl0
    fe80::210:4bff:fe7a:e4ec%xl0 00:10:4b:7a:e4:ec UHL lo0
    fe80::%lo0/64 fe80::1%lo0 U lo0
    fe80::1%lo0 link#2 UHL lo0
    ff01::/32 ::1 U lo0
    ff02::%xl0/32 link#1 UC xl0
    ff02::%lo0/32 ::1 UC lo0

    ping XXX.XXX.75.1: (Ping eventually times out and says host is fown)

    PING XXX.XXX.75.1 (XXX.XXX.75.1): 56 data bytes

    --- XXX.XXX.75.1 ping statistics ---
    9 packets transmitted, 0 packets received, 100% packet loss

    netstat -rn: (After ping, host appears in routing table.)

    Routing tables

    Internet:
    Destination Gateway Flags Refs Use Netif Expire
    127.0.0.1 127.0.0.1 UH 0 0 lo0
    XXX.XXX.75 link#1 UC 0 0 xl0
    XXX.XXX.75.1 00:60:3e:10:d7:e9 UHLW 0 17 xl0 1200

    Internet6:
    Destination Gateway Flags
        Netif Expire
    ::1 ::1 UH lo0
    fe80::%xl0/64 link#1 UC xl0
    fe80::210:4bff:fe7a:e4ec%xl0 00:10:4b:7a:e4:ec UHL lo0
    fe80::%lo0/64 fe80::1%lo0 U lo0
    fe80::1%lo0 link#2 UHL lo0
    ff01::/32 ::1 U lo0
    ff02::%xl0/32 link#1 UC xl0
    ff02::%lo0/32 ::1 UC lo0

    This happens the same way weather or not I define a defult route. As
    I said previously, when I run tcpdump (with no arguments), it takes
    over 2 minutes to respond with the first packet captured. The time
    stamp on that packet is from when tcpdump started. When I connect
    this system to the 100mb hub, tcpdump responds normally showing my
    expected traffic and doesn't drop packets.

    After scrounging around, I laid my hands on a 10mb hub with 1 100mb
    port. Pluggung FBSD into 100mb, with radio in 10mb port, I was able
    to run tcpdump with expected results, but still could not ping the
    router (XXX.XXX.75.1).

    A little backround on myself: While I never claim to be an expert in
    FBSD, I have been working with BSDI at the isp I work for for the last
    8 years. I have a FBSD 4.7 server running in my server farm doing
    backups and audio streaming for some radio stations. In all of these
    years, I don't recall ever seeing symptoms like these. It looks to me
    like it might be some kind of timing issue. I realize that most
    people are useing 100mb or faster networks, but I can't believe that
    noone has tried to connect a FBSD 5.3 system to a 10mb network.

    As for my network topology, I have an internal network that goes
    through a firewall. This network is 100mb. I have no problem useing
    this network. Everything I have tried on FBSD works. I can ping FBSD
    from other systems on internal network.

    My wireless network is for isp customers and I connect to it for
    monitoring purposes. The radios have 10mb ports on them, I have no
    choice. Since BSDI is no longer around, I have to move to another os.
     I prefer not to follow the other sys admin and convert to peguin. I
    have BSDI servers that have been up for over 2 years. On average,
    penguin boxes have to be rebooted every quarter. My FBSD streamer has
    been up fro 281 days (and that was due to power and ups failure at a
    co-lo facility).

    I'm hoping that this will turn out to not be the head scratcher I fear
    it might. Hope this information helps.

    John A.

    On Fri, 18 Mar 2005 07:15:50 -0600, Greg Barniskis
    <nalists@scls.lib.wi.us> wrote:
    > Abu Khaled wrote:
    > ...
    > > Am I the only one interested in this topic? Where is the rest of our
    > > lovely community?
    > > Come on guys let's scratch those gray cells and help John out.
    > >
    >
    > Although progress is being made on getting detail, it's still
    > insufficient (and, not entirely consistent? if the connection in
    > question is *wired* then probably the fact that a wireless access
    > point exists on the same subnet is not likely relevant). Anyway, I
    > do not have a clear vision of what connects to what, how.
    >
    > The relevant portions of rc.conf, ifconfig output (and ipconfig
    > output from the M$ box), the syntax of the tcpdump, the specs of the
    > box, and other relevant details might spur more response. A simple
    > ASCII representation of the network might help.
    >
    > FWIW, I've seen tcpdump behave poorly if the box or card just
    > doesn't have the horsepower required to parse the volume of all the
    > packets being seen on the network.
    >
    > re: can't ping M$ box... M$ firewall sounds like the most likely
    > culprit. If you try to ping and get no response, does the M$ box
    > nevertheless show up in FreeBSD's arp table (compare arp -an before
    > and after the ping test)? If the MAC address shows up, you've got
    > connectivity just fine, but something's dropping the ICMP packets.
    >
    > PS to Abu -- your written English is as good or better than many
    > native speakers of the language, so don't apologize for it. =)
    >
    > --
    > Greg Barniskis, Computer Systems Integrator
    > South Central Library System (SCLS)
    > Library Interchange Network (LINK)
    > <gregb at scls.lib.wi.us>, (608) 266-6348
    >
    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"


  • Next message: Michael Collette: "Permissions for Linux apps via LDAP"