<html>
<P>Hi Jim,</P>
<P>Thanks for your reply and thanks for looking at the other forum and taking the time to analyze the capture.</P>
<P>In fact, for the lab I had two Linksys routers, the 14.137 is an router+ata, and the 14.1 is the default gateway, running dd-wrt+sip server. The .14.109 is another ATA, and .14.111 is the machine doing the capture.</P>
<P>If you look at packets 71 to 80 of the capture, you can see what you explained to me, but ever more puzzling:</P>
<P>In packet 71, the .14.137 ARP's who has .14.1?, and the right response comes in packet 72, where .14.1 tells its MAC. Then, in packet 73, the .14.137 sends to .14.1 (with all addresses correct) a SIP(+SDP) INVITE. So far so good, but just at this moment the .14.111 thinks it's with it (why?), and ARP's who has .14.137 in packet 74. In packet 76, the .14.137 answers. Meanwhile, in packet 75, the machine doing the capture redirects the SIP(+SDP) INVITE to the .14.1, and after the ARP response in packet 76, sends the (unneeded) ICMP redirect to .14.137 telling it to talk directly to .14.11, what is exactly what it was doing in first place!</P>
<P>Puzzling.</P>
<P>At packet 78, the .14.1 anwers the INVITE (as is supposed to do, with the right addresses), but again, the machine doing the capture thinks it's with it, and, at packet 79 sends an (confusing) ICMP to .14.1 telling it to talk directly with .14.1, what is exactly what is was doing at packet 78.</P>
<P>Puzzling.</P>
<P>I was looking at my machine for the problem. I have wireless and wired cards, I have bluetooth DUN, and another installed (USB) NICs (but not plugged in). But as I menctioned in my last email, I tried at another PC's, with another hardware and OS, and saw the same behavior.<BR>
</P>
<P>Suggestions?<BR>
<BR>
<BR>
<B>On Mit Okt 29 23:53 , "Jim Young" <SYSJHY@LANGATE.GSU.EDU>sent:<BR>
<BR>
</P></B>
<BLOCKQUOTE style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #f5f5f5 2px solid; MARGIN-RIGHT: 0px">Hello Feliciano,<BR>
<BR>
<FONT color=red>>>> Feliciano Chavez <<A href="javascript:top.opencompose('chavezf@tutopia.com','','','')">chavezf@tutopia.com</A>> 2008-10-29 20:44 >>></FONT><BR>
<FONT color=red>> I tested today on another machines, and saw the same malfunction.</FONT><BR>
<FONT color=red>> My Toshiba Laptop runs Windows Vista Business English, SP1. </FONT><BR>
<FONT color=red>> WinPcap 4.0.2 installed when installed Wireshark (I updated </FONT><BR>
<FONT color=red>> Wireshark yesterday, but the problem have been happening </FONT><BR>
<FONT color=red>> time ago, but I didn't realized the problem until now). NIC = RTL8101.</FONT><BR>
<FONT color=red>> Today, I installed the latest Wireshark on 6 IBM PC's, and </FONT><BR>
<FONT color=red>> found the same replicating issue when sniffing (with Wireshark) </FONT><BR>
<FONT color=red>> on them (copy of the packet received, but with their own MAC </FONT><BR>
<FONT color=red>> instead of the original one). The IBM PC's are running either </FONT><BR>
<FONT color=red>> Windows NT 2000 spanish or XP Professional (if you need the </FONT><BR>
<FONT color=red>> exact info I can go back and check) . </FONT><BR>
<FONT color=red>> The NPF service used for sniffing without administrator privileges </FONT><BR>
<FONT color=red>> isn't activated.</FONT><BR>
<FONT color=red>> Ideas?</FONT><BR>
<BR>
Regarding this problem, I've taken a look at the trace files you <BR>
included with bug report # 3003 that you initially submitted to <BR>
Wireshark Bug Database:<BR>
<BR>
<A href="parse.pl?redirect=https%3A%2F%2Fbugs.wireshark.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D3003" target=_blank><FONT color=red>https://bugs.wireshark.org/bugzilla/show_bug.cgi\?id=3003</FONT></A> <BR>
<BR>
I saw a couple of curious items in the first trace you attached. <BR>
<BR>
You reported that you have a linksys router at 192.168.14.1. But if <BR>
you look at the Wireshark's ethernet endpoints report, you actually <BR>
appear to have two (2) devices with Cisco/Linksys mac addresses <BR>
on your LAN segment (one at 192.168.14,1, the other at <BR>
192.168.14.137). You also appear to have two hosts:<BR>
<BR>
Cisco-Li_4b:a4:03 (00:1d:7e:4b:a4:03) 192.168.14.1<BR>
Cisco-Li_b6:f7:31 (00:18:39:b6:f7:31) 192.168.14.137<BR>
Grandstr_06:8a:80 (00:0b:82:06:8a:80) 192.168.14.109<BR>
QuantaCo_0b:10:74 (00:1e:68:0b:10:74) 192.168.14.111<BR>
<BR>
The most curious thing to me is that there are ICMP redirect frames <BR>
generated from your machine (00:1e:68:0b:10:74). You can easily <BR>
display these frames with the Wireshark display filter:<BR>
<BR>
icmp.type==5<BR>
<BR>
In some ways it appears that this machine is actively attempting <BR>
to get a copy of each packet sent on the segment. I'm guessing<BR>
you are seeing two copies of each frame because the various <BR>
systems first send the frame directly to your system's specific <BR>
MAC address (in response to the ICMP redirects), then your <BR>
system forwards a copy of the same frame but this time with <BR>
the real destination MAC addresses.<BR>
<BR>
The question is WHY your workstation would be sending these <BR>
ICMP redirects?<BR>
<BR>
If you are interested in knowing more about ICMP redirects you <BR>
can check out the following:<BR>
<BR>
When Are ICMP Redirects Sent?<BR>
<A href="parse.pl?redirect=http%3A%2F%2Fwww.cisco.com%2Fen%2FUS%2Ftech%2Ftk365%2Ftechnologies_tech_note09186a0080094702.shtml" target=_blank><FONT color=red>http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094702.shtml</FONT></A> <BR>
<BR>
ICMP Redirect Message<BR>
<A href="parse.pl?redirect=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FICMP_Redirect_Message" target=_blank><FONT color=red>http://en.wikipedia.org/wiki/ICMP_Redirect_Message</FONT></A> <BR>
<BR>
Explanation of ICMP Redirect Behavior<BR>
<A href="parse.pl?redirect=http%3A%2F%2Fsupport.microsoft.com%2Fkb%2F195686" target=_blank><FONT color=red>http://support.microsoft.com/kb/195686</FONT></A> <BR>
<BR>
Here are some things to look at (in no particular order):<BR>
<BR>
Are you running any type of VPN software on these machines?<BR>
<BR>
Do you have multiple NIC cards installed and enabled in these<BR>
machines (i.e. wireless and wired)? <BR>
<BR>
Have you accidentally enabled bridging or some type of routing <BR>
services on these machines?<BR>
<BR>
Do you have any type of virtual machine software running on<BR>
these machines?<BR>
<BR>
Is there any type of common third party application installed<BR>
on these machines (besides WinPcap/Wireshark)?<BR>
<BR>
Answering yes to any of these questions may lead you to the <BR>
source.<BR>
<BR>
I hope you find this info useful.<BR>
<BR>
Jim Y.<BR>
<BR>
<BR>
_______________________________________________<BR>
Winpcap-users mailing list<BR>
<A href="javascript:top.opencompose('Winpcap-users@winpcap.org','','','')">Winpcap-users@winpcap.org</A><BR>
<A href="parse.pl?redirect=https%3A%2F%2Fwww.winpcap.org%2Fmailman%2Flistinfo%2Fwinpcap-users" target=_blank><FONT color=red>https://www.winpcap.org/mailman/listinfo/winpcap-users</FONT></A><BR>
</BLOCKQUOTE>
</html><BR>