Error: java.io.IOException: Invalid argument (sendto failed)

A couple of days ago my system became very slow to respond and the log is filled repeatedly with the following:

2020-04-11 10:23:25.018 [ERROR] [.jupnp.transport.impl.DatagramIOImpl] -   Details: datagram.socketAddress=/239.255.255.250:1900, length=127, offfset=0, data.bytes=127

2020-04-11 10:23:25.043 [ERROR] [.jupnp.transport.impl.DatagramIOImpl] -   Details: socket=false, closed=true, bound=null, inetAddress=null, remoteSocketAddress=name:0.0.0.0, networkInterface=java.net.MulticastSocket@11c0650

2020-04-11 10:23:25.547 [ERROR] [.jupnp.transport.impl.DatagramIOImpl] - Exception sending datagram to: /239.255.255.250: java.io.IOException: Invalid argument (sendto failed)

java.io.IOException: Invalid argument (sendto failed)

	at java.net.PlainDatagramSocketImpl.send(Native Method) ~[?:1.8.0_222]

	at java.net.DatagramSocket.send(DatagramSocket.java:693) ~[?:1.8.0_222]

	at org.jupnp.transport.impl.DatagramIOImpl.send(DatagramIOImpl.java:156) [bundleFile:?]

	at org.jupnp.transport.impl.DatagramIOImpl.send(DatagramIOImpl.java:149) [bundleFile:?]

	at org.jupnp.transport.RouterImpl.send(RouterImpl.java:300) [bundleFile:?]

	at org.jupnp.protocol.async.SendingSearch.execute(SendingSearch.java:90) [bundleFile:?]

	at org.jupnp.protocol.SendingAsync.run(SendingAsync.java:52) [bundleFile:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]

	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]

This is on a RPi 3 running 2.51 release build.

I hadn’t made any changes prior to this occurring.

A restart didn’t do anything but that was difficult enough to do as access by SSH keeps crashing out.

Has anyone any ideas of what I could try or where to look?

Thanks!

Are you using an SD card with the RPI? I ask b/c the logs plus SSH crashing may be a failing card issue or power supply problem. Check the power supply and make sure it’s providing the correct voltage/amps.

If you have an extra SD card do a fresh install and restore your configuration, see if that helps.

Thank you for your reply.

I’m not using an SD card- I don’t have one fitted - the RPi boots straight from a SSD.
Power is ok and I’ve got back up too.

Have you tried stopping OH and cleaning the cache?

Yes, it made no difference.

Have you looked at other threads by searching “jupnp” ?

Yes. The problems other people appear to have experienced have been connected to specific bindings.
If mine is a binding problem, I cannot work out which one it is.

Start by uninstalling a single binding and see if the error goes away. Keep doing that until you identify what binding is causing the problem.

I’be been doing that. Already had complains that things aren’t working in the house!

I know what you mean, my family hates when I’m troubleshooting issues with home automation. :rofl:

Just reinstall the binding after you verify it’s not the problem.

So I went through and uninstalled every binding in turn but hey weren’t causing this problem.
I replaced the Power brick with a known good one with no change.

I have noticed that when pinging the Pi, it’s sending back a Request time out a few times - which explains why the SSH console is dropping out regularly.
I swapped the ethernet cable to and rebooted the router.

I also installed 2.5.3.

Not sure what else to try apart from a clean install which probably won’t fix it.

Obviously it’s something to do with PnP, and -

that’s a PnP associated multicast address.
I don’t know enough to say if this is openHAB advertising itself, or trying to respond to some external service it has seen.

I thought it was a binding in the end causing that particular error the LGwebOS one but after some time the error came back.

I now think that was a symptom and not the cause with the binding gone, I’ve still got a slow system with other errors coming in too. The common factor seems to be with bindings that communicate a lot over ethernet or with the USB port (I believe the ethernet port uses the same controller as the USB ports on a RPi).

I suppose I could prove or disprove whether the controller is a problem by running the Pi over wifi instead of ethernet.

It looks like this was the problem. I should have listened to you.

I did check the Pi input voltage which was 5.1V.

However, I had a USB power pack that had gone bad and which only delivered 3V with a mains blackout.
My wife managed to trip another circuit last week and although this Pi is on a completely different circuit, perhaps a power fluctuation in another circuit was enough to cause corruption.

It looks like the SSD is corrupt and non-fixable.

Thanks everyone for their help.

Glad you were able to find the problem. Please click the square box on the post that provided the solution to mark the topic as solved.

Thanks

There’s some message here about correlation not implying causation.

i.e. the backup supply was faulty but now I don’t believe it came into play.

I had a new RPi 4 and I thought that I’d put openHAB on that rather than the existing RPi 3.

So I installed openHABian and everything was OK.
Before installing my conf files from backup, I powered down and fixed the IP address to the static address I had used before and rebooted.
SSHing became unresponsive again and pings were not all returned. So this is my original fault.

This is before I installed any bindings and is basically out of the box so it must be something to do with that ip address and something writing to it, as rossko57 suggested in his post.
I can’t easily use another IP address as this address is set in many Arduinos.

Any ideas on how I can proceed? Thanks.

Switch off both Pi and ping that IP address … suspect duplicate

I’ve done that - no response.

I suppose I could unplug everything using wifi/ethernet and see whether the problem goes away.
Again not so easy as some devices are hardwired in to the mains but certainly possible.
I suspect it’s external as it started suddenly and I hadn’t made any recent hardware changes.

Something targeting that IP then. Sounds like lots of possibilities! Maybe your router allows some monitoring of traffic.

I ought to try a different static IP address too.