Missing CIP frame from message.

Hello everyone. I am currently trying to use a Micro850 to send production order info to our Nicelabel server and am running into issues.

I am trying to send a ten digit number over Ethernet using a CIP generic message. When I tested this setup I was using Wireshark to monitor the data I was sending to my desktop and it was coming through just fine. When I try to send it to the server on another sub-net we get the message minus the CIP frame with the info I'm trying to send.

I'm at a loss and a little over my head here as ethernet messaging isn't my strong suit.My IT department has no clue as to why that would be happening so I thought I would post something here to see if anyone had any ideas.

Any help would be appreciated, please let me know what info you need from me.

Thanks,
Luc

Your application is unusual but interesting.

I recommend using Wireshark to capture the local transaction, then use it again to capture the remote transaction. ZIP and post both PCAP files with descriptions of how you captured them.

Here you go. I used a capture filter with the following syntax : SRC 10.240.19.65.

I tried sending it to two different servers without luck. I forgot to mention earlier that the servers are virtual servers and my desktop is a regular engineering workstation.

I'm thinking of using a serial to ethernet server like a MOXA 5110A. Seems like that would be the best approach instead of trying to use something in a way it wasn't intended. I have one coming in tomorrow to test it out.

Thanks,
Luc

I had a look at the traces and they are not that useful. The capture filter is hurting you - we can only see one half of the conversations. We can infer from the behavior, but that involves assumptions when they really are not necessary. If your using Wireshark, can you try a capture filter of

host <ip address>

Or, just publish the whole trace and describe the actors involved - source and destination.

I see the CIP request in frame 5 of LocalComputer.pcap. This follows the Register session, which looks correct. I don't know what service 0x4d to the Identity object is with the data you include, but assume this what you want. You get a response but I don't now what it is because of the capture filter.

For Rockwell Server.pcap, the trace shows the device never answered the TCP SYN, so no TCP connection was made to port 44818. This is not that a CIP message was dropped, this is that you have network issues - the vmware server is not responding. Correct response to a TCP SYN with no listener is a TCP RST. I don't see one - could be because of the capture filter, or could be because of a firewall dropping the TCP SYN before it gets to the stack running in VMWare. Don't know if it's Windows, Linux, or whatever.

NiceLabelServer.pcap shows that at least the EtherNet/IP server is listening, and we see the TCP connection built up. Register session is issued, then the client, the Rockwell device, never issues the CIP request. This is observable by the TCP sequence numbers in frame 4 - after register session, only the keep-alive is issued, but no new bytes were issued. This is indicative of an application level issue - the underlying TCP connection was created, but it appears the session was never created based on TCP sequence numbers. A better capture filter or none at all would really help to see what type of information was returned from the server. Per EIP spec, the client will likely not issue the CIP msg until a session is registered - never tested this, but it from memory it seems correct.

If you want assistance on capturing traffic, describe a little more the network architecture and we can suggest where and how to sniff the traffic.

Excellent work, Robert !

I wanted to add that I don't go anywhere near an Ethernet analysis job without this bad boy in my holster:

http://www.fte.com/products/NetworkTap.aspx

It's functionally similar, I think, to the EtherShark Tap, but may have FTE-specific features too.

http://www.sandman.com/EtherSharkTap.html

At a much lower price and performance, but OK for most purposes:

http://www.dual-comm.com/port-mirroring-LAN_switch.htm

Ken Roach said:

Excellent work, Robert !

http://www.fte.com/products/NetworkTap.aspx

Click to expand...

I use the Dualcomm too, if I don't have a managed switch (shame on the installer, but it happens...)

I have done timing studies with USB based Ethernet adapters and the frame time stamps are terrible - plenty of jitter, on the order of 25ms worst case. This is OK for slow traffic, but if we want to see timing of Ethernet frames I have had much better luck with regular network interfaces coming off a mirror port, which usually adds microseconds of delay. Do you know if these devices time stamp at the device, or are they expecting the PC to do the time stamping, as if it were a regular Ethernet interface into a packet capture tool?

The aggregation feature is nice too - some of the other taps on the market require two ports as Tx and Rx are broken out separately.

The FTE device is very good with timestamps; it must do them onboard.

I haven't had to troubleshoot time dependent issues with it, but I have done some "jitter measurement" to prove that the network wasn't the problem with sensor signal issues, and never found any irregularities with the timestamps.

I think that's where the $750+ premium over a USB/Ethernet dongle comes from.