Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am facing an issue that some packets sent out to internet from inside network were missing. The pattern we are using is like:

  Client A ←→ Switch A ← Router A:NAT ← .. Network .. 
     → Router B:NAT → Switch B ←→ Server B

I want to do below two steps to track the issue:

  1. Capture the packets which are from Client A on Router B.
  2. Check the translation table of Router B.

Are both actions possible?

More information:

  1. Client A is running on Windows XP
  2. Server B is running on Linux (Fedora exactly).
  3. The Router B use static port and address translation table which means incoming packets
    to specific port will be forwarded to Server B.
  4. Both Router A and Router B are TPLink WR340+ products.
  5. Both Router A and Router B have Full-cone NAT.
  6. Switch A is DLink DES-1024R and Switch B is DLink DES-1016D.

The reason why I want to perform the two actions is that we found packets were sent out of the network interface of ClientA, but due to unknown reason the TCP kernel of ClientA machine never receives any ACK packet from the other endpoint, thus it enters data transmission until timeout. And from the server side, also using Tool WireShark we found the network interface of Server B machine never receives the packet sent from client A. I guess the packets were dropped by Router B, so I wonder if it is possible to capture packets at Router B.

Actually the issue only happened when we have two clients, say they are Client A and Client C. The Client A and Client C don't communicate with each other directly, but communicate with Server B instead.

Problem happened when we unplug the network cable of Client A machine and on another machine log in Client A in about 30 seconds, client A on the new machine will start TCP communication with server B, the first many commands are OK, but after that server can't receive any command from Client A anymore.

share|improve this question

migrated from superuser.com Feb 26 '13 at 11:26

This question came from our site for computer enthusiasts and power users.

3 Answers 3

up vote 2 down vote accepted

Server B never received the packet

If you run Wireshark from Server B is ok; if not please consider you would need a managed switch configuring a "mirror/span/monitor" port where you connect to Wireshark's PC.

I would stick with Wireshark moving it to see packets between the Router B and the Switch B (can you add a hub in between to insert wireshark's PC?)

if the packet does not make it to the segment RouterB-SwitchB then your port forwarding at Router B (in order to bypass its NAT services) could be not working right or the router is just not routing your traffic.

share|improve this answer
    
Thanks Pat. But won't any other part of the internet drop the packets? Do you mean the packets will reach Router B, only may router B drop them? I have added much more information, hope it helps. –  Steve Peng Feb 26 '13 at 7:32
    
If your protocol is TCP based Internet will recover from a dropped packet. If you are based on UDP, of course not. The new info about the two clients is a bit confusing; Routers do not know about Client A-B they just know about IP traffic. What you describe of a Client A unplugged and re-logged on a different IP and failing sounds more of a higher level problem rather than an IP packet not reaching destiny. You should first try to see if it is your application failing, or the net. –  Pat Feb 26 '13 at 9:27
    
Yes, the protocol is TCP based and it was for file transfer. Actually I also think this is more likely to be a higher level problem. But we are not able to figure out how application cause the TCP kernel's ACK packets (from Server B to Client A) missing (seems to not reach TCP kernel of Client A machine). –  Steve Peng Feb 26 '13 at 10:51
    
I will try capturing packets from the Switch since we are not able to capture packets from tplink routers directly. Thanks. –  Steve Peng Feb 28 '13 at 5:32

I think it is important to get more information, switches don't do NAT (but routers do), and different routers have widely varying abilities. I've never heard the term "checking the translation table" when referring to switches or routers, but I do understand what you mean with respect of routers.

You will most likely find knowledge of NAT and checking translation tables etc a lot less valuable then using simple network tools. The first tool I would use is "WinMTR" from the Client A. Leave that running for a little (minutes ?) while and see if and where packet loss occurs. This will give you a very good idea where to look further. [ Looking at latencies and spikes in latencies will also give you some hints if you know what to look at ].

For someone to provide more help, you might want to provide more detail as to why you believe packets are going missing, and the characteristics of the problem.

share|improve this answer
    
Thanks David. The reason why I want to perform the two actions is that we found packets were sent out of the network interface of ClientA, but due to unknown reason the TCP kernel of ClientA machine never receives any ACK packet from the other endpoint, thus it enters data transmission until timeout. And from the server side, also using Tool WireShark we found the network interface of Server B machine never receives the packet sent from client A, of course it was not able to send any ACK packet back to ClientA. –  Steve Peng Feb 24 '13 at 8:13
    
I am not sure what you mean of using WinMTR from the Client A. I want to check either thing of following: 1) Packets have reached switch B but were dropped by some reason? 2) If the address translation table on Switch B contains right information which shall let the switch to forward incoming packets to right internal host-- here Server B? Is it possible to do either one by using WinMTR from just client A or Server B? –  Steve Peng Feb 24 '13 at 8:17
    
David, I added more information about the topology we are using. –  Steve Peng Feb 25 '13 at 8:19

Here is an outline of a few ideas, and perhaps others know of how to do it in detail.

Use a linux machine router.

Perhaps Tomato or DDWRT can. So if your router supports that firmware / if you bought one that supports it, you could try that.

You commented "The reason why I want to perform the two actions is that we found packets were sent out of the network interface of ClientA, but due to unknown reason the TCP kernel of ClientA machine never receives any ACK packet from the other endpoint, thus it enters data transmission until timeout. And from the server side, also using Tool WireShark we found the network interface of Server B machine never receives the packet sent from client A, of course it was not able to send any ACK packet back to ClientA."

Maybe a router is damaged, or you have a faulty cable.

I love the fun ideas of how to see what is happening at your router, it may be possible with a fancier router, or better firmware. But if you can/want to do that, then you'd probably have or need a better router, or a replacement one to try. Don't overlook basic troubleshooting techniques, monkey type logic, like swapping parts!

Is it just one way that has an issue? like A->B. Or B->A too? You could troubleshoot a bit there like swapping the cables around. swapping the ports they're connected to.

share|improve this answer
    
Thanks barlop, both ways have the issue which means packets from Sever B also can't reach some specific port of Client A. I have added much more information, hope it helps. –  Steve Peng Feb 26 '13 at 7:35
    
ehh, currently i am not able to get a better router, first of all we are still not sure if it is the router's problem causing this issue. Then I know some router like Cisco product can do that but they are too expensive, like tens of thousand of dollars!! –  Steve Peng Feb 26 '13 at 7:37
    
@StevePeng I did not suggest to get a better router appliance! I suggested to change the router(s) to any router, this is not to capture packets, but to see if after changing the routers, you still have the issue. This is a diagnostic step to see if it is a router issue, and would be done as one is unsure if it is a router issue.That's fundamental troubleshooting. And getting "any" router is not expensive. –  barlop Feb 26 '13 at 10:52
    
@StevePeng The other thing I mentioned that one could call changing router, was a linux machine router. Linux could run on an old computer somebody might give away (or a little appliance designed as a linux router, so w/ router pci card and the free software, not hundreds of dollars), but just even an old computer and just needs a router PCI card (and the technical know-how) and could capture too. It must also be possible to set up a windows machine as a router(and then you can of course capture too). –  barlop Feb 26 '13 at 10:53

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.