Skynet Skynet is blocking github.com?

[dave14305]

I’ve done some more research into the Skynet code and I think the problems some of you are experiencing can be explained as:

1. nslookup github.com only returns 1 IP address, but future calls of nslookup github.com might return a different IP at different times. Not sure if this DNS behavior changed recently or not for them.
2. Skynet’s manual whitelisting of a domain name will only “remember” the IP or IPs returned from the most recent nslookup it runs when refreshing the manual whitelist (i.e. during firewall start, or daily banmalware update). If nslookup github.com later resolves to a different IP (temporarily or not), there is no update to the Skynet whitelist until the next firewall restart or daily banmalware update.
3. Skynet purges any previous manual whitelisted IPs for a manual whitelist of a domain when it refreshes the whitelist, probably to avoid stale IPs from continuing to be whitelisted. Therefore, Skynet does not “remember” previous IPs that github.com resolved to. To me, it’s a design problem in assuming a domain name will not change its DNS response throughout the day. It doesn’t “forget”, it just chooses not to remember old IPs.
4. Whitelisting the banned github.com IP instead of the domain name would avoid this DNS lookup dependency.
5. More energy should be spent logging issues with the Firehol list maintainers to remove the github IP from their lists. See https://github.com/firehol/blocklist-ipsets/issues/188

TL;DR: Try whitelisting the IP 140.82.121.3 instead of the domain github.com.

 

[Jack Yaz]

I’ve done some more research into the Skynet code and I think the problems some of you are experiencing can be explained as:

1. nslookup github.com only returns 1 IP address, but future calls of nslookup github.com might return a different IP at different times. Not sure if this DNS behavior changed recently or not for them.
2. Skynet’s manual whitelisting of a domain name will only “remember” the IP or IPs returned from the most recent nslookup it runs when refreshing the manual whitelist (i.e. during firewall start, or daily banmalware update). If nslookup github.com later resolves to a different IP (temporarily or not), there is no update to the Skynet whitelist until the next firewall restart or daily banmalware update.
3. Skynet purges any previous manual whitelisted IPs for a manual whitelist of a domain when it refreshes the whitelist, probably to avoid stale IPs from continuing to be whitelisted. Therefore, Skynet does not “remember” previous IPs that github.com resolved to. To me, it’s a design problem in assuming a domain name will not change its DNS response throughout the day. It doesn’t “forget”, it just chooses not to remember old IPs.
4. Whitelisting the banned github.com IP instead of the domain name would avoid this DNS lookup dependency.
5. More energy should be spent logging issues with the Firehol list maintainers to remove the github IP from their lists. See https://github.com/firehol/blocklist-ipsets/issues/188

TL;DR: Try whitelisting the IP 140.82.121.3 instead of the domain github.com.

FlexNet confirmed?

 

[thelonelycoder]

FlexNet confirmed?

Get it Mr. Flex aka @dave14305 , i’ll offer to make a choice in amtm for the new repo…

 

[dave14305]

FlexNet confirmed?

Get it Mr. Flex aka @dave14305 , i’ll offer to make a choice in amtm for the new repo…

Fool me once, shame on you. Fool me twice, shame on me!

I would only do it if I could have a mega-thread.

 

[thelonelycoder]

Fool me once, shame on you. Fool me twice, shame on me!

I would only do it if I could have a mega-thread.

… that never expires.

 

[dave14305]

He’s not dead yet.

Skynet blocking GitHub access by "forgetting" existing whitelist entry · Issue #77 · Adamm00/IPSet_ASUS

Brief Description Of Issue Every few days Skynet blocks access to Github.com (e.g. IP 140.82.121.3) due to Github IPs erroneously ending on an IP block list, but somehow the existing whitelisting o...

github.com

Hopefully you can access github.com to read it.

 

[thelonelycoder]

He’s not dead yet.

Skynet blocking GitHub access by "forgetting" existing whitelist entry · Issue #77 · Adamm00/IPSet_ASUS

Brief Description Of Issue Every few days Skynet blocks access to Github.com (e.g. IP 140.82.121.3) due to Github IPs erroneously ending on an IP block list, but somehow the existing whitelisting o...

github.com

Hopefully you can access github.com to read it.

Good to know!

 

[dave14305]

Good to know!

I do think there is still an opportunity for someone to maintain a fork of this project, who is willing to participate and engage with the users on this forum. The barrier of only communicating with the developer via Github is tiresome.

Skynet is a great Addon, in a technical sense. But it now sucks in terms of community engagement, in my brash opinion. Time to shake things up.

 

[thelonelycoder]

I do think there is still an opportunity for someone to maintain a fork of this project, who is willing to participate and engage with the users on this forum. The barrier of only communicating with the developer via Github is tiresome.

Skynet is a great Addon, in a technical sense. But it now sucks in terms of community engagement, in my brash opinion. Time to shake things up.

Bring some (more) activity and excitement back to this forum? How about that!

 

[dave14305]

Bring some (more) activity and excitement back to this forum? How about that!

Exactly!

Sent from my iPhone using Tapatalk

 

[EmeraldDeer]

I’ve done some more research into the Skynet code and I think the problems some of you are experiencing can be explained as:

1. nslookup github.com only returns 1 IP address, but future calls of nslookup github.com might return a different IP at different times. Not sure if this DNS behavior changed recently or not for them.
2. Skynet’s manual whitelisting of a domain name will only “remember” the IP or IPs returned from the most recent nslookup it runs when refreshing the manual whitelist (i.e. during firewall start, or daily banmalware update). If nslookup github.com later resolves to a different IP (temporarily or not), there is no update to the Skynet whitelist until the next firewall restart or daily banmalware update.
3. Skynet purges any previous manual whitelisted IPs for a manual whitelist of a domain when it refreshes the whitelist, probably to avoid stale IPs from continuing to be whitelisted. Therefore, Skynet does not “remember” previous IPs that github.com resolved to. To me, it’s a design problem in assuming a domain name will not change its DNS response throughout the day. It doesn’t “forget”, it just chooses not to remember old IPs.
4. Whitelisting the banned github.com IP instead of the domain name would avoid this DNS lookup dependency.
5. More energy should be spent logging issues with the Firehol list maintainers to remove the github IP from their lists. See https://github.com/firehol/blocklist-ipsets/issues/188

TL;DR: Try whitelisting the IP 140.82.121.3 instead of the domain github.com.

Additionally I would recommend removing list firehol_level3 from Skynet

firewall banmalware exclude firehol_level3.netset

 

[Zastoff]

Seems like Skynet got a update 7.2.6

v7.2.6 · Adamm00/IPSet_ASUS@f0cea07

Add GitHub ASN (AS36459) To Whitelist

github.com

 

[Clark Griswald]

Updated via amtm, and working well (no issues).

 

[protoncek]

Thanks for info, but you said that you didn’t have any problems anway, so it’s no difference for you.
Let’s wait a while for others, who still have skynet installed and had problems before. Hopefully this is a solution.

 

[Clark Griswald]

@protoncek
You are correct.
I was commenting on the ability to update via amtm, and that I experienced no issues with the update, nor with github access.

 

[TheStork]

I do think there is still an opportunity for someone to maintain a fork of this project, who is willing to participate and engage with the users on this forum. The barrier of only communicating with the developer via Github is tiresome.

Skynet is a great Addon, in a technical sense. But it now sucks in terms of community engagement, in my brash opinion. Time to shake things up.

I reported the issue on GitHub and 2 days later there was a new version of the add-on addressing the issue. Not sure I’d agree addressing issues in that fashion is tiresome.

I’m getting a free tool with free support, so I’ll respect the developer’s desired approach for engagement, because really I am getting a free lunch, and those are rare. I’m just happy the issue seems to have been fixed, and seemed to be darn quick too from when I reported it on GitHub.

 

[dave14305]

I reported the issue on GitHub and 2 days later there was a new version of the add-on addressing the issue. Not sure I’d agree addressing issues in that fashion is tiresome.

I’m getting a free tool with free support, so I’ll respect the developer’s desired approach for engagement, because really I am getting a free lunch, and those are rare. I’m just happy the issue seems to have been fixed, and seemed to be darn quick too from when I reported it on GitHub.

2 days is great! Too bad for the Skynet users that this thread started on August 31. Presumably none of the users reporting problems had Github accounts, until you showed up. Thanks!

 

[thelonelycoder]

2 days is great! Too bad for the Skynet users that this thread started on August 31. Presumably none of the users reporting problems had Github accounts, until you showed up. Thanks!

With all due respect to @Adamm but interaction on this board with the developer is still the preferred way.
I hope you make a decision @dave14305

 

[protoncek]

What’s the story about this? Is it working ok now?

 

[Zastoff]

What’s the story about this? Is it working ok now?

Skynet works fine for me with the latest updates, No github issues.