Open widavies opened 1 year ago
Hi! I fully agree that the implementation in pf_cmrdr_inquiry_read_all_reg_ind() is strange, as we check against the sequence number (which will be in the hundreds when running Proneta). This results in the EPM response lacking any meaningful contents.
However this does not seem to relate to missing content in Proneta. I can not reproduce the issue, as the I&M data is shown every time in Proneta. The I&M0 data is read via a "read implicit" request.
Can you please try to reproduce the missing content issue using the sampleapp from this repo?
I'm currently having an issue where a Proneta scan against my device running this stack returns no IM0 record data.
In other words, this section is missing from Proneta:
After investigating this a bit, the particular implementation of
pf_cmrdr_inquiry_read_all_reg_ind
seems a bit bizarre to me. I'm not super familiar with the Profinet specification, so I might just be missing something here.The following here is a Wireshark capture of a request made from Proneta to the IO-device. As highlighted here, Proneta chooses a somewhat random sequence number (in this case
370
):Taking a look at pf_cmrdr_inquiry_read_all_reg_ind, a switch is performed off of the
p_rpc_req->sequence_nmb
field:According to the specification, the sequence number is used to uniquely identify an RPC call. From my understanding, the exact value has no further purpose than to distinguish multiple RPC calls.
To me it seems like the sequence number should not be checked against the fixed values of
0
and1
. Looking at the packet, I can't determine any other way to handle the lookup requests properly than to keep thep_session_info_t
alive instead of killing it after the first request. That way a sequence number can just be handled internally and incremented for the session.I ending up adding the fix for this in, I'm happy to make a pull request.
This sequence number is set to 0 when the session is created and incremented once every time a packet is handled.
Per the above comment, this approach also requires a timeout for closing the session. Any ideas on this are welcome.