Determining the presence of wireshark
in [Wireless Internet]
|
From: Karthik Balaguru on 14 Mar 2010 10:12 On Mar 10, 1:45 am, DanS <t.h.i.s.n.t.h....(a)r.o.a.d.r.u.n.n.e.r.c.o.m> wrote: > Rick Jones <rick.jon...(a)hp.com> wrote in news:hn66ht$h7r$2 > @usenet01.boi.hp.com: > > > In comp.os.linux.networking Bob <b...(a)invalid.invalid> 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
From: Stephen on 14 Mar 2010 15:13 On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru <karthikbalaguru79(a)gmail.com> wrote: >On Mar 10, 1:45�am, DanS <t.h.i.s.n.t.h....(a)r.o.a.d.r.u.n.n.e.r.c.o.m> >wrote: >> Rick Jones <rick.jon...(a)hp.com> wrote in news:hn66ht$h7r$2 >> @usenet01.boi.hp.com: >> >> > In comp.os.linux.networking Bob <b...(a)invalid.invalid> 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 stephen_hope(a)xyzworld.com - replace xyz with ntl
From: Karthik Balaguru on 16 Mar 2010 12:39 On Mar 15, 12:13 am, Stephen <stephen_h...(a)xyzworld.com> wrote: > On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru > > > > > > <karthikbalagur...(a)gmail.com> wrote: > >On Mar 10, 1:45 am, DanS <t.h.i.s.n.t.h....(a)r.o.a.d.r.u.n.n.e.r.c.o.m> > >wrote: > >> Rick Jones <rick.jon...(a)hp.com> wrote in news:hn66ht$h7r$2 > >> @usenet01.boi.hp.com: > > >> > In comp.os.linux.networking Bob <b...(a)invalid.invalid> 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
From: Stephen on 16 Mar 2010 17:09 On Tue, 16 Mar 2010 09:39:30 -0700 (PDT), Karthik Balaguru <karthikbalaguru79(a)gmail.com> wrote: >On Mar 15, 12:13�am, Stephen <stephen_h...(a)xyzworld.com> wrote: >> On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru >> >> >> >> >> >> <karthikbalagur...(a)gmail.com> wrote: >> >On Mar 10, 1:45�am, DanS <t.h.i.s.n.t.h....(a)r.o.a.d.r.u.n.n.e.r.c.o.m> >> >wrote: >> >> Rick Jones <rick.jon...(a)hp.com> wrote in news:hn66ht$h7r$2 >> >> @usenet01.boi.hp.com: >> >> >> > In comp.os.linux.networking Bob <b...(a)invalid.invalid> 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 stephen_hope(a)xyzworld.com - replace xyz with ntl
From: Karthik Balaguru on 18 Mar 2010 13:44
On Mar 17, 2:09 am, Stephen <stephen_h...(a)xyzworld.com> wrote: > On Tue, 16 Mar 2010 09:39:30 -0700 (PDT), Karthik Balaguru > > > > > > <karthikbalagur...(a)gmail.com> wrote: > >On Mar 15, 12:13 am, Stephen <stephen_h...(a)xyzworld.com> wrote: > >> On Sun, 14 Mar 2010 07:12:44 -0700 (PDT), Karthik Balaguru > > >> <karthikbalagur...(a)gmail.com> wrote: > >> >On Mar 10, 1:45 am, DanS <t.h.i.s.n.t.h....(a)r.o.a.d.r.u.n.n.e.r.c.o..m> > >> >wrote: > >> >> Rick Jones <rick.jon...(a)hp.com> wrote in news:hn66ht$h7r$2 > >> >> @usenet01.boi.hp.com: > > >> >> > In comp.os.linux.networking Bob <b...(a)invalid.invalid> 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 |