Hello, we have come up with the similar problem once, but I need you to answer the following question to see if it's really the same situation:
Are MAC address in the ICMP packet really present in your network or are they something like DigitalEquipment_00-02-01 (one such is the source and one is the destination)? Petr Vacha > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Young > Sent: Monday, August 28, 2006 5:25 PM > To: [email protected] > Subject: Re: [Wireshark-users] Ping Replys without Request > > Hello Michael, > > >>> "STEINECKE Michael SD-G (AREVA NP GmbH)" > <[EMAIL PROTECTED]> 08/28/06 4:33 AM >>> > > Hello folks, > > > > i've a bit strange issue in the communication between a Server and > his > > client (a microcontroler). > > The controler send "Echo Reply" packets without a corresponding > ICMP > > requests. Is there another way how this can happen then an program > or > > firmware error? Something like an TCP packet that requests a ICMP > Echo > > par example? > > > > Best Regards > > Michael Steinecke > > Does you controller have multiple NIC interfaces? If so, then > depending on how you've set up your route statements on > the controller (assuming that you can) it's possible that replies > received on one NIC interface will be returned out a different > NIC interface. IP addresses more than one hop away could > be taking a "default" route (out the NIC interface towards > your server). > > Take a look at the destination IP address (where the ping reply > is supposed to go to) and the destination MAC address for the > ping reply. This should give you a clue on who/what might be > generating the original request. > > Then again if it's some type of specialized controller, then I > wouldn't be surprised to see the vendor doing something > non-conventual like using ICMP echo replies to send signalling > information to some other station(s). > > I've also seen some devices that use an an undocumented > private NIC setup internally. I've had a few occasions where > these back-end packets have leaked out the one public NIC. > > I hope this find this useful. > > Jim Young > > > > _______________________________________________ > Wireshark-users mailing list > [email protected] > http://www.wireshark.org/mailman/listinfo/wireshark-users > _______________________________________________ Wireshark-users mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-users
