hello friends
I have a network that I will send you a photo of.
The network is a university that has no problem with 2 buildings.
In one of the buildings, even though the settings are similar to other buildings, in my access points, which are all Mikrotik, it receives IP very slowly or not at all.
All my access points are just bridges, and I have a default route to the default gateway
Can anyone help with this?
My phones and other devices can't connect due to ip delay
I checked many things
I don't have a loop in the network, or dhcp does not interfere with others in the network, there is nothing special about the access point settings, it is just bridged and a name has been given to the Wi-Fis.
All access points were updated to the latest version.
It randomly gives an access point IP, sometimes it doesn't.
Even for example, a 2.4GHZ access point is connected and the 5GHZ one is not connected or vice versa.
This problem is not solved by changing the frequency and channel.
Even the bridge itself on the access point cannot get an IP from dhcp or it takes too long.
can you help ؟
I will also send the Wireshark image
-
-
goudarzi1810
just joined
- Posts: 6
- Joined:
external dhcp delay on cap ac
You do not have the required permissions to view the files attached to this post.
Re: external dhcp delay on cap ac
If you are in charge of Univerisity IT, this is not the place to get your paid work done.
a. take the proper MT courses
b. if an emergency --> https://mikrotik.com/consultants
a. take the proper MT courses
b. if an emergency --> https://mikrotik.com/consultants
Re: external dhcp delay on cap ac
But is the issue generated by the DHCP server or by the last element in the chain (the Mikrotik Ap's) or somewhere in between?
Which device acts as DHCP server?
I would try connecting to one of its ports a dumb switch and see if a device attached to this dumb switch gets an IP and does so in a timely fashion.
Then try at next device in the topology.
Which device acts as DHCP server?
I would try connecting to one of its ports a dumb switch and see if a device attached to this dumb switch gets an IP and does so in a timely fashion.
Then try at next device in the topology.
-
-
goudarzi1810
just joined
- Posts: 6
- Joined:
Re: external dhcp delay on cap ac
IP of my devices is done by CCR and not by CAP ACs themselves.
Does anyone have information about why the DHCP OFFER packet is the source instead of the MAC ADDRESS.
dst: dhcp broadcast is set, in fact, the dhcp steps are not done correctly
In the second step, dhcp offer must be sent unicast ؟
Does anyone have information about why the DHCP OFFER packet is the source instead of the MAC ADDRESS.
dst: dhcp broadcast is set, in fact, the dhcp steps are not done correctly
In the second step, dhcp offer must be sent unicast ؟
Re: external dhcp delay on cap ac
Can you share a config from one cAP? Just to be sure...
Anything in between the CCR and the cAP that could cause this problem?
Anything in between the CCR and the cAP that could cause this problem?
-
-
goudarzi1810
just joined
- Posts: 6
- Joined:
Re: external dhcp delay on cap ac
export
Code: Select all
# 1970-01-07 00:31:53 by RouterOS 7.16.2
# software id = 9NKS-CKZK
#
# model = RBcAPGi-5acD2nD
# serial number = edited
/interface bridge
add comment=defconf dhcp-snooping=yes name=bridge port-cost-mode=short \
priority=0x4000
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX \
disabled=no distance=indoors frequency=2432 installation=indoor mode=\
ap-bridge ssid=B6-F1-1 wireless-protocol=802.11 wps-mode=disabled
set [ find default-name=wlan2 ] band=5ghz-onlyn channel-width=20/40mhz-XX \
disabled=no distance=indoors installation=indoor mode=ap-bridge ssid=\
B6-F1-1-5G wireless-protocol=802.11 wps-mode=disabled
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4 use-network-apn=no
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=default-dhcp ranges=192.168.88.10-192.168.88.254
/caps-man manager
set ca-certificate=auto certificate=auto enabled=yes
/interface bridge port
add bridge=bridge comment=defconf ingress-filtering=no interface=ether2 \
internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf ingress-filtering=no interface=wlan1 \
internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf ingress-filtering=no interface=wlan2 \
internal-path-cost=10 path-cost=10
add bridge=bridge ingress-filtering=no interface=ether1 internal-path-cost=10 \
path-cost=10 trusted=yes
/ip firewall connection tracking
set udp-timeout=10s
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ip settings
set max-neighbor-entries=8192
/ipv6 settings
set disable-ipv6=yes max-neighbor-entries=8192
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface ovpn-server server
set auth=sha1,md5
/ip address
add address=172.18.224.5/22 comment=defconf interface=bridge network=\
172.18.224.0
add address=172.18.224.5/22 interface=ether1 network=172.18.224.0
/ip dhcp-client
add comment=defconf disabled=yes interface=bridge
/ip dns
set allow-remote-requests=yes
/ip dns static
add address=172.18.224.5 comment=defconf name=router.lan type=A
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=\
invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" \
connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=\
out,none out-interface-list=WAN
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=172.18.224.1
/routing bfd configuration
add disabled=yes interfaces=all min-rx=200ms min-tx=200ms multiplier=5
/system identity
set name=B6-F1-1
/system note
set show-at-login=no
/system routerboard mode-button
set enabled=yes on-event=dark-mode
/system script
add comment=defconf dont-require-permissions=no name=dark-mode owner=*sys \
policy=ftp,reboot,read,write,policy,test,password,sniff,sensitive,romon \
source="\r\
\n :if ([system leds settings get all-leds-off] = \"never\") do={\r\
\n /system leds settings set all-leds-off=immediate \r\
\n } else={\r\
\n /system leds settings set all-leds-off=never \r\
\n }\r\
\n "
/tool mac-server
set allowed-interface-list=LAN
/tool mac-server mac-winbox
set allowed-interface-list=LAN
/tool traffic-monitor
add disabled=yes interface=wlan1 name=tmon1
[admin@B6-F1-1] >
Last edited by BartoszP on Tue Jan 21, 2025 9:21 am, edited 1 time in total.
Reason: removed serials - please do not share, use code tag < / > for code
Reason: removed serials - please do not share, use code tag < / > for code
Re: external dhcp delay on cap ac
If you want the accesspoints to be bridges, why are they configured as router?
Re: external dhcp delay on cap ac
I am perplexed 
(but what do I know?)
Both ether1 (classified as WAN) and bridge (classified as LAN) have the same static IP address of 172.18.224.5/22, AND ether1 is member of bridge, AND it is the only flagged trusted interface, AND dhcp snooping is on, AND there is a static route with gateway.
It seems to me like a confused setup.
Normally an access point is a bridge between the wifi and wired interfaces (i.e. all interfaces are in the bridge, minus - maybe - an ethernet port kept separate for emergency management access).
There are no static routes and no firewall filter rules, nor nat.
Strictly speaking there is even no need for assigning an IP to the bridge, if management is done through Winbox via MAC.
And - if you have more than 2 or 3 Ap's, usually capsman is used to centrally manage the whole stuff (but this implies - at least initially - an added layer of complexity).
Having the device not time synchronized (for whatever reason) is not (IMHO) a very good idea:
There are other things that look "strange" (to me), but they should not be related/important.
(but what do I know?)Both ether1 (classified as WAN) and bridge (classified as LAN) have the same static IP address of 172.18.224.5/22, AND ether1 is member of bridge, AND it is the only flagged trusted interface, AND dhcp snooping is on, AND there is a static route with gateway.
It seems to me like a confused setup.
Normally an access point is a bridge between the wifi and wired interfaces (i.e. all interfaces are in the bridge, minus - maybe - an ethernet port kept separate for emergency management access).
There are no static routes and no firewall filter rules, nor nat.
Strictly speaking there is even no need for assigning an IP to the bridge, if management is done through Winbox via MAC.
And - if you have more than 2 or 3 Ap's, usually capsman is used to centrally manage the whole stuff (but this implies - at least initially - an added layer of complexity).
Having the device not time synchronized (for whatever reason) is not (IMHO) a very good idea:
as it will make reviewing logs - to say the least - particularly complex.# 1970-01-07 00:31:53
There are other things that look "strange" (to me), but they should not be related/important.
Re: external dhcp delay on cap ac
So you agree, that if an IT person for a university is going to use MT product, he should
a. actually take some MT courses., or
b. get consulting assistance.
( havent even touched upon security as a component of using MT devices)
a. actually take some MT courses., or
b. get consulting assistance.
( havent even touched upon security as a component of using MT devices)
Re: external dhcp delay on cap ac
You talkin' to me?So you agree, that if an IT person for a university is going to use MT product ...
I don't know/cannot say, I am non-IT and non-university, and just a beginner level user of MT products, I am only commenting on what I see (and on the little I can understand of it) of the posted configuration, which is very different form the other "typical" configurations posted on the forum.
-
-
goudarzi1810
just joined
- Posts: 6
- Joined:
Re: external dhcp delay on cap ac
dhcp snooping is set to receive dhcp packets only from the port that comes from the switch, and the other ports are not trusted. Also, give ip to the bridge interface to manage from It is remote and monitoring.
Also, I did not create rules in the firewall and they are created automatically
I just bridged the ports and gave an IP.
Also, I did not create rules in the firewall and they are created automatically
I just bridged the ports and gave an IP.
Re: external dhcp delay on cap ac
Only for the record:
Firewall rules are not created automatically.
They are present in the default configuration for so-called SOHO Mikrotik devices, that typically have:
1 ) all ports BUT ether1 in bridge
2 ) ether1 as WAN
3 ) bridge as LAN
4 ) default firewall filter rules
5 ) dhcp client on ether1
6 ) dhcp server on bridge (and addresses in the 192.168.88.x/24 range)
7 ) firewall nat on out-interface-list WAN
8 ) other settings. usually identifiable by the comment "defconf" or by their name containing "default"
9 ) all services enabled and particularly Winbox allowed on LAN [1]
10 ) no static routes (the route is dynamically created from connection/dhcp)
11 ) probably something else that I missed
What the experts here usually suggest is (when the intended use is different from AP/router) to completely remove the default configuration and only add the needed settings.
Your configuration is instead evidently the default one with a handful of changes.
I know that you asked a very specific question and not for comments on how wrong (or right) your configuration looks, so consider the above only a side-side note, having a cleaner configuration without unneeded remnants of the default one may help in finding the problems (if any) but it is not strictly needed.
[1] which BTW is (IMHO) pure folly in a public wifi
Firewall rules are not created automatically.
They are present in the default configuration for so-called SOHO Mikrotik devices, that typically have:
1 ) all ports BUT ether1 in bridge
2 ) ether1 as WAN
3 ) bridge as LAN
4 ) default firewall filter rules
5 ) dhcp client on ether1
6 ) dhcp server on bridge (and addresses in the 192.168.88.x/24 range)
7 ) firewall nat on out-interface-list WAN
8 ) other settings. usually identifiable by the comment "defconf" or by their name containing "default"
9 ) all services enabled and particularly Winbox allowed on LAN [1]
10 ) no static routes (the route is dynamically created from connection/dhcp)
11 ) probably something else that I missed
What the experts here usually suggest is (when the intended use is different from AP/router) to completely remove the default configuration and only add the needed settings.
Your configuration is instead evidently the default one with a handful of changes.
I know that you asked a very specific question and not for comments on how wrong (or right) your configuration looks, so consider the above only a side-side note, having a cleaner configuration without unneeded remnants of the default one may help in finding the problems (if any) but it is not strictly needed.
[1] which BTW is (IMHO) pure folly in a public wifi
Re: external dhcp delay on cap ac
Can you please add the config from a working cAP as well?
Is CAPsMAN (don't ask Anav about this option) considered in this environment?
Is CAPsMAN (don't ask Anav about this option) considered in this environment?
-
-
goudarzi1810
just joined
- Posts: 6
- Joined:
Re: external dhcp delay on cap ac
Yes, exactly, the access points were factory reset, and then when it came up, I deleted the extra settings.
For example, in the case of ip pool 192.168.88.0, it is true that it exists, but because the dhcp server has been deleted, it does not work and does not cause any problems.
But the point is that I am moving this access point to another building, there is no problem, the only thing is that I analyzed the dhcp package with Wireshark, and the difference between them is visible in the dhcp offer.
In the first one, the dhcp offer is sent as unicast and correctly, but in the second one, which has a problem, the dhcp offer is sent as broadcast, and I don't understand this!!
172.24.224.1 not ok
172.24.220.1 ok
For example, in the case of ip pool 192.168.88.0, it is true that it exists, but because the dhcp server has been deleted, it does not work and does not cause any problems.
But the point is that I am moving this access point to another building, there is no problem, the only thing is that I analyzed the dhcp package with Wireshark, and the difference between them is visible in the dhcp offer.
In the first one, the dhcp offer is sent as unicast and correctly, but in the second one, which has a problem, the dhcp offer is sent as broadcast, and I don't understand this!!
172.24.224.1 not ok
172.24.220.1 ok
You do not have the required permissions to view the files attached to this post.
Re: external dhcp delay on cap ac
So, you have a chain *like*:
Mikrotik CCR <- running centralized DHCP server
Cisco 2960 #1
Cisco 2960 #2
Mikrotik AP
If the same Mikrotik AP moved to another building (with a similar chain of devices) works, it must mean that *something* is different in another device, either the CCR settings/configuration or the two Cisco devices, since the CHR is the DHCP server, you should re-check it first.
Maybe (for whatever reason) the always-broadcast has been set to yes on that.
You may want to remove the related DHCP server entries and pool and re-enter them fresh after a reboot (to avoid that something remains "sticky" for *whatever* reason.
If it is not a problem in your setup, you could also try to change the IP range of the DHCP server.
Mikrotik CCR <- running centralized DHCP server
Cisco 2960 #1
Cisco 2960 #2
Mikrotik AP
If the same Mikrotik AP moved to another building (with a similar chain of devices) works, it must mean that *something* is different in another device, either the CCR settings/configuration or the two Cisco devices, since the CHR is the DHCP server, you should re-check it first.
Maybe (for whatever reason) the always-broadcast has been set to yes on that.
You may want to remove the related DHCP server entries and pool and re-enter them fresh after a reboot (to avoid that something remains "sticky" for *whatever* reason.
If it is not a problem in your setup, you could also try to change the IP range of the DHCP server.
Re: external dhcp delay on cap ac
From the config:
You set identical IP addresses on ether1 and bridge.
But that is really not your biggest problem here.
Code: Select all
/ip address
add address=172.18.224.5/22 comment=defconf interface=bridge network=\
172.18.224.0
add address=172.18.224.5/22 interface=ether1 network=172.18.224.0But that is really not your biggest problem here.
-
-
goudarzi1810
just joined
- Posts: 6
- Joined:
Re: external dhcp delay on cap ac
Proverb: I can't make sense anymore 
Currently, the problem and question is how to make dhcp offer
It is not sent in unicast mode and it is sent as broadcast?
Pay attention to the previously posted image
Currently, the problem and question is how to make dhcp offer
It is not sent in unicast mode and it is sent as broadcast?
Pay attention to the previously posted image
Last edited by goudarzi1810 on Tue Jan 21, 2025 1:29 pm, edited 1 time in total.
Re: external dhcp delay on cap ac
I'll be honest, the config is a mess. Hence I agree with @anav for either getting the knowledge yourself (training) or externally (consultant):
viewtopic.php?p=1120094#p1120094
The community (at least me) is more than willing to help. But you have to have some basic knowledge.
viewtopic.php?p=1120094#p1120094
The community (at least me) is more than willing to help. But you have to have some basic knowledge.
Re: external dhcp delay on cap ac
The same address on ether1 and on the bridge containing it is "wrong", whether it is part of the issue or not, only the bridge should have an IP address.
The CCR, right?
So there are two possibilities:
1) the CCR sends it as broadcast.
2) one of the devices between the CCR and the end devices captures the dhcp packet and re-transmits it as broadcast.
It still seems more probable #1, but fixing the AP configuration, cleaning it from what is not needed still remains a good idea.
Sent by which device?It is not sent in unicast mode and it is sent as broadcast?
The CCR, right?
So there are two possibilities:
1) the CCR sends it as broadcast.
2) one of the devices between the CCR and the end devices captures the dhcp packet and re-transmits it as broadcast.
It still seems more probable #1, but fixing the AP configuration, cleaning it from what is not needed still remains a good idea.