Log In
Register
Forum
Topic RSS
16:30, EEST
September 14, 2023
Offline
Hello,
I have two real time device, one working as pubblisher and one as subscriber using the UDP address opc.udp://239.0.0.1:4840, however when I try to connect with prosys Browser from my computer to the UDP address I do not see anything on the page (I checked with a client-server connection with one of the device and it’s working fine). I have already enabled the UDP in the Windows Defender Firewall and WireShark is actually able to see the UDP, so I do not know what to do anymore. The only thing that is strange is the fact that my computer is set on eth3 while Browser gives me the possibility to connect to eth2.
Thank you in advance for your support.
12:51, EEST
April 3, 2012
Offline
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.
17:26, EEST
September 14, 2023
Offline
Hi again,
Firstly, thank you for your help.
I made a matlab-simulink project with UDP connection and there it’s working (receiving data). The setup in Matlab is asking the number of the port (4840), to Enable the PortSharing and the IP of the Multicast (239.0.0.1, in my case) while in Browser with opc.udp://239.0.0.1:4840 it’s still not working.
I honestly have no idea to what I’m doing wrong.
9:55, EEST
April 3, 2012
Offline
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:
try {
for (NetworkInterface ni : Collections.list(NetworkInterface.getNetworkInterfaces())) {
if (ni.isUp()) {
networkInterfaces.add(new Pair(ni.getName(), ni));
}
}
}
..some error handing
(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.
9:58, EEST
September 14, 2023
Offline
Thank you for your explanation.
Yes, I tried to connect to eth3 manually but it didn’t work, however I found something interesting since my eth2 is set to a vpn, I connected to the vpn and Browser is calling it “eth3”, so apparently the port are up but just with name switched ( eth3 in my computer is eth2 in Browser and viceversa). Unfortunately I’m still not able to see anything from the multicast UDP address.
17:00, EEST
April 3, 2012
Offline
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.
Most Users Ever Online: 1919
Currently Online:
20 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 726
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1529
Posts: 6471
Newest Members:
gabriellabachus, Deakin, KTP25Zof, Wojciech Kubala, efrennowell431, wilfredostuart, caitlynfajardo, jeromechubb7, franciscagrimwad, adult_galleryModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1032, Jimmy Ni: 26, Matti Siponen: 349, Lusetti: 0
Administrators: admin: 1
