Ethereal-dev: RE: [ethereal-dev] found the rpc problem - not sure if ethereal w ill ever be ab

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Neulinger, Nathan R." <nneul@xxxxxxx>
Date: Fri, 12 Nov 1999 15:42:03 -0600
Yeah, at one point it was on a linux box but we had so much trouble with the
linux ypserv crashing, that we moved it back to an HP... one of the only
services we've ever had bad luck with linux. 

BTW, in case it's of any use at any point, we have a Sniffer Pro box here,
and actually have an old Sniffer as well. 

I sortof wondered about something - is it reasonable to look at the decoded
output from another analyzer (such as sniffer pro) and use that to build (or
help debug) a dissector for ethereal, or is the output of an analyzer
generally considered proprietary?

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@xxxxxxx
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxx]
> Sent: Friday, November 12, 1999 3:32 PM
> To: Neulinger, Nathan R.
> Cc: 'ethereal-dev@xxxxxxxx'
> Subject: Re: [ethereal-dev] found the rpc problem - not sure 
> if ethereal
> will ever be able to handle this or not...
> 
> 
> > Turns out that the problem was that my ypserver is 
> multihomed and the
> > requests are coming back on a different interface. (Actually virtual
> > interface, not a separate card.) The capture is attached.
> > 
> > Requests are going in a virtual interface, and are coming 
> out the primary on
> > the same card. 
> > 
> > That appears to be why it was failing to detect the situation. 
> 
> "snoop" appears to handle this - it even recognized frame 6 as a reply
> to frame 5, even though the hosts were different.
> 
> I wonder whether it looks *only* at port numbers (and 
> transaction IDs),
> or if it looks for a match on the port numbers and at least one of the
> IP addresses, e.g. trusting the sender address of the request and the
> recipient address of the reply.
> 
> BTW, the DNS entries for "stellar" and "nissrv3" seem to 
> disagree about
> the nature of the machine:
> 
> 	tooting$ nslookup
> 	> set type=any
> 	> server jupiter.cc.umr.edu.
> 	> stellar.cc.umr.edu.
>  
> 		...
> 
> 	stellar.cc.umr.edu      CPU = hp9000-735        OS = hpux
> 
> 		...
> 
> 	> nissrv3.cc.umr.edu.
> 
> 		...
> 
> 	nissrv3.cc.umr.edu      CPU = ibm-pc    OS = linux
> 
> 		...
>