[Bug 1455097] Re: /etc/pm/sleep.d/ is no more processed
On 2016-04-06 17:46, ChristianEhrhardt wrote: > I did the task of identifying the remaining packages that are affected. > > $ apt-file search /etc/pm/sleep.d/ > > aiccu: /etc/pm/sleep.d/60aiccu There has been a bug out for this for 4 years already that this should never ever have existed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689584 Short version: please remove any kind of trace from /etc/pm/sleep.d for aiccu. That should take care of your bug report for aiccu at least. Greets, Jeroen ** Bug watch added: Debian Bug tracker #689584 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=689584 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1455097 Title: /etc/pm/sleep.d/ is no more processed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1455097/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1099002] Re: Remote upgrade over aiccu connection failed
** Changed in: aiccu (Ubuntu) Status: New = Opinion -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1099002 Title: Remote upgrade over aiccu connection failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1099002/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1201995] Re: package aiccu 20070115-15.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
No fix has been released for this. This bug is invalid. User just typed in a wrong username/password as per this log message:. Response not accepted: Login failed, login/password mismatch. Nothing the package or the software can do about. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1201995 Title: package aiccu 20070115-15.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1201995/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1221294] Re: package aiccu 20070115-14.1ubuntu3.2 failed to install/upgrade: sub-processo script post-installation instalado retornou estado de saída de erro 1
Two years ago ( 2013-09-05) somebody typed a wrong password. From https://launchpadlibrarian.net/149425621/DpkgTerminalLog.txt Response not accepted: User rogerio does not exist in the DB.. Nothing that can be done about that in the package. ** Changed in: aiccu (Ubuntu) Status: Confirmed = Incomplete ** Changed in: aiccu (Ubuntu) Status: Incomplete = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1221294 Title: package aiccu 20070115-14.1ubuntu3.2 failed to install/upgrade: sub- processo script post-installation instalado retornou estado de saída de erro 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1221294/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1261653] Re: aiccu can not route, looses route
** Changed in: aiccu (Ubuntu) Status: New = Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1261653 Title: aiccu can not route, looses route To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1261653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1031308] Re: Should not ask for password on each installation
No replication of this bug possible. Tested by installing a clean VM and then installing AICCU package, debconf asks for password. Then install it again, and debconf does not ask for it, as the username/password are stored in debconf and aiccu.conf. ** Changed in: aiccu (Ubuntu) Status: Confirmed = Incomplete -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1031308 Title: Should not ask for password on each installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1031308/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 797268] Re: aiccu configuration should warn users that extra steps are needed in order to configure a tunnel
One also has to go to the website for this, little the package can make clearer. ** Changed in: aiccu (Ubuntu) Status: Confirmed = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/797268 Title: aiccu configuration should warn users that extra steps are needed in order to configure a tunnel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/797268/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1436129] Re: aiccu crashed with SIGSEGV in tun_reader()
Did you stop AICCU? Or otherwise terminate it? As that code path would sigsegv when there is a race in the shutdown where the tun_reader thread is still going and g_aiccu is set to NULL as the process is shutting down. More details on the events surrounding would be useful. More importantly: is it repeatable? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1436129 Title: aiccu crashed with SIGSEGV in tun_reader() To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1436129/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 1380022] Re: aiccu's SSL connection is not secure
On 2014-10-11 10:24, rainkin wrote: ** Description changed: Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly. While static analysis is a good thing to identify possible problems, it does not match the intent of code. Now, we find some SSL problems in aiccu, the following is details: As tic.sixxs.net (and other TIC server instances) had a CAcert or self-signed certificate, the check for the certificate is not present and cannot be enforced. Adding a hostname check or a certificate chain check would thus break deployed systems. The only thing that the TLS support adds is hiding of the ephemeral tunnel key that is transmitted for heartbeat and AYIYA tunnels. That key changes every once in a while, thus it does not matter. Any organization that is able to intercept/redirect traffic or change DNS can break the TIC procedure already, in a same way they can perform that attack on the actual tunnel. Note that the actual tunnels are also in clear text. If the adversary can redirect/intercept traffic, they can better target that. Greets, Jeroen -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1380022 Title: aiccu's SSL connection is not secure To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1380022/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1287332] Re: package aiccu 20070115-15.1ubuntu1 failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
/var/log/syslog told me that TIC Server is currently not available. There is likely another error above that message, as that is just the general marker. It was just a misconfiguration at server site, What kind of misconfiguration? How did you resolve that misconfiguration? I could solve that, but I expected such informations in /var/log/aiccu.log or as error message on stderr. (dpkg --reconfigure aiccu or /etc/init.d/aiccu restart are not verbous at all). Unless there is something special creating and filling in a /var/log/aiccu.log, I don't expect that to exist. AICCU logs to syslog in daemonized mode and to stderr in non-daemonized mode. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1287332 Title: package aiccu 20070115-15.1ubuntu1 failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1287332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1287332] Re: package aiccu 20070115-15.1ubuntu1 failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück
Without the output of aiccu or the script that is calling it, there is little to say as except for the line that says that the post-install script failed, there is no actual error message. You might want to check /var/log/* for aiccu related messages; and/or try 'dpkg --configure aiccu' and/or try starting aiccu manually. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1287332 Title: package aiccu 20070115-15.1ubuntu1 failed to install/upgrade: Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1287332/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1261653] Re: aiccu can not route, looses route
THEN TCPDUMP STOPS WHEN GIVING RESTART AICCU DUE SIXXS DROPS OUT
What do you mean with this sentence? Can you rephrase it? (possibly with
interpunction and possibly also in lowercase?)
It sounds like you are restarting things, why?
Note that, as stated on the contact page mentioned in a previous comment
on this bug, looking at the tunneled interface ('sixxs' in this case) is
fruitless; the underlying interface is what should be looked at as that
will show the actual packets being sent out.
ppp0 trafic tcpdump:
You might want to filter out all non-relevant traffic. Relevant traffic
would be the actual AYIYA packets and any kind of ICMP, everything else
just makes people need to search. If you do not want to, then provide a
pcap (though limit the packet size then) so that it can be loaded into
wireshark or similar, grepping text is a lot of work. (also publishing
your private traffic (IMAP to yahoo, XMPP to Google etc) is likely
something to be avoided).
On top of that, the '-n' option (network numbers / do not resolve) is
awesome, makes things a lot more readable too.
The last lines show:
11:25:29.977623 IP fihel01.sixxs.net.5072 10.175.110.58.53305: UDP, length
1324
11:25:29.977849 IP 10.175.110.58.53305 fihel01.sixxs.net.5072: UDP, length 116
11:25:29.997546 IP fihel01.sixxs.net.5072 10.175.110.58.53305: UDP, length
1324
11:25:29.997643 IP fihel01.sixxs.net.5072 10.175.110.58.53305: UDP, length
1324
11:25:29.997799 IP 10.175.110.58.53305 fihel01.sixxs.net.5072: UDP, length 116
11:25:29.997847 IP 10.175.110.58.53305 fihel01.sixxs.net.5072: UDP, length 116
11:25:30.007499 IP fihel01.sixxs.net.5072 10.175.110.58.53305: UDP, length
1324
Seems nothing wrong with that. Shows that you are sending and receiving
packets back.
One reason found, that was at evneing ifconfig wlan2 down and
at morning ifconfig wlan up,... that stops trafic trough sixxs,...
Where are the details as requested several times already?
This is fixed to give restart aiccu after ifconfig wlan up .
Sounds more like your machine is in such an inconsistent state that that
resolves some kind of problem.
Now, the proper solution is not a restart, but providing enough details
so that an answer can be found.
Also got new Huawei driver that gives staedy trafic to ppp0.
As you did not mention Huawei before, what kind of device is this and
how does it relate?
Next to that, it seems you are mixing wlan and ppp0 here, which is
the actual device being used for connectivity?
Still ther have been mystery stops randomly at day,... ppp0
up down transition, could it stop aiccu working?
Without details, little anyone can say.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1261653
Title:
aiccu can not route, looses route
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1261653/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1261653] Re: aiccu can not route, looses route
joni@mpi2:~$ sudo tcpdump -i sixxs Dumping the tunneling interface will only show the traffic that goes into the tunnel. For any kind of tunneling protocol you need to look at the interface that the tunneling happens over. Also, using hostname resolving makes it difficult to see what is really involved, use -n flag. Note that SixXS publishes a really good list of things to report: https://www.sixxs.net/contact/#problems which mentions all these things. If you would actually report all the things requested there it would avoid having to file so many comments in this bug. So, I do not see difrence at sixxs interface after restarting aiccu, sixxs interface repair's, resets somthing at kernel routing,... correct ??? Can you please rewrite this sentence into separate sentences as I don't understand what you are trying to ask. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1261653 Title: aiccu can not route, looses route To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1261653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1261653] Re: aiccu can not route, looses route
AICCU dose not dedetect changes so it can not receive data, IPV4 network works but it can have brakes and IP can change,... conection is lost at IPV6 to incoming direction and aiccu dose not find it. From this sentence I understand you claim that AICCU does not handle IPv4 address changes, it, or actually the protocols AYIYA and heartbeat fully support that. As such, if you think they do not please provide technical details. You must restart aiccu time to time to keep connection. Restarting AICCU does not solve any problem. It will get you blocked from TIC when you do it too often as clearly described in a variety of places. Have I miss understood that aiccu should have it's internal heart beat to sixxs.org, sixxs.org is a IPv6Gateway for HTTP, it is unrelated to AICCU. You likely mean the heartbeat protocol or the AYIYA-internal heartbeat, these both happen automatically inside the protocol (unless specifically disabled). The subject of your bug is: aiccu can not route, looses route Why do you claim that it can not route? And which route does it looses? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1261653 Title: aiccu can not route, looses route To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1261653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1261653] Re: aiccu can not route, looses route
Technical detail is that fact operator changes IP time to time as well there can missing pacets due operator switches radio mode of conection between GRPS-UMTS-HSPA, That is not a *technical* detail, that is merely a description of the problem that you are seeing. As stated, the AYIYA and heartbeat protocols both handle the situation of an IP address change. SHOREWALL6 How is this shorewall6 configured, any connection tracking or other firewalling happening that is blocking packets? I belive this somthing to do whit Operators way handle incoming trafic and chage of IP4, If your operator intentionally (or not) is blocking AYIYA/heartbeat (you don't specify what you are using), then there is nothing that AICCU or the AYIYA/heartbeat protocols can do about this as they are not circumvention protocols. sixxs IPV6 gose down incoming direction but IPV4 works and sixxs IPV6 dose not come back whitout reastarting aiccu,... I was planing to to do script that pings my own site via sixxs and if not find then restart,... From the README and also mentioned on www.sixxs.net/tools/aiccu/ Notes Please read the README that is included with AICCU. Following is an important section of that text: 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. Please also heed the notice in the TIC FAQ which explains what happens to clients that connect repeatively. - Thus in case you did not bother reading that or: https://www.sixxs.net/news/2013/#tichammeringcontinuespleasecon-0722 now you are pointed to it. Thus be forewarned. Thus instead of going the Something is broken, I don't know what, I'll just restart it route, instead please actually provide *TECHNICAL DETAILS* of the problem (strace, netstat, tcpdump, interface and routing tables etc etc etc) without that there is little anyone can say about your situation. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1261653 Title: aiccu can not route, looses route To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1261653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1261653] Re: aiccu can not route, looses route
If operator could block AYIA I belive aiccu did not start ! Even if AYIYA is blocked (or otherwise caused to be broken), AICCU can still start. This as AICCU fetches it's configuration using the TIC protocol, which is independent of the tunnel protocol used afterwards (proto-41, optionally with heartbeat or AYIYA). Restarting is not due aiccu is down or not running,... reason or another it hangs ,... sudo restart aiccu start's incoming ipv6 trafic, ping6 send's packages while aiccu/tunnel is hangig but no response nor error!!! Where are the interface tables, tcpdumps and other details that would maybe show an error? See previous comment for other details that would be very useful. ANY IDEAS HOW TO TEST THAT OPERATOR IS NOT DISTURBIN AYIA / AICCU ??? Providing the requested information would be a good start. joni@mpi2:~$ sudo cat /etc/aiccu.conf There is very little that one can do wrong in the AICCU config; keeping the default options and just having username/password/tunnel_id is all one needs (typically at least). But that is a config,not the output of AICCU when it is running, not a tcpdump nor any other useful technical detail. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1261653 Title: aiccu can not route, looses route To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1261653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1261653] Re: aiccu can not route, looses route
Joni-Pekka, would you please be so kind, and post the output of sudo /usr/sbin/aiccu autotest ? Best would be twice: One before changed IP and one after at least 2 minutes after connection is broken. That does not do anything useful. The 'autotest' mode sets up the tunnel again and thus effectively means you re-started AICCU. (yes, I realize, it would be better if autotest could be run without setting up and breaking down the tunnel, but that is how it is at the moment). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1261653 Title: aiccu can not route, looses route To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1261653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1261653] Re: aiccu can not route, looses route
Problem to supply any usefull is that it dose not happen every days and sometimes twice Then collect the information when the problem happens. How do you mean that the problem happens 'twice'? Most likely this somekind of timeing / protocol,... related problem, Unless your local system clock drifts (your computer is NTP synced right?), what kind of timing/protocol problem do you mean? there have been same kind of reports but those have been negled What 'reports' are you referring to and what do you mean with 'negled'? Yes, IPV4 work's, aiccu run's and incoming IPV6 dose not work. Sounds more like a firewall problem to me in that case. Please provide actual technical details, without it little anybody can say about this. There is one problem but it can be rounting realted, I have not succeed to get intranet machines routed trough router computer whit IPV6. As AICCU does not handle this kind of setup, that is out of scope for this ticket. I suggest using the SixXS Forums for asking for help, there are people there who can tell you what to look at. So could it still be problem whit kernel ipv6 rounting and not aiccu??? It can be anything. Without details, hard to say. I have done all needed steps to get IPV6 work ( fowarding statement, shorewall6, dhcp6 and bind ) Again, without details, nobody can comment on this. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1261653 Title: aiccu can not route, looses route To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1261653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1261653] Re: aiccu can not route, looses route
I mean protocol level timeing, response time, missing packets,... AICCU can do little about high latency or missing packets. As for 'timing' except for the requirement that hosts are NTP synced, there is no timing, AYIYA/proto-41 are lossless protocols, the tunneled protocols (eg TCP) will take care of retransmission. Basically aiccu should not change iptables AICCU does not change iptables, why do you think it does that? Please provide details. and shorewall dose it only ones when it have started,...,... there is no ufw,.. Even if these components do not change, if connection tracking is involved, then that might cause problems when the connection tracking is not properly tracking the connections. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1261653 Title: aiccu can not route, looses route To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1261653/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1221294] Re: package aiccu 20070115-14.1ubuntu3.2 failed to install/upgrade: sub-processo script post-installation instalado retornou estado de saída de erro 1
From https://launchpadlibrarian.net/149425621/DpkgTerminalLog.txt Response not accepted: User rogerio does not exist in the DB.. When wrong user/pass is given, AICCU won't start, and thus indeed it fails. Nothing that can be fixed in the package (except may be providing a way to not start when not properly configured). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1221294 Title: package aiccu 20070115-14.1ubuntu3.2 failed to install/upgrade: sub- processo script post-installation instalado retornou estado de saída de erro 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1221294/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1201995] Re: package aiccu 20070115-15.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
From the DpkgTerminalLog.gz : -- Setting up aiccu (20070115-15.1ubuntu1) ... Response not accepted: Login failed, login/password mismatch. Files /usr/share/aiccu/conf-templates/aiccu.conf and /etc/aiccu.conf differ start: Job failed to start - If you enter a wrong username/password things will not work. Nothing much the package can do about. According to var.log.aiccu.log.txt AICCU is also being restarted a *lot*, what is causing that? The TIC server will not accept repeated logins and will ban the account in question as per this section from the AICCU README: 8--- 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. 8 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1201995 Title: package aiccu 20070115-15.1ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1201995/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1099002] Re: Remote upgrade over aiccu connection failed
Note that the way that ssh solves this is to run an other binary on a different port, OK. I don't understand how that is done transparently, but I guess I can read about it somewhere. It is a feature of update-manager-core, debian's default apt-get dist- upgrade style of upgrading for instance would not do this. As such, any logic like detecting connectivity (be that AICCU's / SSH / OpenVPN / Tinc etc) would have to be done there for it to be done properly. Of course, maybe having a we are upgrading this package, you might lose connectivity warning might be useful to have as a warning in AICCU. I guess when we have native IPv6 then remote upgrades will not have this problem and will be at least as reliable as ipv4 ssh upgrades Over the many years of having native dual-stack IPv4+IPv6 on a large variety of hosts I noticed that is more reliable as one can break for instance IPv4 with a firewall rule and then still use IPv6 to get in ;) A warning would have helped me enormously I agree. I've quickly checked, but I don't see either OpenVPN or Tinc having it, even network manager does not seem to have it. Note that this kind of warning would affect every single upgrade of a binary that is providing network connectivity. This filing may help a few other people to avoid tripping over it. I don't think it will help much, because one typically does not check all the bug reports before doing an upgrade... I am pondering if we could teach apt/dpkg about packages that provide network connectivity, so that when they are being upgraded that that package tag can uniformly inform the user that such an upgrade might cause issues for their connectivity. Would need to determine the right package for that though, as some people use apt, some aptitude, some synaptic and some directly use dpkg and all these package managers, even if they are front-ends to apt, would need to know about it. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1099002 Title: Remote upgrade over aiccu connection failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1099002/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1099002] Re: Remote upgrade over aiccu connection failed
So it looks lot like aiccu dropped te connction during the upgrade. Replacing a package (and thus the binary) implies restarting AICCU to get the new binary up and running. The only way to figure out what happened and what failed is to see the log, which is not attached. preserve connections wherever possible, Due to the restart of the binary, that is impossible. In these kind of situations one could say to not upgrade tools like this remotely Note that the way that ssh solves this is to run an other binary on a different port, this is not possible with AICCU as it is actualy providing the connectivity. The other work around is of course to use IPv4, at least as a backup, as that connectivity is likely there; thus: ssh into the box using IPv6, set up a reverse SSH over IPv4 as a backup connection (similar to the SSH scenario where the alternative port SSH is the backup) and then get into that one over IPv4 too to be sure to be able to survive the AICCU restart. In the end though this is a non-bug mostly. Though there could maybe be a huge warning, similar to the SSH case, to note to the user that AICCU (and any other VPN tool like OpenVPN etc) is being used and that it might be that that connection gets lost, in the same way as SSH. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1099002 Title: Remote upgrade over aiccu connection failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1099002/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1077671] Re: package aiccu 20070115-14.1ubuntu3.2 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1
Entering a valid username would resolve this problem: - Setting up aiccu (20070115-14.1ubuntu3.2) ... Response not accepted: User r37u2a49ci does not exist in the DB.. Files /usr/share/aiccu/conf-templates/aiccu.conf and /etc/aiccu.conf differ start: Job failed to start invoke-rc.d: initscript aiccu, action start failed. dpkg: error processing aiccu (--configure): subprocess installed post-installation script returned error exit status 1 Setting up likewise-open (6.1.0.406-0ubuntu5) ... Error: /usr/sbin/lwsmd --start-as-daemon returned 1 (aborting this script) - (though what exactly produces that 'Response not accepted' is unknown, to me at least, maybe a part of debconf?) From the DistrupgradeAptlog it also looks: -- Log time: 2012-11-11 08:06:32.820707 Starting Starting 2 Done MarkUpgrade() called on a non-upgrable pkg: 'brasero' ERROR:root:Upgrading 'brasero' failed --- that you have problems with brasero... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1077671 Title: package aiccu 20070115-14.1ubuntu3.2 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1077671/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
When the daemon starts, it will terminate if it cannot contact the tunneling service At failures it will always log the error and terminate. This as that is the way that a user will notice things and start looking into logs. Unfortunately people seem to think that everything needs the Win95 treatment and just restart things instead. , which is very different from how the daemon behaves once it's started, where it is supposed to handle network outages gracefully, without a restart. That is correct, but how is that inconsistent? This bug report contains logs that illustrate the behavior: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825. The same behavior is present on my system running a fully patched Ubuntu 12.04 release. That shows as the first line indicates that somebody decided to change the startup method which then caused things to break as there was no network yet. Simple solution: start it (once, btw, and not repeatedly) when your network connectivity is up. These inconsistencies That is not inconsistent. If there is an error condition (broken time, no network) it exits. Now, if your IP address changes while it is already running, then it will keep on working. Neither aiccu's built-in behavior or the Upstart Please note that Upstart is something from Ubuntu etc, do not start blaming AICCU for the way that that start script handles it. (recall the Upstart script looks for the local-file-system signal in addition to the net-device-up signal). Then fix upstart. Seems to me the best solution to these issues is for the aiccu daemon to behave the same way on startup and while running. As it retrieves it's primary configuration details using TIC, it needs them, in it's current incarnation it will thus properly exit. Given the choice, I'd vote for handling network outages gracefully in both scenarios: this makes the startup scripting very simple: start aiccu on boot, and let it handle everything from there. This is what will be likely the case in the next AICCU version, which I want to finish but do not get around to unfortunately, maybe tomorrow will be the right day though -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1058883 Title: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
I found the file `/etc/pm/sleep.d/60aiccu`. This appears to be the offending line: $P6 -I $INT -c 1 f.root-servers.net /dev/null 21 || invoke-rc.d aiccu restart And the million dollar prize question becomes: why is there a restart there? If I comment out the offending line and use the package's original Upstart script (with the local-filesystem condition intact), the sixxs interface is still present on resume. Always good to know that the unmodified version works fine ;) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1058883 Title: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
I'm not sure why the restart is there. Perhaps it's trying to guarantee the routing tables are correct. Why would they not be? Or perhaps it's intended to start up the aiccu daemon if the computer is suspended on a network with native IPv6 support, then resumed on a network without native IPv6 support, where the aiccu daemon is needed. It also restarts aiccu if ping6 isn't found, not sure why. There is no logic in the script or in the default AICCU for this. Thus that cannot be it either. (Logic for detecting native IPv6 and optionally disabling tunneling, or wel, at least the routes for it, is a wishlist item in upstream AICCU) Just in case it wasn't clear, the sleep.d script is part of the default installation as well--I don't have a link, but it can be easily verified by downloading the aiccu source package and looking for the file `60aiccu` in the debian/ directory. Something in Debian/Ubuntu added it; but it is not in default, or maybe better said, original/upstream AICCU. This as one should not have to restart AICCU, ever. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1058883 Title: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
Looking at the Debian changelog, it appears this resume script has its origins in this bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531003 Thus instead of having a log or output or anything else to actually figure out what goes wrong the 'solution' is a restart right. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1058883 Title: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Please remove sleep patch which does not work and does not resolve any problem
[Caleb: thanks for finding the origin of this fix] So it seems this sleep fix, by just restarting (I thought Debian was not an ancient Microsoft product where one just reboots all the time), which was not tested is now causing issues for people: https://bugs.launchpad.net/bugs/1058883 Would it not be prudent to revert such a patch, or better, never have applied it if the patch was not tested or proven working at all?!? It seems there are no logs or other details included about this issue, just a it does not work and I restart it now it works and then a patch for just restarting it. Would be great if there actually where logs for this issue or other details that would demonstrate the problem. Maybe time to remove this patch? As I have stated in various places: AICCU does not need to be restarted, the protocols used should handle it, that is why those protocols, exist. If the tunnel 'breaks', please provide details of what is broken so that the real problem can be addressed just restarting it does not resolve such a problem. Bigger note: If anybody has logs which demonstrate breakage please provide them, then I can take those situations along in the testing of the new AICCU. I've added to the to-check list to check with Virtualbox how a acpisleepbutton event affects the state of AICCU, thus lets see what the result of such a test is (best I can do, no Linux on a laptop anywhere near me at the moment... but this should be similar) Greets, Jeroen -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1058883 Title: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1058883] Re: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend
aiccu doesn't (re)start AICCU should just kept on running during a resume, no need to stop it before and start it after it, nothing is changing for it (except maybe network, and that it can handle). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1058883 Title: start-on conditions in Upstart script prevent aiccu from restarting during resume from suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1058883/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1055818] Re: Aiccu is unable to start
The error message means actually Access to file denied, it looks like only root user can read from the config file. That is how it should be as there are passwords in that file that should not go to third parties. Setting verbose to true does not change anything that I can find in log files... :( Turn daemonize to 'false' then it will not background and it will output to the console instead of syslog. I do not think there is anything really Ubuntu-specific about this issue though -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1055818 Title: Aiccu is unable to start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1055818/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1055818] Re: Aiccu is unable to start
You might want to check what syslog daemon you are running and how it is configured, as when AICCU is in verbose mode it will log everything to syslog when daemonize is not false, thus if you do not see anything in syslog, something there is misconfigured and/or broken... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1055818 Title: Aiccu is unable to start To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1055818/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1055818] Re: Aiccu is unable to start
if adding account data (username,password) to /etc/aiccu.conf
doesn't help, please try to run sudo aiccu stop; sudo aiccu autotest
/tmp/aiccu_autotest; sudo aiccu start and post the file /tmp/aiccu-
autotest here.
One also needs to specify a 'tunnel_id' if one has multiple tunnels.
thus aiccu.conf should have at least:
{{{
username xxx-SIXXS
password
tunnel_id Tn
}}}
And if you want more details out of aiccu you do not use the 'autotest'
option, you first set verbosity to true with the option:
{{{
verbose true
}}}
as then it actually gives out a lot more details. Errors should still be
logged properly though.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1055818
Title:
Aiccu is unable to start
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1055818/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 378251] Re: security bug in nsd requires patching to prevent DOS
3.2.13 is out for a month already, might be nice to get an updated
package...
https://www.nlnetlabs.nl/projects/nsd/
{{{
NSD 3.2.13
Jul 27, 2012
Bugfixes
Bugfix #461 (VU#517036 CVE-2012-2979): NSD denial of service vulnerability from
DNS packet when using --enable-zone-stats.
Bugfix #460: man page correction - identity.
Fix for nsd-patch segfault if zone has been removed from nsd.conf (thanks Ilya
Bakulin)
NSD 3.2.12
Jul 19, 2012
Bugfixes
Fix for VU#624931 CVE-2012-2978: NSD denial of service vulnerability from
non-standard DNS packet from any host on the internet.
NSD 3.2.11
Jul 9, 2012
Features
Fallback to AXFR if IXFR is unknown at the primary. NSD considers IXFR unknown
at the primary if there is a negative response for the IXFR RRtype. This does
not override the value for 'allow-axfr-fallback'.
Allow for reading in new DNSKEY algorithm mnemonics (RFC5155, RFC5702, RFC5933,
and RFC6605 (ECDSA)).
Zone statistics, enable with --enable-zone-stats. This stores the BIND8 stats
per zone in a configurable statistics file. This option does not scale and
should therefore not be enabled when serving many zones.
Support for TLSA RRtype (DANE).
Bugfixes
Fix for qtype ANY for a wildcard domain in NSEC signed zone: Don't add the
wildcard domain NSEC into the answer section. Instead, put the wildcard
expanded NSEC into the answer section and keep the wildcard domain NSEC in the
authority section.
Fix for accept spinning reported by OpenBSD.
Fix restart failed due to bad ixfr packet because of zone removed from nsd.conf.
Bugfix #453: typo in nsdc man page.
}}}
** CVE added: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2012-2978
** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2012-2979
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/378251
Title:
security bug in nsd requires patching to prevent DOS
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/nsd3/+bug/378251/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 378251] Re: security bug in nsd requires patching to prevent DOS
Debian is upto 3.2.12-1, which is almost upto date, see http://packages.debian.org/sid/nsd3 As such, one can easily take their details as usual, no extra work needed for Ubuntu for this... From the UpdateProcedure page: --- The Ubuntu Security team also tracks issues in universe and multiverse and aims to solve vulnerabilities for these packages in the current development release by requesting syncs from Debian. Patches for flaws in packages from universe and multiverse for stable releases should be prepared by community members. - As such, please sync it ;) (and I'll indeed kick Debian folks to update to 3.2.13...) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/378251 Title: security bug in nsd requires patching to prevent DOS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nsd3/+bug/378251/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 378251] Re: security bug in nsd requires patching to prevent DOS
Filed as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685550 ** Bug watch added: Debian Bug tracker #685550 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685550 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/378251 Title: security bug in nsd requires patching to prevent DOS To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nsd3/+bug/378251/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 223825] Re: aiccu init.d script will race dhclient (upstart issue?)
Jeroen, his upstart job does not use the 'respawn' keyword, so it will not be automatically restarted like daemontools does. This is only started when there is a real network interface (something I would think necessary for this daemon to work!), and stopped when the system is going down. I agree that bringing the daemon up when the network goes up is fine, and as there is a PID file it will only run once and not start again when the interface is brought up again. Stopping it when the network goes down though will mean that when the network is flipping (which we have seen at several people already) you will be effectively start/stopping the daemon all the time. From another reply: I cannot find any documentation that indicates AICCU has any purpose other than setting up and tearing down AYIYA tunnels. You might want to start at reading the wikipedia article which already tells you a lot more than that. It does TIC first to retrieve the tunnel configuration, then it can set up a static (which is quite useless on debian due to the great interfaces(5) :) and of course then run a heartbeat or do AYIYA. There is no need for such a tool to run if there is no network connection, unless the tool also monitors network connectivity. The whole point of heartbeat and AYIYA is handling dynamic tunnels. At least on my Natty system, the aiccu daemon simply terminates when no network connection is present, It exits because it is unable to retrieve the configuration. See the log file for a nice message. so it does not appear to have any ability to monitor the status of the system's network connectivity When it is started and it can connect to the TIC server and retrieve it's configuration, then it will nicely inform the PoP of network connectivity state using either the heartbeat or the AYIYA protocol. (and it probably shouldn't have that ability--that's really the system administrator's concern). People who are using AICCU don't care about this, they just want working connectivity and that is what it does. So again, I would be interested to know what function of AICCU makes it useful without a network connection. Without a network connection (and with that an Internet connection not a local network) there is not much it can do, that is why it then also exits. When you though start it when you have working connectivity you can keep it running, no need to exit it, and it won't exit then by itself either. I have in fact read the warning you mention. I'd be interested to know how it applies to my Upstart script and not the one on which Lars Dursig has been working on. See the above, you are also disabling it when the network goes down, as such, if the interface flips, it will Note also that there is no clause anywhere that when that interface goes up/down is actually an interface that can do anything with internet connectivity. Maybe at least a notion of a check that there is a default route would be sane to have? Jeroen, his upstart job does not use the 'respawn' keyword, so it will not be automatically restarted like daemontools does. As Lars said also, it will seem to automatically restart when the network goes mad, this is something that we have seen at several people already, who nicely got a reminder to not effectively attempt to DoS the TIC server. In summary: at network-up time (for a network that actually has connectivity to the TIC server and the PoP) it is fine, but at network- down time it would be quite annoying. The annoying part comes to the user who will get emails, and the SixXS staff who will get silly complains that they had an issue, those issues you will never see here in the ticket tracker though. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/223825 Title: aiccu init.d script will race dhclient (upstart issue?) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 223825] Re: aiccu init.d script will race dhclient (upstart issue?)
Clint: you are mixing two proposals, there is a) one for upstart, b) the network-based one The upstart one indeed does not have that issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/223825 Title: aiccu init.d script will race dhclient (upstart issue?) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 223825] Re: aiccu init.d script will race dhclient (upstart issue?)
Attached is an updated work-around script that emits net-device-up /net-device-down events. I am really wondering if you know what the function of AICCU is, because if you did you would not be stopping it when the network goes down and starting it automatically when the network goes up. Also obviously you did not read the README file included in the original source distribution which contains this little piece of text: 8 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. -8 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/223825 Title: aiccu init.d script will race dhclient (upstart issue?) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/223825/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 794579] Re: aiccu: debconf should ask if you're behind a NAT
The 'behindnat' option only disables a warning, for the rest it does absolutely nothing. It figures out that it is behind NAT (well, it checks if that address is RFC1918) it that is the case and when that is the case it warns the user about this, 'behindnat' disables that warning, that is it. This thing is more a thing for the UI than for the daemon version that is for the linux platforms. When one is behind a NAT, in 99% of the cases you are using AYIYA, and AYIYA does not care that it is behind a NAT. I think what happened in your case is that you requested a tunnel and it did not work directly as the PoP only gets re-configured every 10 minutes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/794579 Title: aiccu: debconf should ask if you're behind a NAT -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 794579] Re: aiccu: debconf should ask if you're behind a NAT
If there was something wrong, I am very sure that the 'behindnat' option had anything to do with solving it ;) As for problems with connectivity, don't hesitate to report those in the proper place as per http://www.sixxs.net/contact/ and of course, with the details as per requested there. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/794579 Title: aiccu: debconf should ask if you're behind a NAT -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
Dear Derek, there is a way to fix this problem in your large corporate network, like we did for that small corporate network that I am using: fix the resolvers. As you are claiming to have a large corporate network, you most likely have only a handful of recursors but you might have a 100k clients, lets see which ones are easier to upgrade, 100k clients which are all over the place or that 10 max or so recursors easy pick I would say. The thing you most likely are forgetting is the fact that the DNS recursors that you are using are not only broken for records, but most likely for every single other address. Thus, by resolving this issue you will solve other magical problems too. You can directly move on to support DNSSEC too for that matter if you are busy anyway. Yes, the problem is annoying, no there is not much that Ubuntu or any other OS can do about this. Thus fix the problem in the right spot. -- [regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
@ Per Heldal / #43 glibc 2.10 does +A queries in parallel. I don't know if it does that also for the ones in the search path, which seems to be the problem you are describing above. Nevertheless, search path should (afaik) only be applied to non-FQDN hostnames (eg 'www' or 'hostname') not to anything containing already a domain (eg 'www.domain'). When this is done and users type eg 'ubuntu.org' then the local search path does not come into play. The problem that I have seen with recursors (even one on an old dd-wrt as even dnsmasq had this issue quite some time ago, but if you don't update it doesn't get fixed ;) was that it simply completely silently dropped queries. It didn't even try to forward them. No response nothing. Even for www.ubuntu.org etc. Which is another error case from the scenario you describe, which is even funnier, as NXDOMAIN should definitely be handled properly (if they don't how the heck does that DNS recursor even work when somebody mistypes a URL ? :). -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
WORKING FIX (run as root of course): apt-get install pdns-recursor resolvconf echo nameserver 127.0.0.1 /etc/resolvconf/resolv.conf.d/base resolvconf -u 1) This will effectively install pdns_recursor which is a DNS recursor that simply works(tm) and it installs the resolvconf framework (which you most likely already have) 2) this echo sets the nameserver to 127.0.0.1, aka pdns 3) update resolv.conf with the above info You should now have nameserver 127.0.0.1 in /etc/resolv.conf and all your DNS queries should be super duper fast again (also because they get locally cached a bit ;) Of course if you have a firewall between your host and the Internet where DNS servers exist the above might not work when DNS gets blocked... I would almost suggest that Ubuntu make the above the default. The problem is though that little firewall thing, if that is there or you visit some netcafe or other network where only HTTP/HTTPS works, then indeed it does not work... -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
@ Jordan.sc #135 I cannot, nor am I authorized to do firmware upgrades at the local coffee shop at the airport and at my place of business And generally these locations have neutered DNS already anyway, eg they only allow HTTP/HTTPS and generally only after authenticating (after being hijacked using DNS to their portal thingy). These locations (coffeeshops, hotels, airports, other generic hotspots etc etc) don't provide true internet anyway and are thus breaking already way too much protocol wise that there is nothing you can do about it. The only thing you can do in those locations is to VPN out if you want to resolve that problem. In the cases where DNS requests are not blocked (like in hotels and coffeeshops), you can setup pdns-recursor and use 127.0.0.1 in your resolv.conf -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
The solution is to use a working DNS server. A couple of ways to accomplish this: - use your ISP DNS servers directly - use OpenDNS or a similar provider - local caching resolver: put 127.0.0.1 as the nameserver (/etc/resolv.conf) and install pdns-recursor The latter can be done per default in Ubuntu and would always work and require no setting changes. The only negative side-effect is that the caching effect of DNS might be less used, but then again, most sites use DNS loadbalancing now, thus this is a non-issue. -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
@cosmo #76, of course it is just a work around. The problem lies in your DSL/cable modem, not in Ubuntu. Thus ubuntu can only work around this issue. You didn't see the issue before as you where not using all the features of the Internet (IPv6 ;) -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
Of course it fixes the problem, this as the problem lies in the DNS resolver that is inside the DSL/cable/etc modem. Thus by entering/using OTHER dns servers, preferably the ones from your ISP, otherwise the ones from the OpenDNS or similar providers, you bypass the DNS resolver in the modem, and thus the device that would otherwise drop DNS queries for records. -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
#64 Tim Coffey, Just try the following: dig @dns server that is broken www.bingabongobango.com That will take quite a long time to return. The problem is that when you install Karmic, you get IPv6, because of that, programs that are IPv6-capable will start asking for records As the DNS Server is broken it will not reply to the request. Thus it looks like things are slow. If the other PCs are using that DNS server, but not asking for records, then all will be fine and you won't notice the slowness indeed. -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 215497] Re: IPv6 configuration is not flushed when interface goes down
(Thanks to swmike for pointing this one out to me) Something one could try is to add in /etc/network/interfaces at the interfaces with the issues, add: pre-down ip -6 addr flush dev name pre-down ip -6 ro flush dev name Then that should fully flush it. That is a hack and should be done by the ifup/down code though, which should be far from hard of being added. -- IPv6 configuration is not flushed when interface goes down https://bugs.launchpad.net/bugs/215497 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 433972] Re: Internet ping very slow on Karmic Koala
*** This bug is a duplicate of bug 417757 *** https://bugs.launchpad.net/bugs/417757 Top right: Duplicate of bug #417757 -- Internet ping very slow on Karmic Koala https://bugs.launchpad.net/bugs/433972 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
@ Nech / #36 I work better using wifi than using wired connection. So, like I ask everybody else, check to see if there is a huge latency time difference when doing: for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i www.microsoft.com ; done Over the wired or wireless; quiker maybe is to check if you get a different set of DNS servers when connected over wired or wireless (just check if /etc/resolv.conf changes). -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
@ Nech / #38 As you have the same DNS server for both wired and wireless, most very likely _your problem_ is not a DNS issue* like what the others show here. * = unless an upstream of your DNS server has the drop unknown DNS records problem and your resolver caches the negative answer correctly, which will cause any subsequent query, like the ones above, to be quick again. To solve your problem, I guess you'll have to take a peek with Wireshark... -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
@ Zack Evans #40 I quickly looked at the Privoxy 3.0.12 IPv6-patch included in Debian (and probably the same thing in Ubuntu) and it seems that it is quite incomplete and has quite a number of broken assumptions. One of the primary brokeness is actually documented in the patch with: /* TODO: Allow multihomed hostnames */ indeed, that also means that if a host has multiple A and/or records, it will only try to use the first one, which might actually be an IPv6 address (which is generally preferred). As an example www.google.com has generally 4 IPv4 IP addresses (A records) and as that Privoxy patch only supports 1 address per hostname, it will only use one of those. If that single address is then IPv6, it will try IPv6. If your IPv6 connectivity is then broken (which might also be the problem for other hosts) then of course it will take quite some time for that to timeout I would say: file a bug report against privoxy as clearly the patch that is included can various websites which have multiple addresses to only have the use of one address. and of course only IPv6 or IPv4 is then supported by it... in other words: BROKEN. With the above in mind, people who have problems with IPv6 should perform two tests: - ip ro sho |grep default ^ if you have a default route somewhere then of course it will be used, thus check where it goes and if that makes sense for you. - for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i www.microsoft.com ; done ^-- if this has huge latency then your DNS resolver (or one above it) is broken. Do test this also with different hostnames then just www.microsoft.com, try especially hostnames that you didn't check in a while as they might be cached somewhere. -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 458223] Re: package aiccu 20070115-9 failed to install/upgrade: subproces post-installation script werd gedood door signaal (Interrupt)
ErrorMessage: subproces post-installation script werd gedood door signaal (Interrupt) Is Dutch for: subprocess post-installation script was killed by signal (Interrupt) I assume somebody thus hit CTRL-C. Note that the Terminal Log contains: Warning: Couldn't find global Tunnel Brokers List, please check your DNS settings and read the FAQ. This tends to indicate that the user has a problem with their DNS resolver (or one of that resolvers upstreams) which fail to pass large TXT records. Do a: for i in `cat /etc/resolv.conf | grep nameserver | cut -f2 -d' '`; do echo -e \n\n$i ==; dig +short @$i _aiccu.sixxs.net txt; done The one which does not properly respond is the broken one. This might cause most of your IPv6 resolving ( records) to likely fail too, although that is just a 'might' as the problem here is long DNS responses which can be caused by the TCP-response that is needed and thus a firewall blocking DNS requests over TCP could be the culprit. Example response of the above: 192.168.0.1 == ;; Truncated, retrying in TCP mode. UKERNA tsp://broker.ipv6.ac.uk http://www.broker.ipv6.ac.uk; gb Hexago / Freenet6 tsp://broker.freenet6.net http://www.freenet6.net; ca ECS Southampton tsp://broker.ecs.soton.ac.uk http://broker.ecs.soton.ac.uk; gb ACADEMIA Sinica Computing Centre tsp://tb2.ipv6.ascc.net http://tb2.ipv6.ascc.net; tw Wanadoo France tsp://ts.ipv6.wanadoo.fr http://www.ipv6.wanadoo.fr; fr # http://www.sixxs.net/tools/aiccu/brokers/; AARNet tsp://broker.aarnet.net.au http://broker.aarnet.net.au; au # AICCU TIC/TSP Servers # name | url | website | tld's SixXS tic://tic.sixxs.net http://www.sixxs.net; be de ee fi gb ie it nl nz pl pt si se us Note that the results might return in a different order. The same content should be returned though. -- package aiccu 20070115-9 failed to install/upgrade: subproces post-installation script werd gedood door signaal (Interrupt) https://bugs.launchpad.net/bugs/458223 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
@ csulok / #32 What that does is avoid fixing the problem. You disable IPv6, and thus glibc plays smart and does not resolve records anymore. Your DNS resolver though is still broken. You might not notice it now, but if for instance per next year DNSSEC gets turned on you will run into it again (and you will probably just disable DNSSEC) -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
@ Pconfig / #20 You can't tell your grandmother to edit some config files because her internet is slow Does your grandmother use Ubuntu then? If so, then just help her out in fixing the issue :) @ Zack Evans / #23 I have a Draytek so blaming the router isn't practical - these have a MASSIVE installed base This problem also is in effect when the user has Windows and IPv6 enabled on that. The problem lies in the DNS resolver (which might not be the NAT box (what you call router) but might be even your ISP, and thus you can avoid the problem by not using the DNS resolver in the NAT box. You might of course also try to upgrade your router, maybe they fixed the problem (you upgrade your Ubuntu and other things too, because they have issues, thus try that) To be honest, only the advanced users would want IPv6 anyway, so why not have it off by default and make it very easy to switch on? Because in a few years or so you will have to enable IPv6 as there won't be any new hosts with IPv4 addresses. As such, better bite the apple today and fix those IPv6 issues, then wait till you really need it. @ camper365 / #24 yes, that is correct, as when you ping www.google.com it has to lookup the hostname in DNS, while if you ping the address, it doesn't. DNS resolving (thus figuring out which address belongs to the requested hostname) is where the problem lies. See the hints about OpenDNS or pdns-recursor to solve it. @ Ragnarel / #25 as per comment #11 try a: for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i www.microsoft.com ; done when connected to wireless and when not connected to wireless. Or just for that matter, check if you are using the same nameservers when connected to wireless and wired, if they are different then you already got a small part of the answer. -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
For everybody not reading the other comments, #7 actually explains what goes on Yes, indeed, probably the best solution is to use just install a local DNS resolver (pdns-resolver), which hits the roots/gtld's etc itself. This is not very friendly to the general Internet, but heck, with the largest DNS server doing short TTLs and based on geography it might not matter too much. Thus kids, apt-get install pdns-recursor and edit your /etc/resolv.conf to point to 127.0.0.1 when you get hit by this issue. -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
@ Markus's #8 comment: as I mentioned Note that the DNS queries go over IPv4 (transport), there is no IPv6 _connectivity_ involved here.. You also state 'so all IPv6 requests are answered by an IPv6 enabled DNS server.; well, unless you configured IPv6 DNS resolver addresses in your /etc/resolv.conf then queries will still go over IPv4 (transport), even though they are queries. AICCU only provides IPv6 connectivity (transport) it does not configure DNS resolvers though. @ Bernard's #9 comment: most likely your livebox contains one of these broken DNS resolvers. Happens a lot that CPEs have this issue. Try the below to check this out. Configuring resolv.conf with OpenDNS or other working DNS servers (eg the ones of your ISP directly, instead of the livebox) might solve your problem. Do also please realize that this problem ALSO occurs on other platforms than Linux, eg Windows, which is what the majority of people are using; what to use is a choice of the user afterall To verify this, do a: for i in `cat /etc/resolv.conf | grep ^nameserver | cut -f2 -d' '`; do dig @$i www.microsoft.com ; done This should return quite quickly, even though no records for www.microsoft.com exist yet. Now, if you have a broken resolver somewhere along the way, these requests won't return quickly (unless they are locally or on-path cached as negative). -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 417757] Re: [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups
This is a problem with the DNS resolver. This problem will occur for any DNS request which the DNS resolver does not support. The proper solution is to fix the DNS resolver. What happens: - Program is IPv6 enabled. - When it looks up a hostname, getaddrinfo() asks first for a record - the DNS resolver sees the request for the record, goes uhmmm I dunno what it is, lets throw it away - DNS client (getaddrinfo() in libc) waits for a response. has to time out as there is no response. (THIS IS THE DELAY) - No records received yet, thus getaddrinfo() goes for a the A record request. This works. - Program gets the A records and uses those. This does NOT only affect IPv6 () records, it also affects any other DNS record that the resolver does not support. Generally these resolvers are embedded into the NAT boxes that consumers have. Working solution, as we are on Linux anyway: don't use the DNS resolver in the NAT box, but install eg pdns-recursor and use that. Of course that does not fix the broken box, which might be the NAT box, or the resolvers at the ISP. Some other people start using OpenDNS because those work (But that is not really true either: https://lists.dns-oarc.net/pipermail/dns-operations/2009-July/004217.html) Note that the DNS queries go over IPv4 (transport), there is no IPv6 _connectivity_ involved here. -- [karmic regression] all network apps / browsers suffer from multi-second delays by default due to IPv6 DNS lookups https://bugs.launchpad.net/bugs/417757 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 223825] Re: aiccu init.d script will race dhclient (upstart issue?)
Given motivation (and no nasty crap coming my way) I'll try to finish up the all brand new AICCU this weekend. This one will have a GUI on all platforms and will also resolve a lot of other tiny tidbits, including 're-connect'. One can then just run the daemon, and it will make sure that connectivity works, if connectivity is not there (yet) it will just retry a bit later to get it up and running. Testing seems to have proven that it all more or less works, but I need to test a couple of other platforms to get everything running fine before actually bringing it out to the public (and then getting flooded with mails that it does not work especially the nice comments in there always give one sooo much motivation to solve other peoples problems that those cases are not worth it). Lets see what the weekend brings ;) -- aiccu init.d script will race dhclient (upstart issue?) https://bugs.launchpad.net/bugs/223825 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 79439] Re: New aiccu version 2007.01.15 released
Markus Vuori wrote: No. It doesn't work for dapper because libgnutls13 is not available. The following packages have unmet dependencies: aiccu: Depends: libc6 (= 2.3.6-6) but 2.3.6-0ubuntu20 is to be installed Depends: libgnutls13 (= 1.4.0-0) but it is not installable Depends: libgnutls13 but it is not installable E: Broken packages It was build on a Debian unstable, and the package worked on the current Ubunty edgy. But that is probably because that has new versions. I also tried to recompile it following the instructions on the sixxs web page. Compilation went ok but the newly compiled package is uninstallable, too, due to unmet dependencies. Which dependencies are unmet? The only versioned depends are lsb-base and libgnutls13. The first should not cause a problem, the latter can be easily changed to libgnutls12 and that should work. Modify debian/control for that and it should work. Unfortunately one can't make a 'generic-latest-on-the-buildbox' control file as far as I know. If one knows how, yell. From the next message: Tried to compile libgnutls13 from edgy source package but it appeared to be quite difficult and complicated because of missing libtasn1-3 packages for dapper :( See above on how to fix that, just use libgnutls13. The dependency for libgnutls13 is there as libgnutls12 is deprecated due to security bugs or something in that area. Greets, Jeroen -- New aiccu version 2007.01.15 released https://launchpad.net/bugs/79439 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 79439] Re: New aiccu version 2007.01.15 released
Jeroen Massar wrote:
Unfortunately one can't make a 'generic-latest-on-the-buildbox' control
file as far as I know. If one knows how, yell.
[..]
${shlibs:Depends} already includes libgnutlsXX it seesms:
Depends: libc6 (= 2.3.6-6), libgnutls13 (= 1.4.0-0), iputils-ping,
iputils-tracepath, iproute, debconf, lsb-base
(= 1.3-9ubuntu2), gawk | awk, libgnutls13
As such the libgnutls13 can be removed. Commited in AICCU CVS.
Can you check that the below control file (just cutpaste into it) works
when rebuilding the package? Note that the Depends: line is one line.
Greets,
Jeroen
debian/control/
-
Source: aiccu
Section: net
Priority: optional
Maintainer: SixXS Staff [EMAIL PROTECTED]
Build-Depends: debhelper ( 3.0.0), libgnutls-dev
Standards-Version: 3.7.2
Package: aiccu
Architecture: any
Depends: ${shlibs:Depends}, iputils-ping, iputils-tracepath, iproute,
debconf, lsb-base (= 1.3-9ubuntu2), gawk | awk
Recommends: ntpdate | ntp
Description: SixXS Automatic IPv6 Connectivity Client Utility
This client automatically gives one IPv6 connectivity
without having to manually configure interfaces etc.
One does need a SixXS account and at least a tunnel. These
can be freely gratis requested from the SixXS website.
For more information about SixXS check http://www.sixxs.net
-
--
New aiccu version 2007.01.15 released
https://launchpad.net/bugs/79439
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 79439] Re: New aiccu version 2007.01.15 released
According to the news page at SixXS all old versions where deprecated when 2007.01.07 was released, that is probably the problem there. But fortunately the version from the download page simply works. Just use a extra apt-repository in /etc/apt/sources.list and done ;) It would be great though if Ubuntu also had this new version so that Ubuntu is up to speed with the rest of the world. -- New aiccu version 2007.01.15 released https://launchpad.net/bugs/79439 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 79439] New aiccu version 2007.01.15 released
Public bug reported: Binary package hint: aiccu New package available from upstream at http://www.sixxs.net/tools/aiccu/ Including amd64, i386 and arm builds, based on Debian unstable, but run perfectly fine on Ubuntu. Debian Package can be built verbatim on Ubuntu from the tarball which is supplied. ** Affects: aiccu (Ubuntu) Importance: Undecided Status: Unconfirmed -- New aiccu version 2007.01.15 released https://launchpad.net/bugs/79439 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 79439] Re: New aiccu version 2007.01.15 released
Laurent Bigonville wrote: I see this new version too. Moreover I think that previous versions don't work anymore due to changed to the authentication system. Can you elaborate on changes to the authentication system ? As as far as I know nothing has changed there at all... Greets, Jeroen -- New aiccu version 2007.01.15 released https://launchpad.net/bugs/79439 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 72518] Re: Include aiccu in multiverse
I, as the author of AICCU am really wondering: * Why you are using diff's for this thing, while the original source tarball already contains perfectly working Debian packages (which are also available on the official site: http://www.sixxs.net/tools/aiccu/) * Why the LICENSE file is missing, or did Ubuntu break the LICENSE by just taking it out? * Why the COPYRIGHT file is changed, or does Ubuntu not need to abide by international COPYRIGHT law? And of course above all: * Where the peep you have gotten that broken 'diff' which will never work and will cause even more complaints to be sent to [EMAIL PROTECTED] about some broken version somewhere on this planet, while my name is on it and other people broke it. Thank you very much. -- Include aiccu in multiverse https://launchpad.net/bugs/72518 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 72518] Re: Include aiccu in multiverse
Richard Johnson wrote: Joeroen, I know, it is a difficult name to cutpaste... Constructive important part below, if you don't want to read the rant part, hit CTRL-F/the search menu/emacs-s/slash-s whatever and look for Constructive Part. I hope that you understand why the tone of this message is far from nice, but try answering people that there is a bug, that it is fixed in the official release, but that for some weird reason some people are releasing broken versions in your (read my) name! It is heavily frustrating, that is why you folks get this rant. Skip reading the following part if you want to be constructive and get to the point in resolving this issue. Rant section is additionally marked with /end of rant Skip to Constructive Part to avoid. start of rant This is a debdiff, all it does is create a patch against the differences between the previous version and the current version. The reason you don't see that stuff is due to it being in the previous and it hasn't been changed with the current You say that the 'debdiff' only includes the 'changes' in the new upstream. Well then lets take a look at the at what the the old PATCH actually does: ftp://ie.archive.ubuntu.com/ubuntu/pool/multiverse/a/aiccu/aiccu_20050131-1.diff.gz The few sections of it: --- aiccu-20050131.orig/debian/docs +++ aiccu-20050131/debian/docs @@ -1,3 +1,2 @@ doc/README -doc/LICENSE doc/HOWTO It throws away the LICENSE as specified by the authors of the program. --- aiccu-20050131.orig/debian/changelog +++ aiccu-20050131/debian/changelog @@ -0,0 +1,6 @@ +aiccu (20050131-1) unstable; urgency=low + + * Initial release + + -- Anand Kumria [EMAIL PROTECTED] Mon, 27 Mar 2006 07:56:20 +1100 + It throws out the original changelog and replaces it with nonsense. And what is this: --- aiccu-20050131.orig/debian/copyright +++ aiccu-20050131/debian/copyright @@ -0,0 +1,57 @@ +This package was debianized by Anand Kumria [EMAIL PROTECTED] on +Mon, 27 Mar 2006 07:56:20 +1100 Who is that person? Gary Coady(*) added the debconf support and we (SixXS) did the debian packaging, as the diff shows, that name is only slapped on to change the COPYRIGHT file, as shown above and include a !CHANGED! license in a !COPYRIGHT! file. Licenses != COPYRIGHT. * = http://www.lyranthe.org/diary/2005/04/17/ipv6-on-ubuntu/ If there is anybody that did something on the packaging then it is Gary Coady who deserves credit, not somebody who even did even has a SixXS account to test anything of it, and clearly, as the diff shows only added his name to it. Next to that the person contacted SixXS to ask if the package could be included in Debian. The Diff also patches this in, which does NOT come from us: 8 +[ summary: BSD-like but with two clauses (4) and (5) which make aiccu non-free ] 8 That is clear nonsense and is NOT the license that SixXS applied, as such it violates the license that SixXS applied to AICCU. Also note: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=388759 also clearly where Steve Langasek ([EMAIL PROTECTED]) states: 8 The license has been discussed on #debian-release, and it's my understanding that the old license was also DFSG-compliant in intent (with the help of some clarifications from upstream that had already happened). ---8 The 'patch' adds that it is non-free, while one of the main people in debian clearly says that it is fine. So this debdiff patch, applies a WRONG license, and even defames the packages this way. It also changes the COPRIGHT into a LICENSE file!? Debian might have a lot of people who consider themselves laywers, but changing copyrights and license files is not thing a thing that one should be able to do. . debdiff only pulls in the differences and applies them to the current version in the repositories. If that is the 'difference' with the new one, when are you actually going to use the REAL NEW one!? This patch doesn't include the fixes that are included in 2007.01.07 as released by us. And as it does not include the fixes, it is broken: that is AYIYA will not work. The official version does work though, see the first part above: users will complain to us and we will have to say that the version released by ubuntu is broken from the version released by us. If the license and copyright files, which I am sure they are, are already in the repos there is no need to reupload them. They are, because Ubuntu choose to use a MODIFIED license which does not match the original license. Changes LICENSES is the freedom of the author, Ubuntu is NOT the author. This is done to save space here in the bug reports. If there wasn't a license or copyright in the package, then it wouldn't be in the repositories in the first place. What a nonsense answer, if you want to save space reference simply to the
Re: [Bug 72518] Re: Include aiccu in multiverse
Richard Johnson wrote: Jeroen, First I apologize for finger-fumbling your name. I did not know that the Current or the 2005 version was in fact wrong. Which is why I am reporting this issue before it goes any further. And I sincerely hope that it gets resolved in a proper manner. The nasty tone is because I am fed up with all this political nonsense and then seeing my code get broken because an upstream uploads it wrongly. Pointing to other places to report bugs is not helping. Saying that this is not the place to report this is not helping either. Please resolve this! The version I used to create a debdiff was from YOUR website. The version you used then was broken, as it does not result in the official release. Trust me and try it yourself. The code that results from applying the 'debdiff' that you made to: ftp://ie.archive.ubuntu.com/ubuntu/pool/multiverse/a/aiccu/ is VERY different from the code at the original sources: http://www.sixxs.net/archive/sixxs/aiccu/unix/aiccu_20070107.tar.gz or the https version; https://noc.sixxs.net/archive/sixxs/aiccu/unix/aiccu_20070107.tar.gz PLEASE verify that and check your md5sum's. What you are patching does NOT result in the same code. There is a real reason why I am writing these messages. Please check it. I noted that in the debdiff it adds your license back in. [..] Also note that this debdiff also includes the correct changelog as provided by the 2007.tar.gz file I downloaded from your website. The changelog gets removed by the patches that will be done by the following debian patch: ftp://ie.archive.ubuntu.com/ubuntu/pool/multiverse/a/aiccu/aiccu_20050131-1.diff.gz and that patch is NOT removed by the patch you are proposing. What Ubuntu has done in the past was not done by me, so I can't tell you word for word what their Policy on the Licensing is, as that is up for the higher-ups to work out. If you claim to be the current maintainer, which according to launchpad you are not, then it is your responsibility to make sure that that is correct. If you are not able/capable to do so, then please explain clearly in the bug report who the higher ups are who are responsible and point those higher ups to this and make sure that it gets fixed. I don't want to be involved in this bureaucracy mess, I just want to have people actually being able to use the correct code. Not having to have to do patches all over the place at distro's who make broken patches. And certainly not having them complain that it is broken. If you have a reason for providing a patch which breaks the code, then please elaborate on why you took that decision. I am very interested in hearing also why the LICENSE and COPYRIGHT is changed by somebody who does not own the code and did not set the LICENSE nor owns any part of the COPYRIGHT. All I did was create a debdiff from the current version in the repositories against the version available from your website. As I mentioned before, and here again: It does *NOT* regenerate the original tarball. I know you may be upset, but just note that Malone, the Ubuntu Bug Tracker, is not the place to voice your rants. Where else do people file reports then? Clearly if the problems are not filed they are not cared for. The problem is caused by Ubuntu not by another place. This is a bug in the Ubuntu package of aiccu, as such hereby I file the bug. Be happy that I take the time for it, but then again that is out of self interest to avoid complaining users and mayhem because you are providing a broken version. It would be easier to be worked out by (a)emailing myself since I created the debdiff and working out This bug report is reaching you not? So why should we mail you? The 'debdiff' as you call it is provided in this bug report and it states that it is up for consideration. With these messages I am notifying you that the proposed patch is broken. Also how is it to be known that we should mail you? https://launchpad.net/ubuntu/+source/aiccu/ clearly reads: 8- Latest release: 20050131-1 Uploaded By: Ubuntu Archive Auto-Sync Maintainer: Anand Kumria Bug contacts For this package: * Kai Kasurinen ---8 It does not list your name. Also I am filing this bug report against Ubuntu, not against you. I have nothing against you. I have something against the Ubuntu package being broken and broken patches to be added. (b)emailing one of the many developement lists or MOTU list for a solution, or One of many development list which one exactly? And why not the bug report? Why does this bug report engine exist if one is not supposed to use it? (c) don't rant, but instead copy and paste the last half of your post here as hey this is how it should be. That text is in the bug report, you can read it there, that is how it should be. It clearly states where to skip to if you are not happy with reading a perfectly valid complaint about
Re: [Bug 72518] Re: Include aiccu in multiverse
Richard Johnson wrote: [..] Short reply, maybe a bit less nasty: Did you TRY the code that results from your patches? It might compile, yes, but does it actually work? - NO And every person knowing how tunneling code works can tell you that by just reading the source. Do you understand the changes that you made to the code break the functionality of the program? Really, compare the official release with the version that you created by doing the 'debdiff' and you will see that it is NOT the same. Greets, Jeroen -- Include aiccu in multiverse https://launchpad.net/bugs/72518 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
