Prev: Global Warming fake science and what you can do to against it
Next: reliance netconnect
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,



First  |  Prev  | 
Pages: 1 2 3 4
Prev: Global Warming fake science and what you can do to against it
Next: reliance netconnect