This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

hosts disconnections

0

Hello,

we have a network with some hosts with static ip adresses; It's happening that some of them are getting disconnected; we would like to monitor network traffic to and from this hosts, could you suggest me wich is the best procedure or filter to set to check this kind of disconnections with wireshark ?

asked 15 Dec '15, 10:37

prometeus's gravatar image

prometeus
6●1●1●4
accept rate: 0%

1

Please precise what you mean by "getting disconnected", I guess their Ethernet cables do not jump out of the switch? I.e. what application reports the disconnection?

(15 Dec '15, 10:41) sindy

Hallo Sindy,

thanks for your comment.

I mean we cannot control them or even ping them.

These hosts are robots being controlled by an application server through a netgear hub. These hosts don't get disconnected when we connect directly to them (i mean without any hub, switch or application server controlling them). On the application server there is a software controlling their status (this is the same software running on the pc we use for debug), we randomly detect these losses but on the contrary when we connect directly through a pc we can control them.

So we want to trace the reason of these disconnections

(16 Dec '15, 02:09) prometeus

One Answer:

1

OK,

we cannot control them or even ping them.

in this case you would want to split the path between the application server and those hosts into parts, and Wireshark may not be enough for investigation.

You may run Wireshark on the application server and watch whether, while the issue exists and you cannot ping them, one of the following happens:

  • the application server is sending the icmp echo requests and nothing at all comes back (which means it knows the MAC address of the hosts but they either don't receive the requests at all or don't attempt to answer them),

  • the application server is sending the icmp echo requests but arp requests come back (which means the host has received the icmp request but doesn't know the MAC to which it should send the response),

  • the application server is sending arp requests instead of icmp echo requests and nothing comes back (which means that the arp cache of the server has timed out and the hosts do not respond even to the arp requests).

Is the NetGear box really a hub or is it actually a switch?
If it is a manageable switch, does its monitoring report any events on the ports to which the hosts are connected?
If not, can you replace it with another switch before diving into some deep studies?

Also, it may sound not scientific enough but when connecting to the host directly from a PC, do you remove the cable from the NetGear and insert it to the PC, or do you disconnect the cable towards the switch port at the host end and replace it with another cable connected to the PC? Rotten or ill-crimped cables as well as specific understanding of L1 speed and duplex negotiation by some equipment vendors can create mysterious behaviour, while Wireshark can only tell you what happens starting from L2 upwards.

If we talk about robots, there may be EMC issues, long cables, damaged cables... all that affects L1 so it is invisible for Wireshark (except consequences).

answered 16 Dec '15, 04:23

sindy's gravatar image

sindy
6.0k●4●8●51
accept rate: 24%

edited 16 Dec '15, 06:21

Dear Sindi

OK I will split in parts and Start from the application server

For now:

  • yes it's a hub

  • I disconnect the cable towards the switch port at the host end and replace it with another cable connected to the PC

I will let you know later
We exclude L1 problems for now

Thanks for your Support
Regards

(17 Dec '15, 01:35) prometeus

Hallo Sindy, I have a feedback with regards of this problems.

Basically we solved these problems installing near each robot a netgear gigabit swithc GS105Ev2.

What's happened in your opinion.

Regards

(01 Apr '16, 01:32) prometeus
1

I could suspect two types of explanation, but too much information is missing:

  • mechanical/chemical (the RJ-45 receptacles on the hub do not like the RJ-45 plugs of your cables due to incompatible mechanical tolerances, or because the hub's contacts are dirty/oxidized, assuming any hub cannot be newer than 10 years). Are there any vibrations coming from the robot's operation which could be transferred to the hubs/cables?

  • L1 electrical issue coming from the fact that the robots' interfaces do not implement 10 Mbit/s mode properly but work fine at 100 or even 1000 Mbit/s. You may confirm (but not refutate (widerlegen)) this assumption if you can force the GS105Ev2's ports to 10 Mbit/s Half Duplex with auto-negotiation off, simulating a 10 Mbit/s hub (hence half-duplex mode) as closely as possible this way. (I mention fixed values and switching off auto-negotiation as two separate settings because some equipment is able to perform the negotiation procedure but accept/offer only a single value of speed and a single value of duplex).

But I guess once you've already spent the $$$ and it has solved the issue, there is little practical value of this information.

(01 Apr '16, 06:52) sindy