Molex Tools: EIP_Tool.exe cannot fetch even simple attributes from OpENer

[liftoff-sr]

Molex_EIPTool_V2_3(ODVA).zip

The executable in this download from Molex cannot retrieve any attributes from the POSIX sample application in the pristine download of current github repo.

Wireshark shows that a seemingly decent reply is being generated, but Molex V2.3.0 build 3 shows

Status: Driver Status = 33 (Timeout)

Anyone know why EIP_Tool is not happy with something so simple? Neither UCMM nor Connected attribute retrieval work. Wireshark shows the reply as "Success".

Some guidance would be much appreciated.

[mmprestine]

Here is another test tool that is a work in progress, but pretty nice. https://sourceforge.net/projects/enipexplorer/

The code is not complete for actual use. Look in cipconnectionmanager.h at the ConnectionObject. This struct is not complete and I am working through what are the missing items right now.

[liftoff-sr]

I run on linux. I'd need a generic build system to build it there, assuming Mono would be compatible enough. This feels like a detour however. I'd like to see OpENer respond to even the simplest of explicit messages in a way that EIP_Tools likes. I have 3 programs running on one Ubuntu linux box:

1) OpENer pristine sample POSIX application. 2) EIP_Tools client, under Wine. 3) Wireshark monitoring loopback interface

It makes no difference, if I put OpENer on a different headless linux box. Wireshark on the initiating machine, still sees what it thinks is a valid reply, but EIP_Tools times out. Also tried EIP_Tools on windows, same thing, so it is not a Wine thing.

My suspicion lies with OpENer.

Even class 1, instance 1, attribute 1 fails: "get vendor id". Everything is seemingly rejected by EIP_Tools. Is this not what they use at ODVA sometimes for conformance testing? We joined ODVA today, so I have nothing from them yet.

[mmprestine]

correct, my response was in regards to the OpENer code not being complete for actual use.

[mmprestine]

I have also been testing with linux as I want a RPI an BBB to be connected to some PLCS.

[liftoff-sr]

The project is 6.5 years old and the stack simply does not work?

Bottom of following page shows billysmithde2 saying that is worked for him.

http://forums.mrplc.com/index.php?/topic/27768-open-source-ethernetip-communication-stack/

I am confused as to the state of this OpENer project......

(Even the name confuses me, since there is also a project at github called OpENER-project which seems unrelated.)

Did the spec run out from under this code? Or has the code always been deficient?

The code will not satisfy even the referenced "Ethernet/IP Explorer" with a getattribute?

[mmprestine]

The last spec CIP vol 1 & 2 that I have access to is from 2007 and that is what I am comparing the code to. Why when people made it work they would not post back here. What I can say is once I make it work it will be posted back here.

[azoitl]

This is very strange. OpENer has been used in several products passing the conformance test. Furthermore it is regularly tested with the testing tool. I also have used the Molex tool in one of the plugfests and could connect. Therefore I would really be interested whats the cause of your issue. May we see the wireshark trace? Please don't use a 2007 spec there are several significant changes that an EtherNet/IP stack has to conform to now.

[mmprestine]

Well it is the only spec I have and hopefully it is good enough to trace the issue.

[mmprestine]

I dont have the wireshark transfers handy but here is the trace output and a question about the ConnectionObject.

There is still a problem with the ForwardOpen code / ConnectionObject. When I connect a controllogix processor to OpENer via a Generic Device (CIP Explicit?) I get an extended error 295 with the OpENer traces enabled. Also, should this not be added to the to the ConnectionObject?

/* pointers to connection handling functions */
    OpenConnectionFunction  open_connection_function;

Trace Output:
creating class 'message router' with id: 0x2
adding 1 instances to class message router
creating class 'identity' with id: 0x1
adding 1 instances to class identity
creating class 'TCP/IP interface' with id: 0xF5
adding 1 instances to class TCP/IP interface
creating class 'Ethernet Link' with id: 0xF6
adding 1 instances to class Ethernet Link
creating class 'connection manager' with id: 0x6
adding 1 instances to class connection manager
creating class 'assembly' with id: 0x4
adding 1 instances to class assembly
adding 1 instances to class assembly
adding 1 instances to class assembly
adding 1 instances to class assembly
adding 1 instances to class assembly
adding 1 instances to class assembly
lwip_socket(PF_INET, SOCK_DGRAM, 17) = 0
lwip_bind(0, addr=192.168.1.2 port=44818)
lwip_bind(0) succeeded
lwip_socket(PF_INET, SOCK_STREAM, 6) = 1
lwip_bind(1, addr=192.168.1.2 port=44818)
lwip_bind(1) succeeded
lwip_listen(1, backlog=10)
lwip_select(2, 0x20009a3c, 0, 0, tvsec=0 tvusec=10000)
lwip_select: timeout expired
lwip_select(2, 0x20009a3c, 0, 0, tvsec=0 tvusec=4000)
lwip_selscan: fd=1 ready for reading
lwip_select: nready=1
networkhandler: new TCP connection
lwip_accept(1)...
lwip_accept(1) returning new sock=2 addr=192.168.1.1 port=51010
networkhandler: opened new TCP connection on fd 2
lwip_select(3, 0x20009a3c, 0, 0, tvsec=0 tvusec=9000)
lwip_selscan: fd=2 ready for reading
lwip_select: nready=1
lwip_recvfrom(2, 0x2000983c, 4z, 0x0, ..)
lwip_recvfrom: top while sock->lastdata=0
lwip_recvfrom: netconn_recv err=0, netbuf=0x20008630
lwip_recvfrom: buflen=28 len=4z off=0 sock->lastoffset=0
lwip_recvfrom(2): addr=192.168.1.1 port=51010 len=4
lwip_recvfrom: lastdata now netbuf=0x20008630
lwip_recvfrom(2, 0x20009840, 24z, 0x0, ..)
lwip_recvfrom: top while sock->lastdata=0x20008630
lwip_recvfrom: buflen=28 len=24z off=0 sock->lastoffset=4
lwip_recvfrom(2): addr=192.168.1.1 port=51010 len=24
lwip_recvfrom: deleting netbuf=0x20008630
Data received on tcp:
reply sent:
lwip_send(2, data=0x2000983c, size=28z, flags=0x0)
lwip_send(2) err=0 written=28z
lwip_select: timeout expired
lwip_select(3, 0x20009a3c, 0, 0, tvsec=0 tvusec=4000)
lwip_selscan: fd=2 ready for reading
lwip_select: nready=1
lwip_recvfrom(2, 0x2000983c, 4z, 0x0, ..)
lwip_recvfrom: top while sock->lastdata=0
lwip_recvfrom: netconn_recv err=0, netbuf=0x20008630
lwip_recvfrom: buflen=112 len=4z off=0 sock->lastoffset=0
lwip_recvfrom(2): addr=192.168.1.1 port=51010 len=4
lwip_recvfrom: lastdata now netbuf=0x20008630
lwip_recvfrom(2, 0x20009840, 108z, 0x0, ..)
lwip_recvfrom: top while sock->lastdata=0x20008630
lwip_recvfrom: buflen=112 len=108z off=0 sock->lastoffset=4
lwip_recvfrom(2): addr=192.168.1.1 port=51010 len=108
lwip_recvfrom: deleting netbuf=0x20008630
Data received on tcp:
notifyMR: routing unconnected message
notifyMR: calling notify function of class 'connection manager'
notify: found instance 1
notify: calling ForwardOpen service
ForwardOpen: ConConnID 0, ProdConnID 2708032, ConnSerNo 33262
key: ven ID 0, dev type 0, prod code 0, major 0, minor 0
classid 4 (assembly)
Configuration instance id 151
assembly: type bidirectional
connection point 150
connection point 100
class id: 4
connection status: 295
connection manager: connect failed
assembleFWDOpenResponse: sending error response
notifyMR: notify function of class 'connection manager' returned a reply
reply sent:
lwip_send(2, data=0x2000983c, size=70z, flags=0x0)
lwip_send(2) err=0 written=70z

[mmprestine]

OK, I found an older version from here http://www.emb4fun.com/archive/opener/index.html that I downed load and ran the testing on, it works fine. So I have to say the something is broken in the current code that here on Github that CapXilinx has been working on. Perhaps they could and should fix the issue or revert the code back to a stable version.

[MartinMelikMerkumians]

Hello, may I asked how you checkout out the OpENer source. As I just wanted to take a look on your reported problem, I just found out, that the HEAD of OpENer even does not compile, as I forgot to add a file in the commit.

[MartinMelikMerkumians]

I just fixed the problem, and the actual HEAD should built. I also tested it against the ODVA conformance tool, and I do not have any errors regarding the unconnected send/UCMM in the official tests, so I don't think OpENer is handling the request or the response wrong.

I also tried the EIP Tool and I also have the time out error, but I don't have a clue why.

[mmprestine]

Yes there was a function missing in cpf.c under encapsulation.

Check out is done via git clone.

The problem does not show up in the older build. I will review the code and see if i can find something.

[MartinMelikMerkumians]

Btw. EIP Tools does not reject the answer, but sends a TCP Ackn message and then stops

[liftoff-sr]

On 03/04/2016 08:30 AM, Martin Melik-Merkumians wrote:

Btw. EIP Tools does not reject the answer, but sends a TCP Ackn message and then stops

A TCP Ackn is from the OS's TCP stack, not from EIP_Tools, but I get your point. I think that means the OS received the OpENer response, but EIP_Tools seems to have ignored it. Ignoring a response seems wrong in any case, and then to claim timeout error. Baah.

We have a support request in to Molex, but this was initiated a week ago, and I think they are not eager to support a free tool. "You get what you pay for" seems to be in play. Its as if they are searching their company for someone who can come up with a pertinent answer.

[liftoff-sr]

On 03/04/2016 01:43 PM, Dick Hollenbeck wrote:

On 03/04/2016 08:30 AM, Martin Melik-Merkumians wrote:

Btw. EIP Tools does not reject the answer, but sends a TCP Ackn message and then stops

I confirm that EIP_Tools says "OK" to the reply coming from the older OpENer code. So we can compare some of the wireshark response packets and see differences.

[liftoff-sr]

I confirm that EIP_Tools says "OK" to the reply coming from the older OpENer code. So we can compare some of the wireshark response packets and see differences.

Attached are the two captures, expanded with wireshark to text format.

packets.new is against new OpENer and causes EIP_tools to timeout.

And packet.old is against old OpENer and seems to make EIP_tools happy.

A good diff tool shows the differences.

No. Time Source Destination Protocol Info 3 3.159706 192.100.100.3 192.100.100.3 CIP Get Attribute Single

Frame 3: 114 bytes on wire (912 bits), 114 bytes captured (912 bits) Encapsulation type: Ethernet (1) Arrival Time: Mar 4, 2016 14:35:51.688057000 CST [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1457123751.688057000 seconds [Time delta from previous captured frame: 0.000098000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 3.159706000 seconds] Frame Number: 3 Frame Length: 114 bytes (912 bits) Capture Length: 114 bytes (912 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:tcp:enip:cip] [Number of per-protocol-data: 2] [Common Industrial Protocol, key 0] [Transmission Control Protocol, key 0] [Coloring Rule Name: Checksum Errors] [Coloring Rule String: eth.fcs_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 || sctp.checksum_bad==1 || mstp.checksum_bad==1 || cdp.checksum_bad==1 || edp.checksum_bad==1 || wlan.fcs_bad==1] Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Destination: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IP (0x0800) Internet Protocol Version 4, Src: 192.100.100.3 (192.100.100.3), Dst: 192.100.100.3 (192.100.100.3) Version: 4 Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 100 Identification: 0xce11 (52753) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (6) Header checksum: 0x23b3 [correct] [Calculated Checksum: 0x23b3] [Good: True] [Bad: False] Source: 192.100.100.3 (192.100.100.3) Destination: 192.100.100.3 (192.100.100.3) Transmission Control Protocol, Src Port: 34294 (34294), Dst Port: EtherNet/IP-2 (44818), Seq: 3718856564, Ack: 1585953681, Len: 48 Source Port: 34294 (34294) Destination Port: EtherNet/IP-2 (44818) [Stream index: 0] [TCP Segment Len: 48] Sequence number: 3718856564 [Next sequence number: 3718856612] Acknowledgment number: 1585953681 Header Length: 32 bytes .... 0000 0001 1000 = Flags: 0x018 (PSH, ACK)

0. .... .... = Reserved: Not set ...0 .... .... = Nonce: Not set .... 0... .... = Congestion Window Reduced (CWR): Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 1... = Push: Set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set Window size value: 342 [Calculated window size: 342] [Window size scaling factor: -1 (unknown)] Checksum: 0x4926 [incorrect, should be 0x97c9 (maybe caused by "TCP checksum offload"?)] [Calculated Checksum: 0x97c9] [Good Checksum: False] [Bad Checksum: True] [Expert Info (Error/Checksum): Bad checksum] [Bad checksum] [Severity level: Error] [Group: Checksum] Urgent pointer: 0 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps No-Operation (NOP) Type: 1 0... .... = Copy on fragmentation: No .00. .... = Class: Control (0) ...0 0001 = Number: No-Operation (NOP) (1) No-Operation (NOP) Type: 1 0... .... = Copy on fragmentation: No .00. .... = Class: Control (0) ...0 0001 = Number: No-Operation (NOP) (1) Timestamps: TSval 120444778, TSecr 120441491 Kind: Time Stamp Option (8) Length: 10 Timestamp value: 120444778 Timestamp echo reply: 120441491 [SEQ/ACK analysis] [Bytes in flight: 48] [Timestamps] [Time since first frame in this TCP stream: 0.000000000 seconds] [Time since previous frame in this TCP stream: 0.000000000 seconds] [PDU Size: 48] EtherNet/IP (Industrial Protocol), Session: 0x00000001, Send RR Data Encapsulation Header Command: Send RR Data (0x006f) Length: 24 Session Handle: 0x00000001 Status: Success (0x00000000) Sender Context: 0c00020000008501 Options: 0x00000000 Command Specific Data Interface Handle: CIP (0x00000000) Timeout: 30 Item Count: 2 Type ID: Null Address Item (0x0000) Length: 0 Type ID: Unconnected Data Item (0x00b2) Length: 8 [Response In: 4] Common Industrial Protocol Service: Get Attribute Single (Request) 0... .... = Request/Response: Request (0x00) .000 1110 = Service: Get Attribute Single (0x0e) Request Path Size: 3 (words) Request Path: TCP/IP Interface Object, Instance: 0x01, Attribute: 0x01 (Status) Path Segment: 0x20 (8-Bit Class Segment)
   1. .... = Path Segment Type: Logical Segment (1) ...0 00.. = Logical Segment Type: Class ID (0) .... ..00 = Logical Segment Format: 8-bit Logical Segment (0) 8-Bit Class Segment Class: TCP/IP Interface Object (0xf5) Path Segment: 0x24 (8-Bit Instance Segment)
   2. .... = Path Segment Type: Logical Segment (1) ...0 01.. = Logical Segment Type: Instance ID (1) .... ..00 = Logical Segment Format: 8-bit Logical Segment (0) 8-Bit Instance Segment Instance: 0x01 Path Segment: 0x30 (8-Bit Attribute Segment)
   3. .... = Path Segment Type: Logical Segment (1) ...1 00.. = Logical Segment Type: Attribute ID (4) .... ..00 = Logical Segment Format: 8-bit Logical Segment (0) 8-Bit Attribute Segment Attribute: 0x01 (Status) Get Attribute Single (Request)

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 64 ce 11 40 00 40 06 23 b3 c0 64 64 03 c0 64 .d..@.@.#..dd..d 0020 64 03 85 f6 af 12 dd a9 3f 74 5e 87 bb 91 80 18 d.......?t^..... 0030 01 56 49 26 00 00 01 01 08 0a 07 2d d7 6a 07 2d .VI&.......-.j.- 0040 ca 93 6f 00 18 00 01 00 00 00 00 00 00 00 0c 00 ..o............. 0050 02 00 00 00 85 01 00 00 00 00 00 00 00 00 1e 00 ................ 0060 02 00 00 00 00 00 b2 00 08 00 0e 03 20 f5 24 01 ............ .$. 0070 30 01 0. No. Time Source Destination Protocol Info 4 3.159812 192.100.100.3 192.100.100.3 CIP Success

Frame 4: 126 bytes on wire (1008 bits), 126 bytes captured (1008 bits) Encapsulation type: Ethernet (1) Arrival Time: Mar 4, 2016 14:35:51.688163000 CST [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1457123751.688163000 seconds [Time delta from previous captured frame: 0.000106000 seconds] [Time delta from previous displayed frame: 0.000106000 seconds] [Time since reference or first frame: 3.159812000 seconds] Frame Number: 4 Frame Length: 126 bytes (1008 bits) Capture Length: 126 bytes (1008 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:tcp:enip:cip] [Number of per-protocol-data: 2] [Common Industrial Protocol, key 0] [Transmission Control Protocol, key 0] [Coloring Rule Name: Checksum Errors] [Coloring Rule String: eth.fcs_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 || sctp.checksum_bad==1 || mstp.checksum_bad==1 || cdp.checksum_bad==1 || edp.checksum_bad==1 || wlan.fcs_bad==1] Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Destination: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IP (0x0800) Internet Protocol Version 4, Src: 192.100.100.3 (192.100.100.3), Dst: 192.100.100.3 (192.100.100.3) Version: 4 Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 112 Identification: 0x4958 (18776) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (6) Header checksum: 0xa860 [correct] [Calculated Checksum: 0xa860] [Good: True] [Bad: False] Source: 192.100.100.3 (192.100.100.3) Destination: 192.100.100.3 (192.100.100.3) Transmission Control Protocol, Src Port: EtherNet/IP-2 (44818), Dst Port: 34294 (34294), Seq: 1585953681, Ack: 3718856612, Len: 60 Source Port: EtherNet/IP-2 (44818) Destination Port: 34294 (34294) [Stream index: 0] [TCP Segment Len: 60] Sequence number: 1585953681 [Next sequence number: 1585953741] Acknowledgment number: 3718856612 Header Length: 32 bytes .... 0000 0001 1000 = Flags: 0x018 (PSH, ACK)

0. .... .... = Reserved: Not set ...0 .... .... = Nonce: Not set .... 0... .... = Congestion Window Reduced (CWR): Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 1... = Push: Set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set Window size value: 342 [Calculated window size: 342] [Window size scaling factor: -1 (unknown)] Checksum: 0x4932 [incorrect, should be 0x49ba (maybe caused by "TCP checksum offload"?)] [Calculated Checksum: 0x49ba] [Good Checksum: False] [Bad Checksum: True] [Expert Info (Error/Checksum): Bad checksum] [Bad checksum] [Severity level: Error] [Group: Checksum] Urgent pointer: 0 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps No-Operation (NOP) Type: 1 0... .... = Copy on fragmentation: No .00. .... = Class: Control (0) ...0 0001 = Number: No-Operation (NOP) (1) No-Operation (NOP) Type: 1 0... .... = Copy on fragmentation: No .00. .... = Class: Control (0) ...0 0001 = Number: No-Operation (NOP) (1) Timestamps: TSval 120444778, TSecr 120444778 Kind: Time Stamp Option (8) Length: 10 Timestamp value: 120444778 Timestamp echo reply: 120444778 [SEQ/ACK analysis] [This is an ACK to the segment in frame: 3] [The RTT to ACK the segment was: 0.000106000 seconds] [Bytes in flight: 60] [Timestamps] [Time since first frame in this TCP stream: 0.000106000 seconds] [Time since previous frame in this TCP stream: 0.000106000 seconds] [PDU Size: 60] EtherNet/IP (Industrial Protocol), Session: 0x00000001, Send RR Data Encapsulation Header Command: Send RR Data (0x006f) Length: 36 Session Handle: 0x00000001 Status: Success (0x00000000) Sender Context: 0c00020000008501 Options: 0x00000000 Command Specific Data Interface Handle: CIP (0x00000000) Timeout: 0 Item Count: 2 Type ID: Null Address Item (0x0000) Length: 0 Type ID: Unconnected Data Item (0x00b2) Length: 8 [Request In: 3] [Time: 0.000106000 seconds] Common Industrial Protocol Service: Get Attribute Single (Response) 1... .... = Request/Response: Response (0x01) .000 1110 = Service: Get Attribute Single (0x0e) Status: Success General Status: Success (0x00) Additional Status Size: 0 (words) [Request Path Size: 3 (words)] [Request Path: TCP/IP Interface Object, Instance: 0x01, Attribute: 0x01 (Status)] [Path Segment: 0x20 (8-Bit Class Segment)] [001. .... = Path Segment Type: Logical Segment (1)] [...0 00.. = Logical Segment Type: Class ID (0)] [.... ..00 = Logical Segment Format: 8-bit Logical Segment (0)] [8-Bit Class Segment] [Class: TCP/IP Interface Object (0xf5)] [Path Segment: 0x24 (8-Bit Instance Segment)] [001. .... = Path Segment Type: Logical Segment (1)] [...0 01.. = Logical Segment Type: Instance ID (1)] [.... ..00 = Logical Segment Format: 8-bit Logical Segment (0)] [8-Bit Instance Segment] [Instance: 0x01] [Path Segment: 0x30 (8-Bit Attribute Segment)] [001. .... = Path Segment Type: Logical Segment (1)] [...1 00.. = Logical Segment Type: Attribute ID (4)] [.... ..00 = Logical Segment Format: 8-bit Logical Segment (0)] [8-Bit Attribute Segment] [Attribute: 0x01 (Status)] Get Attribute Single (Response) (Status) Status: 0x00000001 .... .... .... .... .... .... .... 0001 = Interface Configuration Status: BOOTP/DHCP/NVS (1) .... .... .... .... .... .... ...0 .... = MCast Pending: False .... .... .... .... .... .... ..0. .... = Interface Configuration Pending: False .... .... .... .... .... .... .0.. .... = ACD Status: No Address Conflict Detected (0) 0000 0000 0000 0000 0000 0000 0... .... = Reserved: 0x00000000

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 70 49 58 40 00 40 06 a8 60 c0 64 64 03 c0 64 .pIX@.@..`.dd..d 0020 64 03 af 12 85 f6 5e 87 bb 91 dd a9 3f a4 80 18 d.....^.....?... 0030 01 56 49 32 00 00 01 01 08 0a 07 2d d7 6a 07 2d .VI2.......-.j.- 0040 d7 6a 6f 00 24 00 01 00 00 00 00 00 00 00 0c 00 .jo.$........... 0050 02 00 00 00 85 01 00 00 00 00 00 00 00 00 00 00 ................ 0060 02 00 00 00 00 00 b2 00 08 00 8e 00 00 00 01 00 ................ 0070 00 00 24 00 00 00 00 00 00 00 02 00 20 f6 ..$......... . No. Time Source Destination Protocol Info 5 3.159820 192.100.100.3 192.100.100.3 TCP 34294→EtherNet/IP-2 [ACK] Seq=3718856612 Ack=1585953741 Win=342 [TCP CHECKSUM INCORRECT] Len=0 TSval=120444778 TSecr=120444778

Frame 5: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) Encapsulation type: Ethernet (1) Arrival Time: Mar 4, 2016 14:35:51.688171000 CST [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1457123751.688171000 seconds [Time delta from previous captured frame: 0.000008000 seconds] [Time delta from previous displayed frame: 0.000008000 seconds] [Time since reference or first frame: 3.159820000 seconds] Frame Number: 5 Frame Length: 66 bytes (528 bits) Capture Length: 66 bytes (528 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:tcp] [Number of per-protocol-data: 1] [Transmission Control Protocol, key 0] [Coloring Rule Name: Checksum Errors] [Coloring Rule String: eth.fcs_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 || sctp.checksum_bad==1 || mstp.checksum_bad==1 || cdp.checksum_bad==1 || edp.checksum_bad==1 || wlan.fcs_bad==1] Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00) Destination: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Source: 00:00:00_00:00:00 (00:00:00:00:00:00) Address: 00:00:00_00:00:00 (00:00:00:00:00:00) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) Type: IP (0x0800) Internet Protocol Version 4, Src: 192.100.100.3 (192.100.100.3), Dst: 192.100.100.3 (192.100.100.3) Version: 4 Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00) Total Length: 52 Identification: 0xce12 (52754) Flags: 0x02 (Don't Fragment) 0... .... = Reserved bit: Not set .1.. .... = Don't fragment: Set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: TCP (6) Header checksum: 0x23e2 [correct] [Calculated Checksum: 0x23e2] [Good: True] [Bad: False] Source: 192.100.100.3 (192.100.100.3) Destination: 192.100.100.3 (192.100.100.3) Transmission Control Protocol, Src Port: 34294 (34294), Dst Port: EtherNet/IP-2 (44818), Seq: 3718856612, Ack: 1585953741, Len: 0 Source Port: 34294 (34294) Destination Port: EtherNet/IP-2 (44818) [Stream index: 0] [TCP Segment Len: 0] Sequence number: 3718856612 Acknowledgment number: 1585953741 Header Length: 32 bytes .... 0000 0001 0000 = Flags: 0x010 (ACK)

0. .... .... = Reserved: Not set ...0 .... .... = Nonce: Not set .... 0... .... = Congestion Window Reduced (CWR): Not set .... .0.. .... = ECN-Echo: Not set .... ..0. .... = Urgent: Not set .... ...1 .... = Acknowledgment: Set .... .... 0... = Push: Not set .... .... .0.. = Reset: Not set .... .... ..0. = Syn: Not set .... .... ...0 = Fin: Not set Window size value: 342 [Calculated window size: 342] [Window size scaling factor: -1 (unknown)] Checksum: 0x48f6 [incorrect, should be 0x02bc (maybe caused by "TCP checksum offload"?)] [Calculated Checksum: 0x02bc] [Good Checksum: False] [Bad Checksum: True] [Expert Info (Error/Checksum): Bad checksum] [Bad checksum] [Severity level: Error] [Group: Checksum] Urgent pointer: 0 Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps No-Operation (NOP) Type: 1 0... .... = Copy on fragmentation: No .00. .... = Class: Control (0) ...0 0001 = Number: No-Operation (NOP) (1) No-Operation (NOP) Type: 1 0... .... = Copy on fragmentation: No .00. .... = Class: Control (0) ...0 0001 = Number: No-Operation (NOP) (1) Timestamps: TSval 120444778, TSecr 120444778 Kind: Time Stamp Option (8) Length: 10 Timestamp value: 120444778 Timestamp echo reply: 120444778 [SEQ/ACK analysis] [This is an ACK to the segment in frame: 4] [The RTT to ACK the segment was: 0.000008000 seconds] [Timestamps] [Time since first frame in this TCP stream: 0.000114000 seconds] [Time since previous frame in this TCP stream: 0.000008000 seconds]

0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ..............E. 0010 00 34 ce 12 40 00 40 06 23 e2 c0 64 64 03 c0 64 .4..@.@.#..dd..d 0020 64 03 85 f6 af 12 dd a9 3f a4 5e 87 bb cd 80 10 d.......?.^..... 0030 01 56 48 f6 00 00 01 01 08 0a 07 2d d7 6a 07 2d .VH........-.j.- 0040 d7 6a .j

[MartinMelikMerkumians]

Could you please post the wireshark traces?

I hardly can even read this trace

[MartinMelikMerkumians]

and which trace is for the old or new OpENer?

[liftoff-sr]

post them how?

I attached both files separately to my email. I think you need a better support forum. Seriously, this is fully inadequate. I led the KiCad project for 7 years, a true mailing list seems necessary to support an open source project.

I don't know how to make a pig fly.

[mmprestine]

perhaps it is possible to keep code here but use a sourceforge mailing list for support issues?

Yes all the tools and actual hardware (logix plcs) work with the older version 1.2.

[MartinMelikMerkumians]

@liftoff-sr Instead of mailing them, open the issue in your browser with the provided link.

At the bottom of the message box it is explained how to attach files - "Attach files by dragging & dropping, Dateien auswählen selecting them, or pasting from the clipboard."

Regarding your complaint on my "fully inadequate" system, I want to emphazise that I am doing this alone, not as my fully day job, and free of charge, so I beg your pardon if I don't have the time to set up a more proper system and just go with the GitHub onboard tools.

[liftoff-sr]

packets.new.txt packets.old.txt

[liftoff-sr]

Not sure why you feel this has to be done alone. When I left KiCad 2 years ago we had 500 developers on the mailing list, and 15 of those were reasonably regular contributors. It is up 50% in the two years since I left. I hand picked my most excellent successor, and he seems to be enjoying it and seems to be very good at it.

It starts by learning to ask people to help, rather than merely jumping on them when they offer a suggestion.

[MartinMelikMerkumians]

@liftoff-sr I do not think that I have to do this alone, but matter of fact I did in the last two years.

It seems I misunderstood the intention of your post, and I want to apologize as you just wanted to state a suggestion. But in Austria your post would be considered kind of rude, as I wanted to help you with your issue and you are complaining on how to provide me the information I need.

So again, I am sorry that I jumped at you for your suggestion

[MartinMelikMerkumians]

@mmprestine As the name opener is already reserved at sourceforge and I can not use another name for the project, this is not an option

[liftoff-sr]

There are 12 extra bytes at the end of the response in packets.new.txt that are not present in packets.old.txt. This is our best possible explanation.

[MartinMelikMerkumians]

Yes, I have already seen them. I have to check that in more detail, but I think that's due to that more attributes are now needed to be returned by the get attribute all service

[mmprestine]

Is there anything on the client side that determines the stack level of server and setups up proper protocol checks?

[MartinMelikMerkumians]

Oh, sorry I just realized it's a Get Atrtibute Single request

[mmprestine]

How about a twitter or reddit account for OpENer?

[MartinMelikMerkumians]

As replacement for a mailing list? Never used reddit so no clue if that is feasible. Tweets are probably a bit to unorganized for a mailing list substitution, but I also don't have that much experience with Twitter (but I have an account :D )

So any opinions what would be better suited?

[MartinMelikMerkumians]

Usually the STC and/or EDS file of a device states its properties and capabilites. Protocol checks are not done as far as I know. That's the task of the CIP Conformance testing tool, which is not complaining about getting attributes.

[mmprestine]

mailing lists are ideal and probably better suited than the prior suggestions.

http://www.freelists.org/?

[mmprestine]

Another suggestion is just create a google group called OpENer and it will have a mailing list.

[MartinMelikMerkumians]

Sounds both fine to me.

[liftoff-sr]

Attached is a patch which fixes the bug, which as I said was a bogus extra 12 bytes in the encapsulated payload. This is what was making EIP_tool unhappy.

HTH,

Dick

fix-bogus-encapsulated-packet-length.patch.txt

[MartinMelikMerkumians]

Thank you for your support!

Regards, Martin

[mmprestine]

I have just done some testing and there still is a problem with 8 extra bytes being sent. It looks to be coming from the same AssembleLinearMessage function returning the incorrect message length.

[liftoff-sr]

I found wireshark's menu:

File -> Export Packet Disections -> As Plain Text File (check options "All Expanded", "Packet Bytes")

helpful for communicating problems. These outputs can also be diff-ed, that is what pointed me to the prior problem's origin. A diff between a successful frame from an older version vs. a failed frame from the newest OpENer.

On linux I use package "meld" for diffs.

[mmprestine]

I will get some wire shark captures. When I use a PLC to connect with forwardopen I get a message length of 90 on the old test code and get 98 on the new master. I am pretty sure it is in the same AssembleLinearMessage function as that seems to be where the message length is getting set wrong.

[MartinMelikMerkumians]

I think I found the error. It is not in AssembleLinearMessage, but in FillNextNMessageOctetsWithValueAndMoveToNextPosition in endianconv.h

I mistakenly added another time of n to the existing n in the first line. I opened a new Issue (Issue #53 ) and will add a patch there, if you would be so kind and try it of @mmprestine ?