Logging Framework Change

Decided I was going about it all wrong (it was getting late). Changed the implementation to simply provide convenience methods on top of the Python 'logging' package's framework -- with the added benefit of not having to worry about the nitty-gritty of the 'logging' package. Just simple, direct access to the log methods.

     >>> from loggable  import Loggable
     >>> class A(object): 
     ...    def  __init__(self): 
     ...      self.log = Loggable (self) 
     ...   
     >>> a = A() 
     >>> a.log.info('test') 
     2009-05-24 12:48:08,654 - __main__.A - INFO - test 
     >>> a.log.critical('test') 
     2009-05-24 12:48:19,475 - __main__.A - CRITICAL - test 
     >>> a.log.state('test') 
     2009-05-24 12:48:22,978 - __main__.A - STATE_CHANGE - test 
     >>> a.log.pktsent ('test') 
     2009-05-24 12:48:26,402 - __main__.A - PACKET_SENT - test 
     >>> a.log.generated('test') 
     2009-05-24 12:48:49,516 - __main__.A - RESPONSE_GEN - test 
     >>> a.log.field('test') 
     2009-05-24 12:48:52,475 - __main__.A - FIELD_CHANGE - test

Also have been working on a simple TCP State Machine today. My theory is that we will need to know [1] what state the local TCP connection is in, and [2] what state the remote TCP connection should be in. A simple state machine should allow us to do this with some flexibility. Here is the base class/interface. Suggestions are highly welcomed:

class  TcpState(object):
    ''' 
    Base TCP State class.   Note that it will, by design, ignore all non-TCP layers.
    The TCP State classes will not perform verification that the packets are all
    to/from the same hosts.   That filtering will be implemented elsewhere in the
    framework.
    '''
    
    def  __init__(self):
        self._nextState = None 
    
    def  packetSent(self, tcpPacket):
        ''' 
        Hand off a packet to the TcpState object, where the object will perform
        any necessary calculation, and determine if a state change should be
        caused by the provided packet.
        
        The packet should be a packet that is considered 'sent' from
        the TCP stack that this state belongs to.
        
        @return True if the packet causes a state change.   False otherwise.
        '''
         return  False
    
    def  packetRecvd(self, tcpPacket):
        ''' 
        Same as packetSent, but in the opposite direction.
        
        The packet should be a packet that is considered 'received' from
        the remote TCP stack.
        
        @see packetSent
        '''
         return  False
    
    def  causedStateChange(self):
        ''' 
        Returns true if a previous call to packetSent/packetRecvd caused a  
        state-change.
        '''
        return  self._nextState != None 
    
    def  getNextState(self):
        ''' 
        Returns the class (subclass of TcpState) that represents the state that
        the TCP stack should be in, as a result of previous packetSent/Recvd  calls.
        @return A class object, or None if no state change should occur.
        '''
        return  self._nextState

Interesting Predicament: Blogo does not like pasting HTML code inside of "pre" tags. It tries to make the HTML code visible, by changing each < and > to "<" or ">", respectively. It seems that I can't find a Blog client that does everything perfectly. So no Python syntax highlighting for now.

Read more...

Structure

Thinking about the best way to structure the TCP regression framework. A few things immediately jump out at me:

• Handle either IPv4 or IPv6 gracefully
• Reuse the most code possible
• Easy generations of responses (e.g. create new Chain, with corresponding TCP layer with filled-in fields like Sequence number, Ack number, Ack flag, etc.)
• Ability to test that the opposite side is actually getting a connection and recv'ing data
  

Handling IPv4 and IPv6 Gracefully

The simplest way to do this would be to define an interface and two implementations. However, I need to look into the differences between IPv4 and IPv6 a bit more -- static header size may preclude IPv6 from needing some tests, and there may yet be other differences.

Code Reuse

Code reuse will likely fit into the same category as above. Simple interface/implementation class hierarchy may do the trick. However, aside from the direct manipulation of the tests, there may be some tests which are a subset of other tests, or the same test may need to be run under multiple circumstances. Preventing duplicated code is something I really put a high priority on.

Response Generation

Response generation will also be a subset of the two above areas. For example, let's say I send a SYN packet, and I find the corresponding SYN/ACK packet. Having a method that generates the final ACK packet would be beneficial (or that generates an ACK packet to any packet).

Connectivity Testing

Connectivity testing should be fairly trivial. Basically, set up an echo server. If the connection is properly established, the data should be echoed back without problem. This particular solution should also lend itself to testing window sizes.

Side Note:
The blog client Blogo is amazing. Full-screen, rich-text editing FTW.

Read more...