On Sun, 2010-02-14 at 11:52 +0100, Bojan Sukalo wrote: > First thing thank you both on your usefull remarks. > > > Guido wrote: > > > The kernel is not that old. Most probably you won't necessarily need to > > upgrade the kernel as it is 2.6.x. You can try building and installing > > the latest iptables (version 1.4.6) and only after that a new kernel > > (latest version is 2.6.32.8). > > > But before doing that, I would suggest you first try another ISP using a > > dial-up connection to understand whether the TCP MSS diagnosis is > > correct or not. > > But also Mart said: > > > Changing the iptables version will not change anything, if the current > > version does not have problems setting the kernel part correctly. > > You would need to upgrade kernel. > > I suspect that Mark is right because iptables is just userspace app to > set netfilter kernel module but if that is not the case I could try > and install new version of iptables. > > Mark: > > The rule-set looks okay for me. > > Does it only happen with google.com, or with all web hosts? > > It's happenin for all types of tcp traffic from inside to internet. > Session established but nothing after that. No data traffic. > > > Look how you have set the /proc/sys/net/ipv4/tcp_* options. > > [root@natbox net]# grep -r '' ./ipv4 | grep tcp > ./ipv4/netfilter/ip_conntrack_tcp_max_retrans:3 > ./ipv4/netfilter/ip_conntrack_tcp_be_liberal:0 > ./ipv4/netfilter/ip_conntrack_tcp_loose:3 > ./ipv4/netfilter/ip_conntrack_tcp_timeout_max_retrans:300 > ./ipv4/netfilter/ip_conntrack_tcp_timeout_close:10 > ./ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait:120 > ./ipv4/netfilter/ip_conntrack_tcp_timeout_last_ack:30 > ./ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait:60 > ./ipv4/netfilter/ip_conntrack_tcp_timeout_fin_wait:120 > ./ipv4/netfilter/ip_conntrack_tcp_timeout_established:432000 > ./ipv4/netfilter/ip_conntrack_tcp_timeout_syn_recv:60 > ./ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent:120 > ./ipv4/tcp_slow_start_after_idle:1 > ./ipv4/tcp_workaround_signed_windows:1 > ./ipv4/tcp_bic_beta:819 > ./ipv4/tcp_tso_win_divisor:8 > ./ipv4/tcp_moderate_rcvbuf:1 > ./ipv4/tcp_bic_low_window:14 > ./ipv4/tcp_bic_fast_convergence:1 > ./ipv4/tcp_bic:1 > ./ipv4/tcp_vegas_gamma:2 > ./ipv4/tcp_vegas_beta:6 > ./ipv4/tcp_vegas_alpha:2 > ./ipv4/tcp_vegas_cong_avoid:0 > ./ipv4/tcp_westwood:0 > ./ipv4/tcp_no_metrics_save:0 > ./ipv4/tcp_low_latency:0 > ./ipv4/tcp_frto:0 > ./ipv4/tcp_tw_reuse:0 > ./ipv4/tcp_adv_win_scale:2 > ./ipv4/tcp_app_win:31 > ./ipv4/tcp_rmem:4096 87380 174760 > ./ipv4/tcp_wmem:4096 16384 131072 > ./ipv4/tcp_mem:786432 1048576 1572864 > ./ipv4/tcp_dsack:1 > ./ipv4/tcp_ecn:0 > ./ipv4/tcp_reordering:3 > ./ipv4/tcp_fack:1 > ./ipv4/tcp_orphan_retries:0 > ./ipv4/tcp_max_syn_backlog:1024 > ./ipv4/tcp_rfc1337:0 > ./ipv4/tcp_stdurg:0 > ./ipv4/tcp_abort_on_overflow:0 > ./ipv4/tcp_tw_recycle:0 > ./ipv4/tcp_syncookies:0 > ./ipv4/tcp_fin_timeout:60 > ./ipv4/tcp_retries2:15 > ./ipv4/tcp_retries1:3 > ./ipv4/tcp_keepalive_intvl:75 > ./ipv4/tcp_keepalive_probes:9 > ./ipv4/tcp_keepalive_time:7200 > ./ipv4/tcp_max_tw_buckets:180000 > ./ipv4/tcp_max_orphans:262144 > ./ipv4/tcp_synack_retries:5 > ./ipv4/tcp_syn_retries:5 > ./ipv4/tcp_retrans_collapse:1 > ./ipv4/tcp_sack:1 > ./ipv4/tcp_window_scaling:1 > ./ipv4/tcp_timestamps:1 > > Please if you can find any strange things in this setup let me know > > Bojan > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html Some parameters are non-default at least according to more recent kernels, for example: ./ipv4/tcp_workaround_signed_windows:0 ./ipv4/tcp_tso_win_divisor:3 ./ipv4/tcp_frto:2 ./ipv4/tcp_ecn:2 ./ipv4/tcp_max_orphans:16384 But you could have already rebuilt kernel and iptables in this time... And have you tried another ISP ? The latter is a very important test. Guido -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
