Missing ~amd64 keyword in net-analyzer/cutter ebuild which builds correctly.
it does compile, but it doesnt seem to want to work here.
The ebuild is ok and the cutter program hasn't segfaulted during operation. However, I seem to always get the same output: "No matching connections found" It seems more of an "upstream issue" but has anyone gotten cutter to actually "cut" a tcp connection?
I see the same thing... I had tried it a long time ago and it worked, but it may have been on x86 or with a different kernel version (it relies on ip_conntrack to track connections).
According to what I've read in Debian's bug system, 1.02 was incompatible to kernel 2.6 because ip_conntrack fields had slightly changed and cutter didn't parse them correctly. But theoretically that should be fixed in 1.03 (?). Anyway whether I try Debian's latest patched cutter 1.02-1 or the original 1.03 I still get "No matching connections found". However, if I make the following changes to cutter.c: int getnexthop(in_addr_t ip, char *intf, in_addr_t *gateway) { FILE *id = fopen( "/proc/net/route", "r" ); char buff[500]; static char iface[32]; in_addr_t dest_ip, gateway_ip, mask; static int flags, refcnt, use, metric, mtu, window, irtt; // ========= int scan_conntrack(in_addr_t ip1, int port1, in_addr_t ip2, int port2) { FILE *id = fopen( "/proc/net/ip_conntrack", "r" ); static char src1[32], dst1[32], src2[32], dst2[32]; static int sport1, dport1, sport2, dport2, i; static int packets1, packets2, bytes1, bytes2; [...] if ( (match(ip1,port1,src2n,sport2) && match(ip2,port2,dst2n,dport2)) || (match(ip1,port1,dst2n,dport2) && match(ip2,port2,src2n,sport2)) || (match(ip1,port1,src1n,sport1) && match(ip2,port2,dst1n,dport1)) || (match(ip1,port1,dst1n,dport1) && match(ip2,port2,src1n,sport1)) ) { /* * local network to public network - forwarded connection */ if (localip(src1n) && !localip(dst1n) && !localip(src2n) && localip(dst2n)) { // localip(src1n) has been changed (sensible?) found ++; printf("For connection %s:%d -> %s:%d\n", src1, sport1, dst1, dport1); ok = send_rst(dst1,dport1,src1,sport1) && ok; ok = send_rst(dst2,dport2,src2,sport2) && ok ; } // ======== cc -Wall -g cutter.c -o cutter and then do: cutter-1.03 # netstat | grep 195.72. tcp 0 0 10.215.144.27:42615 195.72.134.129:http ESTABLISHED cutter-1.03 # ./cutter 10.215.144.27 42615 195.72.134.129 80 (runs during approx. 30 seconds) For connection 10.215.144.27:42615 -> 195.72.134.129:80 sending RST from 195.72.134.129:80 to 10.215.144.27:42615 (getnexthop found interface: eth0) ACK not seen so RST not sent (sorry!) sending RST from 10.215.144.27:42615 to 195.72.134.129:80 (getnexthop found interface: eth0) ACK not seen so RST not sent (sorry!) cutter-1.03 # netstat | grep 195.72. tcp 0 0 10.215.144.27:42615 195.72.134.129:http ESTABLISHED (connection still established) // ========= I'm not a C expert and I've stumbled on things like the need to declare static char iface[32] so that scanf can get the interface name, etc. Surely this can't be the way to do it. Maybe there's some issue with the C version, either the lib or the compiler. I have GCC 3.4.4-r1 GLIBC 2.3.6-r3 Also, I changed localip(src1n) in / * local network to public network - forwarded connection */ because it seemed to make sense to me but I'm probably wrong (?). Anyway, I sent an e-mail to the author of cutter (Chris Lowth) but didn't receive any feedback yet.
Another test: User at 10.215.144.48 started downloading a file from ftp://ftp.rediris.es. On Linux gateway "gw1": gw1 cutter-1.03.orig # cat /proc/net/ip_conntrack | grep "dport=21" | grep "src=10.215.144.48" tcp 6 431845 ESTABLISHED src=10.215.144.48 dst=130.206.1.5 sport=1826 dport=21 packets=185 bytes=10138 src=130.206.1.5 dst=192.168.101.2 sport=21 dport=1826 packets=180 bytes=18484 [ASSURED] mark=3 use=2 (The following was done with Debian-patched cutter-1.03-2 from SID) gw1 cutter-1.03.orig # ./cutter 10.215.144.48 1826 130.206.1.5 21 For connection 10.215.144.48:1826 -> 130.206.1.5:21 sending RST from 130.206.1.5:21 to 10.215.144.48:1826 sending RST from 192.168.101.2:1826 to 130.206.1.5:21 ACK not seen so RST not sent (sorry!) For connection 10.215.144.48:1826 -> 130.206.1.5:21 sending RST from 130.206.1.5:21 to 10.215.144.48:1826 ACK not seen so RST not sent (sorry!) sending RST from 192.168.101.2:1826 to 130.206.1.5:21 ACK not seen so RST not sent (sorry!) (The following was done with Gentoo's 1.03 ebuild, thus the original 1.03 source) gw1 cutter-1.03 # cutter 10.215.144.48 1826 130.206.1.5 21 For connection 10.215.144.48:1826 -> 130.206.1.5:21 sending RST from 130.206.1.5:21 to 10.215.144.48:1826 ACK not seen so RST not sent (sorry!) sending RST from 192.168.101.2:1826 to 130.206.1.5:21 ACK not seen so RST not sent (sorry!) gw1 cutter-1.03.orig # cat /proc/net/ip_conntrack | grep "dport=21" | grep "src=10.215.144.48" tcp 6 431940 ESTABLISHED src=10.215.144.48 dst=130.206.1.5 sport=1826 dport=21 packets=186 bytes=10178 src=130.206.1.5 dst=192.168.101.2 sport=21 dport=1826 packets=180 bytes=18484 [ASSURED] mark=3 use=2 gw1 cutter-1.03.orig # ifconfig eth0 Link encap:Ethernet HWaddr 00:C0:A8:8A:01:05 inet addr:192.168.92.2 Bcast:192.168.92.255 Mask:255.255.255.0 inet6 addr: fe80::2c0:a8ff:fe8a:105/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:17800608 errors:0 dropped:0 overruns:0 frame:0 TX packets:16119854 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:498110222 (475.0 Mb) TX bytes:2992125933 (2853.5 Mb) Interrupt:10 Base address:0x6f00 eth1 Link encap:Ethernet HWaddr 00:04:75:AF:AA:C6 inet addr:10.215.144.92 Bcast:10.215.147.255 Mask:255.255.252.0 inet6 addr: fe80::204:75ff:feaf:aac6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:17495376 errors:0 dropped:0 overruns:1 frame:0 TX packets:19096956 errors:0 dropped:0 overruns:0 carrier:0 collisions:316485 txqueuelen:1000 RX bytes:3331993217 (3177.6 Mb) TX bytes:890334772 (849.0 Mb) Interrupt:11 Base address:0x8e80 eth2 Link encap:Ethernet HWaddr 00:60:08:6E:65:A3 inet addr:192.168.100.2 Bcast:192.168.100.255 Mask:255.255.255.0 inet6 addr: fe80::260:8ff:fe6e:65a3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:950456 errors:0 dropped:0 overruns:0 frame:0 TX packets:337207 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:465922942 (444.3 Mb) TX bytes:174957633 (166.8 Mb) Interrupt:5 Base address:0xef00 eth3 Link encap:Ethernet HWaddr 00:10:5A:F1:2F:C3 inet addr:192.168.101.2 Bcast:192.168.101.255 Mask:255.255.255.0 inet6 addr: fe80::210:5aff:fef1:2fc3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:130622 errors:0 dropped:0 overruns:0 frame:0 TX packets:101891 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:68768599 (65.5 Mb) TX bytes:9236846 (8.8 Mb) Interrupt:9 Base address:0x2e00 The system is a multi-ISP gateway/router and cutter is correctly detecting 192.168.101.2's interface eth3. However, the connection is not cut.
Olivier, how did you make your test? (I was doing it wrong) The fact is that I re-read the short documentation and realized I was doing it wrong. Cutter cuts connections that **pass through it**, so the system where cutter is running should be a router/bridge/firewall. So for example: <Internet HTTP server>---<Linux router with cutter>---<LAN client with wget> Suppose you launch wget on the LAN client and download, say, a Gentoo Universal CD iso image. On the Linux router you list the connection: grep Internet_Server_IP /proc/net/ip_conntrack and cut it: cutter LAN_CLIENT_IP LAN_CLIENT_PORT INTERNET_SERVER_IP 80 This should make wget say that the connection was reset by peer. If you redo the test I would appreciate it if you could post the output.
reassigning to netmon, since not ready for stabilization
(In reply to comment #7) > reassigning to netmon, since not ready for stabilization > I meant keywording, sorry.
Fixed in CVS, applied patch from debian and works for me now
