Bug#446343: cutter: does not work at all
Chris Davies
Version: 1.03-2
Severity: grave
Justification: renders package unusable
Cutter does not work as described; it always reports "No matching
connections found". Here is a repeatable example:
netstat -an | grep 'ESTABLISHED'
tcp 0 0 192.168.130.5:38101 10.1.30.129:22 ESTABLISHED
tcp 0 0 192.168.130.5:38819 10.1.30.129:993 ESTABLISHED
....
cutter 192.168.130.5 38101 10.1.30.129 22
No matching connections found
cutter 192.168.130.5 38101 10.1.30.129
No matching connections found
cutter 192.168.130.5 38101
No matching connections found
cutter 10.1.30.129 22 192.168.130.5 38101
No matching connections found
cutter 10.1.30.129 22 192.168.130.5
No matching connections found
cutter 10.1.30.129 22
No matching connections found
Regards,
Chris
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (900, 'stable'), (300, 'unstable'), (50, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages cutter depends on:
ii libc6 2.6.1-1+b1 GNU C Library: Shared libraries
cutter recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Aurélien GÉRÔME
On Fri, Oct 12, 2007 at 11:13:44AM +0100, Chris Davies wrote:
>Cutter does not work as described; it always reports "No matching
>connections found". Here is a repeatable example:
>
>netstat -an | grep 'ESTABLISHED'
>tcp 0 0 192.168.130.5:38101 10.1.30.129:22 ESTABLISHED
>tcp 0 0 192.168.130.5:38819 10.1.30.129:993 ESTABLISHED
>....
>
>cutter 192.168.130.5 38101 10.1.30.129 22
>No matching connections found
>cutter 192.168.130.5 38101 10.1.30.129
>No matching connections found
>cutter 192.168.130.5 38101
>No matching connections found
>
>cutter 10.1.30.129 22 192.168.130.5 38101
>No matching connections found
>cutter 10.1.30.129 22 192.168.130.5
>No matching connections found
>cutter 10.1.30.129 22
>No matching connections found
I am not able to reproduce it. Does cutter still behave like this if
you try it now?
Cheers,
--
.''`. Aurélien GÉRÔME
: :' :
`. `'` Free Software Developer
`- Unix Sys & Net Admin
Aurélien GÉRÔME
> Thanks to this bug, cutter got blindly removed from testing, and I
> still _cannot_ reproduce it. It would ne nice to get some recipe to
> reproduce it, if we ever want it to be released with Lenny.
^
cutter, I meant
--
.''`. Aurélien GÉRÔME
: :' :
Chris Davies
> Thanks to this bug, cutter got blindly removed from testing, and I
> still _cannot_ reproduce it. It would ne nice to get some recipe to
> reproduce it, if we ever want it to be released with Lenny.
I've added some debug to the program, and it seems to me that it simply cannot
work. Either that or I'm grossly misunderstanding what it does.
The attached patch applies my debug code to the debian cutter version 1.03-2.
Apologies for the code quality; I haven't written any C for a good number of
years, now, and it was thrown together in a hurry.
To reproduce the situation where it doesn't work for me, you need three
systems: A (10.1.20.42 /16) and C (192.168.130.252 /21) are connected via B
(10.1.1.106 /16 and 192.168.133.13 /21). There's no NAT involved. On A, ssh to
C. Log in to B and you'll see an entry in /proc/net/ip_conntrack matching the
connection.
I picked it out with this ugly line:
sudo grep 'tcp.*ESTABLISHED' /proc/net/ip_conntrack | grep '10.1.20.42' | grep
'192.168.*252' | grep 'port=22 '
Now run the patched version of cutter and you'll see something like this:
Args: /tmp/cutter 192.168.130.252 22 10.1.20.42
...
Got tcp/ESTABLISHED
> src=10.1.20.42
> dst=192.168.130.252
> sport=36707
> dport=22
> src=192.168.130.252
> dst=10.1.20.42
> sport=22
> dport=36707
Matched IP and port
localip(src1n=10.1.20.42)=0, localip(dst1n=192.168.130.252)=0,
localip(src2n=192.168.130.252)=0, localip(dst2n=10.1.20.42)=0
Got tcp/ESTABLISHED
...
Looking at the code around 540, there are a number of condition criteria that
check for local/remote IP address (I guess that "local" means a local
interface for the box on which cutter is running).
If you have a connection from A to C, via B, then neither of the address pairs
are going to be local, so neither of the two if() statements can succeed.
I haven't had time to dig further (maybe tomorrow), but I would imagine a
patch will be pretty straightforward.
Regards,
Chris
Chris Davies
> Thanks for you detailed analysis. I will try to reproduce your exact
> setup this week-end.
Have you had time to look at this, yet? I would be interested in you
describing a setup that I can try to reproduce here, as I cannot get cutter to
work for me at all.
With regard to my throwaway comment of Feb 14 that, "I would imagine a patch
will be pretty straightforward", are you planning to do this or should I have
a stab at it?
Regards,
Chris
Aurélien GÉRÔME
thanks
Hi,
On Sat, Mar 08, 2008 at 09:37:20AM +0000, Chris Davies wrote:
> Have you had time to look at this, yet? I would be interested in you
> describing a setup that I can try to reproduce here, as I cannot get cutter
> to work for me at all.
No, I had not. I need to organise several boxes in the same network
topology as yours to reproduce your setup, but I currently do not
have physical access to such boxes. I thought about a setup with
several qemu instances though, but this is really tedious.
Perhaps I can hook up some free Ultra5 boxes at work to reproduce
your setup, I will try it this month. I am currently working on the
PS3 integration in Debian, so this probably will not happen this
upcoming week. :)
> With regard to my throwaway comment of Feb 14 that, "I would imagine a
> patch will be pretty straightforward", are you planning to do this or
> should I have a stab at it?
If you can fix what happens in your setup which I believe is a right
use case, I will gratefully accept your patch. I will test it to see
if it does not break my simple daily-use setup, and then do an upload
to fix this bug.
Axel Beckert
Chris Davies wrote:
> Aurélien GÉRÔME wrote:
> >Thanks to this bug, cutter got blindly removed from testing, and I
> >still _cannot_ reproduce it. It would ne nice to get some recipe to
> >reproduce it, if we ever want it to be released with Lenny.
>
> I've added some debug to the program, and it seems to me that it
> simply cannot work. Either that or I'm grossly misunderstanding what
> it does.
work in any other environment like bridges or end points. Cc'ing
upstream. Maybe he can help here. (Here = http://bugs.debian.org/446343)
> The attached patch applies my debug code to the debian cutter
Thanks for that one, this indeed helped to get a little bit further.
> Looking at the code around 540, there are a number of condition
> criteria that check for local/remote IP address (I guess that
> "local" means a local interface for the box on which cutter is
> running).
>
> If you have a connection from A to C, via B, then neither of the
> address pairs are going to be local, so neither of the two if()
> statements can succeed.
outgoing endpoints and bridges (as commonly found on Xen Dom0s) I had
to add the following two cases:
/* Outbound connection from private network device */
else if (localip(src1n) && !localip(dst1n) && !localip(src2n) && localip(dst2n)) {
puts("Outbound connection from private network device");
found ++;
printf("For connection %s:%d -> %s:%d\n", dst2, dport2, src2, sport2);
ok = send_rst(dst1,dport1,src1,sport1) && ok;
ok = send_rst(dst2,dport2,src2,sport2) && ok;
}
/* Connection going through */
else if (!localip(src1n) && !localip(dst1n) && !localip(src2n) && !localip(dst2n)) {
puts("Connection going through");
found ++;
printf("For connection %s:%d -> %s:%d\n", dst2, dport2, src2, sport2);
ok = send_rst(dst1,dport1,src1,sport1) && ok;
ok = send_rst(dst2,dport2,src2,sport2) && ok;
}
Nevertheless, this wasn't everything to make it work. In both cases I
got the message "Cant find next hop gateway in routing table" once or
twice.
The code where you have to start if you want to fix this is likely
around line 312 and then around line 130.
While the if-case in line 129 seems logical for me, the flags variable
always contains 0 despite it contains non-zero values in
/proc/net/route. If I comment out line 132 ("(flags & 0x0001) && //
route is UP"), it seems to select the right route, but I always end up
with the message "ACK not seen so RST not sent (sorry!)".
So I suspect there's more fishy than I found out so far. :-(
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
Axel Beckert
Axel Beckert wrote:
> While the if-case in line 129 seems logical for me, the flags variable
> always contains 0 despite it contains non-zero values in
> /proc/net/route. If I comment out line 132 ("(flags & 0x0001) && //
> route is UP"), it seems to select the right route, but I always end up
> with the message "ACK not seen so RST not sent (sorry!)".
it seems to always work on the bridging computer and sometimes work on
the end point computer. Now I can at least debug the reconnect feature
of my IRC bot.
Attached the patch with which I came that far. It's though very likely
not yet complete to solve all the related issues. (Hence no tag
"patch".)