Hi,
I was talking to X at an Australian Telco recently. X was having
problems with an application that fell under X's responsibility.
The application was split between two UNIX systems (did not find out the
varieties, probably SunOS).
One system initaites a TCP connection to the other and ships lots of
data across that is then formatted for access from the web.
They are having a problem in that only a small portion of the data gets
through, and the TCP connection seems to freeze. When they modofied the
app to send some info back the other way on a regular basis, they
started to find that all the data was getting through.
X said that even though both machines were in the same organization,
there was a large number of firewalls between the two machines (greater
than or equal to 5), and X was looking for ways to figure out what was
going wrong.
My first suspicion was that window updates were not getting back to the
sending system, so it stoped senning after the window filled up, and the
window can be large these days if both systems implement the window
scale option.
I suggested that X get a trace on both ends when the application startes
to send data, and then compare the two traces looking for lost packets
on one side or other other.
Then, on the way back home on the plane, it struct me that this could be
a difficult exercise, but that Ethereal could be modified to help.
It would be interesting if one could read two traces into Ethereal,
filter them both so that only packets between the same two nodes show
up, and then display them side by side, matched, with spaces in one
display where there are no corresponding packets with the other display.
I envision the following:
+------------------------+-----------------------+
| Packet 1 from first | blank as no match |
| Packet 2 from first | Packet 1 from second |
| blank since no match | Packet 2 from second |
| Packet 3 from first | Packet 3 from first |
...
Now, I realize that this will require some [considerable] changes.
Firstly, ethereal will have to be taught how to deal with two separate
traces at once, and I think it currenly cannot do that.
Secondly, there are the issues of how you would indicate a match. My
thinking is, and this ignores non-IP protocols, match on SrcIP, DstIP,
and Ident fields ... And perhaps allow the user to specify other fields
to match on ...
It sounds like this could be very useful in comparing traces, and in our
complex modern networks, I imagine a number of people want to do this. I
know I have in the past.
Regards
-------
Richard Sharpe, rsharpe@xxxxxxxxxx, LPIC1
www.samba.org, www.ethereal.com, SAMS Teach Yourself Samba
in 24 Hours, Special Edition, Using Samba