|
ISK-deployment
![[de]](/s/countries/de.gif) Shadow Hawkins on Wednesday, 06 August 2014 12:09:25
Dear SixXS-team,
thanks a lot for your service, it is extremely helpful to me!
I have one question - I am right now using an AYIYA tunnel, and received the 5 ISK after the first week of activity. Right now, I see an uptime of 22 days in the control panel, in the documentation, I read something like "5 more ISK per two weeks uptime". I did not receive any ISK after the first 5.
Which is the correct number to look for when following the statement "credits will be given every two weeks when the tunnel is alive"?
I am asking because I would like to create a second tunnel for my workplace (under the same account).
A related question: Is there an easy test (for linux) to find out whether proto-41 traffic is passed through without creating a heartbeat-tunnel first? I am sure there is no NAT and the firewall should have only ports blocked (but no protocols), but it would be nice to be able to test it first.
Thanks for all,
Oliver
ISK-deployment
...and received the 5 ISK after the first week ... I did not receive any ISK after the first 5.
Which one is it?
Is there an easy test (for linux) to find out whether proto-41 traffic is passed through without creating a heartbeat-tunnel first?
hping3 can help, no heartbeat is needed for this as a PoP will just respond with an ICMP error, at least indicating that you are not allowed to send from that IP.
ISK-deployment
Shadow Hawkins on Wednesday, 06 August 2014 20:34:00
Jeroen Massar wrote:
>...and received the 5 ISK after the first week ... I did not receive any ISK after the first 5.
Which one is it?
Sorry, I was not very clear:
- One week after tunnel creation, I received 5 ISK (in the log: Dynamic Tunnel is alive for one week), as expected. These are the only ISK I have received up to now.
- According to the "Tunnel information" page, I see an uptime of "Uptime22 days".
In the FAQ-entry on ISK, I read that 5 ISK are given to AYIYA-users every 2 weeks when the tunnel is alive, so I would expect that 5 more ISK are given after "Uptime 21 days". This did not happen until now, though - am I looking at the wrong number?
> hping3 can help, no heartbeat is needed for this as a PoP will just respond with an ICMP error, at least indicating that you are not allowed to send from that IP.
Thanks for the hint!
I tried:
hping3 somePoP -H 41 -d 10
and did not receive the ICMP error with tcpdump, now of course this could also be because our firewall policy blocks incoming ICMP (to "hide" active hosts), as I learnt today - I guess this means I have to go with AYIYA?
Thanks,
Oliver
ISK-deployment
This did not happen until now, though - am I looking at the wrong number?
Yes, as the host has to ping all the time, not just some moments. Your graph shows huge holes where it did not respond.
and did not receive the ICMP error with tcpdump, now of course this could also be because our firewall policy blocks incoming ICMP (to "hide" active hosts),
What exactly are you trying to 'protect', there are a lot of ways to figure out what hosts are alive without using ICMP...
I guess this means I have to go with AYIYA?
Instead of trying to circumvent the firewall, why not fix that instead?
ISK-deployment
Shadow Hawkins on Wednesday, 06 August 2014 21:26:28
Jeroen Massar wrote:
Yes, as the host has to ping all the time, not just some moments. Your graph shows huge holes where it did not respond.
Ok - then my understanding was really wrong, I turn this machine off during night to save power, so no ISK for me then ;-).
What exactly are you trying to 'protect', there are a lot of ways to figure out what hosts are alive without using ICMP...
I know. This "security by partial imperfect obscurity"-policy was not my decision alone, so I can not change it - at least it proved effective against very annoying scans against all our IPv4 address range from outside, most hackers are probably looking for "easier targets" now.
At least I triggered the discussion to implement / get native IPv6 at my workplace in the not-so-far future, maybe we will then do a test-setup outside of that firewall, with a different account.
Thanks for all your explanations!
Oliver
I guess this means I have to go with AYIYA?
Instead of trying to circumvent the firewall, why not fix that instead?
ISK-deployment
![[ch]](/s/countries/ch.gif) Shadow Hawkins on Wednesday, 24 September 2014 05:54:21
Jeroen Massar wrote:
Yes, as the host has to ping all the time, not just some moments. Your graph shows huge holes where it did not respond.
Hhhmm. I just checked one of my tunnels (T78438). It is reported to have a long enough uptime:
Uptime 163 days (based on latency check)
and there are no holes in the graph of last month. Still, the last ISKs I got (according to my Log) are over three weeks ago:
2014-09-01 01:19:12 Dynamic Tunnel T78438 is alive for 20 weeks
What is the reason for not getting ISKs here?
ISK-deployment
It is reported to have a long enough uptime
That is the uptime since it was dead for more than a day, not the uptime since it missed a ping.
What is the reason for not getting ISKs here?
You are getting ISK, check your logs. Also note that dynamic tunnels only get ISK every two weeks.
ISK-deployment
Shadow Hawkins on Wednesday, 24 September 2014 15:51:23
Hi Jeroen
Thanks for your quick reply.
Jeroen Massar wrote:
...not the uptime since it missed a ping.
I thought to have read earlier that missing a few pings does not affect the uptime that qualifies for new ISK. As I can't see any holes in the latency graph of last month for T78438 I don't understand why this tunnel did not get new ISK.
You are getting ISK, check your logs. Also note that dynamic tunnels only get ISK every two weeks.
You are right, I am happily getting ISK, but only for T89862. For T78438 I did not since about 3 weeks. These are the top4 lines of my log:
2014-09-24 05:54:20 Posted a message to the forum
2014-09-20 01:17:18 Dynamic Tunnel T89862 is alive for 10 weeks 5
2014-09-06 01:17:18 Dynamic Tunnel T89862 is alive for 8 weeks 5
2014-09-01 01:19:12 Dynamic Tunnel T78438 is alive for 20 weeks 5
I believe that I should have received ISK for T78438 on 2014-09-15... I would like to understand why that did not happen on Sept 15. Currently it seems that I have no means to determine reliably if (and since when) my current uptime qualifies for ISK or not. This makes it very hard to determine if there is (or was) a problem with the connection.
ISK-deployment
If the system did not give you credits, it is because you did not qualify for them.
ISK-deployment
Shadow Hawkins on Monday, 29 September 2014 05:55:29
Hi Jeroen,
If the system did not give you credits, it is because you did not qualify for them.
Funny. Looking at my log this morning and showing only the entries for the tunnels giving ISK, I see:
2014-09-29 01:18:29 Dynamic Tunnel T78438 is alive for 24 weeks 5
2014-09-20 01:17:18 Dynamic Tunnel T89862 is alive for 10 weeks 5
2014-09-06 01:17:18 Dynamic Tunnel T89862 is alive for 8 weeks 5
2014-09-01 01:19:12 Dynamic Tunnel T78438 is alive for 20 weeks 5
2014-08-23 01:16:39 Dynamic Tunnel T89862 is alive for 6 weeks 5
ISK for every 2nd week for T89862, but for T78438 the credits for the 22nd week were missing, but exactly 4 weeks after the credits for 20th week, the credits for the 24th week came.
I still don't understand how it works. Is the number of "missing pings allowed" so low that it can disqualify for getting ISKs but I can't see holes in the latency monthly latency graph? I do see a few bumps in the Loss statistics, but there is no real difference between the weeks 36/37 and 38/39...
|
on Wednesday, 06 August 2014 19:03:12
Posting is only allowed when you are