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. > > 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. > >> 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. > >> 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). > >> 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. > How would AICCU figure out otherwise that you fixed your network? By waiting some reasonable time period, trying again and finding things work. > 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. > 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). > > 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? That is very surprising I have to say. It certainly isn't Debian at present (it just tries to start once), and the wording of the warnings suggested it was more likely to be end users configuring things. > > 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). > 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? > >> 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). > >> 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, 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.
signature.asc
Description: PGP signature
