Thank you for recent release and addressing a lot of issues we had with 5.6.
A few months ago I asked if it would be possible to add back the ability to sort by port in the Torch. Back then I thought I was all by myself but now if I search on port sort, I see a lot more people complaining about the loss of this function.
A lot of “strange” activity can’t always be detected by a smart script or a config, which is why we also scan our network routers manually, especially when the maps report packet loss or unusual traffic.
THe ability to sort by port (both for src and dst) allows us to reveal viruses, aggressive and encrypted P2P, a stuck process that tries to go to Adobe, etc. etc.
Would it be possible to add this function back to the Winbox GUI?
What was the reasoning in taking it out?
OH yes it can.
Your server stores dns resolves in a cache. If this was a piece of date coming from the google dns server you cache has the faulty data. When you reboot your router the cache gets flushed and new data needs to be used. If now this new data is ok the router works fine, for as long as it takes to get the wrong data from google again…
When I had the problem I tried flushing the dns cache in the rb1200. It gets empty and it doesn’t take any more request so I continue without browsing…
From my experience there is a problem with ROS’ built-in DNS resolver when cache size is set to value bigger than 8192 kB.
With different versions of ROS there was same problem, no response from DNS cache.
Also max. UDP packet size should be increased to value bigger than default 512 bytes (4096-8192).
Because to allow support for DNSSEC packet size allowed should be a minimum of 4096
The second issue is related to the packet size. The authors of the DNSSEC standard realized that there might be a potential problem with TCP queries. TCP puts a higher burden on the DNS servers. (TCP is much more expensive to process than UDP.) To avoid too much TCP traffic, the authors made the EDNS0 extension mandatory for DNSSEC. EDNS0 is a standard that among other things allows a client to signal that it is capable of receiving DNS replies over UDP that are larger than the previous limit of 512 bytes. Some firewalls are not aware of the fact that the EDNS0 standard allows for larger packets and they block any DNS packet larger than the previous limit. Other firewalls allow for the large packets by default, whereas a few vendors require the firewall to be manually configured to do so. Any device in the path that does packet inspection in the application layer must be aware of the EDNS0 standard to be able to make a correct decision whether to forward the packet or not.
This happens on 4.x versions for OpenDNS servers 208.67.220.220 and 208.67.222.222 and for Google DNS servers too.
The particular routerboard for DNS resolving runs HotSpot and is a gateway for the network, ROS 4.17.
One thing I noticed is that you CAN ping the IP address, for ex.208.67.220.220 from the DNS resolver routerboard, but you CAN’T ping the same IP address from the inside of the network, for ex. from client who is authenticated on the HotSpot and Skype running, you get an answer from the DNS resolver routerboard: “destination host unreachable”.
I’ve noticed this problem with earlier versions starting from 4.5 (don’t sure for earlier versions) and only a reboot fixes it. Hope this will shred more light on this problem.
Only one solution is to turn off or on /interface Ethernet switch set 0 switch_all_ports=yes or no, after that routerboard starts to transmit data. But i don’t use hardware switch for boards, no master or slave interfaces, only program switch for bridging Ethernet iface with wireless, Don’t know exact what the problem is, power supply is good, cables is good(at first time we think that the cables cat5e was caused the problem for 1G connection, and than replaced them to cat7 cables - have the same issue).
A hope for some assistance, it’s not suitable to downgrade software or firmware on boards to avoid similar problems with configuration - a can’t to stop transmission through that link cause they are situated on commercial towers and it’s not real to get the boards directly.
Anyone suggest?
My opinion - it’s a firmware trouble of RB435G at a side of Ethernet sensitivity, may be i’m wrong.
I hope the MTIK team to help.
Thanks
i have some troubles with this version:
on RB450G: high CPU usage (DHCP package) - i`m using vlans, so DHCP server is connected to vlan, not ethernet directly.
on all boards (and all 5x versions, i think):
DNS package - when i remove static record, this one persist in memory until router is rebooted.
Graphs: are completly deleted, when RB is rebooted.
so, i`m waiting for next version of RouterOS.
I love how MikroTik are improving on features like the Sniffer. The new filters are awesome.
My home RB450G was running 5.7 since it was released and just today it made me a problem (apart from DNS issues I thought were due to 8.8.8.8 being down)
The problem was that in Profile tool I could see sniffing making close to 100% CPU so I took a supout for support, rebooted, put in the latest unreleased 5.8 in the share subfolder and rebooted again.