UDP Broadcast to 255 does not work. Pls help.

sstyle · Sun Dec 05, 2021 11:59 am

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

mkx · Sun Dec 05, 2021 12:13 pm

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

sstyle · Sun Dec 05, 2021 1:13 pm

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

Tried, but still does not work

sindy · Sun Dec 05, 2021 3:16 pm

Tried, but still does not work

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.

bpwl · Sun Dec 05, 2021 3:34 pm

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?

sstyle · Sun Dec 05, 2021 3:39 pm

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.

Got this

sstyle · Sun Dec 05, 2021 3:44 pm

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?

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

bpwl · Sun Dec 05, 2021 3:50 pm

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)

sstyle · Sun Dec 05, 2021 4:01 pm

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)

This option is disabled in bridge settings.

sindy · Sun Dec 05, 2021 4:20 pm

Got this:

wlan2                                    41.035     11 <-  3C:22:FB:A1:95:36 FF:FF:FF:FF:FF:FF        192.168.16.146:49742                192.168.16.255:6811                 ip:udp       48   0 no 
bridge1                                  41.035     12 <-  3C:22:FB:A1:95:36 FF:FF:FF:FF:FF:FF        192.168.16.146:49742                192.168.16.255:6811                 ip:udp       48   0 no 
wlan2                                    42.102     13 <-  3C:22:FB:A1:95:36 FF:FF:FF:FF:FF:FF        192.168.16.146:49742                192.168.16.255:6811                 ip:udp       48   0 no 
bridge1                                  42.102     14 <-  3C:22:FB:A1:95:36 FF:FF:FF:FF:FF:FF        192.168.16.146:49742                192.168.16.255:6811                 
...

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.

sstyle · Sun Dec 05, 2021 4:53 pm

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

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

sindy · Sun Dec 05, 2021 5:09 pm

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

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.

sstyle · Sun Dec 05, 2021 5:26 pm

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

sutrus · Sun Dec 05, 2021 5:51 pm

Strange behavior.
Try installing the muticast package.

sindy · Sun Dec 05, 2021 5:53 pm

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

sstyle · Sun Dec 05, 2021 8:04 pm

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?

mkx · Sun Dec 05, 2021 8:54 pm

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.

sstyle · Sun Dec 05, 2021 9:03 pm

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

sstyle · Sun Dec 05, 2021 9:04 pm

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

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

mkx · Sun Dec 05, 2021 9:09 pm

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.

sstyle · Sun Dec 05, 2021 10:08 pm

Unfortunately I have no way to check network settings of this device (

Mikrotik connected directly, so there is no other DHCP (except APIPA)

I do not know how to check handshake of DHCP (

bpwl · Mon Dec 06, 2021 12:13 am

Mikrotik debug log for DHCP will tell more (/system logging add topics=dhcp,debug) .... or something like that

Otherwise use Tools Sniffer to see packets. They are quite readable even without copying to Wireshark

sstyle · Mon Dec 06, 2021 2:19 pm

Did some tests today. I think that there are two ways to make it work:
1) Fix situation when I send the UDP request to 19.168.16.255 and device does not answer me for some reason
2) Forward broadcast from 192.198.16.255 -> 255.255.255.255 (may be NAT could help?)

Also FYI - there is 3 devices that connect to the router at same time. Two of them got netmask, one - did not.

====
1st test case. Another brand router:
I sent request to 192.198.16.255 AND 255.255.255.255. And got TWO answers:
.....
.....
.....
2nd test case. Mikrotik:
I sent request to 192.198.16.255 AND 255.255.255.255. And got only ONE answer:
...
...
...
So 255.255.255.255 working.

What I got from DHCP log:

Jan/01/2002 01:00:15 dhcp,debug dhcp1 received request id 353977549 from 0.0.0.0 ''
Jan/01/2002 01:00:15 dhcp,debug,packet flags = broadcast
Jan/01/2002 01:00:15 dhcp,debug,packet ciaddr = 0.0.0.0
Jan/01/2002 01:00:15 dhcp,debug,packet chaddr = D8:18:2B:9C:5B:47
Jan/01/2002 01:00:15 dhcp,debug,packet Msg-Type = request
.....
Jan/01/2002 01:00:15 dhcp,debug dhcp1 sending ack with id 353977549 to 255.255.255.255
Jan/01/2002 01:00:15 dhcp,debug,packet flags = broadcast
Jan/01/2002 01:00:15 dhcp,debug,packet ciaddr = 0.0.0.0
Jan/01/2002 01:00:15 dhcp,debug,packet yiaddr = 192.168.16.131
Jan/01/2002 01:00:15 dhcp,debug,packet siaddr = 192.168.16.254
Jan/01/2002 01:00:15 dhcp,debug,packet chaddr = D8:18:2B:9C:5B:47
Jan/01/2002 01:00:15 dhcp,debug,packet Msg-Type = ack
Jan/01/2002 01:00:15 dhcp,debug,packet Server-Id = 192.168.16.254
Jan/01/2002 01:00:15 dhcp,debug,packet Address-Time = 83400
Jan/01/2002 01:00:15 dhcp,debug,packet Router = 192.168.16.254
===>> NO Subnet-Mask record <<=====

bpwl · Mon Dec 06, 2021 3:46 pm

Klembord-2.jpg

.
But config looks OK in config posted.
.

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

.
Recreate "network" in dhcp server ????????????????????? Or even the whole DHCP server via "Setup". Looks like somewhat corrupted internally????????
I have no better guess.
.

Networks
Sub-menu: /ip dhcp-server network


Property	Description
address (IP/netmask; Default: )	the network DHCP server(s) will lease addresses from
boot-file-name (string; Default: )	Boot file name
caps-manager (string; Default: )	Comma-separated list of IP addresses for one or more CAPsMAN system managers. DHCP Option 138 (capwap) will be used.
dhcp-option (string; Default: )	Add additional DHCP options from option list.
dhcp-option-set (string; Default: )	Add additional set of DHCP options.
dns-none (yes | no; Default: no)	If set, then DHCP Server will not pass dynamic DNS servers configured on the router to the DHCP clients if no DNS Server in dns-server is set. By default if there are no DNS Servers configured, then the dynamic DNS Servers will be passed to DHCP clients.
dns-server (string; Default: )	the DHCP client will use these as the default DNS servers. Two comma-separated DNS servers can be specified to be used by the DHCP client as primary and secondary DNS servers
domain (string; Default: )	The DHCP client will use this as the 'DNS domain' setting for the network adapter.
gateway (IP; Default: 0.0.0.0)	The default gateway to be used by DHCP Client.
netmask (integer: 0..32; Default: 0)	The actual network mask to be used by DHCP client. If set to '0' - netmask from network address will be used.
next-server (IP; Default: )	IP address of next server to use in bootstrap.

sstyle · Mon Dec 06, 2021 3:51 pm

Tried. PC and smartphone and 2/3 devices got network mask correctly. I think my goal is forward UDP request from 192.168.16.255 to 255.255.255.255 may be ARP and DNAT could help with it?

bpwl · Mon Dec 06, 2021 6:00 pm

What is unexplained, is why this 1/3 device is not informed about the subnetmask. What is different? Subnet mask in device , something in the "discover" , the first step in the D-O-R-A handshake? (discover-offer-request-ack)
Is this device in the lease table? As static entry? Seems not, "not found", "arp added"
Well only the last 2 steps are seen of DORA : request & ack. Is this just an out-of-sequence renewal ? (I have no idea how renewal looks like, but found * : "To attempt a lease renewal, the DHCP client sends a DHCPREQUEST packet directly to the DHCP server from which the client obtained the lease.". The DHCP-server reset/reboot could clear the lease table but the client while holding the info still only renews. The client should still have the valid netmask while renewing. No? Just guessing!!!
What then if another AP with the same SSID and same DHCP server address, has sent out a different network mask?

I understand you want to "fix it" with DNAT. But that would probably not be made specidic for the 1/3 device, as the destination will be a broadcast address.

* : https://www.serverbrain.org/network-ser ... rks-1.html

sstyle · Mon Dec 06, 2021 8:01 pm

I know WHY!

1st device sent request to DHCP and he asked only for Router!:

Jan/01/2002 01:01:02 dhcp,debug dhcp1 received request id 353977549 from 0.0.0.0 ''
Jan/01/2002 01:01:02 dhcp,debug,packet flags = broadcast
Jan/01/2002 01:01:02 dhcp,debug,packet ciaddr = 0.0.0.0
Jan/01/2002 01:01:02 dhcp,debug,packet chaddr = D8:18:2B:9C:5B:47
Jan/01/2002 01:01:02 dhcp,debug,packet Msg-Type = request
Jan/01/2002 01:01:02 dhcp,debug,packet Host-Name = "DEVICE9C5B47"
Jan/01/2002 01:01:02 dhcp,debug,packet Parameter-List = Router
Jan/01/2002 01:01:02 dhcp,debug,packet Address-Request = 192.168.16.131

....
....
For example my smartphone asked much more:

Parameter-List = Subnet-Mask,Router,Domain-Server,Domain-Name,Interface-MTU,Broadcast-Address,Address-Time,Renewal-Time,Rebinding-Time,Vendor-Specific,Captive-Portal,Unknown(108)

.....
.....
and two other devices asked for more parameters too:

Jan/01/2002 01:01:02 dhcp,debug dhcp1 received discover id 64235312 from 0.0.0.0 '1:0:1c:d7:af:6b:42'
Jan/01/2002 01:01:02 dhcp,debug,packet secs = 4
Jan/01/2002 01:01:02 dhcp,debug,packet flags = broadcast
Jan/01/2002 01:01:02 dhcp,debug,packet ciaddr = 0.0.0.0
Jan/01/2002 01:01:02 dhcp,debug,packet chaddr = 00:1C:D7:AF:6B:42
Jan/01/2002 01:01:02 dhcp,debug,packet Msg-Type = discover
Jan/01/2002 01:01:02 dhcp,debug,packet Client-Id = 01-00-1C-D7-AF-6B-42
Jan/01/2002 01:01:02 dhcp,debug,packet Host-Name = "DEVICEAF6B42"
Jan/01/2002 01:01:02 dhcp,debug,packet Parameter-List = Subnet-Mask,Domain-Server,Host-Name,Domain-Name,Router,Broadcast-Address

Jan/01/2002 01:01:02 dhcp,debug dhcp1 received discover id 3026077200 from 0.0.0.0 '1:74:e1:82:50:4a:c6'
Jan/01/2002 01:01:02 dhcp,debug,packet secs = 4
Jan/01/2002 01:01:02 dhcp,debug,packet flags = broadcast
Jan/01/2002 01:01:02 dhcp,debug,packet ciaddr = 0.0.0.0
Jan/01/2002 01:01:02 dhcp,debug,packet chaddr = 74:E1:82:50:4A:C6
Jan/01/2002 01:01:02 dhcp,debug,packet Msg-Type = discover
Jan/01/2002 01:01:02 dhcp,debug,packet Client-Id = 01-74-E1-82-50-4A-C6
Jan/01/2002 01:01:02 dhcp,debug,packet Host-Name = "DEVICE504AC6"
Jan/01/2002 01:01:02 dhcp,debug,packet Parameter-List = Subnet-Mask,Domain-Server,Host-Name,Domain-Name,Router,Broadcast-Address

....
....

Is this device in the lease table? As static entry? Seems not, "not found", "arp added"

Yes. All 3 devices is in DHCP leases table and ARP, but not static

....
....

I understand you want to "fix it" with DNAT. But that would probably not be made specidic for the 1/3 device, as the destination will be a broadcast address.

I think there is no issue if it will work for all devices

mkx · Mon Dec 06, 2021 9:02 pm

I know WHY!

1st device sent request to DHCP and he asked only for Router!:

That's the cause. Odd (although technically correct) behaviour of MT DHCP server is that it only returns options asked for. Other DHCP server implementations tend to include all standard options in offer and many DHCP clients tend to accept them.

One of solutions would be to add to LAN another device running a better DHCP server. Not sure if you want to go that way though.

bpwl · Mon Dec 06, 2021 9:44 pm

Txs for the eye opener. Learned again something new today.

Also: viewtopic.php?t=92799

sstyle · Mon Dec 06, 2021 9:53 pm

That's the cause. Odd (although technically correct) behaviour of MT DHCP server is that it only returns options asked for. Other DHCP server implementations tend to include all standard options in offer and many DHCP clients tend to accept them.

One of solutions would be to add to LAN another device running a better DHCP server. Not sure if you want to go that way though.

I have no option to change router (

So, I wrote about workaround with forwarding broadcast request from 192.168.16.255 to 255.255.255.255 . Is it possible? I think yes and this workaround will solve my task

mkx · Mon Dec 06, 2021 10:43 pm

So, I wrote about workaround with forwarding broadcast request from 192.168.16.255 to 255.255.255.255 . Is it possible? I think yes and this workaround will solve my task

I never tried DST-NAT to broadcast address, but it might work. Since technically this is intra-network traffic, you'll have to set use-ip-firewall=yes under /interface bridge settings and make sure packets pass the bridge (i.e. between bridge port members) and avoid any HW offload (set hw=no on all bridge member ports).

UDP Broadcast to 255 does not work. Pls help.

UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Re: UDP Broadcast to 255 does not work. Pls help.

Who is online