Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade
From: Harry Hoffman (hhoffman_at_ip-solutions.net)
Date: 12/28/03
- Previous message: Leonard den Ottolander: "Re: Apache getting htdig/search.html from wrong directory"
- In reply to: Robert Brown: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Next in thread: Robert Brown: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Reply: Robert Brown: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: redhat-list@redhat.com Date: Sun, 28 Dec 2003 12:38:44 -0500
Ah, ok... That's why I included the URL in the (last?) email. More specifically
it pointed to a URL for the ethereal FAQ:
http://www.ethereal.com/faq.html#q5.1
which may or may not be the same issue that you are experiencing.
Come to think of it a quick way to test this out would be to run ettercap on one
of the machines connected to the "hub". Allow ettercap to do arp poisoning and
if you start seeing more packets then before you know that your hub is not a
"true" hub and is either a switch or is using "switch like" functionality.
Then you can make the call to tech support and starting yelling ;-). Never, ever
trust tech support! While they may act as though their knowledge of the product
they support is great my experience has been dismal 99.9% of the time. That is
not a condemnation of all tech-support ppl, but most are there with a script in
hand and that's it. Deviations from the script tend to be disastrous :-)
--Harry
Quoting Robert Brown <eli@typhoon.xnet.com>:
*> I suspect that these are intelligent store-and-forward units that are
*> almost the same as switches, operating as follows:
*>
*> 1. A packet is sent to the device.
*>
*> 2. The device reads the packet into a holding buffer.
*>
*> 3. The device sends the buffer contents to all other ports.
*>
*> Now with this logic, each port could be operating in any of the 4
*> modes of full-10, full-100, half-10, or half-100, since the input and
*> output are buffered.
*>
*> Note that if the device examines the MAC address in the incoming
*> packet, then if it only sends it to a port it has received packets
*> from previously with that same MAC address as source, then you have a
*> switch instead of a hub. I expect that the hub and the switch are
*> identical devices, differentiated only by a firmware option, or
*> perhaps a jumper internally.
*>
*> Incidently, the hubs I am using are Linksys EFAH08W units, as shown
*> here:
*>
*> http://www.linksys.com/products/product.asp?grid=34&scid=31&prid=54
*>
-- 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
- Previous message: Leonard den Ottolander: "Re: Apache getting htdig/search.html from wrong directory"
- In reply to: Robert Brown: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Next in thread: Robert Brown: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Reply: Robert Brown: "Re: tcpdump broken after rh9 2.4.20-27.9 kernel upgrade"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
