Does this tcpdump result has any error?

[shmilyh]

[Expert@FW_02]# tcpdump -i eth2 | grep 192.168.32.133

tcpdump: listening on eth2

11:34:15.634355 192.168.32.133.8801 > 220.199.6.27.34839: S 473200359:473200359(0) ack 3483590450 win 5840 <mss 1460> (DF)

11:34:15.686266 220.199.6.27.34839 > 192.168.32.133.8801: . ack 1 win 65535

11:34:16.967105 220.199.6.27.34839 > 192.168.32.133.8801: P 1:62(61) ack 1 win 65535



11:34:27.835336 192.168.32.133.8801 > 220.199.6.27.34839: S 473200359:473200359(0) ack 3483590450 win 5840 <mss 1460> (DF)

11:34:27.892991 220.199.6.27.34839 > 192.168.32.133.8801: . ack 1 win 65535

11:34:29.025712 220.199.6.27.34839 > 192.168.32.133.8801: P 1:62(61) ack 1 win 65535

11:34:51.836525 192.168.32.133.8801 > 220.199.6.27.34839: S 473200359:473200359(0) ack 3483590450 win 5840 <mss 1460> (DF)

11:34:51.890920 220.199.6.27.34839 > 192.168.32.133.8801: . ack 1 win 65535

11:34:53.188050 220.199.6.27.34839 > 192.168.32.133.8801: P 1:62(61) ack 1 win 65535

11:34:57.993611 220.199.6.27.34839 > 192.168.32.133.8801: R 62:62(0) ack 1 win 65535
Sorry,I am not familiar with this tool,would you pls help me to analyse
it?It would be great if you could tell me how to analyse it.Thanks.

[northlandboy]

Rather than running tcpdump | grep <IP>, it's much more efficient to use the tcpdump filters - e.g. tcpdump -i eth2 host 192.168.32.133

But that session looks OK to me. Read up on how TCP works. Notice that you've got communications going in both directions there, with SYN, ACK, PUSH and RST packets - that shows that there is a valid path right through.

Typical firewall problem might show up as only SYNs coming from one side, with no reply. Or occasionally if there's a reply routing problem, you might have a SYN from one side, a SYN/ACK in return, but then no follow up ACK.

[gavvys]

yeah TCPDUMP is a good tool to monitor the traffic, keep in mind the flags you will get e better view of the traffic.Also you can see the traffic in fw monitor on the Firewall itself to check how packets are coming and going out on the interfaces but use fw monitor in critical issue, it creates load on cpu.
There are several books on the internet that will help you regarding the tcpdum tool.

regards

[shmilyh]

Thanks for your reply,I will read some books about it,thanks

[Adam Carter]

RST packets mean that the session has been killed off suddenly rather than closed down cleanly (in which case you would see FINs instead). Investigate the side that's sending the RSTs first. IIRC hitting stop in a web browser causes and RST - is the service on 8801 a web server or proxy?

[swezwho]

Something else to keep in mind with tcpdump... Like fw monitor, it can bog things down sometimes, say on a particularly busy system for instance. Just keep an eye on the cpu load while you're using it.