LinuxNetworkInterface.GetLinuxNetworkInterfaces - An invalid IP address was specified

[bruinsg]

My application crashed due to an issue reported on github for the dotnet runtime. See: https://github.com/dotnet/runtime/issues/49515 Stacktrace: System.ArgumentException: An invalid IP address was specified. (Parameter 'address') at System.Net.IPAddress..ctor(ReadOnlySpan1 address) at System.Net.NetworkInformation.LinuxNetworkInterface.GetLinuxNetworkInterfaces() at Tmds.MDns.ServiceBrowser.CheckNetworkInterfaceStatuses(Dictionary2 interfaceHandlers) at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) --- End of stack trace from previous location --- at System.Net.NetworkInformation.NetworkChange.OnAvailabilityTimerFired(Object state) at System.Threading.TimerQueueTimer.Fire(Boolean isThreadPool) at System.Threading.TimerQueue.FireNextTimers()

[tmds]

@bruinsg It would be nice if we can find out why this is crashing.

Can you run your application with strace up until the point it crashes:

strace -e recvmsg,socket -s 2000 <app>

Can you share the recvmsg lines before the crash up until the socket(AF_NETLINK line.

[bruinsg]

@tmds This is not about data being received, it happens during in the NetworkAvailabilityHandler.

My application is an embedded device and during a major software update the kernel is being changed. At this point the NetworkAvailabiltyHandler starts receiving notifications every 1-2 seconds. The handler calls the NetworkInterface.GetAllNetworkInterfaces() which has an issue, https://github.com/dotnet/runtime/issues/49515, in it and can throw an exception. I can't handle the exception in my application as it inside the library.

In my opinion we can't fix this bug, we can only catch the exception. It is rare and very hard to reproduce as the full upgrade takes about 30 minutes and the exception has only been reported 3 times. (out of 100s of tests)

[tmds]

This is not about data being received, it happens during in the NetworkAvailabilityHandler.

I know. The strace isn't for network data, it's for the netlink socket.

It is rare and very hard to reproduce as the full upgrade takes about 30 minutes and the exception has only been reported 3 times. (out of 100s of tests)

Maybe you can try running a .NET app that calls NetworkInterface.GetAllNetworkInterfaces in a loop? It might reproduce a lot faster, and provide us the info we need to find the root cause.

[bruinsg]

@tmds I have been trying to reproduce this without much success. To be honest, I am not sure why we need to find the root cause for this as it is not an issue with the Mdns library but a generic dotnet issue. My fix is merely a workaround of the https://github.com/dotnet/runtime/issues/49515 issue

[tmds]

Thank you for trying. I'll take a closer look at the PR.

My fix is merely a workaround of the https://github.com/dotnet/runtime/issues/49515 issue

If we were able to reproduce the issue we probably could have contributed a fix for it. That would have been nice since it's a an issue that causes random software crashes and is hard to reproduce. No one likes those.