UDP Broadcast to 255 does not work. Pls help.

RouterOS General
1

I have a device, that conneted to Mikrotik by LAN and my PC connected by WiFi. I did a bridge LAN<->WLAN and setup DHCP.

PC send UDP request to 192.168.16.255:
192.168.16.107(PC) 192.168.16.255 UDP 48 60219 → 6500 Len=6

But there is no answer from my device! (This is my goal)

BUT if PC did a UDP request to 255.255.255.255 - everything work as expected:
192.168.16.107(PC) 255.255.255.255 UDP 48 64487 → 6500 Len=6
192.168.16.144(Device) 192.168.16.107 UDP 98 6500 → 64487 Len=56

Everything works with TPLINK, but I must setup Mikrotik. Please help. Thank you!


/interface bridge
add ageing-time=55m dhcp-snooping=yes igmp-snooping=yes multicast-querier=yes name=bridge1

/interface ethernet
set [ find default-name=ether1 ] mac-address=...

/interface wireless
set [ find default-name=wlan1 ] band=2ghz-onlyn channel-width=20/40mhz-XX ......
/ip pool
add name=dhcp_pool0 ranges=192.168.16.100-192.168.16.150

/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=bridge1 lease-time=23h10m name=dhcp1

/interface bridge port
add bridge=bridge1 interface=wlan1
add bridge=bridge1 interface=ether1

/ip address
add address=192.168.16.254/24 interface=bridge1 network=192.168.16.0

/ip dhcp-server config
set store-leases-disk=23h5m

/ip dhcp-server network
add address=192.168.16.0/24 dns-server=192.168.16.254 gateway=192.168.16.254

/ip dns
set allow-remote-requests=yes servers=192.168.16.254
2

Try setting multicast-helper=full on wlan1 interface. It says multicast, but works for broadcasts just the same.

3

Tried, but still does not work

4

Open a command line window on the Mikrotik, make it as wide as your screen allows, run /tool sniffer quick ip-address=192.168.16.255 in it and see whether, while you send the UDP from the PC, the “subnet broadcast” packets arrive via the WLAN interface and leave via any other interface. I’m afraid that if you send something to 255.255.255.255, the PC uses a broadcast MAC address of ff:ff:ff:ff:ff:ff as a destination, but if you send to subnet broadcast (192.168.16.255), it may not be the case. Given that ether1 and wlan1 are bridged together, and that there are no bridge rules in your configuration, there’s no reason why Mikrotik should block delivery of these packets from the “PC” to the “device”. So unless the sniff proves me wrong, I assume that either the PC doesn’t send them to a broadcast MAC address or the device ignores them.

5

Strange!
(my answer was typed before I saw the last one from Sindy. It’s the same answer but in other words)
What is the subnet mask of the PC? If subnet mask is not /24 , then the MAC address used will be wrong.
What is the MAC address used for 192.168.16.255?

6

Got this

7

I am using 255.255.255.0 for all wired and wireless clients. .255 - it is not real device, it is broadcast message that sent to all nodes (as I understand)

/ip address
add address=192.168.16.254/24 interface=bridge1 network=192.168.16.0

/ip dhcp-server network
add address=192.168.16.0/24 dns-server=192.168.16.254 gateway=192.168.16.254

For example my PC got this settings by DHCP from Mikrotik:

DHCP Enabled: Yes
IPv4 Address: 192.168.16.146
IPv4 Subnet Mask: 255.255.255.0
Lease Obtained: Sunday, December 5, 2021 16:44:39
Lease Expires: Monday, December 6, 2021 15:54:43
IPv4 Default Gateway: 192.168.16.254
IPv4 DHCP Server: 192.168.16.254
IPv4 DNS Server: 192.168.16.254

8

The 192.168.16.255 is indeed sent with the correct MAC address. (subnet broadcast)
The AP with bridged interfaces only reacts on the MAC address, not on the IP address. (Unless … “Use IP Firewall” is set in the bridge settings)

9

This option is disabled in bridge settings.

10

Sorry, I keep forgetting that sniffing behaves odd when hw is set to yes on an /interface bridge port row. So please do /interface bridge port set [find where bridge=bridge1] hw=no and repeat the sniffing test. As the packet did reach the bridge1 interface, it must have reached ether1 as well, but I want to see it confirmed.

The PC does it right (uses broadcast MAC as destination), so either the Mikrotik bridge fails or the device ignores the packet.

11

Yep, something wrong. But as I said with two other routers - it works well.

12

Nothing in the part of the configuration which you have shown before explains this, so it looks like a clear bug of the Mikrotik’s bridge. But there may be something in the part you haven’t shown, and/or one of the non-default settings (dhcp-snooping=yes, igmp-snooping=yes, multicast-querier=yes) may affect the behaviour. So I’d try to set these to no one by one to narrow the search before opening a ticket with Mikrotik. My favorite candidate is the dhcp-snooping=yes, as that is the only bridge setting which has to do with IP addresses as such.

13

Yeah, I tried to disable this options too, because it looks very logic, but did not help. So I think it is a bug (

14

Strange behavior.
Try installing the muticast package.

15

There are no multicast IP addresses or multicast MAC addresses involved, why should it help?

16

I did some tests, and now I’m stuck ((

I ran an UDP Monitor on the smartphone and connected it to the Mikrotik by LAN (like my device). Then I sent UDP requests from PC and it works well.

…
…
So, looks like DHCP works not correctly for my device or something else Or device receive request but does not answer for some reason. Do you have some ideas?

17

As your device answers to packets targeting address 255.255.255.255 but doesn’t answer to broadcasts sent to actual broadcast address 192.168.16.255 it seems like device actually uses subnet mask /0 (which, along with own IP address, defines broadcast address). Hence doesn’t recognise dst-adress as broadcast address and discards received packet (in IP stack, dst-MAC address doesn’t matter any more).

One way of checking if the above is true, would be to make connections to device from different subnet … if it’s indeed using wrong netmask, it won’t use gateway for return traffic, it’ll try to deliver packets directly. Which of course will fail, the only sign of device trying to answer would be “ARP who has” broadcasts sent by device asking for MAC address of device using foreign IP address.

18

My device has APIPA. So it can set ip automatically if connected device does not provide DHCP. But I see from DHCP leases that device get an IP from mikrotik DHCP. May be my DHCP server does not setup properly network mask for device and it stay 255.255.0.0? Or something else

19

It works even with request to 192.168.255.255, so mask is not /0. I think it is /16 instead of /24 that I setup in DHCP settings

20

Do you have any way of checking actual network settings on that device after it’s provisioned (by DHCP)?

I’d be very much surprised if Mikrotik’s DHCP server wouldn’t send out correct netmask, I never saw any such bug report on this forum.

Are you sure there isn’t another DHCP server which might serve your device with different subnet mask? I.e. are you absolutely sure that network consists only of 3 devices (MT AP, PC and the misbehaving gadget)? You can try to sniff the DHCP handshake when device connects to network to verify that DHCP handshake is accurate.