Rick Jones wrote in news:hn66ht$h7r$2
@usenet01.boi.hp.com:

In comp.os.linux.networking Bob wrote:
Have you tried SNAT? I noticed it on YouTube last week.
http://www.snat-project.com/documentation.html

I'm not sure how robust this:

This action is the one I really like. With the help of it you can
check if a host on your network is running a sniffer (well,

SNIP

host I want to check is 192.168.1.8 As usual go to the directory
where you have snat.jar and execute the command (if you have any
problems go here) :

will be. First, I suppose that 99 times out of 10 a host responding
to that MAC address will be in promiscuous mode, but since the group
bit is set... And I would think all it takes is a small change to the
ARP code to verify that the destination MAC was a full broadcast...

Is this supposedly for Windows, Linux, OSX, BSD, etc ?

I'm sure it's OS specific. For instance, a Windows box will not reply to a
broadcast ping, but a Linux box will.

On Mar 10, 1:45*am, DanS
wrote:
Rick Jones wrote in news:hn66ht$h7r$2
@usenet01.boi.hp.com:

In comp.os.linux.networking Bob wrote:
Have you tried SNAT? I noticed it on YouTube last week.
http://www.snat-project.com/documentation.html

I'm not sure how robust this:

* * This action is the one I really like. With the help of it you can
* * check if a host on your network is running a sniffer (well,

SNIP

* * host I want to check is 192.168.1.8 As usual go to the directory
* * where you have snat.jar and execute the command (if you have any
* * problems go here) :

will be. *First, I suppose that 99 times out of 10 a host responding
to that MAC address will be in promiscuous mode, but since the group
bit is set... *And I would think all it takes is a small change to the
ARP code to verify that the destination MAC was a full broadcast...

Is this supposedly for Windows, Linux, OSX, BSD, etc ?

I'm sure it's OS specific. For instance, a Windows box will not reply to a
broadcast ping, but a Linux box will.

But why Windows box does not reply to the broadcast ping :-( whereas
the Linux box replies to the broadcast ping ? That is,
any specific reasons for not being supported in Windows and for
being supported in Linux ?

Thx in advans,
Karthik Balaguru

On Mar 10, 1:45*am, DanS
wrote:
Rick Jones wrote in news:hn66ht$h7r$2
@usenet01.boi.hp.com:

In comp.os.linux.networking Bob wrote:
Have you tried SNAT? I noticed it on YouTube last week.
http://www.snat-project.com/documentation.html

I'm not sure how robust this:

* * This action is the one I really like. With the help of it you can
* * check if a host on your network is running a sniffer (well,

SNIP

* * host I want to check is 192.168.1.8 As usual go to the directory
* * where you have snat.jar and execute the command (if you have any
* * problems go here) :

will be. *First, I suppose that 99 times out of 10 a host responding
to that MAC address will be in promiscuous mode, but since the group
bit is set... *And I would think all it takes is a small change to the
ARP code to verify that the destination MAC was a full broadcast...

Is this supposedly for Windows, Linux, OSX, BSD, etc ?

I'm sure it's OS specific. For instance, a Windows box will not reply to a
broadcast ping, but a Linux box will.

But why Windows box does not reply to the broadcast ping :-( whereas
the Linux box replies to the broadcast ping ? That is,
any specific reasons for not being supported in Windows and for
being supported in Linux ?

Thx in advans,
Karthik Balaguru

On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru
wrote:

On Mar 10, 1:45*am, DanS
wrote:
Rick Jones wrote in news:hn66ht$h7r$2
@usenet01.boi.hp.com:

In comp.os.linux.networking Bob wrote:
Have you tried SNAT? I noticed it on YouTube last week.
http://www.snat-project.com/documentation.html

I'm not sure how robust this:

* * This action is the one I really like. With the help of it you can
* * check if a host on your network is running a sniffer (well,

SNIP

* * host I want to check is 192.168.1.8 As usual go to the directory
* * where you have snat.jar and execute the command (if you have any
* * problems go here) :

will be. *First, I suppose that 99 times out of 10 a host responding
to that MAC address will be in promiscuous mode, but since the group
bit is set... *And I would think all it takes is a small change to the
ARP code to verify that the destination MAC was a full broadcast...

Is this supposedly for Windows, Linux, OSX, BSD, etc ?

I'm sure it's OS specific. For instance, a Windows box will not reply to a
broadcast ping, but a Linux box will.

But why Windows box does not reply to the broadcast ping :-( whereas
the Linux box replies to the broadcast ping ? That is,
any specific reasons for not being supported in Windows and for
being supported in Linux ?

i seem to remember using broadcast ping to populate ARP tables on a
router to hunt used IP addresses, so i am not sure this is right.

i think that it may be more about the sender, not the reciever.

if i ping the local LAN s/net on my w2000 PC - no response and nothing
changes in the arp table (arp -a)

do the same on a win7 PC and i get a response, and the arp table gets
some added entries - some of the entries are w2k and xp boxes.....

the win7 box has static ARP entries installed for the IP local
broadcast address and network broadcast (this seems to be part of the
default interface settings).
Adding the same statics on the w2k box doesnt change anything.

i cannot run up wireshark to check any further right now - but it sure
looks like the apparent lack of response to broadcast ping might be at
the Windows sender, not the responder.

Thx in advans,
Karthik Balaguru
--
Regards

- replace xyz with ntl

On Mar 15, 12:13*am, Stephen wrote:
On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru





wrote:
On Mar 10, 1:45*am, DanS
wrote:
Rick Jones wrote in news:hn66ht$h7r$2
@usenet01.boi.hp.com:

In comp.os.linux.networking Bob wrote:
Have you tried SNAT? I noticed it on YouTube last week.
http://www.snat-project.com/documentation.html

I'm not sure how robust this:

* * This action is the one I really like. With the help of it you can
* * check if a host on your network is running a sniffer (well,

SNIP

* * host I want to check is 192.168.1.8 As usual go to the directory
* * where you have snat.jar and execute the command (if you have any
* * problems go here) :

will be. *First, I suppose that 99 times out of 10 a host responding
to that MAC address will be in promiscuous mode, but since the group
bit is set... *And I would think all it takes is a small change to the
ARP code to verify that the destination MAC was a full broadcast...

Is this supposedly for Windows, Linux, OSX, BSD, etc ?

I'm sure it's OS specific. For instance, a Windows box will not reply to a
broadcast ping, but a Linux box will.

But why Windows box does not reply to the broadcast ping :-( whereas
the Linux box replies to the broadcast ping ? *That is,
any specific reasons for not being supported in Windows and for
being supported in Linux ?

i seem to remember using broadcast ping to populate ARP tables on a
router to hunt used IP addresses, so i am not sure this is right.

i think that it may be more about the sender, not the reciever.

if i ping the local LAN s/net on my w2000 PC - no response and nothing
changes in the arp table (arp -a)

do the same on a win7 PC and i get a response, and the arp table gets
some added entries - some of the entries are w2k and xp boxes.....

the win7 box has static ARP entries installed for the IP local
broadcast address and network broadcast (this seems to be part of the
default interface settings).
Adding the same statics on the w2k box doesnt change anything.

i cannot run up wireshark to check any further right now - but it sure
looks like the apparent lack of response to broadcast ping might be at
the Windows sender, not the responder.


On similar lines, i came across an info that states that due to
a weakness in Linux TCP/IP implementation , it will answer to
TCP/IP packets sent to its IP address even if the MAC address
on that packet is wrong while in promiscuous mode.
But, it seems that the standard behavior is that it will not be
answered because the network interface will drop them as it
is containing wrong MAC address .

I am eager to know Why is the linux implementation different
from that of the standard implementation ? Is it good or bad ?

Thx in advans,
Karthik Balaguru

On Tue, 16 Mar 2010 09:39:30 -0700 (PDT), Karthik Balaguru
wrote:

On Mar 15, 12:13*am, Stephen wrote:
On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru





wrote:
On Mar 10, 1:45*am, DanS
wrote:
Rick Jones wrote in news:hn66ht$h7r$2
@usenet01.boi.hp.com:

In comp.os.linux.networking Bob wrote:
Have you tried SNAT? I noticed it on YouTube last week.
http://www.snat-project.com/documentation.html

I'm not sure how robust this:

* * This action is the one I really like. With the help of it you can
* * check if a host on your network is running a sniffer (well,

SNIP

* * host I want to check is 192.168.1.8 As usual go to the directory
* * where you have snat.jar and execute the command (if you have any
* * problems go here) :

will be. *First, I suppose that 99 times out of 10 a host responding
to that MAC address will be in promiscuous mode, but since the group
bit is set... *And I would think all it takes is a small change to the
ARP code to verify that the destination MAC was a full broadcast...

Is this supposedly for Windows, Linux, OSX, BSD, etc ?

I'm sure it's OS specific. For instance, a Windows box will not reply to a
broadcast ping, but a Linux box will.

But why Windows box does not reply to the broadcast ping :-( whereas
the Linux box replies to the broadcast ping ? *That is,
any specific reasons for not being supported in Windows and for
being supported in Linux ?

i seem to remember using broadcast ping to populate ARP tables on a
router to hunt used IP addresses, so i am not sure this is right.

i think that it may be more about the sender, not the reciever.

if i ping the local LAN s/net on my w2000 PC - no response and nothing
changes in the arp table (arp -a)

do the same on a win7 PC and i get a response, and the arp table gets
some added entries - some of the entries are w2k and xp boxes.....

the win7 box has static ARP entries installed for the IP local
broadcast address and network broadcast (this seems to be part of the
default interface settings).
Adding the same statics on the w2k box doesnt change anything.

i cannot run up wireshark to check any further right now - but it sure
looks like the apparent lack of response to broadcast ping might be at
the Windows sender, not the responder.


On similar lines, i came across an info that states that due to
a weakness in Linux TCP/IP implementation , it will answer to
TCP/IP packets sent to its IP address even if the MAC address
on that packet is wrong while in promiscuous mode.
But, it seems that the standard behavior is that it will not be
answered because the network interface will drop them as it
is containing wrong MAC address .

I am eager to know Why is the linux implementation different
from that of the standard implementation ? Is it good or bad ?

it probably comes down to implementation issues.

FWIW responding to broadcasts is like many things - useful but can be
dangerous to network stability in some setups.

there are standards that covers a lot of this stuff.....

RFC 1122 is for host requirements - section 3.2 says a fair bit about
handling broadcasts.

Thx in advans,
Karthik Balaguru
--
Regards

- replace xyz with ntl

On Mar 17, 2:09*am, Stephen wrote:
On Tue, 16 Mar 2010 09:39:30 -0700 (PDT), Karthik Balaguru





wrote:
On Mar 15, 12:13*am, Stephen wrote:
On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru

wrote:
On Mar 10, 1:45*am, DanS
wrote:
Rick Jones wrote in news:hn66ht$h7r$2
@usenet01.boi.hp.com:

In comp.os.linux.networking Bob wrote:
Have you tried SNAT? I noticed it on YouTube last week.
http://www.snat-project.com/documentation.html

I'm not sure how robust this:

* * This action is the one I really like. With the help of it you can
* * check if a host on your network is running a sniffer (well,

SNIP

* * host I want to check is 192.168.1.8 As usual go to the directory
* * where you have snat.jar and execute the command (if you have any
* * problems go here) :

will be. *First, I suppose that 99 times out of 10 a host responding
to that MAC address will be in promiscuous mode, but since the group
bit is set... *And I would think all it takes is a small change to the
ARP code to verify that the destination MAC was a full broadcast....

Is this supposedly for Windows, Linux, OSX, BSD, etc ?

I'm sure it's OS specific. For instance, a Windows box will not reply to a
broadcast ping, but a Linux box will.

But why Windows box does not reply to the broadcast ping :-( whereas
the Linux box replies to the broadcast ping ? *That is,
any specific reasons for not being supported in Windows and for
being supported in Linux ?

i seem to remember using broadcast ping to populate ARP tables on a
router to hunt used IP addresses, so i am not sure this is right.

i think that it may be more about the sender, not the reciever.

if i ping the local LAN s/net on my w2000 PC - no response and nothing
changes in the arp table (arp -a)

do the same on a win7 PC and i get a response, and the arp table gets
some added entries - some of the entries are w2k and xp boxes.....

the win7 box has static ARP entries installed for the IP local
broadcast address and network broadcast (this seems to be part of the
default interface settings).
Adding the same statics on the w2k box doesnt change anything.

i cannot run up wireshark to check any further right now - but it sure
looks like the apparent lack of response to broadcast ping might be at
the Windows sender, not the responder.

On similar lines, i came across an info that states that due to
a weakness in Linux TCP/IP implementation , it will answer to
TCP/IP packets sent to its IP address even if the MAC address
on that packet is wrong while in promiscuous mode.
But, it seems that the standard behavior is that it will not be
answered because the network interface will drop them as it
is containing wrong MAC address .

I am eager to know Why is the linux implementation different
from that of the standard implementation ? Is it good or bad ?

it probably comes down to implementation issues.

FWIW responding to broadcasts is like many things - useful but can be
dangerous to network stability in some setups.

there are standards that covers a lot of this stuff.....

RFC 1122 is for host requirements - section 3.2 says a fair bit about
handling broadcasts.


Thx for the RFC. The RFC 1122 does talk about handling broadcasts.
I found the section 3.3.6 very interesting. But, i wonder why do
implementations vary between windows and linux

Karthik Balaguru

On Mar 9, 11:27*pm, Karthik Balaguru
wrote:
Hi,
How to determine the presence of wireshark in a network ?
Are there any specific packet types exchanged while it
is present in the network so that it can be used to determine
its presence in the network . Any tool to identify its presence
in either Windows or Linux ? Any ideas ?

Thx in advans,
Karthik Balaguru

One indicator of sniffer activity is a lot of DNS requests from the
sniffer.
This detection is not always effective, since sniffer's DNS resolution
can be turned off.

Junior Lazuardi

On Mar 9, 11:27*pm, Karthik Balaguru
wrote:
Hi,
How to determine the presence of wireshark in a network ?
Are there any specific packet types exchanged while it
is present in the network so that it can be used to determine
its presence in the network . Any tool to identify its presence
in either Windows or Linux ? Any ideas ?

Thx in advans,
Karthik Balaguru

One indicator of sniffer activity is a lot of DNS requests from the
sniffer.
This detection is not always effective, since sniffer's DNS resolution
can be turned off.

Junior Lazuardi

On Mar 17, 2:09*am, Stephen wrote:
On Tue, 16 Mar 2010 09:39:30 -0700 (PDT), Karthik Balaguru





wrote:
On Mar 15, 12:13*am, Stephen wrote:
On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru

wrote:
On Mar 10, 1:45*am, DanS
wrote:
Rick Jones wrote in news:hn66ht$h7r$2
@usenet01.boi.hp.com:

In comp.os.linux.networking Bob wrote:
Have you tried SNAT? I noticed it on YouTube last week.
http://www.snat-project.com/documentation.html

I'm not sure how robust this:

* * This action is the one I really like. With the help of it you can
* * check if a host on your network is running a sniffer (well,

SNIP

* * host I want to check is 192.168.1.8 As usual go to the directory
* * where you have snat.jar and execute the command (if you have any
* * problems go here) :

will be. *First, I suppose that 99 times out of 10 a host responding
to that MAC address will be in promiscuous mode, but since the group
bit is set... *And I would think all it takes is a small change to the
ARP code to verify that the destination MAC was a full broadcast....

Is this supposedly for Windows, Linux, OSX, BSD, etc ?

I'm sure it's OS specific. For instance, a Windows box will not reply to a
broadcast ping, but a Linux box will.

But why Windows box does not reply to the broadcast ping :-( whereas
the Linux box replies to the broadcast ping ? *That is,
any specific reasons for not being supported in Windows and for
being supported in Linux ?

i seem to remember using broadcast ping to populate ARP tables on a
router to hunt used IP addresses, so i am not sure this is right.

i think that it may be more about the sender, not the reciever.

if i ping the local LAN s/net on my w2000 PC - no response and nothing
changes in the arp table (arp -a)

do the same on a win7 PC and i get a response, and the arp table gets
some added entries - some of the entries are w2k and xp boxes.....

the win7 box has static ARP entries installed for the IP local
broadcast address and network broadcast (this seems to be part of the
default interface settings).
Adding the same statics on the w2k box doesnt change anything.

i cannot run up wireshark to check any further right now - but it sure
looks like the apparent lack of response to broadcast ping might be at
the Windows sender, not the responder.

On similar lines, i came across an info that states that due to
a weakness in Linux TCP/IP implementation , it will answer to
TCP/IP packets sent to its IP address even if the MAC address
on that packet is wrong while in promiscuous mode.
But, it seems that the standard behavior is that it will not be
answered because the network interface will drop them as it
is containing wrong MAC address .

I am eager to know Why is the linux implementation different
from that of the standard implementation ? Is it good or bad ?

it probably comes down to implementation issues.

FWIW responding to broadcasts is like many things - useful but can be
dangerous to network stability in some setups.

there are standards that covers a lot of this stuff.....

RFC 1122 is for host requirements - section 3.2 says a fair bit about
handling broadcasts.


It seems that the flaw in Linux TCP/IP stack has been fixed in
kernel 2.2.10 as they drop the incoming packets that are not
destined for this ethernet address.

So, there is a tough job to detect the presence of in network
if the sniffer is running on Linux Kernel 2.2.10.

Karthik Balaguru