On 2016-02-26 14:56, Mark Brown wrote:
> On Fri, Feb 26, 2016 at 02:17:46PM +0100, Jeroen Massar wrote:
>> On 2016-02-26 13:55, Mark Brown wrote:
>>> On Wed, Feb 17, 2016 at 11:03:41PM +0100, Jeroen Massar wrote:
>
>>>> No VPN-alike tool does such a thing. OpenVPN for instance also nicely
>>>> aborts as it can't do anything with that situation. SSH tunnels also
>>>> nicely state "no network".
>
>>> This is true for things intended to be used interactively from a UI but
>>> not for everything, for example IPSEC tunnels establised with FreeS/WAN
>>> can be started with just local configuration.
>
>> There is no external configuration for IPSEC. You just configure the
>> parameters statically on both ends, and presto.
>
> Yes, everything is stored in local config files which does make things a
> easier to implement.
Thus, how would you do it when that is not the case?
>>> The UI presented for
>>> AICCU is much more that of a daemon than of a GUI or something designed
>>> to tie into ifup/ifdown type scripting. It's really not obvious how to
>>> robustly start AICCU in a way that fits well with the UI as it stands,
>>> the constraints it has are pretty tight.
>
>> Which UI?
>
> The way it interacts with the rest of the system and hence the user is a
> UI.
(I think you want to rephrase that sentence ;)
>>>> It is helping: it logs an error message stating you to fix your network.
>
>>> Compared to other system daemons this is highly unusual behaviour, I
>>> think this is my main point - there's a conflict between the interface
>>> presented and the error handling.
>
>> Since when is reporting an error in the logs unusual for a daemon?
>
>> Which "interface" are you exactly talking about?
>
> Reporting errors via logs is not unusual. Exiting when confronted with
> transient runtime errors is much more unusual.
AICCU does not know that the problem is 'transient' or 'persistent'.
Only a human knows this is the case and how to resolve the problem.
Make a typo in nginx, apache etc config, they will all bail out as they
cannot resolve it either.
Same situation: broken configuration -> log & exit.
That is the model that AICCU operates under as it is one that makes sense.
Keeping on retrying does not resolve anything and just makes things magic.
>>>> Your logs will love being spammed with that amount of activity.
>
>>> If it tries and/or logs excessively then sure. This is a readily
>>> solvable problem though.
>
>> How is such a thing solvable? Are you going to suppress some but not all
>> messages?
>
> That's one option but I was more thinking of things like rate limiting
> the activity being logged (which would be needed to avoid hammering on
> the TIC, assuming we get far enough to even talk to it).
Do you also rate limit these events on the other side and every hop in
between of that connection?
What about the router, DNS server and many other elements that are involved?
As you do not know what the actual problem is, how do you know what to
rate limit, or when that problem goes away?
>>>> It is not a solution in any way: fix your network instead.
>
>>> ...and then manually kick AICCU. It's the manually kick that isn't
>>> great, especially as IPv4 will recover by itself and most things will
>>> fall back to IPv4 which makes the problem less obvious than it might
>>> otherwise be.
>
>> Why is that "not great"?
>
> It's not a good user experience, the whole "see if the network came up
> then try again" loop is something that everything else in my system
> (mail, NTP, whatever) does without manual intervention.
Those configurations you are talking about are static, there are no
dynamic parts there.
>> How would AICCU figure out otherwise that you fixed your network?
>
> By waiting some reasonable time period, trying again and finding things
> work.
You mean: keep on hammering on something, even though the real problem
has not been resolved whatsoever...
>> How will "IPv4 recover by itself"?
>
> In the case of my home network the cable modem, router and the network
> end will decide they'll talk to each other again through a similar
> process of monitoring links and retrying to the one I'm suggesting.
All your hosts monitor all those links? How do they do that? Is that
standard in Debian or for that matter any other OS?
Also, every other VPN tool does that "Can't reach other side, bye bye".
I am pretty sure that even more advanced UIs (Windows, OSX) towards
users also nicely show "it is broken, try again later, quiting now".
But they can as there the user is most very likely looking at the
desktop. The problem with Linux/BSD in general is that the user is not
sitting behind the screen where that warning goes.
>> Is the IPv4 connectivity also provided by a VPN-alike tool?
>
> No (well, I'm not actually sure how VPN like cable modems are TBH -
> there is some other network going on and for stuff over phone lines it
> pretty much is a tunnel over the phone network, especially in the UK
> where the IPs all share a local loop infrastructure).
Cable == DOCSIS in most cases, and that is effectively a tunnel.
But in those situations you are not crossing several other parties to
reach the other side, the path between the 'modem' (be that cable or
PPP) and the server side of that path is controlled by one single entity.
Remember with a typical AICCU setup you have:
```
[Host] - {Network} - {Internet} - {TIC server}
\
\--- {PoP}
```
Hence, any of those parts, in both directions, and many more (eg DNS,
NTP, firewall) can be broken.
How exactly do you monitor or compare that? Keep on spewing packets to
check all those things? It does not solve anything and just causes more
garbage on the Interwebz.
Especially firewall or magic broken connectivity (eg only packets < 512
come through, which happens sometimes on DOCSIS) can give all kinds of
effects where some things come through and others do not; hence testing
for it does not help either.
>>> I think some of what might be happening is that there's some noticable
>>> proportion of people who feel they need to restart AICCU a lot are doing
>>> so to work around things like transient errors on startup and are doing
>>> it in an unsophisticated way due to inexperience or thoughtlessness.
>
>> No, those restarts are happening become some person in a distribution
>> position (eg Debian, OpenWRT developers) made that decision.
>
>> The user only notices it when they are locked out though. They typically
>> do not read the logs...
>
> So you're saying you're having this problem as a result of distributors
> shipping this sort of hack rather than end users?
We are having TIC-hammering issues as there are both users and a a
couple of distributions that have been thinking they know better.
For instance this fun one is in Debian, still...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689584
and I won't even bother to OpenWRT or MacPorts....
> That is very surprising I have to say. It certainly isn't Debian at present
> (it just
> tries to start once),
Patently false, see the above referenced bug (#689584). Closing a laptop
lid / sleep and voila, re-open and it restarts.... and as per the notes
there that 'patch' was not even properly tested when it was added.
> and the wording of the warnings suggested it was
> more likely to be end users configuring things.
Both users and distros do it.... while, you know, they could contact
i...@sixxs.net.... but people do not unfortunately. Hence why I am
fighting hard against those changes.
>>> Were the daemon to handle this in a less surprising fashion that'd most
>>> likely greatly reduce the number of people doing this.
>
>> Please elaborate how the daemon could handle what in what exact way.
>
> For the portion of things prior to getting a connection to the server
> I'd expect it to sit and retry at some reasonable interval (once every
> ten minutes or something off the top of my head).
Forever? As we see that from some IP addresses.
Nobody there reads the logs, nobody fixes things. Hence it is not a
solution in any way or form.
>> How can it know that "the network is fixed"?
>
>> Is there something magic that I am not aware of?
>
>> Broken connectivity can be because of way too many reasons.
>
> Does it matter why the connectivity was failing if it starts working
> again?
It matters, as magic does not exist.
Keeping on ramming on something will not make it work magically either.
>>>> This as AICCU is an implementation of a transition technology to allow
>>>> someone to play with IPv6 and learn from it, it is not a permanent
>>>> solution to get IPv6 or a static IPv6 prefix..... one day, it will all
>>>> go away.
>
>>> It also seems like if the server side were more widely available it'd be
>>> really helpful for VPN providers.
>
>> What "server side"?
>
> The software that runs on the provider side (so the TIC and the PoPs).
You could just ask for the crown jewels of a project of course ;)
>>>> Hence, if you are depending so much on it, you might want to look at
>>>> native IPv6... or solving the problem for one of the many VPN tools that
>>>> are out there.
>
>>> VPN tools aren't much help without something on the other end.
>
>> Which "other end"?
>
> Again, VPN provider. I keep looking for a good commercial IPv6 VPN
> provider,
SixXS is not a commercial entity in any way or form. It is just a
(mostly) fun hobby project that is there to provide IPv6 connectivity so
that the transition to IPv6 can actually will ever happen. Unfortunately
it seems we have bitten ourselves in our foot, because that transition
is taking waaay too long and some ISPs are not moving at all.
There are literally thousands of commercial VPN providers, ask them for
solving the actual problem that you seem to be having.
> especially for use with my laptop (where SiXXS isn't really
> appropriate as it's very mobile) but never managed to come up with
> anything useful that I could even look at client side tooling for.
SixXS is perfectly useable on a mobile device.
>From our stats we know that several thousand folks use AYIYA tunnels on
their mobile devices (Android) and that they are extremely happy with
it. Though, these folks will have a lot of pain when SixXS shuts the
doors as the transition to IPv6 is over....
Greets,
Jeroen
