I was tracing down why my router was not responding to the web interface and found in smb log that it had been polling a connected USB device so much that there were at least a few thousand repetitions of this entry in less than an hour:
At that point the router had also stopped providing DNS and being lazy I was on the command line rather than my usual console client so did not have full logging but the prompt's 9000 line buffer was filled with those request appearing to relate to a printer.
I haven't had a printer connected to the router for months, long before I did a reset to factory defaults last week or two (no settings restore) for the last firmware update..
Thinking back, earlier in the day libhide had crashed on my iPhone and spit out all the system icons. I tapped a few including one that came up with an empty Print Queue screen. I closed it and rebooted not thinking much of it. Now, it's late and I'm fuzzy, but is it possible that tapping that icon put the router into a tailspin by way of Bonjour -> UPnP -> pcap?
Searching the output above, the solution appears to usually be to pipe pcap to /dev/null when no printers are configured, but that was not the setting in the smb comf. Should it be to prevent loops like this?
There wasn't much in syslog except the following every 5 min:
I managed to get the drive out with umount -l but couldn't reboot as the router was responding "nvram doesn't exist" whenever I issued the command. It then killed dropbear so being stuck in telnet I just hit the button.
There's not much on the drive except a <1 KiB rstats file. I wasn't sure how to read that but stripping it of \x00 left only 41 bytes and a few other unprintable chars. I'll try data recovery and post anything useful.
I thought it was strange that the drive was notably hot when I picked it up since I'd never seen that from an SSD. FWIW it's a late gen enterprise drive with 0 failures logged in >100k hours. The heat was well distributed across the surface, but there were no issues remounting on another machine.
Code:
kernel: printing/pcap.c:pcap_cache_reload(159) Unable to open printcap file /etc/printcap for read!At that point the router had also stopped providing DNS and being lazy I was on the command line rather than my usual console client so did not have full logging but the prompt's 9000 line buffer was filled with those request appearing to relate to a printer.
I haven't had a printer connected to the router for months, long before I did a reset to factory defaults last week or two (no settings restore) for the last firmware update..
Thinking back, earlier in the day libhide had crashed on my iPhone and spit out all the system icons. I tapped a few including one that came up with an empty Print Queue screen. I closed it and rebooted not thinking much of it. Now, it's late and I'm fuzzy, but is it possible that tapping that icon put the router into a tailspin by way of Bonjour -> UPnP -> pcap?
Searching the output above, the solution appears to usually be to pipe pcap to /dev/null when no printers are configured, but that was not the setting in the smb comf. Should it be to prevent loops like this?
There wasn't much in syslog except the following every 5 min:
Code:
cstats[541]: Problem loading /mnt/sda1/asuslogs/tomato_cstats_d850e6457de8.gz. Still trying...
rstats[537]: Problem loading /mnt/sda1/asuslogs/tomato_rstats_d850e6457de8.gz. Still trying...I managed to get the drive out with umount -l but couldn't reboot as the router was responding "nvram doesn't exist" whenever I issued the command. It then killed dropbear so being stuck in telnet I just hit the button.
There's not much on the drive except a <1 KiB rstats file. I wasn't sure how to read that but stripping it of \x00 left only 41 bytes and a few other unprintable chars. I'll try data recovery and post anything useful.
I thought it was strange that the drive was notably hot when I picked it up since I'd never seen that from an SSD. FWIW it's a late gen enterprise drive with 0 failures logged in >100k hours. The heat was well distributed across the surface, but there were no issues remounting on another machine.
Last edited:
