Confirmed, address display for /tool torch is somehow messy (src-address is 192.168.230.1, dst-address not shown). The display within Winbox is ok.
[admin@MikroTik] > /tool torch interface=WAN dst-address=0.0.0.0/0
MAC-PROTOCOL SRC-ADDRESS TX RX TX-PACKETS RX-PACKETS
ip 2.4kbps 1840bps 2 2
2.4kbps 1840bps 2 2
[admin@MikroTik] > /tool torch interface=WAN src-address=0.0.0.0/0
MAC-PROTOCOL TX RX TX-PACKETS RX-PACKETS
ip 4.2kbps 920bps 2 1
4.2kbps 920bps 2 1
[admin@MikroTik] > /tool torch interface=WAN src-address=0.0.0.0/0 dst-address=0.0.0.0/0
MAC-PROTOCOL SRC-ADDRESS TX RX TX-PACKETS RX-PACKETS
ip 192.168.230.1 4.6kbps 920bps 2 1
4.6kbps 920bps 2 1
/interface ethernet switch port> print stats
name: ether2-skybox ether3-tv ether4-ap ether5-trunk switch1-cpu
driver-rx-byte: 0 0 0 1 359 887 146
driver-rx-packet: 0 0 0 6 157 431
driver-tx-byte: 0 0 0 7 683 300 763
driver-tx-packet: 0 0 0 8 133 653
rx-bytes: 0 0 0 0
rx-too-short: 0 0 0 0
rx-64: 0 0 0 0
rx-65-127: 0 0 0 0
rx-128-255: 0 0 0 0
rx-256-511: 0 0 0 0
rx-512-1023: 0 0 0 0
rx-1024-1518: 0 0 0 0
rx-1519-max: 0 0 0 0
rx-too-long: 0 0 0 0
rx-broadcast: 0 0 0 0
rx-pause: 0 0 0 0
rx-multicast: 0 0 0 0
rx-fcs-error: 0 0 0 0
rx-align-error: 0 0 0 0
rx-fragment: 0 0 0 0
rx-overflow: 0 0 0 0
tx-bytes: 0 0 0 0
tx-64: 0 0 0 0
tx-65-127: 0 0 0 0
tx-128-255: 0 0 0 0
tx-256-511: 0 0 0 0
tx-512-1023: 0 0 0 0
tx-1024-1518: 0 0 0 0
tx-1519-max: 0 0 0 0
tx-too-long: 0 0 0 0
tx-broadcast: 0 0 0 0
tx-pause: 0 0 0 0
tx-multicast: 0 0 0 0
tx-underrun: 0 0 0 0
tx-collision: 0 0 0 0
tx-excessive-collision: 0 0 0 0
tx-multiple-collision: 0 0 0 0
tx-single-collision: 0 0 0 0
tx-excessive-deferred: 0 0 0 0
tx-deferred: 0 0 0 0
tx-late-collision: 0 0 0 0
/interface ethernet> print stats
name: ether1-gateway ether2-skybox ether3-tv ether4-ap ether5-trunk
driver-rx-byte: 7 288 415 796 0 0 0 1 361 018 164
driver-rx-packet: 8 072 759 0 0 0 6 165 323
driver-tx-byte: 831 390 476 0 0 0 7 692 641 941
driver-tx-packet: 5 676 361 0 0 0 8 143 470
rx-bytes: 0 0 0 0
rx-too-short: 0 0 0 0
rx-64: 0 0 0 0
rx-65-127: 0 0 0 0
rx-128-255: 0 0 0 0
rx-256-511: 0 0 0 0
rx-512-1023: 0 0 0 0
rx-1024-1518: 0 0 0 0
rx-1519-max: 0 0 0 0
rx-too-long: 0 0 0 0
rx-broadcast: 0 0 0 0
rx-pause: 0 0 0 0
rx-multicast: 0 0 0 0
rx-fcs-error: 0 0 0 0
rx-align-error: 0 0 0 0
rx-fragment: 0 0 0 0
rx-overflow: 0 0 0 0
tx-bytes: 0 0 0 0
tx-64: 0 0 0 0
tx-65-127: 0 0 0 0
tx-128-255: 0 0 0 0
tx-256-511: 0 0 0 0
tx-512-1023: 0 0 0 0
tx-1024-1518: 0 0 0 0
tx-1519-max: 0 0 0 0
tx-too-long: 0 0 0 0
tx-broadcast: 0 0 0 0
tx-pause: 0 0 0 0
tx-multicast: 0 0 0 0
tx-underrun: 0 0 0 0
tx-collision: 0 0 0 0
tx-excessive-collision: 0 0 0 0
tx-multiple-collision: 0 0 0 0
tx-single-collision: 0 0 0 0
tx-excessive-deferred: 0 0 0 0
tx-deferred: 0 0 0 0
tx-late-collision: 0 0 0 0
Very clever, but you really think that I didn't test new version before I upgrade a critical router?Why upgrade that critical router before testing by yourself on other non critical place ?
I first upgrade my home MT router everything working then update non critical part of network and after that update critical part of network. I know people using today 2.9.27 or 3.30 or 4.17 or 5.26 or 6.22 and there are happy with that version.
Don't upgrade before testing on other non critical place.
RouterBoard have option to make partition make two partition one for testing other with working system tested before is something wrong happens just switch back to tested working system.
http://wiki.mikrotik.com/wiki/Manual:Partitions
If is something very very important upgrade must me planed, tested, prepared with replaced device ready to replace.... upgrading critical part of network without precise planing is crazy. It is nice button upgrade just to try sorry but on some places I can afford that luxury.
Why do you the update of a critical router not during a maintenance windows? Even a tiny configuration change to a critical router i would only do during a maintenance windows having an implementation- and a rollback-plan. So if it is not working i roll back. For systems that are critical i have spare hardware. Those hardware is also be used for tests in the lab.
Very clever, but you really think that I didn't test new version before I upgrade a critical router?
I have tested it on 3 other Routerboards... there is all ok, but on this very important router it ***** everything.
So next time please try to think before post some stupidity
Steen, you are a partner of Mikrotik?Hello Folks!
60% of our devices successfully updated to RoS6.22, rock solid for a week: rb333, rb411,rb433,rb600,rb750,crs and ccr. Remaining will be taken upcoming weekend.
+1Very clever, but you really think that I didn't test new version before I upgrade a critical router?Why upgrade that critical router before testing by yourself on other non critical place ?
I first upgrade my home MT router everything working then update non critical part of network and after that update critical part of network. I know people using today 2.9.27 or 3.30 or 4.17 or 5.26 or 6.22 and there are happy with that version.
Don't upgrade before testing on other non critical place.
RouterBoard have option to make partition make two partition one for testing other with working system tested before is something wrong happens just switch back to tested working system.
http://wiki.mikrotik.com/wiki/Manual:Partitions
If is something very very important upgrade must me planed, tested, prepared with replaced device ready to replace.... upgrading critical part of network without precise planing is crazy. It is nice button upgrade just to try sorry but on some places I can afford that luxury.
I have tested it on 3 other Routerboards... there is all ok, but on this very important router it ***** everything.
So next time please try to think before post some stupidity
Very clever, but you really think that I didn't test new version before I upgrade a critical router?
I have tested it on 3 other Routerboards... there is all ok, but on this very important router it ***** everything.
So next time please try to think before post some stupidity
Please upgrade the RouerBoard firmware to v3.19 and check if the situation gets better.Have 2SHPn as well.
All the sudden the past two versions and even RC23 are all causing SSID not to be broadcasted or allow attaching UNTIL REBOOT...
This is happening now very very very often... Had to ROLL BACK TO LAST V.5 to gain stability of SSID/RADIO broadcasting..
2SHPn IS NOT FIXED, STILL LOOSING SSID/RADIO (I do not have CPU 50/100 issue.., Clients just cannot connect and do not see SSID)
Pretty much this. You need to duplicate the device. As much as a pain in the ass that is to do. We don't even make changes to our core routers during business hours, let alone any upgrade.Why do you the update of a critical router not during a maintenance windows? Even a tiny configuration change to a critical router i would only do during a maintenance windows having an implementation- and a rollback-plan. So if it is not working i roll back. For systems that are critical i have spare hardware. Those hardware is also be used for tests in the lab.
Very clever, but you really think that I didn't test new version before I upgrade a critical router?
I have tested it on 3 other Routerboards... there is all ok, but on this very important router it ***** everything.
So next time please try to think before post some stupidity
If i'm afraid something breaks i do a real test:
1. Export the config from the live system.
2. Replace the IPs with the ones from the test range. Just a search/replace with a text editor.
3. Import the new config into the test/spare device.
4. Do the planned change/upgrade on the test device.
Over all i agree that MT can improve the testing before they release a version. Some bugs are visible without a special config and should be found by doing basic tests.
I have problem with Intel Corporation 82576 Gigabit Network card after upgrade to: 6.15, 6.19, 6.22 MT lost 2-5% packet on this interface. 5.26 works fineNo, we have packet loss only on version 6.8-6.22.Versions 6.5-6.7 works stable. After 20-30 minutes MT start drops packet on all interfaces. In log file we see next message "105 (no buffer space available)". We try start VM on next servers:What about this problem?
http://forum.mikrotik.com/viewtopic.php?f=2&t=86119If you have packet loss in all versions, maybe there is some sort of hardware problem? if you have the chance, try another machine or at least other NIC
1. Supermicro X8DTT 12CPUs x 2.4 GHz Processor Type Inter(R) Xeon(R) CPU E5645 @ 2.40GHZ
Intel Corporation 82576 Gigabit Network Connection
RB433UAHWhat's new in 6.23rc7 (2014-Nov-25 08:26):
*) files - allow to move files between different disks in winbox;
*) dhcpv4 server - fix adding address lists;
*) dhcpv4 server - make radius classless static route tag as dhcp vendor specific;
*) smb - fixed HDD used/free space reporting
*) made powerpc metarouters work again (were broken in v6.22);
*) disks - fixed fat32 formatting where some bogus files with strange names were created
(to delete existing files reformatting is needed);
*) disks - fixed problem where some of USB disks were not recognized;
*) fetch - allow checking certificate trust without crl checking;
*) userman - fix more web session problems when user uses
customer and administrator interfaces at the same time;
*) snmp - fix external storage info reporting;
*) snmp - fix bulk walk problem introduced in v6.20;
*) fix tunnels - keep keepalive disabled for existing tunnels when upgrading;
*) fix tunnels - mtu for eoip tunnels was not allowed
to be set less than 1280 since 6.20;
*) using routing-marks could lead to tunnel loop detection to turn off tunnels;
What kind of configuration was deleted? Give a few examples what was lostUpgrading Omnitik from 5.24 to 6.13 works fine.
But after that, upgrade from 6.13 to 6.22 delete all my wlan1 configuration, exactly in the same way that 5.26 to 6.14.....
6to4 tunnel NO fixed !!!
Router OS 6.22 Router OS 6.19 (6to 4 work OK)
6to4 tunnel NO fixed !!!
Router OS 6.22 Router OS 6.19 (6to 4 work OK)
Hi miszak,
I have same problems; you can post the ipv6 configuration?
for me, working only with version 6.15; have some problems with 6.20.
Thanks.
/ip address add address=AA.BB.CC.DD/24 interface=ether1 /ip route add gateway=AA.BB.CC.GG /interface 6to4 add local-address=AA.BB.CC.DD mtu=1480 name=6to4 /ipv6 address add address=2002:AABB:CCDD::1/16 advertise=no interface=6to4 /ipv6 route add distance=1 dst-address=2000::/3 gateway=::192.88.99.1%6to4Reset config:
/system reset-configuration run-after-reset=6to4bug.rscAnd then try to ping some IPv6 address:
[admin@MikroTik] > /ping address=2002:ca0c:1dea::1 count=1 HOST SIZE TTL TIME STATUS 2002:59b9:e186::1 104 64 0ms hop limit exceeded sent=1 received=0 packet-loss=100% [admin@MikroTik] > /ping address=2a02:610:7501:1000::2 count=1 HOST SIZE TTL TIME STATUS no route to host sent=1 received=0 packet-loss=100%This is how it looks on 6.22, pinging other 6to4 address fails with "hop limit exceeded", native one fails with "no route to host". It works fine on 6.19 and lower.
Same problem i have, sometimes ....Upgrading Omnitik from 5.24 to 6.13 works fine.
But after that, upgrade from 6.13 to 6.22 delete all my wlan1 configuration, exactly in the same way that 5.26 to 6.14.....
My thoughts exactly.Steen, you are a partner of Mikrotik?Hello Folks!
60% of our devices successfully updated to RoS6.22, rock solid for a week: rb333, rb411,rb433,rb600,rb750,crs and ccr. Remaining will be taken upcoming weekend.
Or you're a lucky guy.
*) dhcpv4 server - fix adding address lists from radius;
Please try to install RouterOS v6.23rc10 and test if the issue is fixed as we have fixed only issue regarding 802.11ac driver.Wireless clients randomly stop transmitting when connected to R11e-5HacD. Only fix is to disconnect and reconnect. Tested Yoga 3 Pro, iPad mini, Macbook pro, Apple tv, Netgear PTV3000, and Droid turbo. Also tried all the latest betas with the same results.
(the card is in a 912UAG-2HPnD)
Try, test and report back! LOLPlease try to install RouterOS v6.23rc10 and test if the issue is fixed as we have fixed only issue regarding 802.11ac driver.Wireless clients randomly stop transmitting when connected to R11e-5HacD. Only fix is to disconnect and reconnect. Tested Yoga 3 Pro, iPad mini, Macbook pro, Apple tv, Netgear PTV3000, and Droid turbo. Also tried all the latest betas with the same results.
(the card is in a 912UAG-2HPnD)
Everyone, I believe .EDIT: I have 2 more 750UPs I could setup in a lab environment and see if I couldn't reproduce the issue. Anyone interested?
Please provide more detailed info on this problem to support@mikrotik.com and include a support output file.Hi.
When I update link to 6.22 witch wirelessfp my link loss packet randomly downgrade to 6.12 no problem.
So far so good. No interface lockups but still to early to call it.Please try to install RouterOS v6.23rc10 and test if the issue is fixed as we have fixed only issue regarding 802.11ac driver.Wireless clients randomly stop transmitting when connected to R11e-5HacD. Only fix is to disconnect and reconnect. Tested Yoga 3 Pro, iPad mini, Macbook pro, Apple tv, Netgear PTV3000, and Droid turbo. Also tried all the latest betas with the same results.
(the card is in a 912UAG-2HPnD)
Hello!After upgrading to 6.22 I am getting warnings for "transmit loop detected, downing interface for 60 seconds" just as described in the logs. This is with a GRE tunnel that between two mikrotiks that was working before.
The tunnel is from one location with 2 internet providers to another location with a single internet provider. The first location has 2 tunnels setup with difference source addresses but the same destination address and the second location with the same source address but 2 different destination address. One of the tunnels works fine but the second is now useless. It was setup with a route to prefer our favored internet provider and to failover to the second if the primary's link failed.
What exactly is the loop detection supposed to do?
Hello!After upgrading to 6.22 I am getting warnings for "transmit loop detected, downing interface for 60 seconds" just as described in the logs. This is with a GRE tunnel that between two mikrotiks that was working before.
The tunnel is from one location with 2 internet providers to another location with a single internet provider. The first location has 2 tunnels setup with difference source addresses but the same destination address and the second location with the same source address but 2 different destination address. One of the tunnels works fine but the second is now useless. It was setup with a route to prefer our favored internet provider and to failover to the second if the primary's link failed.
What exactly is the loop detection supposed to do?
I had the same problem, and found reason of problem. In my case transmit loop detection was triggered because i used route-mark for making routing decision. After i've made static routes for my gre destinations - problem disappeared.
/interface 6to4
add clamp-tcp-mss=no comment="Hurricane Electric IPv6" \
local-address=<Static Public IPv4 Address> mtu=1280 name=sit1 remote-address=\
<Server IPv4 Address>
/ip neighbor discovery
set sit1 comment="Hurricane Electric IPv6"
/ipv6 address
add address=<Client IPv6 Address> comment="IPv6 Gateway" interface=sit1
add address=<Routed /64> comment="IPv6 Network 1" interface=\
ether2-master-local
add address=<Routed /64>1 comment="IPv6 Network 2" interface=\
ether5-slave-local
/ipv6 firewall filter
add chain=input comment="Allow established connections" connection-state=\
established
add chain=input comment="Allow related connections" connection-state=related
add chain=input comment="Router Allow IPv6 ICMP" protocol=icmpv6
add chain=forward comment="Router Allow IPv6 ICMP" protocol=icmpv6
add chain=input comment="Allow UDP" protocol=udp
add chain=forward comment="Allow HTTP" dst-address=\
<server web>/128 dst-port=80 protocol=tcp
add action=log chain=input disabled=yes in-interface=sit1
add action=drop chain=input comment="Drop everything else"
add chain=forward comment="Allow any to internet" out-interface=sit1
add chain=forward comment="Allow established connections" connection-state=\
established
add chain=forward comment="Allow related connections" connection-state=\
related
add action=drop chain=forward
add action=log chain=output disabled=yes log-prefix="[DROP IPv6] " \
out-interface=sit1
/ipv6 firewall mangle
add action=change-mss chain=forward in-interface=sit1 new-mss=1220 protocol=\
tcp tcp-flags=syn tcp-mss=1221-65535
add action=change-mss chain=forward new-mss=1220 out-interface=sit1 protocol=\
tcp tcp-flags=syn tcp-mss=1221-65535
/ipv6 nd
set [ find default=yes ] advertise-dns=yes hop-limit=64
/ipv6 route
add distance=1 gateway=<Server IPv6 Address>
/ipv6 route
add dst-address=::/0 gateway=<Server IPv6 Address>