dave14305
Part of the Furniture
If you search the system log fori reran with skynet restarted & here is output:
firewall-start, does it always show wan0?
Code:
grep firewall-start /jffs/syslog.log-1 /jffs/syslog.log
If you search the system log fori reran with skynet restarted & here is output:
firewall-start, does it always show wan0?grep firewall-start /jffs/syslog.log-1 /jffs/syslog.log
no, this is the orderIf you search the system log forfirewall-start, does it always showwan0?
Code:grep firewall-start /jffs/syslog.log-1 /jffs/syslog.log
I guess this is the heart of the problem. The wan interface name is part of the Skynet rules, and yours seems to start as eth0 then change to wan0. Never seen that before.no, this is the order
Jan 4 15:13:39 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
Jan 4 15:13:39 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
Dec 31 18:01:11 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Dec 31 18:01:11 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Dec 31 18:01:24 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
Jan 4 15:13:39 custom_script: Running /jffs/scripts/firewall-start (args: wan0)
i reposted log with lockfile arguments above, do you think that could be the issue?I guess this is the heart of the problem. The wan interface name is part of the Skynet rules, and yours seems to start as eth0 then change to wan0. Never seen that before.
Thank you for including the entire selected country code list in the skynet.cfg now as well... much easier to finally see what was included and what was not.I've pushed v8.0.9
This is odd...I have all default settings in skynet and mine didn't automatically update. I don't think I never had Skynet update automatically.I had the option to auto update skynet to a new version set to 'disable' (I do so because there have been versions in the past that were caused issues).
However, it seems like this latest version (8.0.9) auto-updated anyway. I have double checked my setting was indeed 'disabled'.
Was this option bypassed somehow by this release or is there a bug ?
Also, as many of us use our routers for business use, can there be a a preprod version published so people can test? Maybe it is only me but we should not push something without testing.
cru l | grep Skynet
cru l | grep Skynet
[Ignore the actual values, look at the #labels]
25 20 * * * sh /jffs/scripts/firewall banmalware #Skynet_banmalware#
20 1 * * Mon sh /jffs/scripts/firewall update check #Skynet_checkupdate#
0 * * * * sh /jffs/scripts/firewall save #Skynet_save#
31 */12 * * * sh /jffs/scripts/firewall debug genstats #Skynet_genstats#
30 1 * * Mon sh /jffs/scripts/firewall update #Skynet_autoupdate#
[1] --> Skynet Auto-Updates | [Disabled]
cru d Skynet_autoupdate
Speaking for myself (Not the creator of the script)I had the option to auto update skynet to a new version set to 'disable' (I do so because there have been versions in the past that were caused issues).
However, it seems like this latest version (8.0.9) auto-updated anyway. I have double checked my setting was indeed 'disabled'.
Was this option bypassed somehow by this release or is there a bug ?
Also, as many of us use our routers for business use, can there be a a preprod version published so people can test? Maybe it is only me but we should not push something without testing.
It was a bug that was fixed in 8.0.9, so the next version update (8.1.0?) should not auto-upgrade. Anything between 8.0 and 8.0.8 will likely auto-upgrade to 8.0.9.I had the option to auto update skynet to a new version set to 'disable' (I do so because there have been versions in the past that were caused issues).
However, it seems like this latest version (8.0.9) auto-updated anyway. I have double checked my setting was indeed 'disabled'.
Was this option bypassed somehow by this release or is there a bug ?
Yes, Skynet blocks incoming WAN connections matching the ban list regardless of whether it is in response to an outbound request. Most firewall traffic outside of Skynet will allow return traffic to pass, but Skynet operates in the netfilter raw table which ignores any existing conntrack states.Doing "Inbound only", is it normal that the Malware list is still blocking the ips/domains when the source is a local device, so initiating an outbound connection?
Thx. I checked and there are no 'old' skynet cron jobs, only current, AND the setting for 'Skynet Auto-Updates' is indeed 'Disabled' . Seems like , per post 234, that there is a known bug.run the following:
Code:cru l | grep Skynet
You should get
Code:cru l | grep Skynet [Ignore the actual values, look at the #labels] 25 20 * * * sh /jffs/scripts/firewall banmalware #Skynet_banmalware# 20 1 * * Mon sh /jffs/scripts/firewall update check #Skynet_checkupdate# 0 * * * * sh /jffs/scripts/firewall save #Skynet_save# 31 */12 * * * sh /jffs/scripts/firewall debug genstats #Skynet_genstats#
If you get something labeled as '#Skynet_autoupdate#' such as :
Code:30 1 * * Mon sh /jffs/scripts/firewall update #Skynet_autoupdate#
the old autoupdate cron entry is still there !!!???
Ensure that you have set in settings (option 11) the following:
Code:[1] --> Skynet Auto-Updates | [Disabled]
run the following to remove the 'autoupdate' cron entry:
Code:cru d Skynet_autoupdate
ensure you have the #Skynet_checkupdate# labeled entry.
(This is set when you set 'Skynet Auto-Updates' to 'Disabled')
Thanks @dave14305 for letting me know of the existing 'bug'. I'll see what happens whenever the next version of skynet is relaesed.It was a bug that was fixed in 8.0.9, so the next version update (8.1.0?) should not auto-upgrade. Anything between 8.0 and 8.0.8 will likely auto-upgrade to 8.0.9.
Yes, Skynet blocks incoming WAN connections matching the ban list regardless of whether it is in response to an outbound request. Most firewall traffic outside of Skynet will allow return traffic to pass, but Skynet operates in the netfilter raw table which ignores any existing conntrack states.
Thank you very much.Yes, Skynet blocks incoming WAN connections matching the ban list regardless of whether it is in response to an outbound request. Most firewall traffic outside of Skynet will allow return traffic to pass, but Skynet operates in the netfilter raw table which ignores any existing conntrack states.
With logging enabled in Skynet, it should be logging any blocked connection regardless of direction. What do your rules look like?What is "disturbing" in this situation (Skynet doing inbound only and Malware list) is the fact that real time logs don't display information, we have to guess to find what is causing the trouble.
iptables -t raw -S
Here is the output:With logging enabled in Skynet, it should be logging any blocked connection regardless of direction. What do your rules look like?
Code:iptables -t raw -S
We use essential cookies to make this site work, and optional cookies to enhance your experience.