GSoc 2008 project proposal.. please suggest any uncovered details

anish babu anishbabu.m at
Sat Apr 12 14:50:59 UTC 2008

Sorry for my multiple mails.. previous mail was sent acidentally with
out complete details.

Hi all,
 My name is Anish and I am a graduate student at Texas A&M University ,
 college station. I made a proposal for GSoC 2008 and the description
 is as follows.

 Title: "Passive libpcap based TCP session anomaly detector"
  A daemon to listen on a network interface and logs the anomalies in
 connection is to be designed. If there are no anomalies, then normal
 information like sequence numbers, acknowledgment numbers, SYN
 features etc, are logged to understand the behavior of connection. In
 case of anomalies, like duplicate packets, duplicate acknowledgments,
 SACK responses, out of order segments etc...  then it logs the packet
 headers into the tcpdump file for later analysis by tools like

 This tool helps in analyzing various TCP algorithms in real practice
 on internet instead of abstract theoretical explanations.


 Steps to capture packets using lippcap library:
 1) Open an interface
 2) Open the device for capturing packets:
 3)Apply filters to capture only TCP packets:
 4)Collect a set of 'count' packets and apply a call back function for
 each of the pakcet.
 We now have the packet in the u_char* packet variable of the callback
 function. If we we are accessing TCP/IP packets on an Ethernet, then
 we have ethernet, IP. TCP headers in order at the start of packet. So,
 we have to strip ethernet headers and IP headers in order to access
 TCP headers.

 All of the main processing is done in call back function.

 Assumptions ( for the below solution):
 1)Before this, I have a few doubts regarding sliding window protocol
 working. Is there a any way to access the 'Last byte Read by
 application', 'Next Byte Expected', 'Last Byte received' values from
 our function? I assume that we can somehow know these values.

 2)We are maintaining seperate statistics for each session indicated by
 (dest.port, dest.IP, Source.port, Source.IP) pair. However, if we are
 collecting statistics on a single machine, (dest.port, source.port)
 pair is enough to uniquely track each session.

 3) That the transmit and receive side buffers are linear. however
 below ideas can be easily extended if they are circular.

 On Receiving side:
 a) Duplicate packets: Maintain a bit array of size ('Last Byte read' -
 'Next Byte Expected'). If any packet with sequence numbers in this
 range is found , set the bit to 1 if already 0. Otherwise, increment
 the counter of duplicate packets. If any packet with sequence number
 less that 'Next byte Expected' is found, then just the increment the
 counter of duplicate packets.

 b) Out of order segments :
 For every packet, if the sequence number is less than the 'Last Byte
 Received' that means that this is an out of order packet. So increase
 the counter for this session.

 Sending side:

 c) Duplicate Acknowledgements:
 Use the 'Last Byte Acknowledged' pointer of sliding window to track
 until howmany bytes were acknowledged and check with this for all
 incoming ACK packets. Lesser ACK in new packet means this is duplicate
 ACk packet and increment the counter for this session.

 d) SACK responses: ( I think this is not necessary when we are
 maintaining statistic for out of order packets on receiving side. What
 you say? )
 we can use the SACK packets ( if both sides agree to use SACK option)
 to track how many packets are reaching the receiver out of order. Use
 the log details stored in Header for the start and end of
 non-contiguous bytes reached to receiver.

 All of the above statistics are collected for each individual session.
 We can apped the details even if the session incarnates( begins
 Produce summarized results for easy understanding.

 More detailed description is can be found in my application in GSoC 2008.
Please feel free to ask me for any further details.


More information about the freebsd-hackers mailing list