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@xxxxxxxxxxxxxxxx>: > > *> 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@xxxxxxxxxxx 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@xxxxxxxxxx?subject=unsubscribe > *> https://www.redhat.com/mailman/listinfo/redhat-list > *> > > > -- > Harry Hoffman > hhoffman@xxxxxxxxxxxxxxxx > > #----------------------------------------------------------------# > # 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@xxxxxxxxxx?subject=unsubscribe > https://www.redhat.com/mailman/listinfo/redhat-list > -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
