Reversed udp addresses
r.fulton at auckland.ac.nz
Tue May 11 17:33:54 EDT 1999
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 18.104.22.168.5632 <- aaa.bbb.37.70.1755 0 1 0 10 TIM
> udp aaa.bbb.37.70.1755 -> 22.214.171.124.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.
[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 <-> 126.96.36.199.22 ACC
Tue 05/11 15:31:55 udp aaa.bbb.37.70.1755 <-> 188.8.131.52.22 ACC
Tue 05/11 15:31:55 udp aaa.bbb.37.70.1755 <-> 184.108.40.206.22 ACC
Tue 05/11 15:31:55 udp aaa.bbb.37.70.1755 <-> 220.127.116.11.22 ACC
Tue 05/11 15:31:55 udp aaa.bbb.37.70.1755 -> 18.104.22.168.22 TIM
Tue 05/11 15:31:55 udp aaa.bbb.37.70.1755 -> 22.214.171.124.22 TIM
Tue 05/11 15:31:55 udp aaa.bbb.37.70.1755 -> 126.96.36.199.22 TIM
Tue 05/11 15:31:55 udp aaa.bbb.37.70.1755 -> 188.8.131.52.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?
More information about the argus