diff --git a/README b/README
index 0cabc2d..7796050 100644
--- a/README
+++ b/README
@@ -1,27 +1,30 @@
-FTester - Introduction and Tutorial v1.0
 
-The Firewall Tester (ftester for friends), is a tool designed for testing 
-firewalls filtering policies, from version 0.6 it also includes an Intrusion 
+NOTE: this tool is now outdated and is presented here for historical reasons.
+
+FTester - Introduction and Tutorial
+
+The Firewall Tester (ftester for friends), is a tool designed for testing
+firewalls filtering policies, from version 0.6 it also includes an Intrusion
 Detection System (IDS) testing feature. Basically ftester is made of a packet
-generator tool (ftest) and a sniffer (ftestd), the first script injects custom 
-packets with a signature in the data part while the sniffer listens for such 
-marked packets, the comparison of the sniffer logs with the injector ones 
-permits the identification of firewall filtering rules. Unlike common firewall 
-testing tools or packet generators ftester is capable of generating network 
-traffic that will looks like real connections to the firewall or IDS system 
-tested, this feature allows us to test stateful inspection firewalls (like 
-netfilter or ipfilter) and IDS (like snort). Another advantage of this 
-architecture is that we can spoof crafted packets source address since the 
-sniffer knows which packets are generated by it's counterpart, some tricks 
-involving TTL permits the spoofing also when simulating real connections, this 
-is described as the 'connection spoofing mode'. 
+generator tool (ftest) and a sniffer (ftestd), the first script injects custom
+packets with a signature in the data part while the sniffer listens for such
+marked packets, the comparison of the sniffer logs with the injector ones
+permits the identification of firewall filtering rules. Unlike common firewall
+testing tools or packet generators ftester is capable of generating network
+traffic that will looks like real connections to the firewall or IDS system
+tested, this feature allows us to test stateful inspection firewalls (like
+netfilter or ipfilter) and IDS (like snort). Another advantage of this
+architecture is that we can spoof crafted packets source address since the
+sniffer knows which packets are generated by it's counterpart, some tricks
+involving TTL permits the spoofing also when simulating real connections, this
+is described as the 'connection spoofing mode'.
 
 The ftester components are perl scripts so they can be executed on any platform
 with a recent version of perl (at least 5.6.1 is recommended) and the three perl
-modules Net::RawIP, Net::PcapUtils, NetPacket, they can be downloaded at 
+modules Net::RawIP, Net::PcapUtils, NetPacket, they can be downloaded at
 www.cpan.org or using the CPAN shell.
 
-Installation is quite simple, just untar the archive ftester-X.X.tar.gz and 
+Installation is quite simple, just untar the archive ftester-X.X.tar.gz and
 everything we need will be decompressed in the ftester-X.X directory, here
 we'll find:
 
@@ -30,7 +33,7 @@ we'll find:
  - ftest.conf (ftest example configuration file)
  - freport (a script for comparing ftest and ftestd log files)
 
-the rest is documentation (I recommend reading the man page ftester.8). 
+the rest is documentation (I recommend reading the man page ftester.8).
 
 The invocation of ftest and ftestd without options will show an usage summary,
 look at the documentation for a detailed explanation regarding these options and
@@ -90,7 +93,7 @@ for ICMP packets
 
 here's are a few examples:
 
-# SYN packet to 10.1.7.1 port 80 
+# SYN packet to 10.1.7.1 port 80
 192.168.0.10:1024:10.1.7.1:80:S:TCP:0
 
 # PSH,ACK reply from 192.168.0.10
@@ -116,13 +119,13 @@ can be accomplished with the following syntax:
 stop_signal=192.168.0.1:666:10.1.7.1:666:S:TCP:
 
 the stop_signal can be a TCP, UDP or ICMP packet, this packet will cause the
-termination of the sniffer so every packet specified after the stop_signal 
+termination of the sniffer so every packet specified after the stop_signal
 directive wont be seen by ftestd.
 
-Let's first see it's basic usage in testing basic non-stateful firewall 
-filtering policies.  We'll use the ftest script on a machine placed outside the 
-firewall and ftestd on a machine placed inside the firewall on the DMZ we want 
-to test (of course if we want to test outbound filtering we can reverse ftest 
+Let's first see it's basic usage in testing basic non-stateful firewall
+filtering policies.  We'll use the ftest script on a machine placed outside the
+firewall and ftestd on a machine placed inside the firewall on the DMZ we want
+to test (of course if we want to test outbound filtering we can reverse ftest
 and ftestd placement).
 
 -----------                             ------------
@@ -135,7 +138,7 @@ Host A IP Address: 10.1.7.1
 
 Step 1:
 
-For testing which privileged services can be reached from the outside we'll use 
+For testing which privileged services can be reached from the outside we'll use
 the following simple configuration file:
 
 - ftest.conf -
@@ -155,7 +158,7 @@ Let's start as root ftestd on Host B:
 
 [root@hostb]# ./ftestd -i eth0 -v
 
-Let's injects the packets as root on Host A: 
+Let's injects the packets as root on Host A:
 
 [root@hosta]# ./ftest -f ftest.conf -v -d 0.01
 
@@ -174,7 +177,7 @@ created.
 1024 - 192.168.0.10:1025 > 10.1.7.1:1024 S TCP 0
 1025 - 192.168.0.10:1025 > 10.1.7.1:1025 S TCP 0
 1026 - 192.168.0.10:1025 > 10.1.7.1:3128 S TCP 0
-1027 - 192.168.0.10:80 > 10.1.7.1:1025 PA TCP 
+1027 - 192.168.0.10:80 > 10.1.7.1:1025 PA TCP
 # ftest stopped on Tue Jun  4 22:38:42 CEST 2002
 
 On Host B ftestd shows the same messages and creates the ftestd.log file.
@@ -224,32 +227,32 @@ As we can see ftp,telnet,ssh,smtp,http,pop3,auth are apparently reachable from
 the outside, https is forwarded to host 10.1.7.5 and the rest, including the
 proxy port is filtered, of course NAT regarding the destination address can be
 detected only if we sniff on a non-switched environment otherwise only port
-address translation or source address translation can be detected. 
+address translation or source address translation can be detected.
 
-The sniffing of packet 1027 (the PSH,ACK from port 80) demonstrate that we are 
+The sniffing of packet 1027 (the PSH,ACK from port 80) demonstrate that we are
 dealing with a simple firewall that does not perform connection tracking,
 however as of today stateful inspection firewalls are more likely to be found in
 real environments. Stateful inspection firewalls usually performs connection
 tracking and they are not suppose to pass unmatched packets that aren't part of
-a previously initiated connection, for this reason if we need to test the 
-filtering policies regarding PSH,ACK and moreover URG,RST,FIN packets we have to 
-create a real connection with the proper SYN,SYN-ACK,ACK handshake before 
-sending them with the correct sequence numbers, the ftestd process will send the 
-correct replies.  However when simulating the connection if we are spoofing the 
-source address the stack of the destination host will reply to our spoofed 
-packets and the real host that we'are spoofing will consequently reset the 
-connection since it hasn't started it. So we have to do two things, hiding the 
-stack response to the spoofed host and to the firewall and make sure that ftestd 
-reply will traverse the firewall by not reaching the spoofed host. Hiding the 
-stack response could be done by setting a very low default TTL in 
-/proc/sys/net/ipv4/ip_default_ttl (Linux only). Hiding to the spoofed host 
-ftestd reply is done by setting its TTL to a low value equal to the hop delay 
-between ftestd and the firewall. The -s flag for ftest and the -c flag for 
-ftestd must be tuned for this mode, for example use ./ftestd -c 0:3 for 
-temporarly setting default stack ttl to 0 and ftestd reply ttl to 3, the 
+a previously initiated connection, for this reason if we need to test the
+filtering policies regarding PSH,ACK and moreover URG,RST,FIN packets we have to
+create a real connection with the proper SYN,SYN-ACK,ACK handshake before
+sending them with the correct sequence numbers, the ftestd process will send the
+correct replies.  However when simulating the connection if we are spoofing the
+source address the stack of the destination host will reply to our spoofed
+packets and the real host that we'are spoofing will consequently reset the
+connection since it hasn't started it. So we have to do two things, hiding the
+stack response to the spoofed host and to the firewall and make sure that ftestd
+reply will traverse the firewall by not reaching the spoofed host. Hiding the
+stack response could be done by setting a very low default TTL in
+/proc/sys/net/ipv4/ip_default_ttl (Linux only). Hiding to the spoofed host
+ftestd reply is done by setting its TTL to a low value equal to the hop delay
+between ftestd and the firewall. The -s flag for ftest and the -c flag for
+ftestd must be tuned for this mode, for example use ./ftestd -c 0:3 for
+temporarily setting default stack ttl to 0 and ftestd reply ttl to 3, the
 ip_default_ttl will be restored when a stop_signal is received.
 
-The so called 'connection spoofing mode' can be activated with the 'connect=' 
+The so called 'connection spoofing mode' can be activated with the 'connect='
 prefix, let's use this mode:
 
 - ftest.conf -
@@ -263,9 +266,9 @@ stop_signal=192.168.0.10:1025:10.1.7.1:80:S:TCP:0
 
 and again:
 
-[root@hostb]# ./ftestd -i eth0 -c 0:3 -v 
+[root@hostb]# ./ftestd -i eth0 -c 0:3 -v
 
-[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 
+[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1
 
 Sent Syn Probe => 192.168.0.10:1025 > 10.1.7.1:22 S TCP
 Sleeping for 1 seconds
@@ -278,7 +281,7 @@ Sent Ack Reply => 192.168.0.10:1025 > 10.1.7.1:23 A TCP
 8 - 192.168.0.10:1025 > 10.1.7.1:23 UR TCP 0
 Stop packet => 192.168.0.10:1025 > 10.1.7.1:80 S TCP
 
-note that this time ftest is configured to wait 1 second for ftestd replies. 
+note that this time ftest is configured to wait 1 second for ftestd replies.
 
 It's useful to see what traffic we are generating using tcpdump:
 
@@ -299,12 +302,12 @@ It's useful to see what traffic we are generating using tcpdump:
 15:16:06.032223 192.168.0.10.1025 > 10.1.7.1.23: S [tcp sum ok] 63848:63856(8) win 65535 (DF) (ttl 200, id 6, len 48)
 15:16:06.034946 10.1.7.1.23 > 192.168.0.10.1025: S [tcp sum ok] 64872:64872(0) ack 63856 win 65535 (DF) [tos 0x10]  (ttl 200, id 1, len 40)
 15:16:07.051963 192.168.0.10.1025 > 10.1.7.1.23: . [tcp sum ok] ack 1 win 65535 (DF) (ttl 200, id 7, len 40)
-# the correct RST 
+# the correct RST
 15:16:07.061863 192.168.0.10.1025 > 10.1.7.1.23: R [tcp sum ok] 63856:63871(15) win 65535 urg 0 [RST ftestertcpprobe] (DF) (ttl 200, id 8, len 55)
 15:16:07.072021 192.168.0.10.1025 > 10.1.7.1.23: R [tcp sum ok] 63871:63876(5) win 65535 urg 0 [RST ackme] (DF) (ttl 200, id 9, len 45)
 15:16:07.074616 10.1.7.1.23 > 192.168.0.10.1025: . [tcp sum ok] ack 21 win 65535 (DF) [tos 0x10]  (ttl 200, id 2, len 40)
 
-# the stop_signal 
+# the stop_signal
 15:16:07.083321 192.168.0.10.1025 > 10.1.7.1.80: S [tcp sum ok] 0:11(11) win 65535 (DF) (ttl 200, id 10, len 51)
 
 again here's the logs comparison:
@@ -329,21 +332,21 @@ Filtered or dropped packets:
 5 - 192.168.0.10:1025 > 10.1.7.1:23 UR TCP 0
 
 the first RST has been dropped this confirm that we'are probably dealing with a
-stateful inspection firewall. 
+stateful inspection firewall.
 
 If more than one packet is specified with the 'connect=' prefix and the same
 connection parameters (source address/port, destination address/port) the
--r/-F flags must be used to correctly close (with a RST or a FIN handshake) each 
-connections, otherwise, if the firewall is performing sequence numbers tracking, 
-connections other than the first will be blocked. 
+-r/-F flags must be used to correctly close (with a RST or a FIN handshake) each
+connections, otherwise, if the firewall is performing sequence numbers tracking,
+connections other than the first will be blocked.
 
 The IDS testing option permits the injection of arbitrary packets with custom
 payload, using a payload that is supposed to trigger an IDS alert we can test
-IDS visibility on the network and it's ability of sniffing fragmented/segmented 
-packets. A number of common IDS evasion techniques are also implemented for 
-activation during packets injection. The configuration file for this mode will 
-use the standard syntax with the 'ids=' and 'ids-conn=' prefixes, additionally 
-ftest can directly use a snort (http://www.snort.org) rule definition file 
+IDS visibility on the network and it's ability of sniffing fragmented/segmented
+packets. A number of common IDS evasion techniques are also implemented for
+activation during packets injection. The configuration file for this mode will
+use the standard syntax with the 'ids=' and 'ids-conn=' prefixes, additionally
+ftest can directly use a snort (http://www.snort.org) rule definition file
 (check documentation for currently supported keywords). Here's a syntax example:
 
 - ftest.conf -
@@ -385,16 +388,16 @@ Let's start as root ftestd on Host B:
 
 [root@hostb]# ./ftestd -i eth0 -c 0:3 -v
 
-Let's injects the packets as root on Host A: 
+Let's injects the packets as root on Host A:
 
-[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F 
+[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F
 
 Sent Syn Probe => 192.168.0.10:1025 > 10.1.7.1:80 S TCP
 Sleeping for 1 seconds
 Sent Ack Reply => 192.168.0.10:1025 > 10.1.7.1:80 A TCP
 6 - 192.168.0.10:1025 > 10.1.7.1:80 PA TCP 0 "cmd.exe"
 
-Immidiately snort alerts us with the following syslog message (notice that snort
+Immediately snort alerts us with the following syslog message (notice that snort
 also warn us about ftest signature in the SYN packet):
 
 Jun  5 16:25:13 lcars snort[4467]: [111:5:1] spp_stream4: DATA ON SYN detection [Classification: Unknown Traffic] [Priority: 3]: {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
@@ -405,13 +408,13 @@ techniques (see documentation for a detailed description):
 
 [root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F -g 2
 [root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F -e stream -p 3
-[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F -e stream -p 1b 
+[root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F -e stream -p 1b
 [root@hosta]# ./ftest -f ftest.conf -v -d 0.01 -s 1 -F -e desync1
 
 and so on...
 
 Since snort rocks it identifies correctly the triggering payload each time:
- 
+
 Jun  5 16:29:32 lcars snort[4467]: [111:5:1] spp_stream4: DATA ON SYN detection {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
 Jun  5 16:29:34 lcars snort[4467]: [1:1002:2] WEB-IIS cmd.exe access [Classification: Web Application Attack] [Priority: 1]: {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
 Jun  5 16:30:16 lcars snort[4467]: [111:5:1] spp_stream4: DATA ON SYN detection {TCP} 192.168.0.10:1025 -> 10.1.7.1:80
diff --git a/README.redhat b/README.redhat
deleted file mode 100644
index 7a182fb..0000000
--- a/README.redhat
+++ /dev/null
@@ -1,14 +0,0 @@
-
-- Notice to RedHat 8 users (last update: 14/05/03)
-
-It seems that ftest has some problems on RedHat 8, especially with the 'ids='
-syntax, corrupted packets were seen on two different installations. However
-ftest works correctly on another RedHat 8 installation and other distros. 
-
-I'm trying to isolate the cause but since I'm not using RedHat on my dev machines 
-it will take some time to find a solution. Meanwhile I would appreciate any report
-about strange packets (especially on RedHat 8) because it can be really useful for 
-catching this bug.
-
-By the way evidence suggests that this is some low-level problem related only to redhat
-perl+libpcap+glibc? and Net-RawIP, definetly not some coding issue (I hope ;) ).
diff --git a/debian/changelog b/debian/changelog
index fc2e76b..46203fe 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ftester (1.0+git20170213.1.2d8f0eb-0kali1) UNRELEASED; urgency=low
+
+  * New upstream snapshot.
+
+ -- Kali Janitor <janitor@kali.org>  Mon, 24 May 2021 15:51:25 -0000
+
 ftester (1.0-1kali2) kali-dev; urgency=medium
 
   [ Raphaƫl Hertzog ]
diff --git a/ftester.8 b/ftester.8
index 4a4d210..f1b6db5 100644
--- a/ftester.8
+++ b/ftester.8
@@ -62,6 +62,8 @@ FTester - Firewall and IDS testing tool
 FTester is a tool designed for testing firewalls filtering policies and
 Intrusion Detection System (IDS) capabilities.
 
+.B NOTE: this tool is now outdated and is presented here for historical reasons.
+
 The tool consists of two perl scripts, a packet injector
 .RI ( ftest )
 and the listening sniffer
@@ -563,8 +565,7 @@ published by the Free Software Foundation.
 .B Andrea Barisani
 .BI <andrea@inversepath.com>
 
-The latest version of FTester can be found at
-.BI http://dev.inversepath.com/trac/ftester
+.B NOTE: this tool is now outdated and is presented here for historical reasons.
 
 .SH NOTES