Community
Participate
Working Groups
It looks to me as if you cannot bind the forte runtime to an IPv6 address using `-c`. I can only bind to `0.0.0.0` which results in: ~~~ [root@jreimann-up2-1 jreimann]# ss -tl State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 1 0.0.0.0:61499 0.0.0.0:* LISTEN 0 100 0.0.0.0:opcua-tcp 0.0.0.0:* LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* LISTEN 0 100 [::]:opcua-tcp [::]:* LISTEN 0 128 [::]:ssh [::]:* ~~~ Where you can see that e.g. SSH also binds to "[::]". Using `-c [::]:61499`. I think that can be resolved to use AF_INET6, instead of AF_INET in `CBSDSocketInterface::openTCPClientConnection`.
Can you please elaborate a bit more on what you would like to do? with ss -tl you are listing the listening sockets. So this would be the server sockets. If that is the case I think you mean the default server socket where FORTE listens to commands from configuration tools. Currently we only set the port for this operation. So everything before the port is ignored and we bind to INADDR_ANY.
What I would like to do, is to connect to the monitor port via IPv6. Assuming I have an IPv6 only network. Yes, I figured out that the address part of `-c` is ignored. That may another issue. What I would like to see, that both the IPv4 ANY and the IPv6 ANY address are used for listening. From what I understood, it should be sufficient to use AF_INET6, and inaddr6_any, in order to bind to IPv4+6 on a dual stack setup.
Hmh for server sockets this may be a solution. The only thing I fear is that the code you a referring to is for all platforms except Windows. So performing a change here would affect all platforms. Did you do already experiments if changing to AF_INET6 will solve the issue for you? I have some idea about adding such a feature more gracefully with either a template parameter or a constant the platform has to provide. but I fear in the mid term we would need a full IPv6 concept for our communication, which is currently not even foreseen in the "IEC 61499 Compliance Profile for Feasibility Demonstrations", which we are implementing here. We have some plans and prototypes migrating this communication to OPC UA. As I see from your ss output this would also solve your issue, am I right?