Skynet Skynet - Router Firewall & Security Enhancements

[2992]

For me reformatting the USB resolved the issue.

already reformatted each one for several times and started from scratch with installations. I'm still getting those errors since it has originally started, several days ago...
'Funny' thing is that ABS is working perfectly fine for each time when I reinstall it, no matter which USBDrive I'm using...

 

[Protik]

already reformatted each one for several times and started from scratch with installations. I'm still getting those errors since it has originally started, several days ago...
'Funny' thing is that ABS is working perfectly fine for each time when I reinstall it, no matter which USBDrive I'm using...

Just to be sure, are you doing fresh install of Skynet each time?

 

[thelonelycoder]

'Funny' thing is that ABS is working perfectly fine for each time when I reinstall it, no matter which USBDrive I'm using...

I like that kind of fun

 

[skeal]

already reformatted each one for several times and started from scratch with installations. I'm still getting those errors since it has originally started, several days ago...
'Funny' thing is that ABS is working perfectly fine for each time when I reinstall it, no matter which USBDrive I'm using...

How are you going about formatting these drives? please explain are you using the router to format are you using windows program or linux?

 

[Adamm]

@Adamm
Found a minor error in the stats for 382.

Top 50 Blocked Devices (Outbound);
grep: /tmp/var/lib/misc/dnsmasq.leases: No such file or directory
grep: /tmp/var/lib/misc/dnsmasq.leases: No such file or directory
grep: /tmp/var/lib/misc/dnsmasq.leases: No such file or directory
grep: /tmp/var/lib/misc/dnsmasq.leases: No such file or directory
370x 192.168.2.111 (No Name Found)
63x 192.168.2.114 (No Name Found)
58x 192.168.2.115 (No Name Found)

@Adamm As with the crontab file location, for 382.x or maybe just for the AC86U: Leave out the leading /tmp and it works for 380 and 382.
Might also be that the file is not yet created after a fresh boot.

Thanks, will add an exception for the .382 codebase assuming its relevant for all devices there. @RMerlin

 

[thelonelycoder]

Thanks, will add an exception for the .382 codebase assuming its relevant for all devices there.

No need for an exception, just use /var/... for both.

 

[Adamm]

No need for an exception, just use /var/... for both.

Good call, didn't realise it was a symlink on .380

 

[2992]

Just to be sure, are you doing fresh install of Skynet each time?

Yep. It takes just few minutes.

How are you going about formatting these drives? please explain are you using the router to format are you using windows program or linux?

I've formated them with the router first. Then I've formated them again with a Linux (first I've used the quick option, then later I've used to o-ing option). I do believe I've formated them correctly..
And I've tried them (reinstall everything) after each format. Same issue each time. I now came to the conclusion that are not the USBs not performing (cannot be that all 3 of them are brocken) , as ABS is each time working perfectly fine. It's either something wrong on the router, or the Skynet. I've start having this issue only since few Skynet releases ago. Before it was working fine.

 

[Adamm]

It's either something wrong on the router, or the Skynet.

I mean, if it works for hundreds of other users, and it works fine with a JFFS install, not sure what else to say. There's also the chance its caused by XWRT but the line of code its failing on kind of makes one assume its a filesystem related error.

if [ -f "${location}/scripts/ipset.txt" ]; then ipset restore -! -f "${location}/scripts/ipset.txt"; else logger -st Skynet "[INFO] Setting Up Skynet..."; touch "${location}/scripts/ipset.txt"; fi

Which basically means, if file "ipset.txt" doesn't exist, then create a fresh one. In your case the ipset.txt does physically exist, but its not registered by this check. With that being said, this is a very hard check to fail due to how basic it is.

The only thing I can think of is, post the output of the following commands.

if grep -qE "usb=.* # Skynet" /jffs/scripts/firewall-start; then location="$(grep -ow "usb=.*" /jffs/scripts/firewall-start | awk '{print $1}' | cut -c 5-)/skynet"; else location="/jffs"; fi

l s -la "$location/scripts"

(Remove the space between "l s" in the second command, the website doesn't like it being posted for some reason)

 

[HardCat]

@Adamm - Updated to v5.5.2 this morning, I really like the Locked Processes explanation. This goes far in helping the user understand that sometimes you must be patient and wait a bit for a process to complete.

 

[2992]

I mean, if it works for hundreds of other users, and it works fine with a JFFS install, not sure what else to say. There's also the chance its caused by XWRT but the line of code its failing on kind of makes one assume its a filesystem related error.

if [ -f "${location}/scripts/ipset.txt" ]; then ipset restore -! -f "${location}/scripts/ipset.txt"; else logger -st Skynet "[INFO] Setting Up Skynet..."; touch "${location}/scripts/ipset.txt"; fi

Which basically means, if file "ipset.txt" doesn't exist, then create a fresh one. In your case the ipset.txt does physically exist, but its not registered by this check. With that being said, this is a very hard check to fail due to how basic it is.

The only thing I can think of is, post the output of the following commands.

if grep -qE "usb=.* # Skynet" /jffs/scripts/firewall-start; then location="$(grep -ow "usb=.*" /jffs/scripts/firewall-start | awk '{print $1}' | cut -c 5-)/skynet"; else location="/jffs"; fi

l s -la "$location/scripts"

(Remove the space between "l s" in the second command, the website doesn't like it being posted for some reason)

Could it be the rights are not right for that ipset.txt file?...

admin@R7000-XWRT:/tmp/home/root# if grep -qE "usb=.* # Skynet" /jffs/scripts
/firewall-start; then location="$(grep -ow "usb=.*" /jffs/scripts/firewall-start
 | awk '{print $1}' | cut -c 5-)/skynet"; else location="/jffs"; fi
admin@R7000-XWRT:/tmp/home/root# l s -la "$location/scripts"
drwxrwxrwx    2 admin    root          4096 Nov 10 08:47 .
drwxrwxrwx    3 admin    root          4096 Nov 10 08:47 ..
-rw-rw-rw-    1 admin    root          3213 Nov 10 12:00 ipset.txt
admin@R7000-XWRT:/tmp/home/root#

 

[2992]

PS: need space between l and s, as I've got almost blocked by SNB trying to post the results of that command...

 

[Adamm]

Could it be the rights are not right for that ipset.txt file?

The only way to fail that test is;

It is not a directory, device file, block device, FIFO or socket. If you do an l s -l. The ones which start with a "-" are the files. Actually what most people to refer as just a file.

So you can even chmod 000 the file and change ownership to some random user and it will still pass. For some reason though this file becomes corrupt or something of that nature during reboots when installed on your USB.

So considering JFFS installs work... its really hard to give you an answer here, had it been on an Asus device or even possible to replicate on one then we could track down the issue in the firmware, but because XWRT is close source there's not much else I can advise beyond installing to JFFS.

 

[2992]

The only way to fail that test is;



So you can even chmod 000 the file and change ownership to some random user and it will still pass. For some reason though this file becomes corrupt or something of that nature during reboots when installed on your USB.

So considering JFFS installs work... its really hard to give you an answer here, had it been on an Asus device or even possible to replicate on one then we could track down the issue in the firmware, but because XWRT is close source there's not much else I can advise beyond installing to JFFS.

Ok, I kind of understand.. Maybe something strange has happen during one of the Skynet upgrades and had that file corrupted. Or maybe during some power-off of the router, or maybe the USB was taken out without umounting it first... no idea.
Is there any way to maybe remove that file, and create it again? Or maybe re-set the ownership of the file for each time when router reboots and before each time when is trying to use it, right before Skynet is trying to use the file? (I'm just asking these questions, as I do not know how it's the whole process working anyways...)

Also, is there any downside if installing and keeping Skynet on JFFS?

 

[Adamm]

Ok, I kind of understand.. Maybe something strange has happen during one of the Skynet upgrades and had that file corrupted. Or maybe during some power-off of the router, or maybe the USB was taken out without umounting it first... no idea.

Uninstalling deletes that file (and all traces of Skynet) so I assume something is happening on boot that causes this. You could confirm that its a "boot only" issue by running;

sh /jffs/scripts/firewall restart

Which fully unloads, then loads up Skynet again. If it works as expected, then that's the case.

Is there any way to maybe remove that file, and create it again? Or maybe re-set the ownership of the file for each time when router reboots and before each time when is trying to use it, right before Skynet is trying to use the file?

As my previous post explains, this test is very basic and hard to fail, ownership/read permissions set incorrectly wouldn't even cause it to fail. The only way is for the system not to recognise it as a file, weather its the USB or XWRT causing this is hard to say. I assumed it was a USB related issue, but if you did test 3 different devices freshly partitioned and wiped clean then I take your word for it.

Also, is there any downside if installing and keeping Skynet on JFFS?

There's the infamous "flash wear" debate. But personally I had Skynet and other scripts installed to JFFS for years without any issue. The write cycle count on modern nand is so high that its more likely you will get a new device or it will stop working from other causes before it ever became an issue.

 

[2992]

Uninstalling deletes that file (and all traces of Skynet) so I assume something is happening on boot that causes this. You could confirm that its a "boot only" issue by running;

sh /jffs/scripts/firewall restart

Which fully unloads, then loads up Skynet again. If it works as expected, then that's the case.



As my previous post explains, this test is very basic and hard to fail, ownership/read permissions set incorrectly wouldn't even cause it to fail. The only way is for the system not to recognise it as a file, weather its the USB or XWRT causing this is hard to say. I assumed it was a USB related issue, but if you did test 3 different devices freshly partitioned and wiped clean then I take your word for it.



There's the infamous "flash wear" debate. But personally I had Skynet and other scripts installed to JFFS for years without any issue. The write cycle count on modern nand is so high that its more likely you will get a new device or it will stop working from other causes before it ever became an issue.

The behaviour lately is like this: after reboot, it shows ok, then at the first fix hour update, it's back to 0.

Nov 10 13:08:33 Skynet: [INFO] Lock File Detected (start banmalware autoupdate usb=/tmp/mnt/ABS2) (pid=683) - Exiting
Nov 10 13:08:33 openvpn[1392]: Initialization Sequence Completed
Nov 10 13:08:39 Skynet: [Complete] 162465 IPs / 2464 Ranges Banned. 162465 New IPs / 2464 New Ranges Banned. 0 Inbound / 0 Outbound Connections Blocked! [22s]
...
Nov 10 14:00:01 Skynet: [Complete] 0 IPs / 0 Ranges Banned. -162465 New IPs / -2464 New Ranges Banned. 0 Inbound / 0 Outbound Connections Blocked! [1s]

So, now I just ran the command to restart it, and:

Nov 10 16:00:01 Skynet: [Complete] 0 IPs / 0 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 0 Inbound / 0 Outbound Connections Blocked! [0s]
Nov 10 19:31:40 Skynet: [INFO] Restarting Skynet...
Nov 10 19:31:41 rc_service: service 4650:notify_rc restart_firewall
Nov 10 19:31:41 start_nat_rules: apply the nat_rules(/tmp/nat_rules_vlan2_vlan2)!
Nov 10 19:31:42 custom_script: Running /jffs/scripts/firewall-start (args: vlan2)
Nov 10 19:31:42 Skynet: [INFO] Startup Initiated... ( banmalware autoupdate usb=/tmp/mnt/ABS2 )
Nov 10 19:32:03 Skynet: [Complete] 0 IPs / 0 Ranges Banned. 0 New IPs / 0 New Ranges Banned. 0 Inbound / 0 Outbound Connections Blocked! [21s]

then I manually ran option [3] Banmalware, and it's ok...

Nov 10 19:36:03 Skynet: [Complete] 159903 IPs / 2459 Ranges Banned. 159903 New IPs / 2459 New Ranges Banned. 0 Inbound / 0 Outbound Connections Blocked! [51s]

 

[skeal]

Yep. It takes just few minutes.

I've formated them with the router first. Then I've formated them again with a Linux (first I've used the quick option, then later I've used to o-ing option). I do believe I've formated them correctly..
And I've tried them (reinstall everything) after each format. Same issue each time. I now came to the conclusion that are not the USBs not performing (cannot be that all 3 of them are brocken) , as ABS is each time working perfectly fine. It's either something wrong on the router, or the Skynet. I've start having this issue only since few Skynet releases ago. Before it was working fine.

Did you try EXT4 file system yet just curious?

 

[J4042]

Does anyone have a suggestion for IP lists that are a little less aggressive?

I just install skynet and have ran across a couple sites that I had to whitelist. It's not a huge deal if I run across them but it is a huge pain if I am going to have to whitelist multiple sites a day for each person in my family.

 

[2992]

Did you try EXT4 file system yet just curious?

it doesn't work on Ext3 or Ext4. The message is that it cannot find the partition... even if Skynet is finding the USB during the installation process, at a later stage quits saying it cannot find partition.

Anyway, I think I will give up having Skynet on USB, and I will install it on JFFS (even if RMerlin doesn't recomment that https://github.com/RMerl/asuswrt-merlin/wiki/JFFS). I will keep it on JFFS for a while, under observation.

 

[2992]

seemingly I cannot edit my posts (since I've tried to post l and s without space inbetween), so I write it here now in a separate post: thank you very much @Adamm for you help, extremmely happy to have your support during these days!