Modify

Opened 6 years ago

Closed 6 years ago

Last modified 3 years ago

#11592 closed defect (fixed)

Aiccu should not reconnect so often (can cause a ban on TIC server)

Reported by: bastian433@… Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc:

Description

From doc/README in the aiccu distribution:

WARNING: never run AICCU from DaemonTools or a similar automated
'restart' tool/script. When AICCU does not start, it has a reason
not to start which it gives on either the stdout or in the (sys)log
file. The TIC server *will* automatically disable accounts which
are detected to run in this mode. Use 'verbose true' to see more
information which is especially handy when starting fails.

eventually it will go:

{{{Jun 4 21:23:18 OpenWrt local7.err syslog: TIC Server is currently not available

Jun 4 21:23:18 OpenWrt local7.err syslog: Retrying TIC login in 120 seconds...
Jun 4 21:25:19 OpenWrt local7.err syslog: TIC Server is currently not available
Jun 4 21:25:19 OpenWrt local7.err syslog: Retrying TIC login in 120 seconds...
Jun 4 21:27:19 OpenWrt local7.err syslog: TIC Server is currently not available
Jun 4 21:27:19 OpenWrt local7.err syslog: Retrying TIC login in 120 seconds...
Jun 4 21:29:20 OpenWrt local7.err syslog: TIC Server is currently not available
Jun 4 21:29:20 OpenWrt local7.err syslog: Retrying TIC login in 120 seconds...
}}}

It means in my case I am banned from the TIC server, it should really stop after a few retries and not start with 10/20 intervals.

Somehow someone decided to put it in:

https://dev.openwrt.org/browser/packages/ipv6/aiccu/Makefile?rev=28796

Attachments (0)

Change History (8)

comment:1 follow-up: Changed 6 years ago by jow

  • Resolution set to wontfix
  • Status changed from new to closed

If the server is not available it sees no request and thus cannot disable any accounts.
If we take out the reconnect again another one will complain that aiccu does not reconnect.

I suggest to find a less facist broker or one that does not rely on proprietary protocols and clients.

comment:2 in reply to: ↑ 1 ; follow-up: Changed 6 years ago by jeroen@…

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Replying to jow:

If the server is not available it sees no request and thus cannot disable any accounts.

As the log above only shows "TIC Server is currently not available", it could mean one of several things: it could be that DNS is broken and that thus the host indeed could not be reached, it could also mean that an attempt was made and that the request was rejected. Only a verbose log would show what the real reason is.

The original AICCU would just exit, as it has no way to resolve whatever the problem is.

If we take out the reconnect again another one will complain that aiccu does not reconnect.

Obviously you missed the portion from the README in the AICCU distribution, quoted by the reporter, which clearly states it should never automatically reconnect. There is nothing AICCU can do to resolve any network issues and that is why the original code exits. It is there for a reason, it is because the problem does not get resolved anyway, by exiting people do notice the problem and will actually resolve it.

Do you also automatically restart apache2, bind or sendmail when they exit because their configuration is broken?

I suggest to find a less facist broker or one that does not rely on proprietary protocols and clients.

"Facist"? Wow, the nazi card is thrown quickly here and obviously without reason. What exactly makes them facist? Please do enlighten your concerns.

Also, what protocol is proprietary? All protocols are documented in IETF styled drafts and the source for it is open, aiccu is the source, it is even with a BSD license, it cannot be more open than this.

SixXS indeed set a restriction on not automatically reconnecting as it is not needed. The reason that AICCU exists is because there is an issue that the operator has to resolve, the tool cannot do so as it does not know how.

The only thing that happens now is that clients who do this keep on hammering on the TIC servers and because we do want other users to be able to keep on using the service those clients get blocked. Nothing "facist" about letting real users actually use a free service....

comment:3 in reply to: ↑ 2 ; follow-up: Changed 6 years ago by jow

As the log above only shows "TIC Server is currently not available", it could mean one of several things: it could be that DNS is broken and that thus the host indeed could not be reached, it could also mean that an attempt was made and that the request was rejected. Only a verbose log would show what the real reason is.

The original AICCU would just exit, as it has no way to resolve whatever the problem is.

  • AICCU exits because of a bad system, NTP time on OpenWrt is synced asynchronously, the utility should recover as soon as the time discrepancy is solved.
  • AICCU exits because the server is not reachable, the utility should retry to resolve the TIC server until it is reachable.

Neither of these failure conditions should lead to a forceful client shutdown, that is extremely poor software architecture for a unix service intended for unattended operation.

Obviously you missed the portion from the README in the AICCU distribution, quoted by the reporter, which clearly states it should never automatically reconnect. There is nothing AICCU can do to resolve any network issues and that is why the original code exits. It is there for a reason, it is because the problem does not get resolved anyway, by exiting people do notice the problem and will actually resolve it.

The way it is implemented makes it completely useless in an unattended setup. In mobile scenarios, when there are unreliable or changing wan links, the utility should be able to initiate sessions as soon as connectivity becomes available not exit and demand user interaction whenever there are transient network issues. If DNS is yet unavailable because the dial in is in progress or if the system clock is off then AICCU can retry just fine without bothering TIC servers since there is guaranteed to be no connection attempt to the remote side.

The AICCU utility is actually advertised as solution to dynamically changing links, yet it is totally unusable as-is - especially as it fails to work with PPPoE connections and frequently changing iface indexes (1)(2)(3)(4)(5)(6). A fixed version was promised (7)(8) but only released as closed source windows executable (9) and no offical fix has been made public (10).

Do you also automatically restart apache2, bind or sendmail when they exit because their configuration is broken?

No, but I do restart them if the interfaces they serve or the mount points they read from are changing.
However luckily, in contrast to AICCU, those services tend to be able to cope with changing environments.

Also, what protocol is proprietary? All protocols are documented in IETF styled drafts and the source for it is open, aiccu is the source, it is even with a BSD license, it cannot be more open than this.

Attempts to implement alternative clients using the existing protocol descriptions apparently got sabotaged by SixXS (11).

SixXS indeed set a restriction on not automatically reconnecting as it is not needed.

Your definition of reconnects is flawed and prevents downstream users from fixing actual problems while a fixes client release is held back and the problem argued away. Common sense dictates that it would legitimate to retry a connection attempt as long as no actual contact has been made to the TIC server, yet solutions that attempt to work around AICCUs deficiencies tend to get censored (12) or demanded to get removed despite obvious client problems with dnyamic links (13).

The reason that AICCU exists is because there is an issue that the operator has to resolve, the tool cannot do so as it does not know how.

In our case NTP and DNS are expected to become available without intervention, just potentially delayed due to the nature of the IPv4 upstream connection, they're just not available when the AICCU service is started - revealing yet another architectural weakness of the offically blessed implementation - it depends on system conditions (always available DNS, always correct NTP) which are simply not satisfiable by an embedded router with dialup connection.

Despite this, several tickets outlined below show that the client simply fails with reconnecting, thus essentially forcing users to manually intervene in order to reestablish tunnels after an automatic line reconnect, thus making the utility essentially unusable for its intended purpose - especially with regard to the de-facto ban of any reconnect measures to kick the bugged client back into operation.

The only thing that happens now is that clients who do this keep on hammering on the TIC servers and because we do want other users to be able to keep on using the service those clients get blocked. Nothing "facist" about letting real users actually use a free service....

See (14).

So to summarize:

  • the initialization of AICCU is broken by design
  • the reconnect handling of AICCU is broken, a fix is being held back or not really developed
  • workarounds violate the "no reconnect ever"-rule, leading to account suspension, bans and censorship
  • alternative implementations are being rejected
  • no updates since 2007 have been made to the client despite numerous well known problems



comment:4 in reply to: ↑ 3 ; follow-up: Changed 6 years ago by jeroen@…

Replying to jow:

As the log above only shows "TIC Server is currently not available", it could mean one of several things: it could be that DNS is broken and that thus the host indeed could not be reached, it could also mean that an attempt was made and that the request was rejected. Only a verbose log would show what the real reason is.

The original AICCU would just exit, as it has no way to resolve whatever the problem is.

  • AICCU exits because of a bad system, NTP time on OpenWrt is synced asynchronously, the utility should recover as soon as the time discrepancy is solved.
  • AICCU exits because the server is not reachable, the utility should retry to resolve the TIC server until it is reachable.

Neither of these failure conditions should lead to a forceful client shutdown, that is extremely poor software architecture for a unix service intended for unattended operation.

AICCU is not intended for 'unattended operation'. It is intended to automate tunnel configuration. When the environment it is asked to run in is broken though it cannot fix that environment it exits.

The same way that Apache, BIND, sendmail, postfix and a lot of other services exit.

The difference with those services though is that they do not reach out to an external service at start time to fetch their configuration details.
AICCU does do that. Thus if it gets restarted it reaches out to that external service. If it gets restarted too quickly it reaches out to that service too often and thus that service will block that client.

In the original AICCU code that does not happen (unless somebody puts loops into the code or scripts a loop etc).
Instead the user will notice "hey it is broken", check the logs and fix the problem that is reported.

These are restrictions that are very well known. As such, live with those restrictions and fix those issues instead of hacking around it and causing problems to a service you do not run.

If you would add a wget loop to fetch Facebook/Google/Yahoo/Bing pages or anything like that you will trigger their DDoS limits also at one point or another, then again their infrastructure is quite a bit larger than that of SixXS as such their limits are much and much higher, likely that they can't care about that single user hitting them.

For SixXS though we do not have unlimited resources, as such we nicely block that client from connecting to the TIC service which resolves the overload problem and we also notify the user where possible by email of them doing so.

Note that even though the email notes that the account gets blocked, it is only the TIC login that gets blocked, nothing else.

Obviously you missed the portion from the README in the AICCU distribution, quoted by the reporter, which clearly states it should never automatically reconnect. There is nothing AICCU can do to resolve any network issues and that is why the original code exits. It is there for a reason, it is because the problem does not get resolved anyway, by exiting people do notice the problem and will actually resolve it.

The way it is implemented makes it completely useless in an unattended setup.

It is not meant for unattended. It reports things to log files that are intended for a user to read.

In mobile scenarios, when there are unreliable or changing wan links, the utility should be able to initiate sessions as soon as connectivity becomes available not exit and demand user interaction whenever there are transient network issues

There is no need for this. AICCU is only needed to start once (1), fetch it's config from the TIC server and that is it. It afterwards never have to perform TIC as it knows the configuration values it gets from TIC.

If DNS is yet unavailable because the dial in is in progress or if the system clock is off then AICCU can retry just fine without bothering TIC servers since there is guaranteed to be no connection attempt to the remote side.

If DNS is unavailable, do not start AICCU.
If the clock is wrong, do not start AICCU.

Simple as that. These are things you can test for outside of AICCU.

The AICCU utility is actually advertised as solution to dynamically changing links, yet it is totally unusable as-is - especially as it fails to work with PPPoE connections and frequently changing iface indexes (1)(2)(3)(4)(5)(6). A fixed version was promised (7)(8) but only released as closed source windows executable (9) and no offical fix has been made public (10).

Thank you for referencing those links that have not been reported to info@… before. The fix is trivial, just use an unconnected UDP socket instead of a connected one and all is fine.

The fixed version has not been released though as we do not have had time to properly test it on the myriad of platforms and configuration environments that AICCU is run on and as the majority just works better to keep that version out for the time being.

Note that the Windows version is not closed source, it is exactly the same source tree as the unix version and released under the BSD license.

Do you also automatically restart apache2, bind or sendmail when they exit because their configuration is broken?

No, but I do restart them if the interfaces they serve or the mount points they read from are changing.
However luckily, in contrast to AICCU, those services tend to be able to cope with changing environments.

If you mess up your configuration file Apache nicely will exit. If Apache can't find it's own IP address then it will fail too.
When your DNS is broken or your clock is off AICCU has a broken configuration.


Also, what protocol is proprietary? All protocols are documented in IETF styled drafts and the source for it is open, aiccu is the source, it is even with a BSD license, it cannot be more open than this.

Attempts to implement alternative clients using the existing protocol descriptions apparently got sabotaged by SixXS (11).

Sabotaged? How exactly could we "sabotage" anybody from implementing something?

The person behind that website was hammering the TIC servers and got automatically blocked, similar to other users like OpenWRT users now.
He states there that he modified the user-agent which was not true, the thing he apparently did do was relicense it at first under GPL, which well, is something one cannot do when one does not hold the copyright.

Please do not believe what pissed off people tell on the Internet, there is always a much nicer version of it somewhere else. We do not see a need to make pissing contests on the Internet though, we rather spend our time fixing the problems at hand.

Also as a proper counter argument, AVM have their own implementation, it is what their Fritz!Box is using which is used by thousands of users worldwide.

SixXS indeed set a restriction on not automatically reconnecting as it is not needed.

Your definition of reconnects is flawed and prevents downstream users from fixing actual problems while a fixes client release is held back and the problem argued away.

If you connect and then connect again, you are reconnecting. The problem is also not argued away. The problem you have is that you have a broken envirinment (DNS, clock) and that you are now causing reconnects automatically without actively resolving said problems.

The user will also never know that they do this till they get an email from SixXS stating that they are doing this and that they are blocked.

As such, notify the user in a proper way that AICCU failed to start, resolve the issue, and then try again. Do not just automatically try to start stuff, it does not work and does not resolve the problem.

Common sense dictates that it would legitimate to retry a connection attempt as long as no actual contact has been made to the TIC server, yet solutions that attempt to work around AICCUs deficiencies tend to get censored (12) or demanded to get removed despite obvious client problems with dnyamic links (13).

Yes we removed that script, but that is not censoring at all, especially as we clearly state that we remove that script as we are of the opinion that it is a bad idea. We need to protect our infrastructure and not put stupid ideas in people's heads.

Same that we are contesting this change here. It is a bad idea and the wrong solution for the problem.

The "dynamic link" problem, as you call it, happens because AICCU in it's current form uses a connected UDP socket, as such when the local IPv4 address used for the UDP connection for AYIYA or heartbeat changes things break. Generally people are fine though as they are behind a NAT and it does not break.

But that problem is completely unrelated to the "solution" you have added here where the either the DNS or clock is not correct yet when you start AICCU.
The "dynamic link" problem happens after possibly several hours of run time and functioning and thus your "solution" does not fix that issue at all.

The reason that AICCU exists is because there is an issue that the operator has to resolve, the tool cannot do so as it does not know how.

In our case NTP and DNS are expected to become available without intervention, just potentially delayed due to the nature of the IPv4 upstream connection, they're just not available when the AICCU service is started

If you know this, then do not start AICCU.

  • revealing yet another architectural weakness of the offically blessed implementation - it depends on system conditions (always available DNS, always correct NTP) which are simply not satisfiable by an embedded router with dialup connection.

Call it what you want, but Sendmail for instance does not start either when it can't find it's hostname. NTPd also fails when it can't do DNS.

Fix your start order, do not modify AICCU.

Despite this, several tickets outlined below show that the client simply fails with reconnecting, thus essentially forcing users to manually intervene in order to reestablish tunnels after an automatic line reconnect, thus making the utility essentially unusable for its intended purpose - especially with regard to the de-facto ban of any reconnect measures to kick the bugged client back into operation.

If one restarts AICCU once an hour there is no problem and TIC won't block it. If you are restarting at high rates though then the system decided that something is broken and thus it will ban that client and inform the owner per email.

The only thing that happens now is that clients who do this keep on hammering on the TIC servers and because we do want other users to be able to keep on using the service those clients get blocked. Nothing "facist" about letting real users actually use a free service....

See (14).

Yes, some people get kicked off the service and they do not like that. Out of 30.000+ people some people complain and present false facts. Welcome to the Internet. Nothing we can do to resolve that, even you trying to now state that that is at all related to the problem described in this ticket.

So to summarize:

  • the initialization of AICCU is broken by design

You mean: OpenWRT is starting AICCU too early before DNS or the clock is properly synced.

  • the reconnect handling of AICCU is broken, a fix is being held back or not really developed

As stated above: we lack enough resources (time) to properly perform a proper test of it all to make sure we do not break other setups.

  • workarounds violate the "no reconnect ever"-rule, leading to account suspension, bans and censorship

Account suspension because of this does not happen. The user's client IP only gets blocked from the TIC server, that is it.

Censorship? How exactly do we do censorship? We really cannot stop people from posting nonsense on the Internet as can be seen in this ticket and the nonsense you reference from it.

  • alternative implementations are being rejected

Which alternative implementation has been rejected? AVM's implementation works like a charm.

  • no updates since 2007 have been made to the client despite numerous well known problems

Lots of updates have been made, they have also been released for the Windows platform.

None of these updates though are relevant to the problem mentioned in this ticket: automatic restarting of AICCU.

Greets,

Jeroen

comment:5 in reply to: ↑ 4 Changed 6 years ago by jow

  • Resolution set to fixed
  • Status changed from reopened to closed

Replying to jeroen@…:

Replying to jow:

As the log above only shows "TIC Server is currently not available", it could mean one of several things: it could be that DNS is broken and that thus the host indeed could not be reached, it could also mean that an attempt was made and that the request was rejected. Only a verbose log would show what the real reason is.

The original AICCU would just exit, as it has no way to resolve whatever the problem is.

  • AICCU exits because of a bad system, NTP time on OpenWrt is synced asynchronously, the utility should recover as soon as the time discrepancy is solved.
  • AICCU exits because the server is not reachable, the utility should retry to resolve the TIC server until it is reachable.

Neither of these failure conditions should lead to a forceful client shutdown, that is extremely poor software architecture for a unix service intended for unattended operation.

AICCU is not intended for 'unattended operation'. It is intended to automate tunnel configuration. When the environment it is asked to run in is broken though it cannot fix that environment it exits.

Then I see no point in supporting it anymore.

The same way that Apache, BIND, sendmail, postfix and a lot of other services exit.

Apache, BIND, sendmail and postfix to not exist themselves if a remote peer is stating their time is wrong. They also do not make assumptions about the environment, this comparisation is flawed...

The difference with those services though is that they do not reach out to an external service at start time to fetch their configuration details.

... as you point out here.

These are restrictions that are very well known. As such, live with those restrictions and fix those issues instead of hacking around it and causing problems to a service you do not run.

Yes we decided to that. AICCU in OpenWrt will get stripped to only the binary and any support questions will get directed to the capable Sixxs staff.

There is no need for this. AICCU is only needed to start once (1), fetch it's config from the TIC server and that is it. It afterwards never have to perform TIC as it knows the configuration values it gets from TIC.

If the protocol would simply provide the details without being smart-ass about system time differences there would be no need to hammer the tic servers.

If DNS is yet unavailable because the dial in is in progress or if the system clock is off then AICCU can retry just fine without bothering TIC servers since there is guaranteed to be no connection attempt to the remote side.

If DNS is unavailable, do not start AICCU.

We do not know that DNS is not working until we attempt to contact a hostname.

If the clock is wrong, do not start AICCU.

We do not know that the clock is wrong until a TIC server knows better and refuses the connection.

Simple as that. These are things you can test for outside of AICCU.

That means adding even more hacks to accomodate for a single piece of software that does not perform as documented.

Thank you for referencing those links that have not been reported to info@… before. The fix is trivial, just use an unconnected UDP socket instead of a connected one and all is fine.

You wrote that 4 years ago already so you knew about the problem, yet no fix was developed and released.

The fixed version has not been released though as we do not have had time to properly test it on the myriad of platforms and configuration environments that AICCU is run on and as the majority just works better to keep that version out for the time being.

If you do not manage to release a fix within four years you should stop devloping it and stop to pretent that it works fine and stop to tell people thats a "start once" service and at the same time forbid them to restart it if it is clearly broken.

Note that the Windows version is not closed source, it is exactly the same source tree as the unix version and released under the BSD license.

I see no public source tree for the latest windows version so I cannot verify this.

If you mess up your configuration file Apache nicely will exit. If Apache can't find it's own IP address then it will fail too.

Apache will not fail if DNS is not available and Apache will not fail if the system time clock is off, you can stop making this flawed comparisation.

Also as a proper counter argument, AVM have their own implementation, it is what their Fritz!Box is using which is used by thousands of users worldwide.

Fritz!Box devices have RTC clocks and do not suffer from TIC servers blocking clients with a wrong time.

Yes we removed that script, but that is not censoring at all,

I'll let this stand as it is...

Same that we are contesting this change here. It is a bad idea and the wrong solution for the problem.

Did you actually read the patch? It properly handles fatal conditions. The only flaw was that it does not handle the case of "not available" TIC servers, that does not invalidate the solution per-se. But seriosly, if your TIC server is not available then put it off the network.

The "dynamic link" problem, as you call it, happens because AICCU in it's current form uses a connected UDP socket, as such when the local IPv4 address used for the UDP connection for AYIYA or heartbeat changes things break. Generally people are fine though as they are behind a NAT and it does not break.

So you're essentially asserting here that AICCU is broken for operation on the firewall/router, duly noted.

After a discussion among the developers we decided that we have no further interest in supporting the client software so I removed anything OpenWrt related (except compilation fixes) in r32666. I am confident that the Sixxs support stuff will be able to help users to set it up properly in accordance with the Sixxs terms of service.

comment:6 follow-up: Changed 6 years ago by jeroen@…

Then I see no point in supporting it anymore.

Because you are unable to present to the user the message produced in the log by AICCU?

Yes we decided to that. AICCU in OpenWrt will get stripped to only the binary and any support questions will get directed to the capable Sixxs staff.

What do you mean exactly with 'stripped to only the binary'?

http://www.sixxs.net/contact/ is the right avenue for questions.

Do not modify the code though, as we cannot resolve problems caused by those modifications, we'll just do what we do now, point them back at the cause of the problem.

Please also note that like OpenWRT and many many other internet based projects, SixXS is run by volunteers in their spare time, and that resource is quite limited.

If the protocol would simply provide the details without being smart-ass about system time differences there would be no need to hammer the tic servers.

There is nothing smart-ass about this. Lots of systems have misconfigured clocks. Having a correct system time is essential for cryptographic verification to function. SSL uses that (eg expiry times of certificates), thus the moment we would turn on SSL, the code is in AICCU, and your clock is wrong that would make that fail too.

Both the heartbeat and AYIYA protocols rely on a stable clock. Without a stable clock packets are not accepted to avoid replay attacks. As such, it is the only thing to do as any step afterwards would cause a wrong packet to be sent. This way the user knows about the problem.

The hammering is caused by restarting without fixing the problem.

One approach that we have discussed with people but which people generally do not like to take is to use the time provided by TIC to set the local time. That would mean though that if we where providing a wrong time this could mess up your system. We have no intention to do so of course, but it is a concern raised by some that they rather trust NTP. Also, it tends to be that hosts with wrong clocks do not run NTP and that they tend to drift and thus lose the right clock afterwards. As such we have rejected that idea some while back.

We do not know that DNS is not working until we attempt to contact a hostname.

There are various ways to guess that there is proper internet connectivity, eg trying to resolve the root (.).
This is a problem outside of the scope of AICCU.

We do not know that the clock is wrong until a TIC server knows better and refuses the connection.

It does not refuse the connection, it does refuse service as any step after that does not make sense, see above about having wrong time and crypto.
Something that can be resolved by a simple 'ntpdate ntp.openwrt.org' or similar before starting AICCU. And in the case of WRTs that is something that is smart to do anyway as their clocks are far from reliable. Afterwards/same-time start NTPd of course.

That means adding even more hacks to accomodate for a single piece of software that does not perform as documented.

It 'performs' exactly as documented (see the README accompanying it) : it exits when the system is in a wrong state.

You wrote that 4 years ago already so you knew about the problem, yet no fix was developed and released.

We are very aware of the "dynamic link" problem yes. The fix exists and has been released, I've also described it several times already.

If you do not manage to release a fix within four years you should stop devloping it and stop to pretent that it works fine
and stop to tell people thats a "start once" service and at the same time forbid them to restart it if it is clearly broken.

The fix was published already in 2008, see the change log.

The "dynamic link" problem only affects a small part of folks and is totally unrelated to restarting it in the script as when it hits you cannot detect it with the "fix" that has been implemented.

Different problem altogether from not having a working DNS or clock.

Apache will not fail if DNS is not available and Apache will not fail if the system time clock is off, you can stop making this flawed comparisation.

It will misconfigure itself as "localhost" and that is what I stated. I also stated that if the configuration is broken, that it will exit.

Note that the information retrieved by TIC is for AICCU it's configuration and thus if it cannot retrieve that that it should exit, which is what it normally does.

Fritz!Box devices have RTC clocks and do not suffer from TIC servers blocking clients with a wrong time.

Because they have indeed the correct time. As you show this is an external thing you can fix, a simple ntpdate would resolve it for OpenWRT for not only AICCU but a lot of other situations too.

Did you actually read the patch? It properly handles fatal conditions. The only flaw was that it does not handle the case of "not available" TIC servers, that does not invalidate the solution per-se. But seriosly, if your TIC server is not available then put it off the network.

I read the patch, thought that it looked okay and made sense, but it does not solve the problem at hand: no DNS and no correct time.

TIC servers are monitored (that is we have custom client connecting to it to check if they function correctly) and automatically taken out of DNS when they are considered not available. Typically though unless they are getting DoSsed through one form or another they are fully available.

The "dynamic link" problem, as you call it, happens because AICCU in it's current form uses a connected UDP socket, as such when the local IPv4 address used for the UDP connection for AYIYA or heartbeat changes things break. Generally people are fine though as they are behind a NAT and it does not break.

So you're essentially asserting here that AICCU is broken for operation on the firewall/router, duly noted.

No, I am not saying that at all, that is how you are twisting things. Also note again that you (well the folks commenting here in this thread) are mixing up unrelated problems.

After a discussion among the developers we decided that we have no further interest in supporting the client

software so I removed anything OpenWrt related (except compilation fixes) in r32666.
I am confident that the Sixxs support stuff will be able to help users to set it up properly in accordance with the Sixxs terms of service.

Or you could have simply added a little check if DNS worked and a call to ntpdate and fixed a lot of other issues for your users...
And/or provided a way to notify your users of the problems their little box is having.

comment:7 in reply to: ↑ 6 Changed 6 years ago by jow

Because you are unable to present to the user the message produced in the log by AICCU?

Oh, there is a message in the log, the user can read it.

What do you mean exactly with 'stripped to only the binary'?


It means that we only provide the aiccu binary. Since its not meant for unattended operation, users can ssh into their router, run aiccu and fix any problem their environment has.

http://www.sixxs.net/contact/ is the right avenue for questions.

Thank you, we'll direct users there.

Do not modify the code though, as we cannot resolve problems caused by those modifications, we'll just do what we do now, point them back at the cause of the problem.

Your code does not compile without modifications.

Please also note that like OpenWRT and many many other internet based projects, SixXS is run by volunteers in their spare time, and that resource is quite limited.

Exactly, therfore we have no further interest in putting resources into this sinkhole.

There is nothing smart-ass about this. Lots of systems have misconfigured clocks. Having a correct system time is essential for cryptographic verification to function. SSL uses that (eg expiry times of certificates), thus the moment we would turn on SSL, the code is in AICCU, and your clock is wrong that would make that fail too.

We do not ship with SSL support.

Both the heartbeat and AYIYA protocols rely on a stable clock. Without a stable clock packets are not accepted to avoid replay attacks. As such, it is the only thing to do as any step afterwards would cause a wrong packet to be sent. This way the user knows about the problem.

See above.

The hammering is caused by restarting without fixing the problem.

No the hammering in this specific instance was caused by not checking the "TIC server not available" condition, not because the approach was wrong, stop repeating this wrong assertion.

One approach that we have discussed with people but which people generally do not like to take is to use the time provided by TIC to set the local time. That would mean though that if we where providing a wrong time this could mess up your system. We have no intention to do so of course, but it is a concern raised by some that they rather trust NTP. Also, it tends to be that hosts with wrong clocks do not run NTP and that they tend to drift and thus lose the right clock afterwards. As such we have rejected that idea some while back.

I am not interested in rejected approaches.

There are various ways to guess that there is proper internet connectivity, eg trying to resolve the root (.).
This is a problem outside of the scope of AICCU.

Exactly, so how can a failed DNS cause hammering of your TIC servers then?

It does not refuse the connection, it does refuse service as any step after that does not make sense, see above about having wrong time and crypto.

See above note about not checked

Something that can be resolved by a simple 'ntpdate ntp.openwrt.org' or similar before starting AICCU. And in the case of WRTs that is something that is smart to do anyway as their clocks are far from reliable. Afterwards/same-time start NTPd of course.

Does not work for wan connections that become available only later.

It 'performs' exactly as documented (see the README accompanying it) : it exits when the system is in a wrong state.

Yes.

We are very aware of the "dynamic link" problem yes. The fix exists and has been released, I've also described it several times already.

I don't see any released fix in the source repository and we cannot run windows exectuables on openWrt.

The fix was published already in 2008, see the change log.

Only for windows.

The "dynamic link" problem only affects a small part of folks and is totally unrelated to restarting it in the script as when it hits you cannot detect it with the "fix" that has been implemented.

Would not call pppoe users a "small part of folks".

Different problem altogether from not having a working DNS or clock.

Exactly, yet one that requires restart loops.

It will misconfigure itself as "localhost" and that is what I stated. I also stated that if the configuration is broken, that it will exit.

The aiccu configuration is not broken.

Because they have indeed the correct time. As you show this is an external thing you can fix, a simple ntpdate would resolve it for OpenWRT for not only AICCU but a lot of other situations too.


We tried it in the past and doesn ot work reliably.

I read the patch, thought that it looked okay and made sense, but it does not solve the problem at hand: no DNS and no correct time.

It solves this problem very efficiently by connecting immediately if DNS and a correct time become available.

No, I am not saying that at all, that is how you are twisting things. Also note again that you (well the folks commenting here in this thread) are mixing up unrelated problems.

Yes, like bringing apache or bind into the equation.

Or you could have simply added a little check if DNS worked and a call to ntpdate and fixed a lot of other issues for your users...

We already sync NTP automatically, but there is no guarantee that WAN links are available at init time and we will not restart aiccu for wan ifup events because many dial ins would imply many connection attempts, thus spamming. However you attempt to twist it, AICCU will fail in any but the most simple case (static wan) in which I can simply use static tunnels and get rid of it entirely.

And/or provided a way to notify your users of the problems their little box is having.

We already have logread exposing the problem.

comment:8 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.