Recent content by VZ3

I do, time to time. This is something with kernel and there is no solution other then restart router.

You can use next command to monitor malware packets been dropped iptables -vL -t raw If you see chain pkts counter goes up that means your firewall is doing it's thing.

For the Foscam cameras - they like to keep "heart bit" thingy for the cloud services, kinda thing Foscam using for it's application in order to connect through their hosted server. And it's impossible to turn it off through Foscam UI. Sure thing to block this shady behavior is to not specify...

@Pir8pete Looks like your are leeching and 1900 router does not like it :). Jokes aside, try different router (with more pedigree).

Also, let's make time when our routers will hit the firehol server for the updates a bit random. Imaging if thousands clients hitting firehol server at exact same time like 0:00 then 6:00 then 12:00 then 18:00. It will look like DoS attack. At least put some random minutes number into your...

Just tested it and it's working : https://www.snbforums.com/threads/yet-another-malware-block-script-using-ipset-v4-and-v6.38935/page-22#post-348147 Question is this permanent solution, maybe not. Well, anyway we will see.

We need to find new URLs for ip block list. I guess we have hammered github with read requests and administration does not like it and blocked the repository. PS: well, looks like it's not us reading too much it's automatic script updates lists too often. They contacted Github and waiting on...

Again, there is nothing to see in top command except that one core stuck with high IO.

I have the same issue with AC87R and 380.68. It something with disk IO, somewhere in kernel. There is nothing unusual to see in TOP command other that one CPU is waiting/looping/got stuck on IO. PS: I have an impression that Web UI is kinda facilitated/triggered that bug. Or maybe it got stuck...

I'm using Merlin's firmware. I'm not familiar with Tomato but looks like in your version there is no iptables-save command. You can ignore the first error, this is just a wget reporting on commented line with level4 list. Then we see script fetched 47k ip list, so this part is working fine...

Nice job, you are deleting block set from iptables but you forgeting about actual ipset destroying its unused named set.

Looks like the same problem I had: https://www.snbforums.com/threads/ac-rt87r-on-380-68-high-cpu-utilization.41055/ PS: after such event, I usually just delete traffic.db from jffs and let it rebuild again.

One core stuck at 100%. Does not happened too often. In fact it's third time in a months. Usually router would run for weeks without reboot. Top command shows 50%IO - so looks like CPU got stuck waiting on disk IO. I have external SSD which is used by FTP daemon but when I have unmounted it...

When previously some "BAD" IP will become "GOOD" one, maybe due to time or other criteria, your router will still treat it as "BAD" until next "overfill" or router reboot. As for me, it's like good reputation - one have to treasure it from the very beginning :).

Your curl output command with commented out URL as expected - meaning no IP list are downloaded from that URL. Those level1,2,3 and 4 URLs are sources for YAMB block list which later aggregated into YAMalwareBlock 1, 2, 3 etc. lists. YAMB single set cannot hold more then 65k addresses, so it...