This has happened to me at least 3 times now that I can remember… I am currently on 3.6 x86 but I know it has happened in 2.9 as well. For some odd reason my logins don’t work anymore so just out of curiousity I try admin/blank password and then I’m in. Router is still passing traffic, but terminal window and supout wont work. Users windows shows only admin user, not the other 3-4 I have assigned. Reboot the router and everything is back to normal, admin account is disabled and i can get back in with my main login. WEIRD.
Main problem - sometimes admin / blank passwords will allow entrance when the router is in this state. What the hell is going on!
I took a supout and a camtasia video of it and will send to support, just wondering if this has ever happened to anyone else.
I upgraded my MT ROS to 3.25 it worked for around 3.5 days
and now the same problem.
I made support.rif but couldnot find out where it get saved i ftp://myserver and searched there but it was not there
can any body help me locate “support.rif”
It’s Surely a BUG
Thanks
sanjeev
one thing confirmed YOU CANNOT MAKE SUPPORT.RIF FILE while in this weird situation
i rebooted my router it came back to normal mode and now i can create support.rif file and i can get it by ftp.
guys please take this issue seriously and take step to fix this problem
Thankyou very much
Sanjeev
yes, i believe you cannot run a supout or anything else that writes to the disk. My guess is that the disk is getting ejected and so routerOS runs in read only or something.
Are there any logging topics that could be added to detect DISK errors / timeouts? (Hint hint - please add this MT)
in my case it has always been x86 with compact flash. Version 2.9 - 3.13 or so I saw this, although I replaced the CFIDE adapter and CFDISK after it kept happening so it makes me think it was related to disk access issues. Either way, it would be nice (and have made me realize WAY earlier) to see disk errors in the logs. Can a topic ‘disk’ be added and used for disk subsystem problems ?
I encountered something similar - A combination of a defective Addonics CF to SATA adapter with a Sandisk Extreme III flash card.
Basically, the system would initialize in a UDMA mode, but the interface would fail and hang. The Kernel then gets stuck in a write loop, constantly trying to write the same data to the disk. The reads then hang up, causing the unusual problems you are seeing.
I suspect this is a bug in the UDMA driver, or the kernel systems that control/access it… The kernel is not falling back to PIO when something goes wrong. BIOS settings make no difference.
I tried to report this to Mikrotik some time back - Ticket #2009011266000041. Didn’t have the time to argue and try to prove it so we just junked the CF system all together and went for USB sticks.
For what it’s worth, it was a Core 2 Duo system - A Dell PowerEdge R200.
this could happen only if your disk is faulty. the kernel will notice this, and will turn off writing. reboot helps. the correct remedy is to replace disk to a quality one
normis, can you pull some strings and get a logging topic added for disk errors / events ? it would help diagnose disk problems tremendously. im sure this would be beneficial for nand stuff as well.
Yes, it will detect a faulty disk and turn off writing, but it will not always detect a faulty interface module, SATA cable, etc, especially when it masquerades as certain types of DMA timeouts.
