Archer A7 NAT bug with TCP packets with FIN flag set

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

Archer A7 NAT bug with TCP packets with FIN flag set

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Archer A7 NAT bug with TCP packets with FIN flag set
Archer A7 NAT bug with TCP packets with FIN flag set
2020-05-29 23:45:43
Model: Archer A7  
Hardware Version: V5
Firmware Version: 1.0.14 Build 20200220 rel.33197(5553)

I had occasion to do some packet sniffing on the Ethernet between my A7 and my cable modem. While doing that, I noticed some packets whose IP addresses were LAN/WiFi addresses (i.e., in 192.168.0/24) instead of the expected post-NAT address (the address assigned by my ISP).

 

Here is a typical example, in tcpdump format. I've changed my actual IP address to 24.25.26.27, but otherwise this is straight out of tcpdump:

 

15:23:44.028678 IP 24.25.26.27.57334 > 52.216.110.131.80: Flags [S], seq 759188019, win 65535, options [mss 1460,sackOK,TS val 813650 ecr 0,nop,wscale 6], length 0
15:23:44.116721 IP 52.216.110.131.80 > 24.25.26.27.57334: Flags [S.], seq 997296986, ack 759188020, win 65535, options [mss 1432,wscale 8,nop,sackOK,nop,nop], length 0
15:23:44.119038 IP 24.25.26.27.57334 > 52.216.110.131.80: Flags [.], ack 1, win 1369, length 0
15:23:44.119329 IP 24.25.26.27.57334 > 52.216.110.131.80: Flags [P.], seq 1:196, ack 1, win 1369, length 195: HTTP: GET /kindle-wifi/wifistub.html HTTP/1.1
15:23:44.209809 IP 52.216.110.131.80 > 24.25.26.27.57334: Flags [.], ack 196, win 119, length 0
15:23:44.212226 IP 52.216.110.131.80 > 24.25.26.27.57334: Flags [P.], seq 1:357, ack 196, win 119, length 356: HTTP: HTTP/1.1 200 OK
15:23:44.212227 IP 52.216.110.131.80 > 24.25.26.27.57334: Flags [P.], seq 357:776, ack 196, win 119, length 419: HTTP
15:23:44.214466 IP 24.25.26.27.57334 > 52.216.110.131.80: Flags [.], ack 357, win 1386, length 0
15:23:44.214667 IP 24.25.26.27.57334 > 52.216.110.131.80: Flags [.], ack 776, win 1403, length 0
15:23:44.234756 IP 52.216.110.131.80 > 24.25.26.27.57334: Flags [P.], seq 357:776, ack 196, win 119, length 419: HTTP
15:23:44.237105 IP 24.25.26.27.57334 > 52.216.110.131.80: Flags [.], ack 776, win 1403, options [nop,nop,sack 1 {357:776}], length 0
15:24:07.222860 IP 52.216.110.131.80 > 24.25.26.27.57334: Flags [F.], seq 776, ack 196, win 119, length 0
15:24:07.258495 IP 24.25.26.27.57334 > 52.216.110.131.80: Flags [.], ack 777, win 1403, length 0
15:28:44.217643 IP 192.168.0.15.57334 > 52.216.110.131.80: Flags [F.], seq 759188215, ack 997297763, win 1403, length 0
15:28:44.508362 IP 192.168.0.15.57334 > 52.216.110.131.80: Flags [F.], seq 0, ack 1, win 1403, length 0
15:28:44.808349 IP 192.168.0.15.57334 > 52.216.110.131.80: Flags [F.], seq 0, ack 1, win 1403, length 0
15:28:45.408261 IP 192.168.0.15.57334 > 52.216.110.131.80: Flags [F.], seq 0, ack 1, win 1403, length 0
15:28:46.608471 IP 192.168.0.15.57334 > 52.216.110.131.80: Flags [F.], seq 0, ack 1, win 1403, length 0
15:28:49.008396 IP 192.168.0.15.57334 > 52.216.110.131.80: Flags [F.], seq 0, ack 1, win 1403, length 0
15:28:53.818477 IP 192.168.0.15.57334 > 52.216.110.131.80: Flags [F.], seq 0, ack 1, win 1403, length 0
15:29:03.438341 IP 192.168.0.15.57334 > 52.216.110.131.80: Flags [F.], seq 0, ack 1, win 1403, length 0

 

We see the normal handshake starting a TCP connection, between my Amazon Fire TV Stick 4K, which has IP 192.168.0.15 on my WiFi, but is correctly NATed to 24.25.26.27 on the WAN side of things, and some Amazon server at 52.216.110.131. The connection is successfully established and all goes well until after the FIN from the Amazon server is received.

 

Instead of the expected FIN from our side with the 24.25.26.27 IP address, we get a FIN but with the raw WiFi side address, 192.168.0.15. I'm going to call this a NAT leak.

 

That gets repeated periodically. If I hadn't stopped the tcpdump, it would have gone on much longer.

 

Most connections work fine, final FIN and all. It is only sporadic, and the occurrances seem to be indepdent. The Fire TV Stick likes to make hit several Amazon servers in succession, for example, which usually all work. When the NAT leak does strike, it seems to only hit one of them.

 

I've also seen this NAT leak with RST packets. I've never seen it on a packet that did not have either FIN or RST set.

 

So far, I've only seen it with packets from three devices on my network. The Amazon Fire TV Stick 4K, an iPhone X, and an iMac, all using 5 GHz WiFi. I've only seen it happen once with the iPhone. With the iMac it is a couple times or so an hour. With the Fire TV Stick 4K it happens every minute or so with mine. This was with the Fire TV Stick not playing anything, just doing whatever its normal background activities are. The iMac, on the other hand, was being heavily used. This suggests what ever triggers it has something to do with the nature of the traffic it is dealing with, because if it was not then it should be hitting the iMac more than the Fire TV.

 

I don't know if it is related or not, but the reason I was packet sniffing on the WAN side was to try to figure out another mystery of the A7. In the traffic stats, an entry shows up for 192.168.0.1, showing around 3 or 4 packets per hour, each 87 bytes according to the A7. The MAC address shown is the MAC address of the gateway at Comcast's end of my connection. I was trying to find out what that packet is. I could not find any packets with IP 192.168.0.1 on the WAN side, and since every packet on the WAN side includes the gateway MAC address in either its source MAC or destination MAC, filtering on that wasn't helpful either.  So I was just tcpdumping everything and hoping something would stand out.

  0      
  0      
#1
Options
1 Reply
Re:Archer A7 NAT bug with TCP packets with FIN flag set
2020-05-31 00:01:03

@tzs108 

 

I was able to watch some of these with tcpdump running on both the WAN side and LAN side.  The reason that the bad packets are repeating on the WAN side is that because they have the wrong IP address they never make it to their destination, and so the client on the LAN side keeps retrying.

 

Once the NAT failure happens on a given TCP connection, it seems permanent, so the retries also do not make it through. Eventually the client on the LAN side gives up and sends a RST.

 

I believe in all cases I've seen, it only happens when the service side has already sent a FIN. The client on the LAN sends its ACK for that, and then later sends a FIN. That A7 applies NAT to the ooutgoing ACK just fine. It is only when the client goes to shutdown its side that the NAT starts failing.

 

The reason the sequence numbers look wonky for the packets with the wrong IP addresses is that tcpdump shows absolute sequence numbers on the first packet of a connection and relative sequence numbers afterwards. To it, the first packet with the bad IP address looks like a different connection, so the first one gets absolute sequence numbers. Then the subsequent ones get relative sequence numbers relative to that.

 

This bug itself probably does not have much impact. From the client side, it looks like the server dropped the connection but it only happens when the client is trying to shut down the connection anyway, so all that happens is it is going to retry the shutdown for a while and then try an RST. Aside from slightly increased resource usage because of the connecting lingering in the connection table longer than it needs to, no big deal.

 

  0  
  0  
#2
Options

Information

Helpful: 0

Views: 386

Replies: 1

Related Articles