hi Team, I am facing a problem whith Jboss,we are able to ping source(A) to destination(B) and from B to A also ,but we are able to do telnet from source(A) to destination(B) , but from from B to A we are not able to do telnet . pleas find the packet capture file "A". please let me know any information you required from my end. asked 01 Mar '16, 10:10  zubair edited 01 Mar '16, 18:35  Bill Meier ♦♦ showing 5 of 12 show 7 more comments |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Please publish the capture file somewhere (cloudshark, google drive) and edit your question with a link to it.
https://my.pcloud.com/publink/show?code=XZCV64ZS6EM9wY53hu2SIUrXGjPkVKwhvk0
please find the link if any information required pleas let me know
If you are concerned about privacy, use tracewrangler to obfuscate the MAC and IP addresses and remove the payload. Text file is a nightmare to analyse and one cannot use the help of Wireshark.
https://my.pcloud.com/publink/show?code=XZR564Z8l4zqID17MSGXDIJza9M70dfKYH7
After down loading the please let me know
ip.addr eq 192.168.X.X and ip.addr eq 170.Y.Y.Y
Done, but that's not how this site works, to publish a file and then remove it. Please do have a look at tracewrangler while I have a look at the capture.
Thanks for your support .
What is A and what is B? Give me some attributes by which I can find the stream you are interested in, there are 800 tcp streams...
i have to check the communication ip.addr eq 192.168.10.37 and ip.addr eq 170.193.75.X.
Any information you required from my end .
Thanks for your quick response
Two points:
what TCP stack is running at the client (private IP)? The server sends a FIN flag already in the packet providing the response. Doing so is legal although not typical, the TCP RFCs explicitly say that it should be interpreted as if the FIN came after the payload of the packet. The client ACKs that packet but does not set its own FIN flag in the packet ACKing the server's FIN, so obviously the session remains alive at its side (possibly because it has ignored the FIN it has not expected, but it is just my guess). The fact that the client deems the session active at this point is confirmed seven minutes later, when something times out at the client and so it sends its own FIN still within the context of the old session. But the server ignores that FIN packet from the client, because at its own side that session has been long gone at that time. So the client retransmits it for a couple of times and finally sends a RST.
it is not a typical behaviour (because it is quite resource-intensive in its consequence, see something about TIME WAIT state) that a server closes a tcp session immediately after sending the response, does the server application have any good reason to do that?
In any case both ends' behaviour could be improved.
Thanks for your support.
in details :-
server(192.168..X.X) wants to communicate 170.X.X.X with port(12793),
return traffic should be 170.X.X.X to 192.168.X.X .
Connection details Server(192.168.X.X) ----Firewall---Site--to--site--VPN----Client(170.X.X.X)
If so and you suspect some of the intermediate elements to affect the communication, you'd have to capture at both the client and the server simultaneously and compare the capture from both sides, looking for packets which do not look the same in the client-side and server-side captures. If you spot a difference but would need someone else to have a look at it too, be sure to filter just the session in question using a display filter (such as
ip.addr == 192.168.10.37 and ip.addr == 170.193.75.0/24) and then useFile->Export Specified Packetsto save only that session into a new file. Of course do this for both ends' captures and publish both as well.From me it is all for today, I'm too sleepy to think more.