CaP AC can't get IP via DHCP

I’ve setup a cAP AC in brige mode (in the same switch which an AC3 is already working in bridge mode without any issues) but the cAP AC can’t get an address via DHCP

Connected machines via wired (haven’t tried wireless yet) can connect to the internet and to other machines on the network withouth (I’m writing this with a machine connected to the AC with a CAT cable) any issues, but the AC itself cannot get an IP address via DHCP, route 0.0.0.0 to the default GW shows as unreachable (see attachment) (and I cannot ping the default GW from the tools->ping)

[admin@MikroTik-cap-ac] /ip dhcp-client> print
Flags: X - disabled, I - invalid, D - dynamic

INTERFACE USE-PEER-DNS ADD-DEFAULT-ROUTE STATUS ADDRESS

0 bridge yes yes searching…


Since the AC itself cannot see the default GW (nor the DNS) it cannot run any updates since it can’t resolve mikrotik.com DNS name

The problem doesn’t seem to be DHCP, since I’ve tried to configured the IP statically and it’s still unreachable.

I haven’t changed anything on the default config, so I’m at a loss what the issue could be.

Is it the firewall? or something very obvious that I’m missing? The router is obviously connected since clients can use the network, but the AC cannot directly reach anything

These are the firewall rules

/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
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

Any tips would be most appreciated, I have been banging my head on the wall for hours…

Thanks in advance
0000.png

/export hide-sensitive the configuration of the CAP

Bang no further,
There are no firewall rules needed.
Assuming you have some vlans for the WIFI (home, guest, iot devices - so at least three).

One will be the trusted vlan (typically the home vlan).
Give the CAPAC an IP address on this vlan

One bridge
identify vlans with interface bridge
assign bridge ports
ether1 trunk port to switch or router whatever
vlan10 to bridge (pvid=) {home}
vlan20 to bridge (pvid=) {guest}
any virtual wlans to bridge (pvid=) {iot devices}

Ensure there is on interface list entry called manage.
add interface=vlan10 list=manage
ip neighbours discovery list=manage
tools winmacserver list=manage

ip routes
dst-address=0.0.0.0/0 gwy=192.168.20.1

Setup bridge ports and bridge vlan accordingly
Activate bridge vlan filtering.
Details are in this excellent document see example post # 4, after reading and understanding the main pages.
http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1
++++++++++++++++++++++++++++++++++++++++++++++
To add in my own twist.
USE ether 2 as a wired backup (or use virtual wlan as a wireless back up, both OFF Bridge where you can configure the router and less apt to lock yourself out).
As always though make good use of SAFE MODE!!
https://forum.mikrotik.com/viewtopic.php?t=181718

/interface bridge
add admin-mac=2C:C8:1B:B0:CB:AC auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-B0CBAD wireless-protocol=802.11
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX country=portugal disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-B0CBAE wireless-protocol=802.11
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk group-ciphers=tkip,aes-ccm mode=dynamic-keys supplicant-identity=MikroTik unicast-ciphers=tkip,aes-ccm
/ip dhcp-server
add interface=bridge name=defconf
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
add bridge=bridge interface=ether1
/ip neighbor discovery-settings
set discover-interface-list=all
/interface list member
add comment=defconf interface=ether1 list=WAN
add interface=ether2 list=LAN
add interface=wlan2 list=LAN
add interface=wlan1 list=LAN
/ip address
add address=192.168.0.102/24 interface=ether2 network=192.168.0.0
/ip dhcp-client
add interface=bridge
/ip dhcp-server network
add address=0.0.0.0/24 comment=defconf gateway=0.0.0.0 netmask=24
/ip dns
set allow-remote-requests=yes servers=192.168.0.92,192.168.0.101
/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
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 route
add distance=1 gateway=192.168.0.101
/system identity
set name=MikroTik-cap-ac
/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

Thanks, lot of great info.

Unfortunately I have no VLANs yet (it’s on the todo list (but it’s been there for a big while. so unlikely to change in the near future), I have bookmarked your answer to tackle it on the future.

Most obviously the CAP gets an Address from the DHCP server on the Bridge interface…
However the address 192.168.0.102/24 must be assigned in the Bridge and not on the slave interface…
But if you want to assign a static IP Address then you need no DHCP Client…

There are more parts in the configuration that are wrong…

OKAY so assuming you only have one flat design (only one subnet, and its assigned to the bridge).
So no bridge vlan filtering.
When you do switch over, then the bridge will have no subnet and all subnets will be on vlans.
Also one should modify LAN to MANAGE for interface as that will identify which subnet is the trusted vlan (usually the home one or the one the admin resides on/uses)


Now to the CONFIG
Grossest error was this one…
add address=192.168.0.102/24 interface=ether2 network=192.168.0.0 (should be bridge)!

Based on flat one subnet then…
/export hide-sensitive the configuration of the CAP/interface bridge
add admin-mac=2auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-B0CBAD wireless-protocol=802.11
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX country=portugal disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-B0CBAE wireless-protocol=802.11
/interface list
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk group-ciphers=tkip,aes-ccm mode=dynamic-keys supplicant-identity=MikroTik unicast-ciphers=tkip,aes-ccm
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
add bridge=bridge interface=ether1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add interface=bridge list=LAN
/ip address
add address=192.168.0.102/24 interface=bridge network=192.168.0.0 {WHY USE 102 and not 1 or 254??}
/ip dns
set allow-remote-requests=yes servers=192.168.0.92,192.168.0.101

/ip route
add distance=1 gateway=192.168.0.101 {if your going to use 102 then this should match and also be .102 }
/system identity
set name=MikroTik-cap-ac
/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=NONE {not secure and thus set to none)
/tool mac-server mac-winbox
set allowed-interface-list=LAN

I see you have ether2 attached to the bridge, any special reason?
If none, then suggest you use ETHER2 or perhaps another virtual WLAN both OFF the bridge, to be able to reach the router or configure the router separately from the bridge (safer in my opinion).
Check it out.
https://forum.mikrotik.com/viewtopic.php?t=181718

The dhcp client is disabled by default, so as your export doesn’t show disabled=no, it must have been disabled at the time you did the export. But previously you’ve shown it to be in searching state, which means it wasn’t disabled at that time.

In the same export, the dhcp server attached to the same (bridge) interface doesn’t show disabled=no either. So make sure the server is disabled (or removed), and the client is enabled, these two cannot coexist on the same interface.

No switch chip rules there either so that also cannot be the reason.

I’d try sniffing - first, /interface bridge port set [find interface~“ether”] hw=no, then /tool sniffer quick port=67, and watch whether the DHCP requests are being sent and whether any responses come.

If you can see the responses to come, /system logging add topics=dhcp and then /log print follow-only should tell you why the cAP ac doesn’t like the responses.

that was a very stupid one indeed, don’t know it ended up there though, I think it was the quickset :frowning: (but setting it to bridge doesn’t fixes the issue though)

Well this is a very old story, for (very) historical reasons my default GW has always been 101, so all APs, switches and such are in the range 102-110

I think I have configured (disregard wireless, haven’t configured that yet) and yet the problem persists.

In fact i tried something else, I did a reset, used the default configuration (router) without changing anything and yet no IP is obtained via DHCP.

Either this unit is defective, or there is a problem with the cables (I’ve already switched them).

The funny thing is that I can this this on the router
/ip dhcp-server lease> print
192.168.0.102 2C:C8:1B:B0:CB:AC MikroTik-cap-ac internal offered 1s

[admin@MikroTik-cap-ac] > ping 192.168.0.101
SEQ HOST SIZE TTL TIME STATUS
0 192.168.0.101 timeout
1 192.168.0.101 timeout
2 192.168.0.101 timeout
3 192.168.0.101 timeout
4 192.168.0.101 timeout

This is the current config

/interface bridge
add admin-mac=2C:C8:1B:B0:CB:AC auto-mac=no comment=defconf name=bridge
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n channel-width=20/40mhz-XX disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-B0CBAD wireless-protocol=802.11
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40/80mhz-XXXX country=portugal disabled=no distance=indoors frequency=auto installation=indoor mode=ap-bridge ssid=MikroTik-B0CBAE wireless-protocol=802.11
/interface list
add comment=defconf name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge comment=defconf interface=ether2
add bridge=bridge comment=defconf interface=wlan1
add bridge=bridge comment=defconf interface=wlan2
add bridge=bridge interface=ether1
/ip neighbor discovery-settings
set discover-interface-list=LAN
/interface list member
add interface=bridge list=LAN
/ip address
add address=192.168.0.102/24 interface=bridge network=192.168.0.0
/ip dhcp-client
add disabled=no interface=bridge
/ip dns
set allow-remote-requests=yes servers=192.168.0.92,192.168.0.101
/ip route
add distance=1 gateway=192.168.0.101
/system identity
set name=MikroTik-cap-ac
/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=none
/tool mac-server mac-winbox
set allowed-interface-list=LAN


MAYBE this is the problem

[admin@MikroTik-cap-ac] /system> check-installation


damaged routeros-arm package: bad image

This was not the problem. I’ve now upgraded to 6.49.2, the packages no longer show as bad but still not able to ping the default GW


[admin@MikroTik-cap-ac] /system> check-installation
status: installation is ok

What does sniffing (as suggested above) show?

This needs to be removed/disabled!! Other than that do not see anything particularly wrong.
/ip dhcp-client
add disabled=no interface=bridge

one question can you tell us what the capac plugs into and how that unit may be configured??

Can’t really understand why it’s failling… The logs print this over and over…

00:53:18 dhcp,debug,packet dhcp-client on bridge sending discover with id 1198716654 to 255.255.255.255
00:53:18 dhcp,debug,packet secs = 19
00:53:18 dhcp,debug,packet ciaddr = 0.0.0.0
00:53:18 dhcp,debug,packet chaddr = 2C:C8:1B:B0:CB:AC
00:53:18 dhcp,debug,packet Msg-Type = discover
00:53:18 dhcp,debug,packet Parameter-List = Subnet-Mask,Classless-Route,Router,Static-Route,Domain-Server,NTP-Server,CAPWAP-Server,Vendor-Specific
00:53:18 dhcp,debug,packet Host-Name = “MikroTik-cap-ac”
00:53:18 dhcp,debug,packet Client-Id = 01-2C-C8-1B-B0-CB-AC


Could it be the time/date? Since NTP is not working…

NOPE it’s not the clock.

The thing that bothers this, is that I only have mikrotik devices on the network.

Anyway, DHCP is probably just a simptom, this is most likely the trouble…

[admin@MikroTik-cap-ac] > ping 192.168.0.101
SEQ HOST SIZE TTL TIME STATUS
0 192.168.0.101 timeout
1 192.168.0.101 timeout

The cap is connected to a CSS106-1G-4P-1S switch (https://mikrotik.com/product/CRS106-1C-5S) which powers the AC with PoE and the switch is connected to a RB951G-2HnD which is my main router

I CAN’T BELIEVE What the problem was.

the AC was connected to port 4 of the switch. I have now connected it to port 5 and IT WORKS.

This means I disabled the HAP ac3 that was on port 5.

Now that I have connected the AC3 to the port where the CAP was, the AC3 can no longer acquire an IP Address !@!#$%$&$^^$%%$

192.168.0.104 48:8F:5A:A5:70:30 MikroTik-ac3 internal offered 2s

Could it be the port is defective? could it be that if fails when more power is drawn from PoE? (the switch is powering 3 devices)

It is probably the former. I disconnected the AC3 and connected only the AC (on port 4) and it fails

I don’t see anything on swos which could be the cause of this…

Humm port 4 of the switch had a different setting on egress VLAN header. It was set to “Add if missing” whereas the other ports had “leave as is”

I set it to “leave as is” and it’s now working… I wonder if it was luck or that was the problem. (can’t see why this would affect DHCP and ICMP though).

The logs now say there was an error with DHCP (but it works)

21:11:32 dhcp,debug,packet dhcp-client on bridge received ack with id 1368314587 from 192.168.0.101
21:11:32 dhcp,debug,packet flags = broadcast
21:11:32 dhcp,debug,packet ciaddr = 0.0.0.0
21:11:32 dhcp,debug,packet yiaddr = 192.168.0.102
21:11:32 dhcp,debug,packet siaddr = 192.168.0.101
21:11:32 dhcp,debug,packet chaddr = 2C:C8:1B:B0:CB:AC
21:11:32 dhcp,debug,packet Msg-Type = ack
21:11:32 dhcp,debug,packet Server-Id = 192.168.0.101
21:11:32 dhcp,debug,packet Address-Time = 14400
21:11:32 dhcp,debug,packet Subnet-Mask = 255.255.255.0
21:11:32 dhcp,debug,packet Router = 192.168.0.101
21:11:32 dhcp,debug,packet Domain-Server = 192.168.0.92,192.168.0.101
21:11:32 dhcp,debug,packet CAPWAP-Server = 192.168.0.101
21:11:32 dhcp,debug,state dhcp-client on bridge entering state

Of course it was the problem. The switch was adding VLAN tags to frames it was sending to the connected device, which expects tagless frames, so it was ignoring the tagged ones. Sniffing would have shown you that.

What this demonstrates that only providing us with one piece of the puzzle was confusing.
Suggest a network diagram for future posts to show what is connected which may always be part of the problem.

But I did sniff :slight_smile:

Maybe I’ve missed something, but I don’t think it showed that

Agreed. Although in this case one of the ports had a different config (for now apparent reason)

Thanks to everybody who chimed in