OK, now I am ready to incriminate the hubs! I started tcpdump on the eth0 port of the NIDS and all it could sniff was packets with its own address or braodcast packets such as arps. I then power cycled the hub. When the hub powered back up, tcpdump siffed 2 packets that did not have its own ip address as either src or dst, then it quit! I power cycled again: same thing -- 2 packets, then nada. It seems that these "hubs" are blocking traffic not destined for a port after a brief period of "proper hub-like" operation. I am not looking forward to the phone call to linksys tomorow. :-< Harry Hoffman writes: > 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@xxxxxxxxxxxxxxxx>: > > *> 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@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
