Reversed udp addresses

[Russell Fulton]

On Tue, 11 May 1999 08:01:35 -0400 Carter Bullard 
<cbullard at nortelnetworks.com> wrote:

> Hey Russell,
> First, is this 1.8 code?  That does make a difference.

Sorry, yes, it is the latest 1.8 code that you emailed me on or about 
the 28th April, although the 1.5 code behaves the same way. 

> 
> The data appears to be correct, based on your
> description.  All traffic is being sourced by
> aaa.bbb.37.70.  But because of the nature of the
> dst port numbers, we get some rather interesting output.
> 
> How a particular IP address gets into the left most
> position on the ra() output is somewhat convoluted.  The
> primary logic is that the lower port number should
> be on the right (most destination ports are in the
> < 1024 range, and so this is not a terrible idea).
> The idea being we would like most of the arrows pointing
> in the -> direction.

For UDP it is essentially an arbitrary choice I guess. The other 
approach would be to take the source and destination as they appear in 
the first packet in a stream.  Again it would probably lead to some 
situations where the output is not ideal.

> 
> This is the essence of Russell's problem.
> 
> We are flip flopping the addresses because there are
> two flows going on, udp ports 1755 <-> 5632 and 1755 <-> 22.
> We get a flip flop condition on the ra() output, because
> the source port is < in the first, and > in the other.
> 
> The arrow is trying to correct for the problem where
> the source and destination have been mismapped to
> the wrong columns.  So in these two records:
> 
> udp 130.216.168.1.5632 <-  aaa.bbb.37.70.1755  0   1   0   10  TIM
> udp aaa.bbb.37.70.1755  -> 130.216.168.1.22    1   0   10  0   TIM
> 
> aaa.bbb.37.70 is the source for both.
> 
> Now if this is all there is to it then there isn't
> really a problem, its just seems cosmetic.  The real
> issue is, do we get both of the these records if we
> do this:
> 
>    ra -ncr filename src host aaa.bbb.37.70
> 
> If we don't get them both from this select,
> and see the flip flopping, then we've got a problem.
> 

Oops! 

[argus at ruru argus]$ zcat data/1999.05.11/argus-1999.05.11.15.00.gz | 
bin/ra-1.8 -n src host aaa.bbb.37.70
Tue 05/11 15:31:55  udp   aaa.bbb.37.70.1755  <-> 130.216.168.25.22 ACC
Tue 05/11 15:31:55  udp   aaa.bbb.37.70.1755  <-> 130.216.168.27.22 ACC
Tue 05/11 15:31:55  udp   aaa.bbb.37.70.1755  <-> 130.216.168.28.22 ACC
Tue 05/11 15:31:55  udp   aaa.bbb.37.70.1755  <-> 130.216.168.29.22 ACC
Tue 05/11 15:31:55  udp   aaa.bbb.37.70.1755   ->  130.216.168.1.22 TIM
Tue 05/11 15:31:55  udp   aaa.bbb.37.70.1755   ->  130.216.168.2.22 TIM
Tue 05/11 15:31:55  udp   aaa.bbb.37.70.1755   ->  130.216.168.3.22 TIM
Tue 05/11 15:31:55  udp   aaa.bbb.37.70.1755   ->  130.216.168.4.22 TIM

Thanks for the explaination and spotting the real problem!

I guess 'udp and src net|host' has to be true if the net|host
transmitted any packets at all.   What does tcpdump do in this case?

Cheers, Russell.