Possible NAT problems with borderline signal strength?

Post new topic   Reply to topic    DD-WRT Forum Index -> Generic Questions
Author Message
web1
DD-WRT Novice


Joined: 14 May 2011
Posts: 39

PostPosted: Sat Apr 07, 2012 7:48    Post subject: Possible NAT problems with borderline signal strength? Reply with quote
It looks like the problem comes from them using the checksum to check the TCP packets.

Checksum is susceptible to single bit error corruption of data, that's why they came up with CRC.

It looks like the NAT routing code only uses the checksum to check if the packet is valid.

If a single bit gets corrupted or two bits, and if it happens to be the "close" bit, then NAT thinks that the TCP session is done and no longer forwards the packets to the user down the line.

Anything sent to that port number from the internet side is then dropped, and TCP at the user end (think browser) just sits waiting for anything to come in for it's port number.

It's like firewalling TCP in the middle of a connection.

This is why when you have a borderline wireless connection, you can sometimes stop a web page that's half loaded but sitting there, then hit return (or reload) and the page will suddenly come in full - because the connection got better for that second and everything made it and no important bits were trashed.

TCP won't open a new port to try again, it keeps trying over and over using the same port, just sending more packets and NAT doesn't care to pass them anymore.

So is this a good theory?

I think this is coming up as a problem now because before this all networks were wired and single bit errors were hard to get. With a wire you either get bits or you don't.

What would be the fix?

Is there something the developers / project support people of NAT could do?

Is there a part of the code that could be set so that it never ends NAT forwarding no matter what bits may be wrong?

If TCP retries, just pass that along to the same port as before, even if you think the TCP connection is closed, wouldn't that work?

If it's a NAT "routing" table length problem, drop the last entries as you run out of memory space, that way the table is always valid for all connections even if they are old.

Or maybe if the user end resends a TCP packet, then consider that connection open again and continue on?
Sponsor
Sash
DD-WRT Guru


Joined: 20 Sep 2006
Posts: 17619
Location: Hesse/Germany

PostPosted: Sat Apr 07, 2012 9:34    Post subject: Reply with quote
are u running the latest beta?
_________________
Forum Guidelines...How to get help
&
Forum Rules
&
RTFM/STFW
&
Throw some buzzwords into the WIKI search Exclamation
_________________
I'm NOT rude, just offer pure facts!
_________________
Atheros (TP-Link & Clones, etc ) debrick service in EU
_________________
Guide on HowTo be Safe, Secure and Protect Your Online Anonymity!
web1
DD-WRT Novice


Joined: 14 May 2011
Posts: 39

PostPosted: Sat Apr 07, 2012 15:55    Post subject: Reply with quote
Sash wrote:
are u running the latest beta?
I looked at the changelog and couldn't find any mentions about changes to the NAT code.

Did you find an entry for any NAT changes?
web1
DD-WRT Novice


Joined: 14 May 2011
Posts: 39

PostPosted: Sun Apr 22, 2012 18:38    Post subject: Reply with quote
You would see changes to iptables or references to NAT problems. Or possibly changes to the radio code if they screwed up CRC checking somehow.

But I think most of that hasn't changed.

And since my last post I did try the latest and greatest bleeding edge development version and.... same thing!
Display posts from previous:    Page 1 of 1
Post new topic   Reply to topic    DD-WRT Forum Index -> Generic Questions All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum