DOTNET with new firmware

I have a custom application using dotnet with both EPIC and RIO devices. After upgrading firmware and testing, dotnet gives warnings about needing a version number for libstdc++. The library is installed and I am assuming that the new firmware may have later versions of the library in the linux distribution. The application appears to run OK except it is tripping up on opening a TCP connection for listening on a port not otherwised used. It appeared to be working fine on the previous firmware.

Is anyone else seeing issues with new firmware and dotnet? I should mention that the optmmp library I have is working fine, all of the device I/O functions work. I am having difficult with the TCP connection which is used to cumminicate to an external system.

(I am using dotnet 3.1 LTS)

See the following messages.

$ ./dotnet --info
./dotnet: /usr/lib/libstdc++.so.6: no version information available (required by ./dotnet)
./dotnet: /usr/lib/libstdc++.so.6: no version information available (required by ./dotnet)
./dotnet: /usr/lib/libstdc++.so.6: no version information available (required by ./dotnet)
./dotnet: /usr/lib/libstdc++.so.6: no version information available (required by ./dotnet)
.NET Core SDK (reflecting any global.json):
Version: 3.1.421
Commit: 42eb11123f

Runtime Environment:
OS Name: Linux
OS Version:
OS Platform: Linux
RID: linux-arm
Base Path: /home/admin1/dotnet/sdk/3.1.421/

Host (useful for support):
Version: 3.1.27
Commit: 2d4bb962fd

.NET Core SDKs installed:
3.1.421 [/home/admin1/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.App 3.1.27 [/home/admin1/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.27 [/home/admin1/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
.NET Downloads (Linux, macOS, and Windows)

dotnet stuff is a bit tricky for us to test here as its not something we use very often.

I did a little bit digging with your extra info in this last post… Best as I can see from the engineering docs we did not change the version of the libstdc++.so.6 with this firmware update.

I also did some Google foo on the ‘no version…’ and it seems to be a notice of a version miss match and not a critical issue.
One page I read suggested that you rename /usr/lib/libstdc++.so.6 to be /usr/lib/libstdc++.so.6.old As I said, I cant test it here, but feel its worth a mention.

Regarding the TCP connection that used to work, but now does not, I am not sure. There were no changes to the firewall or networking in this update. Just the addition of the dataservices for the most part.

Sorry we cant help much more without getting acquainted with your dotnet app.

Thanks Beno, I realize support is limited for this.

It is difficult to determine if the issue I am having is a dotnet issue, problem in my code, or a firmware issue One of the things I am doing is setting up a simple TcpListener and a separate sender and see if it will talk. It acts like the ports are blocked even though I have a firewall rule setup and it worked before OK

Of course I will post here as I go.

Thanks

Sanity check (mine - not yours!)

You say the firewall rule is setup… Can you share a screenshot or just the exact rule?
What EPIC Eth port are you coming in on, 0 or 1?
UDP or TCP transmission?
Are you using a port above port 1024?

I think the connection issue is on my side. Still testing. I have the firewall set at a port number in the 50000 range for the non vpn port, TCP/UDP. Using TCP. I am pretty sure the “./dotnet: /usr/lib/libstdc++.so.6: no version information available (required by ./dotnet)” message is harmless as all else works. I am away from the remote location at the moment so will post back here when I confirm my hunch.

Beno, I am curious, have you tried opening the optommp interface using the loopback IP, 127.0.0.1?. I am teleworking today, so don’t have eyes on it here today but this idea popped into my mind of possibly setting up the ETH0 on an IP address needed externally and do the IO on the loopback, aka localhost.

I will also try to use the lun port and do a port redirect. Otherwise, still stuck in a conflict.

Update: Using the loopback interface (127.0.0.1) for the optommp server works great.

After some tedious debugging I learned some useful things. The legacy application we have ported to Epic/RIO uses raw TCP sockets. It originally ran on windows based industrial PCs.

The whole basis of using the RIO/EPIC is to migrate this off of windows, which in my humble opinion is unsuitable for this application. The EPIC/RIO allows us to simplify the hardware design by eliminating a windows based component, saving power and space.

What we discovered is that by default dotnet sets socket defaults to blocking I/O whereas Linux based systems use non-blocking. I wrote a small test program using the dotnet TCPListener class and it apparently does the right thing and it works as far as listening/sending TCP messages on the EPIC/RIO.

The lesson here is that in spite of what people may think, dotnet is not 100% portable across platforms. In this case a rather subtle bug where a background thread was happily waiting and doing nothing, blocked inside itself and hung itself. To give some credit where due. The dotnet world is working flawlessly for all other aspects of this application without changing thousands of lines of code.

I still have some work to convert this to a working implementation and will update further when I get there.

1 Like

Thanks a heap for reporting back.
Very interesting and I guess it makes a bit of sense. The Windows TCP stack is nothing like the Linux TCP stack.
That said, you would think dotnet would know (roughly) what stack its running on and make some internal adjustments, but it would seem not.

Very valuable debugging and again, I really appreciate you dropping back and letting everyone know. Going to save someone a whole bunch of time at some point in the future!