conntrack TIMEWAIT
大家帮帮忙 我自己编译的内核，无法自动挂在编译好的nf_conntrack.ko 我自己手动将模块插进内核后，sudo cat /proc/net/nf_conntrack 内没有任何的输出。 查看dmesg|tail 后，我执行sudo sysctl net.netfilter.nf_conntrack_acct=1 后 sudo cat /proc/net/nf_conntrack 内没有任何的输出。 哪位过来人帮帮我看看这是为什么？如何解决？谢谢
by ryan3216_cu - 内核源码 - 2010-04-23 13:09:27 阅读（1413） 回复（5）
加大ip_conntrack_max.查看是哪里增加了连接.马上断开连接改变默认超时 用NAT上网,最近老是报conntrack表满的错,加大ip_conntrack_max就没问题了. 查看是哪里一下增加了这么多连接. cat /proc/net/ip_conntrack > /root/conntrack_table grep 192.168.0.201 conntrack_table > 201_table 居然有1800行,也就是说201这台机器就发出了1800个连接,当然不够.看看端口,688*,还有888*,估计是bt了 暂时封一下吧，不应该在nat中过滤，应...
编译内核的时候，可以修改/usr/src/linux/include/net/tcp.h里面的 #define TCP_timewait_LEN (60*HZ) ==> 1*HZ 用新编译的内核启动后，就生效了 RedHat 在不编译内核的情况下，不知道是调整哪个参数可以实现，编内核实在是麻烦的事情
编译内核的时候，可以修改/usr/src/linux/include/net/tcp.h里面的 #define TCP_timewait_LEN (60*HZ) ==> 1*HZ 用新编译的内核启动后，就生效了 RedHat 在不编译内核的情况下，不知道是调整哪个参数可以实现，编内核实在是麻烦的事情 有兄弟知道么？
编译内核的时候，可以修改/usr/src/linux/include/net/tcp.h里面的 #define TCP_timewait_LEN (60*HZ) ==> 1*HZ 用新编译的内核启动后，就生效了 RedHat 在不编译内核的情况下，不知道是调整哪个参数可以实现，编内核实在是麻烦的事情 有兄弟知道么？
/* Netfilter hook itself. */ unsigned int ip_conntrack_in(unsigned int hooknum, struct sk_buff **pskb, const struct net_device *in, const struct net_device *out, int (*okfn)(struct sk_buff *)) { struct ip_conntrack *ct; enum ip_conntrack_info ctinfo; struct ip_conntrack_protocol *proto; int set_reply = 0; int ret; /* Pr...
conntrack记录 我们先来看看怎样阅读/proc/net/ip_conntrack里的conntrack记录。这些记录表示的是当前被跟踪的连接。如果安装了ip_conntrack模块，cat /proc/net/ip_conntrack 的显示类似： tcp 6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 dport=32775 use=2 conntrack模块维护的所有信息都包含在这个例子中了，通过它们就...
我们先来看看怎样阅读/proc/net/ip_conntrack里的conntrack记录。这些记 录表示的是当前被 跟踪的连接。如果安装了ip_conntrack模块，cat /proc/net/ip_conntrack 的显示类似： tcp 6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \ dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \ dport=32775 use=2 ...
目前我的理解，pthread_cond_timewait执行时，其内部如下机制： unlock 等待唤醒 || 时间timeout lock 如果类似我上面的理解，那再lock时，如果锁已经被其他线程持有，那调用pthread_cond_timewait的线程岂不会又陷入休眠。 从而不能在时间timeout后被唤醒？ 个人写程序验证。测试结果，在其他线程不释放锁的情况下，pthread_cond_timewait不能保证在timeout后就被唤醒。 求证以上观点。
inline static void thread_sleep(long int sec, long int milsec) { pthread_cond_t cond = PTHREAD_COND_INITIALIZER; pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER; struct timespec time; bzero(&time, sizeof(struct timespec)); time.tv_sec = sec; time.tv_nsec = milsec * 1000000; pthread_mutex_lock(&mutex); pthread_cond_timedwait(&cond, &mutex, &time); pthread_mutex_unlock(&mutex); pthread_m...
