Bug : Latest updates from device not reflecting on remote nodes

[zeustd]

Bug Description:
With 2 nodes deployed and 1 device connected to Node X sending data at interval 10 seconds on (OSMand) protocol.
On Node Y The latest position data is not reflected on the web app.
Broadcast/Multicast is working and enabled on all interfaces.
Websocket is open on both Nodes

Node Y receives an empty array every minute

Steps to reproduce the behavior:

Connect Traccar Client to One Server
Check the Second Server web app for updates

Node X:

Node Y:

[tananaev]

Can you please try with this change (95ba344) to see if you actually receive broadcasts.

[zeustd]

Sure, will test and provide updates. Thank you very much

[zeustd]

Updated both Node X and Y with a new build.
Device connected to Node X, no broadcast log entry in Node Y.
Tried again with full-stack traces enabled no activity related to broadcast on the Node Y Log.

Additonal info : Screenshot of ifocnfig from "Node X"

[tananaev]

Are you sure multicast is working on your network? I tried it only locally so far and it worked fine. Maybe you can also try two local instances.

[zeustd]

I did some further digging. I am using Ubuntu 20,04 with 2 interfaces, eth0 is the public interface, and eth1 is the local interface for the private/local network.

Do you think Traccar will need to be aware of the interface to broadcast on?

Attached is a screenshot of the Broadcast with netcat from Node X and seeing the packet arrive on Node Y using tcpdump.

[tananaev]

I'm not too sure. I thought it should be able to figure it out. And listening should happen on all interfaces.

[zeustd]

My understanding is that applications need to be aware of the interface to listen and broadcast on if there are multiple network interfaces on the node.

Found a writeup on Multicast please refer to a section: "Interface selection" on the following link.
Multicast

[tananaev]

Hosts attached to more than one network should provide a way for applications to decide which network interface will be used to output the transmissions. If not specified, the kernel chooses a default one based on system administrator's configuration.

We don't specify it, so I guess OS will select the default.

[zeustd]

I will try to capture some TCP dump data to see if I am able to figure out what is happening when Traccar broadcasts.

[zeustd]

Update:

Traccar client connected to Node X send 3 location updates.
Node Y, TCP dump captured 3 packets that arrived.

So with that, it looks like Node X did broadcast and Node Y did receive, but the broadcast did not reflect on Node Y Traccar.

Screenshot of TCP dump on Node Y.

[tananaev]

Have you checked logs? Nothing there?

[zeustd]

Yes, Nothing in the logs related to broadcast, nor osmand.

[tananaev]

I guess receiving broadcast is not working for some reason. The code is pretty trivial though, so I'm not sure why it's not working:

https://github.com/traccar/traccar/blob/master/src/main/java/org/traccar/broadcast/MulticastBroadcastService.java#L156-L168

[zeustd]

Yes, it should work from what I can understand of the code.

Give me some time, I will try to make some changes in the receiving broadcast code and test to see if I can figure out something.

[zeustd]

After a few checks, something after line 157 felt odd, hardcoded a log entry there yet it did not capture it in the log.

So I commented the socket.joinGroup(address); out L157 and now the broadcast is working and being received on Node Y.

I do not know the exact reason behind this, but was hoping you may be able to shed some light on this.

traccar/src/main/java/org/traccar/broadcast/MulticastBroadcastService.java

Line 157 in 0112af2

socket.joinGroup(address);

[tananaev]

Without joinGroup you just have regular UDP communication. How did you pick the multicast address? I have a suspicion you have some conflict there.

[zeustd]

There was no other change in the build except for the joinGroup line being commented out. Not sure how it picked up the multicast address.

I compiled a new build with only 4 lines of addition as shown in the screenshot, and no other changes.

Please correct me, I may be totally wrong, What I notice is that after the joinGroup the code maybe is not getting executed.

[tananaev]

Yeah, seems like it gets stuck.

[zeustd]

Hello,

With the socket.joinGroup(address); it returned an error stating the address is not a multicast address.

Did some search and found this: https://stackoverflow.com/questions/33946043/java-net-socketexception-not-a-multicast-address

A multicast group is specified by a class D IP address and by a standard UDP port number. Class D IP addresses are in the range 224.0.0.0 to 239.255.255.255, inclusive. The address 224.0.0.0 is reserved and should not be used.

Ran the following command on ubuntu command line: ip maddr show found the multicast IP address for my network and configured that by adding the following line.

InetAddress multicastAddress = InetAddress.getByName("224.0.0.1");
socket.joinGroup(multicastAddress);

Tested it and received broadcast,

Do you think this is the correct cause and solution? the broadcast address is not the same as the multicast address.

[tananaev]

Broadcast and multicast are different. We use multicast. So does everything work now?

[zeustd]

I think I now get what went wrong, I configured the broadcast address instead of the multicast address in the config file. Although you had mentioned it in the forum to use the multicast address the config key confused me. Sorry about that.

Yes it works now.

To verify I re-built with the original code and only updated my config file the broadcast.address keys value to the multicast address and re-tested it, it is working now.

Thank you very much Anton for the support. I think we can close this issue.

[tananaev]

Thanks for testing it.

[tananaev]

Just FIY the code has been updated and you need to explicitly specify broadcast.interface now. Looks like without it multicast doesn't work in some cases.