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. > 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? >>> I'd argue that AICCU can do things to help. > >> 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? >>> I'd expect it to try indefinitely. I'd not expect it to hammer on >>> things but rather to try periodically. > >> 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? Please note that people who do not look at logs, will never figure out that there is a statement in the logs. If there is 1 or thousands of messages. >> 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"? How would AICCU figure out otherwise that you fixed your network? How will "IPv4 recover by itself"? Is the IPv4 connectivity also provided by a VPN-alike tool? >>> constantly) and to have options to control that behaviour for cases >>> where there are concerns about resource usage. > >> You, and many others, seem to not understand that we have been trying >> fight people from restarting AICCU for a long time now. > > No, I've seen the stuff about not hammering on the TIC. You might have seen it, but do you understand it? > The other way > of looking at this is that if there are very large numbers of users who > are trying to do this then probably there is some need that is not being > met. Very large numbers? Please remind yourself that if something gets built into something and then distributed that it automatically affects every single one of the people who automatically gets to run that code. > 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... > 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. > Probably there are other people doing this for reasons I can't think of > right now of course but I'd not be surprised if they were in the > minority. Probably there are people who want to have a pony. Without actually describing what the problem is, and how something can be properly resolved, there is really little to state about things. >> If you notice that it is does not start properly: make sure that the >> environment is correct for starting it in the first place. > >> There is nothing AICCU can do about your network being broken when you >> try to start it. > > It can't fix the network by itself, no. It can recover when the network > is fixed though. 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. >> And in the end..... more importantly: > >> Did you call your ISP for native IPv6? > > Yes, not in this particular campaign but recently enough. I'd actually > be fairly happy with a commercial VPN service but can't seem to find one > that's able to cope with dynamic IPs. Sounds you have a business case. >> 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"? >> 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"? Greets, Jeroen
