Hi,

Hmm … as far as I remember, wireshark happens before firewall, and this has bit me in the past, at least on linux. Though, if it is not the correct network interface, then the multicast wouldn’t be received. Basically we do show what Java internally gives us (via NetworkInterface.getNetworkInterfaces()). However, we only show the interfaces which are considered to be ‘up’. Is there any way the ‘eth3’ would not be ‘up’?

Could you try to use something else (than wireshark / Browser) to see does the data really arrive? On linux one could use ‘socat’, but not sure what on windows.

In the first post you said eth3 should be the interface, while we give eth2 as an option (I assume the list of interfaces didn’t contain ‘eth3’ when Browser asks what to chose; for others reading this later this happens because multicast addresses do not define interface, they work for each one of them, and thus it must be chosen what to use here). So once you select the eth2 the address string becomes ‘opc.udp://239.0.0.1:4840/eth2’. That is our custom format since we wanted a single string and basically there cannot be a “servername part” (that is in client-server sometimes) so we put the interface name there. Could you just try entering the address as ‘opc.udp://239.0.0.1:4840/eth3’ manually in the address string? Though, if that works then it is very interesting..

Anyway, since this is related to the Browser (i.e. you are not yourself directly using our SDK), I’m not sure to what lengths you are willing to test things. What internally happens is we run basically:

(some day we’ll make better code formatting options to this forum….)
and that is used to populate the UI. In general there can be a somewhat lot of non-UP intefaces, thus this has been a good filter, but you could maybe run this manually (you would need to setup a java development environment etc. if you do not have that already) and see if ‘eth3’ is not ‘up’.

If that doesn’t give a lead then I’m not sure what to try next.

P.S.
Our SDK does set java.net.StandardSocketOptions.SO_REUSEADDR (https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/net/StandardSocketOptions.html#SO_REUSEADDR) as true for multicast addresses, I believe this is the same as the ‘port sharing’ for your matlab thing, or should give similar effect.

Sorry, but it would seem I’m out of help options to give. Like we could fix it if we know what is wrong, but we do not know. There has been one case where UDP multicast didn’t go through a vpn due to it’s settings (unicast did work though), but since it seems you are able to receive this in matlab for the same interface this is probably not the case.