The previous version was 7.11.2
Guessing if the issue I had and I have is related to other Dude issue I now read in this topic…
Hi:
My RB4011 on firmware 7.12 reboot random from 45m to 3 ir 6 hours, on firmware 7.11.2 works fine.!!!
Can anyone help ir a clue, no messages on logs nothing … Just reboots.
My RB4011 runs fine in 7.12
What are the first 5 messages after boot?
When you no longer can see these because there are a lot of other messages, configure logging to disk or syslog server…
15:09:53 dns,error DoH server connection error: Network unreachable
15:09:53 dns,error DoH server connection error: Network unreachable [ignoring repeated messages]
15:09:56 interface,info BridgeLAN20 detect LAN
15:09:56 interface,info BridgeTSJogos detect LAN
15:10:04 interface,info ISP_1 link up
15:10:05 bridge,info “BridgeLAN20” mac address changed to xx.xx.xx.xx…
15:10:05 interface,info Vlan98 link up
15:10:05 interface,info Vlan99 link up
15:10:05 interface,info vlan200 link up
15:10:05 interface,info vlan300 link up
15:10:05 interface,info vlan301 link up
i no longer have 7.12 instaled but it was like this, the time was 00:02 or similar
i have checked transformer and replaced … the same i have used POE .. same thing. when i return to 7.11.2 OK..!!!
New problem with DoH.
“Verify DoH certificate” was always on.
" /certificate/settings/set crl-use=no" was set after update to 7.12.
rb4011, after reboot some sites are resolved, some not!
For sure before each test I make DNS cache flush.
My Config :
/ip dns static
add address=192.168.0.1 comment=defconf name=router.lan
add address=8.8.8.8 name=dns.google
add address=8.8.4.4 name=dns.google
/ip dns
set allow-remote-requests=yes cache-max-ttl=1d use-doh-server=
https://dns.google/dns-query verify-doh-cert=yes
The error can be seen at any device connected to router as unable to resolve dns
Mikrotik does the same:
[sas@MikroTik] > ping libreswan.org
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
while resolving ip-address: could not get answer from dns server
After I switched off “verify-doh-cert=no”, everything works fine.
Trust certs imported of course.
Ipv6 was always disabled.
i can not add new cap to existed old capsMan
cAP ac or cAP ax? For the latter you will have to wait for v7.13 (currently beta) to be able.
RBcAPGi-5acD2nD to RBD52G-5HacD2HnD
So you’re trying to add cAP XL ac to capsman controller running on AC2.
Correct ?
AC2 is running which version ? And which packages on it ?
cAP XL ac is running which version ? And which packages on it ?
nop
i am trying add cAP AC to hAP AC2
both are old AC.
manual provisioning works from CAP Interface tabs
7.12 broken sfp pon-stick (model:XE-99S)
When the system reboot, pon-stick can not init successful although the port show 10G-UP.
Good job.
had the same issue beginning with 7.12rc2, the issue seems to be, as you said, that “directly” connected routes are not sent over area boundaries (lsa’s of other routers are though). 7.13beta1 seems to fix it already, so I think they are aware of this but since nobody noticed the did not bother putting it in changelog (or 7.13 was branched before 7.12rc2 and is about to have that issue backported)
I created an IPv4 input rule on a hAP ac2 and I restricted it to an address list but the address list restriction did not work until I rebooted the router. Has anyone else encountered this?
I’m pretty sure address lists “work” immediately. There’s another “gem” with regard to firewall: new drop rules only affect new connections. Already established connectiobs are not affected. Clearing connection tracking table does the job (but drops all the rest of established connections, unrelated to the new rule) and rebooting router is one way to achieve this.
Nice explanation!
Agreed, I’ve never before implemented an address list that did not take effect immediately.
The need to clear the state table to allow new rules to work is normal, both for Mikrotik and other products. I checked the table before rebooting though, just to be thorough, and there were no established connections related to the issue I was experiencing. My logs showed multiple attempts from various sources and I tested myself from an unauthorized IP and was able to get through. After the reboot, everything was properly restricted.
There’s another “gem” with regard to firewall: new drop rules only affect new connections
This is based on how iptables work: existing connections are in established stated what us usually handled by “established, related, (untracked)” rules before drop rules.
So new drop rules only apply to connections with state “new”, what does not include existing connections.
What can be done is using a script traversing the connection table and dropping all existing connections with source/dest IP addresses/ports as matched by the new drop rule.
to clarify:
in cisco world “show ip route w.x.y.z” is checked against the “main” routing table
for VRFs it is “show ip route vrf ABC w.x.y.z”
somthing like that i guess could also be implemented in ROS.