From: Sidney Lambe on 31 Jan 2010 11:52 On comp.os.linux.misc, Sidney Lambe <sidneylambe(a)nospam.invalid> wrote: > On comp.os.linux.misc, Grant Edwards <invalid(a)invalid.invalid> wrote: >> [delete] >> Bully for you, but running out-of-date software puts you at >> risk of attack. > > It isn't out-of-date. It displays the packets as they cross > the interface. That's all I want. > > Sometimes I'll log the packets and examine them more closely > if necessary. Tethereal allows you to see everything that's > there. > > No packet sniffer does anything about stopping attacks. That's > the firewall's job. > Actually, that's wrong. There's nothing any packet sniffer or firewall can do to prevent attacks. The firewall can fend them off, that's all. The sniffer can't do anything but watch. [delete] Sid
From: Nico Kadel-Garcia on 31 Jan 2010 15:34 Oh, dear. Getting in a thread where Sidney pops up is always.... troublesome. He's often quite wrong, but not necessarily for the obvious reasons that it's so easy to yell at him about. So it can be worth posting a followup thread to correct his confusions, explaining rather than yelling. In this case, a fast lookup shows that "ethereal" was renamed "wireshark" roughly four years ago. Sidney's use of the old tool indicates that he's missed out on years of patches and updates. Such patches can be performance, legality, or security related. And for an application as powerful and subtle as wireshark, it's not "some geeks have twiddled with an app", that's roughly 4 years of development being ignored. The ChangeLog for the for the 1.0.8 version for RHEL 5 shows continuing developments for things like SSL and MPEG handling, and even before then, there's all *kinds* of fascinating network behavior that's gotten more common that wireshark may have gotten better with. (RST packets, for example, which have become ubiquitous at Comcast for throttling Bittorrent.) The security risks of running out of date software with security privileges such as wireshark needs to monitor packets are.... interesting. Old security flaws might be an issue, especially if Sidney is leaving the rest of his software that far out of date or if there were any fascinating flaws in their compilation. More importantly, old monitor software is liable to *miss* things that more recent software will detect. So, yes, poo-pooing the far more recent releases on the grounds that the old one "works fine" is foolish.
From: J G Miller on 6 Feb 2010 09:42 On Sat, 30 Jan 2010 18:14:55 -0800, Greg Russell wrote: > The trouble is that it doesn't work for some strange reason. The Windows > client connects, authentication completes, but the Windows client then > disconnects after about 5-15 seconds for no discernible reason. Was this problem ever resolved?
From: Greg Russell on 8 Feb 2010 01:01 In news:1265467344_3(a)vo.lu, J G Miller <miller(a)yoyo.ORG> typed: >> The trouble is that it doesn't work for some strange reason. The >> Windows client connects, authentication completes, but the Windows >> client then disconnects after about 5-15 seconds for no discernible >> reason. > > Was this problem ever resolved? No, I'm sorry to report. Wireshark on both the client and CentOS 5.4 server show nothing unusual. The problem seems to be that the M$-Windows 2000 client virtual interface simply won't accept the DHCP configuration for unknown reasons.
From: H.Janssen on 9 Feb 2010 01:26
Greg Russell wrote: > In news:1265467344_3(a)vo.lu, > J G Miller <miller(a)yoyo.ORG> typed: > >>> The trouble is that it doesn't work for some strange reason. The >>> Windows client connects, authentication completes, but the Windows >>> client then disconnects after about 5-15 seconds for no discernible >>> reason. >> >> Was this problem ever resolved? > > No, I'm sorry to report. Wireshark on both the client and CentOS 5.4 > server show nothing unusual. The problem seems to be that the M$-Windows > 2000 client virtual interface simply won't accept the DHCP configuration > for unknown reasons. Pity. I tested it on a virtual W2K SP4 machine, and it works without problem in a net-to-net configuration with TAP adapters and separate subnet for the VPN. (CentOS4 server). Only remarkable thing is that I get an error in the W2K logs about the address refused by the DHCP server, but the TAP interface gets it's address.... Do you have no information in the Windows event viewer? Kind regards, |