# Software > OpenWrt >  Asymmetric Routing & OpenWRT

## acoul

Τον τελευταίο καιρό υπάρχει μια κατακόρυφη έξαρση στο asymetric routing το οποίο γενικά θεωρείται "κακό" πράγμα από τους ειδήμονες του χώρου. 

Το πρόβλημα έγινε αισθητό σε συσκευές που τρέχουν openwrt. Συγκεκριμένα το τελευταίο καιρό εμφανίζουν το ακόλουθο στο syslog τους:


```
ip_conntrack: table full, dropping packet
```

Μια και το ip_conntrack είναι από default enabled στο kernel του openwrt ένας τρόπος για να αντιμετωπιστεί το πρόβλημα είναι ο ακόλουθος:


```
echo "21600" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
```

το οποίο μπορεί να μπει στο:


```
/etc/init.d/S41awmn
```




> OpenWRT: The Wireless Freedom

----------


## NetTraptor

Ή αλλάζουμε αυτό σε κάτι τεράστιο 

/proc/sys/net/ipv4/ip_conntrack_max

Για να τα crasharoume….  ::   ::   ::

----------


## mojiro

δε ξερω αν εχει σχεση, αλλα και το routerακι(openwrt?, asus?, δε θυμαμαι)
του stafan δε μπορει να routαρει olsr traffic...

ουτε ping...

----------


## stafan

> δε ξερω αν εχει σχεση, αλλα και το routerακι(openwrt?, asus?, δε θυμαμαι)
> του stafan δε μπορει να routαρει olsr traffic...
> 
> ουτε ping...


Τελικά δεν είναι αυτό. Έστησα ένα δεύτερο wrt και δούλευε κανονικά το olsr routing, οπότε επέμεινα με acinonyx και κάτι βρήκε απο κεί  ::  με ξεχασμένη λάθος ip...

----------


## ngia

> Τον τελευταίο καιρό υπάρχει μια κατακόρυφη έξαρση στο asymetric routing το οποίο γενικά θεωρείται "κακό" πράγμα από τους ειδήμονες του χώρου. 
> ..
> ip_conntrack: table full, dropping packet
> ..
> echo "21600" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established


δεν έχει σχέση με το ασύμμετρο routing.

http://www.plug.org/pipermail/plug/2005 ... 13012.html
γεμίζει ο πίνακας με εγγραφές -μάλλον από τα p2p που παράγουν τις περισσότερες και τις απορρίπτει.
Αυτό είναι πρόβλημα γιατί κλειδώνει και δεν αφήνει άλλες συνδέσεις.



```
The Linux kernel, in file net/ipv4/netfilter/ip_conntrack_core.c sets the default number of connection tracking buckets to 1/16384 of the total memory on the system.  Unfortunately, on a system with only 16MB RAM (as is the case with the GT-701WG), this means that there are only 1024 buckets available; ie, only 1024 connections can be tracked simultaneously.

Now ordinarily, this isn't a problem.  But P2P programs are notorious for two things: sloppy TCP connections (especially with regards to closing properly the connection) and lots and lots of TCP connections to lots and lots of hosts.
ip_conntrack by default will continue to track a connection for *five days*= ifit is established and not closed.  So if the remote host goes down without closing the connection, the Linux kernel will continue to track that connection for five days before dropping it from the table.

So hopefully you can see where the problem is.  After running a P2P app for about 24 hours, and subjecting it to all kinds of unclosed TCP connections, the tiny ip_conntrack table fills up all of its 1024 slots, most of which are TCP connections that are supposedly established to hosts that aren't even up anymore.  Thus, the kernel (and therefore the router) will no longer create any TCP connections to anywhere -- including to itself.  Thus, the modem locks up, locks out the user, and the only way to reset it is to power-cycle the router.

So here's the fix.  Fortunately, it doesn't require any any kernel hacking,
just a few lines added to the startup script of the modem.  Both the number of entries in the ip_conntrack table and the time to wait before dropping an established TCP connection can be adjusted through the /proc filesystem in the files /proc/sys/net/ipv4/netfilter/ip_conntrack_max and
/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established .  I have set these values to 8192 and 3600 respectively, and doing so entirely eliminated the lockup problems when using P2P apps (and I did some *heavy* testing with about 8 copies of BitTorrent and one copy of gtk-gnutella open simultaneously for about a week straight).  So I would highly suggest adding the two following lines to the startup script of the modem (/etc/init.d/rcS):

echo 8192 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 3600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

It would probably be a good idea to add
echo 600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait

too, to drop connections closed as CLOSE_WAIT after 10 minutes.
```

----------


## cirrus

Βέβαια παίζει και το

```
rmmod ip_conntrack
```

αν είναι compiled σαν module.

----------


## acoul

> δεν έχει σχέση με το ασύμμετρο routing.


Αναφερόμουν στο broken asymmetric routing όπου το three way tcp handshaking δεν ολοκληρώνεται με επιτυχία με αποτέλεσμα να δημιουργούνται half-open connections που δεν κλείνουν ποτέ, ειδικά από εφαρμογές που επιμένουν να κάνουν ανεξέλεγκτα retries.



> It would probably be a good idea to add
> echo 600 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait


Το default στο openwrt είναι 60 και καλό είναι να μην αλλαχτεί.

----------

