Skynet Skynet is blocking github.com?

  • ATTENTION! You'll notice a Prefix dropdown when you create a thread. If your post applies to one of the topics listed, please use that Prefix for your post. When browsing the thread list you can use the Prefix to filter the view.
  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

dave14305

Part of the Furniture
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

Part of the Furniture
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?
 

dave14305

Part of the Furniture

thelonelycoder

Part of the Furniture
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

Part of the Furniture

thelonelycoder

Part of the Furniture

dave14305

Part of the Furniture
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. :p
 

thelonelycoder

Part of the Furniture
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. :p
Bring some (more) activity and excitement back to this forum? How about that!
 

EmeraldDeer

Very Senior Member
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
Code:
firewall banmalware exclude firehol_level3.netset
 

Clark Griswald

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

protoncek

Occasional Visitor
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

Senior Member
@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

Occasional Visitor
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. :p
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

Part of the Furniture
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

Part of the Furniture
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
 

Zastoff

Very Senior Member

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top