Default value for org.fmi_standard.fmi_ls_xcp.[Tcp|UDP]ListenIpAddress can not be resolved from a2l

[adriantirea]

Is there a field in a2l that really has the meaning of ListenIpAddress?

To my knowledge and based on the experiments I did with some Measurement Tools (INCA, ETAS https://www.etas.com/download-center-files/products_ETK/etas-access-devices-operation-as-xcp-on-ethernet-device-20240315.pdf#page=30), the IP address in the a2l is the address of the XCP server, not the filter for the addresses where the XCP server listens. Therefore I think the sentence If not present: Defaults to the protocol data values found in the relevant A2L file. is not correct.

   org.fmi_standard.fmi_ls_xcp.TcpListenIpAddress
        Description:         "TCP IP address where the XCP slave listens for XCP protocol commands."
        Type:                String
        Example Start Value: "0.0.0.0"
        Requirement Type:    Should be supplied, if the FMU provides an XCP service using TCP
        If not present:      Defaults to the protocol data values found in the relevant A2L file.

   org.fmi_standard.fmi_ls_xcp.UdpListenIpAddress
        Description:         "UDP IP address where the XCP slave listens for XCP protocol commands."
        Type:                String
        Example Start Value: "0.0.0.0"
        Requirement Type:    Should be supplied, if the FMU provides an XCP service using UDP
        If not present:      Defaults to the protocol data values found in the relevant A2L file.

Possible solutions:

• default value is INADDR_ANY == 0.0.0.0
• default value is LOCALHOST == 127.0.0.1

Related ticket #20

[pmai]

If there is no variable, especially not a changeable one, then the FMU must do whatever it thinks useful to make the IP address it supplies in the A2L file work; it is up to the FMU's implementation and the default discussed above is the default that the importer can assume, i.e. it is the address the importer can assume it can connect to.

How the FMU handles this internally is up to it: It can just listen on the IP address in the A2L file (which will only work if there is an interface that has this IP addresss assigned), it can hope that listening on INADDR_ANY will listen at least on that IP address (and likely might want to check if that is true, and possible issue a warning if that is not true). It very likely should not listen on localhost, unless the address supplied in the A2L file is localhost.

I don't see how specifying different default behavior than "look into the A2L file to find an IP address to try to connect to" is going to be useful...

It still seems to be that there is an assumption that FMI-LS-XCP supercedes A2L where really it should not be seen like this, but rather FMI-LS-XCP augments the A2L in cases where there is something that goes beyond what A2L can provide, like changeable listen address, or enabling/disabling at startup.

[adriantirea]

Current wording that org.fmi_standard.fmi_ls_xcp.UdpListenIpAddress defaults to the protocol data values found in the relevant A2L files means undefined behavior because there is no information in the a2l file to match UdpListenIpAddress.

[pmai]

I don't know what you are trying to do, as obviously there are protocol data values in the A2L file that indicate which address to connect to:

taggedunion {
    "HOST_NAME" char[256];
    "ADDRESS" char[15];
    "IPV6" char[39];
  };

When there is no variable, that's the only information the importer has, and it will use it to connect. Nothing undefined here. What the FMU internally does in terms of listen/bind calls is up to the FMU in any case.

Not only do I not see a problem, I don't see anything that we could write that would make any of this better. So this brings me back to the question: What are you trying to do, and how does the current spec affect this?

[adriantirea]

The current fmi-ls-xcp does not block Silver functionality in any way. It is a matter of correctness or usefulness in what we write in fmi-ls-xcp document.

The ADDRESS in the taggedunion is the IP address of the xcp slave inside the FMU. The MDC tool will use this IP to connect to xcp slave. fmi-ls-xcp has no parameter to overwrite the ADDRESS from the a2l.

The org.fmi_standard.fmi_ls_xcp.UdpListenIpAddress is not the address of the xcp slave, but the filter where from the xcp slave accepts connections from. Therefore, when telling to look for the default value in the a2l, we tell to look for something does not exist.

Example 1:

• FMU has IP address 192.158.1.1
• then the ADDRESS in the a2l is the same value 192.158.1.1.
• org.fmi_standard.fmi_ls_xcp.UdpListenIpAddress is not present in modelDescription.xml. Then fmi-ls-xcp says the value is the one specified by the a2l. Which value from a2l? Actually is up to the FMU to do whatever it wants and a2l is oblivious to what addresses FMU listen to.
• the MDC tool has the IP 192.158.2.2. The MDC tool cannot know if its IP will be accepted by the FMU. Therefor the MDC tool has to simply try it and see.

I agree with your sentence:

What the FMU internally does in terms of listen/bind calls is up to the FMU in any case.

Current sentence is useless because there is nothing in A2L about listening address.

"If not present: Defaults to the protocol data values found in the relevant A2L file."

A better formulation could be: "If not present: The FMU does not inform about the value or provide a way to configure the value through FMI variables"

I can live with this usefulness. I would not stop the releasing of fmi-ls-xcp 1.0 for this. If anybody else do not see this as a problem, I agree to close the ticket.

[pmai]

I agree with your sentence:

What the FMU internally does in terms of listen/bind calls is up to the FMU in any case.

That is true, however regardless of the variable and its value, as the FMU still has to do whatever it thinks best to enable listening on the provided address, whether it is the one provided as part of the A2L file or if it is changed as part of a changeable variable.

Current sentence is useless because there is nothing in A2L about listening address.

That is not true, as the A2L address is the listening address, i.e. the FMU is determined to try to listen on this IP address, same as if that address is provided via the variable. In either case the FMU will have to decide how to effectuate this, and it might not be able to do so (again in either case, as there is no guarantee that the host has any interface that will allow binding to this address).

And in any case the importer will do the same thing, too: Try to connect to that address.

Your formulation would leave it open which address the importer should try to connect to, and that should not be left open, as it very clearly is the A2L address that shall be used in this case. Now I might have prefered different wording about all of the variables, but the current wording seems much less confusing/unclear than the proposed change.

[adriantirea]

Current sentence is useless because there is nothing in A2L about listening address.

That is not true, as the A2L address is the listening address, i.e. the FMU is determined to try to listen on this IP address, same as if that address is provided via the variable. In either case the FMU will have to decide how to effectuate this, and it might not be able to do so (again in either case, as there is no guarantee that the host has any interface that will allow binding to this address).

I think we get to the critical question on the subject now. What is the ADDRESS inside A2L? My answer is: the IP address of the xcpSlave. Your answer was: the address of the MDC that the xcpSlave will listen to.

[chrbertsch]

Can we resolve this issue before possible soonish release?

[chrbertsch]

FMI Steering Committee: Pierre: Pierre and Adrian hat a short call before the meeting. We can live with the current sulution. The current solution does not cover the full complexity, there are slight differences in IP addresses ... The default works. We should discuss the complexity of this e.g. in the implementer's guide Andreas: We should talk to ASAM to clarify addresses ...

[adriantirea]

I want to add that my premise I started the discussion with was wrong. I thought that the IpListeningAddress acts like a filter for the IP addresses of the MDC tools.

The correct understanding is that the IpListeningAddress is used to select the IP address of the xcpSlave slave where to operate. On a machine where the xcpSlave is located, there may be multiple IP stacks available. By configuring the FMU with org.fmi_standard.fmi_ls_xcp.[Udp|TCP]ListenIpAddress we tell the FMU which of the IPs to use. If we do not want to be specific, then INADDR_ANY can be supplied, meaning that a MDC can connect to the xcp slave on any of the IPs of the machine where the xcp_slave is located.

In some sense, the ListeningIpAddress is a filter, but not for the IPs of the MDC tool, but for the IPs of the machine where the xcp_slave is located.