Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade

From: Robert Brown (eli_at_typhoon.xnet.com)
Date: 12/28/03

  • Next message: Peter Kiem: "DVD+RW burns 3GB but only reads back as 13MB"
    To: redhat-list@redhat.com
    Date: Sat, 27 Dec 2003 22:33:00 -0600 (CST)
    
    

    Harry Hoffman writes:
    > Robert,
    >
    > Hmm, can you provide your tcp filter? Also, are you sure you're listening on the
    > right interface (sorry, I know it's a stupid question). Perhaps something in the
    > upgrade of the kernel caused the interfaces to be changed...? (really streching
    > on that one).

    You know, I had that nagging thought myself -- that the interfaces got
    detected in a different order. But I have 3 NICs in this box, and
    only one of them has an assigned IP address, so it can communicate on
    the LAN. The other 2 NICs are anonymous and used only for sniffing
    thru a read-only cable adapter. Since the box can communicate on the
    LAN, I know that at leats the LAN's NIC is still the same, and I
    cannot see packets unless they have the LAN NIC's IP address as src or
    dst, or they are broadcast packets.

    The filter is real easy. I just did:

      # tcpdump -n -i eth0

    which should not cause too many packets to be filtered out. ;-)

    > One thing to do to check if it's a filter problem would be to sniff for ARP, as
    > these packets should be broadcast to every port on a switch or hub
    > tcpdump -i <ethX> -ln arp
    > Although, you do state that you are seeing broadcast packets.

    Yes, specifically I do see arp requests and responses.

    > Do you have another *nix box that you can throw in place to ensure it's not
    > network related?

    Yes, and I have similar symptoms on other boxes, although the only
    other multi-homed boxes are the firewalls. I see the problem even
    when I run the above tcpdump cammand line from my worksation.

    I think promiscuous mode is broken. I can set it with ifconfig, and
    ifconfig reports that it is set, but I do not think it is working
    anymore, not since the upgrade to the 2.4.20-27.9 kernel.

    How, other than by sniffing with tcpdump, can I verify this?

    >
    > HTH,
    > Harry
    >
    >
    > Quoting Robert Brown <eli@typhoon.xnet.com>:
    >
    > *> OK, then back to my original question: any ideas why tcpdump is not
    > *> working when an interface is in promiscuous mode? It seems to capture
    > *> packets with the interface's own ip address as either src or dst, and
    > *> also broadcast packets, but it misses other packets. The network
    > *> hardware setup is unchanged from before the 2.4.20-27.9 kernel was
    > *> installed, when tcpdump was working fine. I am using 2 nics, one on
    > *> my lan with a 192.168.1.* ip address, one on my dmz with no assigned
    > *> ip address, and one on my wild zone where the bridge to the internet
    > *> is. The lan and dmz are 10/100baseT hubs, and the wild is a 10baseT
    > *> half-duplex hub. The nics are nailed up appropriately in my
    > *> /etc/modules.conf file thusly:
    > *>
    > *> alias eth0 8139too
    > *> alias eth1 8139too
    > *> alias eth2 8139too
    > *> options 8139too 0x100,0x100,0x10
    > *>
    > *> The use of hubs and half-duplex rather than switches and full-duplex
    > *> is required for the NIDS to see all the packets.
    > *>
    > *> --
    > *> -------- "And there came a writing to him from Elijah" [2Ch 21:12]
    > *> --------
    > *> R. J. Brown III rj@elilabs.com http://www.elilabs.com/~rj voice 859
    > *> 567-7311
    > *> Elijah Laboratories Inc. P. O. Box 166, Warsaw KY 41095 fax 859
    > *> 567-7311
    > *> ----- M o d e l i n g t h e M e t h o d s o f t h e M i n d
    > *> ------
    > *>
    > *>
    > *> --
    > *> redhat-list mailing list
    > *> unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
    > *> https://www.redhat.com/mailman/listinfo/redhat-list
    > *>
    >
    >
    > --
    > Harry Hoffman
    > hhoffman@ip-solutions.net
    >
    > #----------------------------------------------------------------#
    > # Harry: version 4.0a #
    > # Known bugs: #
    > # 1) Verbal output may occur before data processing is complete. #
    > # 2) Loudspeaker option may activate without being invoked. #
    > # 3) Other bugs as reported #
    > #----------------------------------------------------------------#
    >
    > -------------------------------------------------
    > This mail sent through IpSolutions: http://www.ip-solutions.net/
    >
    >
    > --
    > redhat-list mailing list
    > unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
    > https://www.redhat.com/mailman/listinfo/redhat-list
    >

    -- 
    redhat-list mailing list
    unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
    https://www.redhat.com/mailman/listinfo/redhat-list
    

  • Next message: Peter Kiem: "DVD+RW burns 3GB but only reads back as 13MB"

    Relevant Pages

    • Re: How to set NIC to promiscuous mode from FilterHook driver
      ... So from your reply I take it you are interested in getting packets destined to other hosts -that are not necessarily originated from the host your filter is running on-. ... As I said in my previous post, setting the adapter to promiscuous mode is not going to help you. ... the filter hook driver I mentioned is as per the msdn ...
      (microsoft.public.development.device.drivers)
    • Re: Req: info on IP range popup ad software supposedly called "Extreme Marketing"
      ... forges packets for wndows dialup connections. ... I'd pick a switch that could filter on MAC and IP ... > that should be hooked up to that port. ...
      (comp.security.misc)
    • Re: PF, bridge, states and window scaling problem
      ... My problem comes with the filter rules. ... the bridge use TCP window scaling. ... but not matched by the rest of the packets ... statefull firewall has an unpredictable behaviour on bridges. ...
      (freebsd-questions)
    • Re: Comodo blocking port forwarding
      ... filter to drop every packets, how exactly would you try to circumvent this? ... As for a more practical example: I setup a packet filter to only allow HTTP ... Well, most you say about PFW, can be easily applied ...
      (comp.security.firewalls)