| 
 Hi Kelvin, 
  
The radius dissectors uses a hash table to store 
multiple sessions per conversation. You might want to have a look at it 
(epan/dissectors/packet-radius.c). If you need a tracefile to work with, showing 
multiple requests/responses in the same conversation, I could create one for 
you... 
  
Hope this helps, 
Cheers, 
     Sake 
  ----- Original Message -----  
  
  
  Sent: Friday, June 26, 2009 7:19 AM 
  Subject: [Wireshark-dev] Using 
  find_conversation with multiple conversations conducted over the same UDP 
  address / port pairs 
  
 
  Hi Wireshark Dev List, 
  
  We have a network with DNP3.0 that is 
  using UDP.  We have a gateway device that communicates to a collections 
  of RTUs (RTU = Remote Terminal Unit, a device on the DNP3.0 network) over a 
  serial radio-modem network and we talk to the gateway using UDP / IP. 
  
  The DNP3.0 dissector uses the standard 
  calls to find_conversation etc... and fragment_add_seq_next etc... to do 
  application layer frame re-assembly as follows: 
        if (! (tr_fir && tr_fin)) 
         {          /* A fragmented packet */ 
           pinfo->fragmented = 
  TRUE; 
          /* Look 
  up the conversation to get the fragment reassembly id */ 
           conversation = 
  find_conversation(pinfo->fd->num, &pinfo->src, 
  &pinfo->dst,        
      pinfo->ptype, pinfo->srcport, pinfo->destport, 
  0); 
          if 
  (conversation == NULL) {        
      /* No conversation yet, so make one */            conversation = 
  conversation_new(pinfo->fd->num,  &pinfo->src, 
  &pinfo->dst, pinfo->ptype,    
            pinfo->srcport, pinfo->destport, 
  0);          } 
  
          conv_data_ptr = 
  (dnp3_conv_t*)conversation_get_proto_data(conversation, 
  proto_dnp3); 
          
  if (conv_data_ptr == NULL) {      
        /* New data structure required */ 
             conv_data_ptr = 
  se_alloc(sizeof(dnp3_conv_t)); 
    
          /*** Increment static global fragment reassembly 
  id ***/            
  conv_data_ptr->conv_seq_number = seq_number++; 
  
            
  conversation_add_proto_data(conversation, proto_dnp3, (void 
  *)conv_data_ptr);          
  }          conv_seq_number 
  = conv_data_ptr->conv_seq_number; 
          /*    
        * Add the frame to          * whatever reassembly is in progress, if 
  any, and see          * if 
  it's done.          
  */ 
          frag_msg = 
  fragment_add_seq_next(al_tvb, 0, pinfo, conv_seq_number, 
               
  al_fragment_table,        
        al_reassembled_table,              tvb_reported_length(al_tvb), 
  /* As this is a constructed tvb, all of it is ok */              !tr_fin); 
  
          next_tvb = 
  process_reassembled_data(al_tvb, 0, pinfo,              "Reassembled DNP 3.0 
  Application Layer message", frag_msg, &dnp3_frag_items, 
               
  &update_col_info, tr_tree); 
  Unfortunately this does not take into account the fact that over the 
  same IP address / port number pairs we may receive messages from many 
  different source RTUs that should be treated as separate conversations. 
   The problem we have at the moment is that we are getting fragment 
  re-assembly occurring for fragments from difference RTUs. 
  Is there a standard way to handle situations like this? 
   If so can someone point me to the correct dissector to look at? 
  
  We can provide packet captures that 
  demonstrate the issue if desired.   It is considered acceptable to attach 
  a .pcap file to a posting to this mailing list? 
  Thanks in advance, 
  Kelvin Proctor  
  
    
  ___________________________________________________________________________ Sent 
  via:    Wireshark-dev mailing list 
  <wireshark-dev@xxxxxxxxxxxxx> Archives:    
  http://www.wireshark.org/lists/wireshark-dev Unsubscribe: 
  https://wireshark.org/mailman/options/wireshark-dev              
  mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe 
 |