bcm5700 7.2.2, debian 3.0 r2 and tcpdump

From: the Know Hunter (debian_at_knowhunter.cjb.net)
Date: 05/29/04

  • Next message: steef van duin: "Re: scsi under sarge" 
    To: debian-user@lists.debian.org
Date: Sat, 29 May 2004 13:58:54 +0100

    oix ppl,

            I have a HP DL360 G3, with a dual bcm5700 NIC, installed with debain 3.0r2
    bf24, stable branch, and the driver compiled from the sources at broadcom.

            The proporse for this particular server is log http logs sniffed from my
    network. I have this solution already working on a R5400 da compaq, with a
    100 MiB NIC, but I need to upgrade the sistem to GiB, once the R5400 have too
    much overruns, and I'm loosing to much trafic, that shoud being logged.

            My actual config for the new box is:

            eth0 is used to sniff and log trafic, and is connect to a port in my main
    switch that is a mirror target from our port that connects to the external
    router.

            eth1 is used to management and copy logs to other box to processing.

            My problem is with eth0. I have it up, but without IP. I seted it in
    promiscous mode and without promiscous, with the same weird results.

            When I run tcpdump with any filter ("ip", "tcp", "port 80", ...) I only get
    some initial packets, in traffic time that means 37 packets, sometimes less
    than that, as I could see never more than that. The same weird thing happens
    with any other network tool I know (snort, ngrep, ethereal as the ones I
    tried), and obviasly with the software I use to sniff the logs (pandora).

            When running tcpdump, or any other without filter I get miles of packets, for
    as long as I keep the sniffer running.

            Please, someone help me. I already checked anyplace I know, read HOWTOs,
    FAQs, searched in google, and can find nothing like this.

            Some info:

    # ifconfig eth0
    eth0 Link encap:Ethernet HWaddr 00:0E:7F:FE:89:FA
              UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
              RX packets:51070854 errors:0 dropped:0 overruns:0 frame:0
              TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:100
              RX bytes:3839235087 (3.5 GiB) TX bytes:0 (0.0 b)
              Interrupt:11 Memory:f7ef0000-f7f00000

    When running this:
    # tcpdump -nn -i eth0|grep "80 "

    I get thousands lines, that keep going as long as I keep this running.

    Running:
    # tcpdump -nn -i eth0 "port 80"

    I get some lines, changing from run to run, but never more than 50 (highest
    common value is 37).

    This is nicinfo for my eth0:

    # cat /proc/net/nicinfo/eth0.info
    Description HP NC7781 Gigabit Server Adapter
    Driver_Name bcm5700
    Driver_Version 7.1.22
    Bootcode_Version 5703-v2.33
    PCI_Vendor 0x14e4
    PCI_Device_ID 0x16a7
    PCI_Subsystem_Vendor 0x0e11
    PCI_Subsystem_ID 0x00cb
    PCI_Revision_ID 0x02
    PCI_Slot 2
    PCI_Bus 1
    PCI_Bus_Speed 64-bit PCIX 100MHz
    Memory 0xf7ef0000
    IRQ 11
    System_Device_Name eth0
    Current_HWaddr 00:0e:7f:fe:89:fa
    Permanent_HWaddr 00:0e:7f:fe:89:fa
    Part_Number N/A
     
    Link up
    Auto_Negotiate on
    Speed_Advertisement 10half 10full 100half 100full 1000half
    1000full
    Flow_Control_Advertisement pause
    Speed 1000
    Duplex full
    Flow_Control receive/transmit
    State up
    MTU_Size 1500
     
    Rx_Packets 51363109
    Tx_Packets 0
    Rx_Bytes 4015840304
    Tx_Bytes 0
    Rx_Errors 0
    Tx_Errors 0
     
    Tx_Carrier_Errors 0
    Tx_Abort_Excess_Coll 0
    Tx_Abort_Late_Coll 0
    Tx_Deferred_Ok 0
    Tx_Single_Coll_Ok 0
    Tx_Multi_Coll_Ok 0
    Tx_Total_Coll_Ok 0
    Tx_XON_Pause_Frames 0
    Tx_XOFF_Pause_Frames 0
     
    Rx_CRC_Errors 0
    Rx_Short_Fragment_Errors 0
    Rx_Short_Length_Errors 0
    Rx_Long_Length_Errors 0
    Rx_Align_Errors 0
    Rx_Overrun_Errors 0
    Rx_XON_Pause_Frames 0
    Rx_XOFF_Pause_Frames 0
     
    Tx_MAC_Errors 0
    Rx_MAC_Errors 0
     
    Tx_Checksum on
    Rx_Checksum on
    Scatter_Gather on
    VLAN off
     
    NIC_Tx_BDs off
    Tx_Desc_Count 120
    Rx_Desc_Count 200
    Rx_Jumbo_Desc_Count 0
    Adaptive_Coalescing on
    Rx_Coalescing_Ticks 25
    Rx_Coalesced_Frames 5
    Tx_Coalescing_Ticks 200
    Tx_Coalesced_Frames 20
    Stats_Coalescing_Ticks 1000000
    Wake_On_LAN off

    Anyone have any ideia??

    thanks
    mpneves 

    -- 
www.camelot.co.pt
-- 
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
  • Next message: steef van duin: "Re: scsi under sarge"

    Relevant Pages

    • Re: Ethernet issue: works one way but not another
      ... packets transmitted, 5 packets received, 0% packet loss ... (This is when connected directly to internet through ... FBSD, I have been working with BSDI at the isp I work for for the last ... As for my network topology, I have an internal network that goes ...
      (freebsd-questions)
    • Re: Update: UDP 770 Potential Worm
      ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
      (Incidents)
    • Re: IDSIPS that can handle one Gig
      ... especially with 64-byte UDP packets. ... There are plenty of network IPS's ... IDS/IPS devices through use of fragments. ... Find out quickly and easily by testing it with real-world attacks from ...
      (Focus-IDS)
    • Re: iptables and dhcp
      ... > the same physical network segment as the firewall and the remote DHCP ... You used INPUT and not FORWARD chain ... # This target allows packets to be marked in the mangle table ...
      (comp.os.linux.networking)
    • Re: Update: UDP 770 Potential Worm
      ... > were no packets indicating some form of replication. ... > my capture was limited due to the switched ... to see if the problem occurs on the test network, ... The proxy had already been isolated from the ...
      (Incidents)