OpENer
OpENer copied to clipboard
EIPStackGroup
Producing connections without raw sockets
Added a global UDP socket for io messaging to g_network_status CreateUdpSocket is called once in OpenCommunicationChannels CloseUdpSocket is called once in CloseCommunicationChannelsAndRemoveFromActiveConnectionsList CreateUdpSocket adapted parameters removed, open the global socket, doing a bind(2) to define the src port Remove all socket configuring stuff from all functions called in EstablishIoConnection New functions created for additional TTL and Multicast settings formerly done in CreateUdpSocket Renamed CheckAndHandleConsumingUdpSockets to CheckAndHandleConsumingUdpSocket
Do I understand this correctly, that there is always only one outgoing UDP port? What if the originator wants two connections with two different ports? I am not sure if this is covered by this patch and the conformance tester tests
Yes you do understand correctly this. I understood that for implicit IO messaging always port 2222 should used for src and dest port, isnt it?
@CapXilinx: I did implement, what we discussed related to issue #157, the functionality of the stack should remain the same as before. There is no change in the port addressing except the source port in the IO messages sent will be always 2222 (as before). How shall we proceed now?
@CapXilinx Hi Martin It is quite a while since we have been in touch. In the meantime I tested it with the Posix port as also with my new STM32 port together with a Rockwell PLC and it works fine in the modes Unicast and Multicast. Your concern: "What if the originator wants two connections with two different ports?" can be answered in the way that I did not touch the handling of the remote (dest) address (and port). Can you provide any guidance how I could test this? BR Peter
Hi @PeterChristen577, sorry for the very late reply. For every Forward Open there needs to be an additional Sockaddr Info Item in the message, defining the O->T and T->O connections. For PtP there the sin_port field can be any port. Port 0x8AE (2222) is recommended, so perhaps in 90% of all cases this should pose no problem, but there could be vendors or users who do not want to use this port. Also, with the CIP Security extension, secure connections will use port 2221 (0x8AD) so this will become a problem in the future if we only can have one port.
My fix for that would be to allow multiple sockets for different ports, but as you have implemented it now, only one socket per port and scanning all ports sequentially and reroute the messages to the correct connections.
How to test this all... that's the hardest question. I don't know of any software to do this easy. One solution would be to create one connection via ENIPExplorer and then send a second request via the Messaging Tool in the ODVA Conformance Test Tool or the Molex or Hilscher ENIP Tool, where you can then specify also the Sockaddr Info Item.
But I am not sure if this really works, such low level test are unfortunately hard to do. Another possibility would be to create a small Python script to send the Forward Open with the needed Sockaddr Item.
I hope that helps, and I am happy to help you in testing and programming if you want to extend your patch regarding the things mentioned above.
I would like to try to extend this myself, but currently, I am busy on CIP Security, CIP File and updating the core to conform with the new specification, so I unfortunately can't right now.
Best regards, Martin
Oh, what I forget to mention, I have some problems putting your branch on the current master. Not sure if this a problem with my setup but I can't merge it properly
@CapXilinx Hi Martin Thanks for your answer. Let me think about a little about that. Just for my understanding two questions:
- When you are talking about port 2221, do you mean the source or destination port?
- I have only very old versions of THE CIP NETWORKS LIBRARY, Volume 1 and 2 (Edition 1.4, November 2007) where can I can more recents versions of it? About your mention concerning the merge. I had to resolve some conflicts, this has been done now.
Hi @PeterChristen577,
ad 1): again, this can be both for originator and target. At least it seems that CIP Security does not allow the use of other ports for their communication. ad 2): At the ODVA (https://www.odva.org/). The most recent version should be April 2021,the next version will be probably released in November.
@CapXilinx Hi Martin
-
I had a look using WireShark to the Forward open message - sent by ENIPExplorer: There I expect to see any address information, but I could not find it:
but in the response from the target to the originator this information is included:
-
I do not have $1000 spare to buy the specs ;)
If you could provide some guidance in this topic. this would be great.
About testing: I am able to compile ENIPExplorer. I could create a version where the port(s) can be configured and then use two instances of it with different ports set up.
Hi @PeterChristen577 ,
sorry again for the long delay. Flu season starts it seems ':)
If no address information is sent, then the default (2222) is assumed.
@PeterChristen577 perhaps you want to skype on your open questions? I think that would be easier than discussing it here
@CapXilinx yes this is a very good proposal. Let me know when it would fit in time for you.
@CapXilinx Hi Martin I took the source code from the Hilscher Ethernet/IP Tool and added the possibility the change the IP port in the forward open request.
Forward Open with port 2222 (standard):
IO date T>O:
Forward Open with port with port 2221:
IO date T>O:
This has been tested with both branches: master and this pull request without raw sockets. The behaviour is equal for both branches.
Has there been a final decision made on this PR yet? It worksforme (TM) communicating with a simple Allen Bradley PLC and I am very tempted to use it instead of master since not needing Administrator rights on Windows would be quite nice.
We are currently testing it. We have identified an issue with the last commit 'RPI Timer fix' to produce errors in the CT, where it does not receive some messages. Without that commit is seems to work fine.
Can you provide a more specific information about the issues with 'RPI Timer fix'? After vacation season I would have time to do some analysis.
I found an issue in cases where the elapsed time is higher than the RPI set up. This has been fixes. The implementation before was more proof of concept, sorry for the circumstances. Please test it again
Merged in 6068d32066358e71f832e4f0cf21599cfe7e6cbe Seems like Github didn't recognize it