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
Hi, I am not able to reproduce it. Does cutter still behave like this if you try it now? Cheers,
Also, did you run it as root? Cheers,
Aurélien GÉRÔME wrote:
I have just reconfirmed that it still does not work for me. (This is running
it as root.). I have cutter package 1.03-2 installed from "testing", and
kernels 2.6.18 (custom build) and 2.6.22-3-686 (debian).
I've checked cutter on a transit firewall and also on an end-point. It does
not work for me in either situation ("No matching connections found").
Regards,
Chris
Hi, 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. Cheers,
^
cutter, I meant
# Automatically generated email from bts, devscripts version 2.10.14 # unreproducible severity 446343 important
Aurélien GÉRÔME wrote: 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
Hi, Thanks for you detailed analysis. I will try to reproduce your exact setup this week-end. Cheers,
Aurélien GÉRÔME 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. 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
tags 446343 - moreinfo unreproducible thanks Hi, 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. :) 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. Cheers,
$ ip addr show
6: ppp1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc
pfifo_fast state UNKNOWN qlen 3
link/ppp
inet 94.179.179.252 peer 10.6.6.6/32 scope global ppp1
$ netstat -W -t -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 94.179.179.252:43485 74.125.65.109:993 ESTABLISHED
$ sudo cutter 74.125.65.109
openning /proc/net/ip_conntrack: No such file or directory
$ sudo modprobe ip_conntrack
$ sudo cutter 74.125.65.109
No matching connections found
$ sudo cutter 94.179.179.252 43485
No matching connections found
My set up is simpler, just a desktop with firestarter as the firewall with a DSL modem/1 port router. It seems there is a connection left in '/proc/net/ip_conntrack' (also in '/proc/net/nf_conntrack' by the way) from a Vuze/Azureus session which was closed and I'd like to kill it. Attached is an strace of 'cutter <IP address of other host>', which reports 'No matching connections'. I will try and build a debug version and figure out why no match is found yet the entry is clearly visible in '/proc/net/ip_conntrack' as having port number 14187: sudo cat /proc/net/ip_conntrack | grep 14187 tcp 6 402541 ESTABLISHED src=180.131.225.230 dst=192.168.1.64 sport=51883 dport=14187 src=192.168.1.64 dst=180.131.225.230 sport=14187 dport=51883 [ASSURED] mark=0 use=2
Hi, Dominique Brazziel wrote: Even simpler here: An end point with no firewall stuff enabled and running an IRC bot whose auto-reconnect feature I'd like to test by cutting off his connection using cutter. I had to "modprobe ip_conntrack" first and then restart the IRC bot to get the needed data. From thereon I just get "No matching connections found", even if I just enter the IP address of the IRC server. (There is no other connection present to the IRC server. With the patch by Chris Davies, I noticed that cutter outputs once "Matched IP and port" and yet outputs "No matching connections found" at the end (and the connection seems not resetted) as reported by him, too. Regards, Axel
Hi,
Chris Davies wrote:
I suspect that this program is just made for NAT routers and does not
work in any other environment like bridges or end points. Cc'ing
upstream. Maybe he can help here. (Here = http://bugs.debian.org/446343)
[...]
Thanks for that one, this indeed helped to get a little bit further.
Indeed. At that point there seem quite some cases missing. For
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
Hi again, Axel Beckert wrote: I've risen the amount of time to wait for an ACK to 80 seconds and now 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".) Regards, Axel
Hi, According to the following mail by upstream to an Ubuntu bug report against cutter (https://bugs.launchpad.net/bugs/240147), this has been fixed with a new upstream release. A new version of "cutter" has been released today. It .. * resolves the "no matching connection" issues on recent kernels * provides more useful error messages when things dont work out * improves reliability You can download the source from http://www.digitage.co.uk/cutter ----- End forwarded message ----- Regards, Axel -- ,''`. | Axel Beckert <abe@debian.org>, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Dear submitter, as the package cutter has just been removed from the Debian archive unstable we hereby close the associated bug reports. We are sorry that we couldn't deal with your issue properly. For details on the removal, please see https://bugs.debian.org/1010705 The version of this package that was in Debian prior to this removal can still be found using http://snapshot.debian.org/. Please note that the changes have been done on the master archive and will not propagate to any mirrors until the next dinstall run at the earliest. This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing ftpmaster@ftp-master.debian.org. Debian distribution maintenance software pp. Thorsten Alteholz (the ftpmaster behind the curtain)