pe1chl mentioned people rearranging power cords, and you quoted that. It was more of a tongue-in-cheek joke. I am sorry.
1 Like
Dear rextended, this behavior is highly undesirable on a professional forum. Please moderate yourself. Thank you. As I said, "we will see", and as pe1ch1 stated also, its not downward compatible. I tested it and indeed. Complained, because changes like this inside a mature stable train is dangerous, but as I already said, I accept the vendor's answer. We will live with this.
1 Like
This is less probable problem with dual-PSU devices, but similar situation has been observed when Mikrotik's cheap-*ss 24V power brick "almost fails". More than one access point had to be revived by netinstall because "repeating-brownout-while-booting" messes device up to unbootable state. These power bricks are one of weakest points of Mikrotik hardware as they tend to fail more often than other equipment. If Mikrotik device (fed by this power brick) is offline after power outage, then first thing to check is the power brick and more than once it turns out to be the cause.
1 Like
Maybe your issue is caused by using the wrong export format.
You should use "/export show-sensitive" or at most "/export terse show-sensitive", NOT "/export verbose".
Doing so will cause problems like the one you mention.
That is true. I would not say that they fail more frequently than similar power bricks from other manufacturerers, but for sure they fail more frequently than the routers.
Every time when we had an issue at some site (router no longer working), it always turned out to be a defective power brick and replacing it fixed the issue.
True,
in fact, most CCRs that have "dual" power, I replace one with "direct" battery power.
Those that have only one, remove it and power it directly from the batteries (no PoE, right on the internal connector).
Straight DC input can be handy if appropriate DC power is available. That's why RB1100AHx4 has separate DC 24 - 57V input connector in addition to 2 AC inputs. It might be a good idea for other devices to have it as well probably...
2 Likes
Maybe they'd put them everywhere...
±24V and ±48V... (better leave 48>24 V conversion OUT of the board...)
CCR2216 - 7.19.6
Monitored VLAN traffic from both Winbox and CLI show drastic "flaps" in the Tx/Rx. Gbps down to Kbps for a brief moment.
The physical interfaces (qsfp28-1-1 and qsfp28-2-1) do not reflect these flaps and traffic through the router seems fine. Same for the bond interface.
Has anyone else seen this?
1 Like
The problem with providing 48V input is that the users expect it to be isolated because they feed it with -48V, so it cannot be the usual diode wired-or that is used on the low-end models.
There has to be an isolated powersupply converting 48V to something else (probably 24V) and then it can be wired-or into the DC line that is again downconverted to 5V, 3.3V etc.
Have that on all models would introduce extra cost, and also the chance of failure of that module is about the same as for a 100-240V supply.
I tested it with, exported config with /export show-sensitive file=..., cleared config with /system/reset-configuration, downgrade from 7.19.6 to 7.19.4, and tried to import, and import command pointed the exact line number where /system logging action set [ find name="remote" ] ... vrf=notmain
This is how I mean the "downward incompatibility", but we can live with this little inconvenience.
Yes but there you have set the VRF, of course that would not work because 7.19.4 does not support that.
But when you had just upgraded a 7.19.4 to 7.19.6, not touched that logging action remote, exported the config and imported that back into downgraded 7.19.4, it would have worked.
That is because when the vrf has not been set, the vrf= parameter will not be included in a compact or terse export, only in a verbose export.
1 Like
what's the reason to zoom in so much? we could make a higher resolution logo, but it will take up valuable space
1 Like
Isn't it a vector-based image?
1 Like
Well, of course the idea behind .svg is that you describe the geometry, not specify the pixels.
Getting rid of those artifacts could even make the logo smaller.
3 Likes
All the same 2kB .svg file generously provided by MT in the header of this page 
...
2 Likes
The webfig logo is not the same as the logo published at https://mikrotik.com/logo. I can't see a reason why using a broken logo in webfig. Processing both by SVGOMG - SVGO's Missing GUI there is no relevant difference in size. Normis, I guess you are not responsible for CI at Mikrotik. Just hand over the information/facts to the designers. They should decide what to do. Most probably it is just an outdated version that is shipped with webfig.
1 Like
RB3011
after updating from 7.19.4 to 7.19.6 i got
USB flash drive FS=unknown.
Replacing the USB flash drive with a brand new one did not produce any results
(after several hours of work, the same error)
Writing a lilttle bit logs + storing one adlist.txt for /ip/dns/adlist/
P.S.
Before the update, the uptime was 43 days, everything worked perfectly.
(ext4, mbr, SanDisk Ultra Flair 16gb)
the second one is Silicon Power Jewel J80 8gb.
Formatting the USB causes a reboot. Terminal echo log says ~kernel failure in previous boot.
Downgrading back to 7.19.4 solves the problem.
Send supout.rif when this happens to support ( or autosupout if already created).
12 posts were split to a new topic: Mikrotik fixes for OpenWRT in 7.19.6 and 7.20