UDP from wireless through wired

[Samwel]

I have the RT-AX82U with firmware 3.0.04.386_43129.

My issue is not directly with this firmware, I think.
I have a home theater prepro that’s connected by wire to my network.
In the Ipad I have a control app. It has a automatic discovery function.
The prepro can’t be found though.
Both the Ipad and the prepro have internet. Have no issues with other
communication or apps.

I have been in contact with the app author.
He says the app sends a UDP broadcast on port 7000 waits 1.5sec for the
answer. The prepro is programmed to respond to this. My router however
blocks this somehow.
The thing is I have another device connected to the network which also
talks to the prepro with UDP the same way, this works fine. The difference
being this is UDP over wired only network.
The app author thinks my router blocks/limits UDP broadcasts from wireless
to wired.
The thing is the app works fine for others with different brands of routers.
I have not checked if any other have ASUS routers that get this working.

Is this a known issue with ASUS routers? Can it be fixed with settings?
I have no other issue with router. Mostly set to default in settings.
I manage IPs for all my devices with the DHCP server though.

 

[Samwel]

Anyone?

 

[mohsha]

Can you try over wired network for pairing only?

 

[Samwel]

No not really.. The app is for Android and iOS/iPadOS only.
I have no way of connecting any of these by wire.

Although the author has put the same UDP calling code inside
a hardware box I have connected by wire. This finds the prepro
just fine.

 

[ColinTaylor]

What WiFi band are you connecting to? Are you using a guest WiFi SSID or the primary SSID?

 

[Samwel]

I’m using my main 5G network. Tried my 2.4G as well the same result.

However I do have a guest network set up. But it’s not available to communicate
with other devices on my network. So can’t use it for this..

 

[Samwel]

The thing is.. My (5 week old) AX82U broke from a lightning strike this week. I decided to buy a better router which also supports Merlin.. RT-AX86U!
Installed it and updated to the latest Merlin release 386_2.6.
Still locked from recieving UDP broadcast wireless from my Ipad to the prepro which is connected through wire.

Is there a way I can see why the router rejects the broadcast or if it even recieves it from the ipad in the first place?

 

[raven-au]

I wonder if "Enable IGMP Snooping" will make a difference, if it isn't already enabled of course.

 

[bbunge]

What app are you using?
In the app setup is there a place to insert the remote device IP address? If it uses the remote device name try the IP address.

 

[Samwel]

IGMP Snooping on or off makes no difference.

The app (Emotiva remote 3.0) only have automatic discovery through
UDP broadcast to port 7000.

 

[raven-au]

IGMP Snooping on or off makes no difference.

The app (Emotiva remote 3.0) only have automatic discovery through
UDP broadcast to port 7000.

Broadcast to what address?

AFAICT multicast address are forwarded, you should see a route in the routing table for them.
Essentially 239.0.0.0/255.0.0.0 via br0, and br0 should include all the local interfaces including the wireless interfaces.

If it's a straight network broadcast it should be forwarded, if not that might be a bug.

That assumes the sender and receivers are on the same network (ie. same subnet not just same physical network).

You should be able to find out what addressing is used by getting a packet capture.
If they aren't being forwarded then you would need to do the capture on the device generating the broadcasts.

 

[Samwel]

To a local device (Emotiva RMC-1) on 192.168.1.12 connected by wire.
My Ipad is on 192.168.1.38 connected through 5G wireless.
My router is 192.168.1.1, subnet 255.255.255.0..
All devices on the same subnet, I even have my Ipad set to manual IP settings.
Although, have tried to change to automatic without any change.

It’s a straight UDP broadcast, the app developer explained to me that the chip
in RMC-1 didn’t support multicast at all. That’s the reason he used UDP broadcast.

Do you have a recommended way for doing the packet capture?
For Ipad and ASUS both..

 

[ColinTaylor]

As you have installed Merlin's firmware you can also install Entware on an attached USB drive (using amtm) and then tcpdump.

# tcpdump -i br0 -n udp and broadcast
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:18:41.268364 IP 192.168.1.87.137 > 192.168.1.255.137: UDP, length 50
19:18:42.018706 IP 192.168.1.87.137 > 192.168.1.255.137: UDP, length 50
19:19:12.019539 IP 192.168.1.1.9999 > 255.255.255.255.9999: UDP, length 512
19:19:13.520532 IP 192.168.1.1.9999 > 255.255.255.255.9999: UDP, length 512
19:19:15.021208 IP 192.168.1.1.9999 > 255.255.255.255.9999: UDP, length 512
19:19:19.008978 IP 192.168.1.1.53632 > 192.168.1.255.7788: UDP, length 60
19:19:41.033453 IP 192.168.1.49.138 > 192.168.1.255.138: UDP, length 201
19:20:11.050551 IP 192.168.1.1.137 > 192.168.1.255.137: UDP, length 50
19:20:12.063425 IP 192.168.1.116.137 > 192.168.1.255.137: UDP, length 50
19:20:12.828779 IP 192.168.1.116.137 > 192.168.1.255.137: UDP, length 50
19:20:13.594191 IP 192.168.1.116.137 > 192.168.1.255.137: UDP, length 50
19:20:14.945965 IP 192.168.1.116.138 > 192.168.1.255.138: UDP, length 201
19:20:19.109834 IP 192.168.1.1.39872 > 192.168.1.255.7788: UDP, length 60
19:20:26.824373 IP 192.168.1.87.137 > 192.168.1.255.137: UDP, length 50
19:20:27.573794 IP 192.168.1.87.137 > 192.168.1.255.137: UDP, length 50

 

[raven-au]

You should be able to find out what addressing is used by getting a packet capture.
If they aren't being forwarded then you would need to do the capture on the device generating the broadcasts.

Or a tcpdump on the router wireless interface the broadcasts are being sent to.
And, once you work out what the broadcast looks like, compare with what your seeing on br0 to prove they aren't being forwarded.
You could log a bug report to ASUS with that information.

There might be a kernel parameter you can check and perhaps set, not sure, but you should really confirm the broadcast isn't being forwarded before going down that path.