Hi there! This post is somehow connected with my other posts about problems with HTB. In fact - in my case it can be problem of linux kernel :-/? Ok, here is the hardware and software: Linux Debian working on classic pentium 120MHz. Kernel 2.4.18. MLDonkey is working for some period of time. It is generating traffic very intensively. Here you can see the output of ''netstat -t''. http://josh876.republika.pl/netstat.txt Ok, here is the situation: I can see the LED from modem is blinking very fast - no - it is not blinking it is static light. As you can see after opening netstat.txt 99% of traffic is generated by mldonkey''s 4662 and 4661 ports. Now I am appending these rules: iptables -t filter -A INPUT -p tcp \ --destination-port 4662 -j DROP iptables -t filter -A INPUT -p tcp \ --source-port 4662 -j DROP iptables -t filter -A OUTPUT -p tcp \ --destination-port 4662 -j DROP iptables -t filter -A OUTPUT -p tcp \ --source-port 4662 -j DROP and same ones for port 4661. What is happening? It looks like Linux is trying to drop these packets, but they are braking down VERY slowly. It seems like linux is unable to handle that and there are still many packets out of iptables control. Look at this: here you can see ''netstat -n'' output written after (about half of minute) appending iptables DROP rules: http://josh876.republika.pl/netstat-dropped.txt modem''s LED is blinkink randomly from time to time but and it is slowing. But MLDonkey is still reporting downloading. ..and this is after few minutes http://josh876.republika.pl/netstat-dropped-few-minutes.txt MLDonkey is generally not reporting downloading, but it is still happening that it will show download for a very short while. The conclusion is, that if IPTABLES has big prolems slowing this damned thing it is also possible that HTB cannot manage it... :-(( What do you think? p.s. here is someting taken from MLDonkey configuraton: (I dont know what this means exactly, but it seems like mldonkey has a limit of 5 download attempting per secound) max_clients_per_second = 5
Wow. It is very interesting. Did you tried to read counters in iptables -vL and compare counts ? Like to read value from /proc/net/dev compare to count of packets at INPUT chain and then compare with no of packets in DROP chains. It could give us better picture where are the packets going to. But it seems there is problem with too many connections. The dropping may work but remote sites will still try to resend the packets and because you have high number of connections there SYNs and duplicates will go at least several minutes. devik> > and same ones for port 4661. > What is happening? > It looks like Linux is trying to drop these packets, but they are braking down VERY slowly. It seems like linux is unable to handle that and there are still many packets out of iptables control. > Look at this: > here you can see ''netstat -n'' output written after (about half of minute) appending iptables DROP rules: > > http://josh876.republika.pl/netstat-dropped.txt > > modem''s LED is blinkink randomly from time to time but and it is slowing. But MLDonkey is still reporting downloading. > > ..and this is after few minutes > > http://josh876.republika.pl/netstat-dropped-few-minutes.txt > > MLDonkey is generally not reporting downloading, but it is still happening that it will show download for a very short while. >
Martin Devera wrote:> > Wow. It is very interesting. Did you tried to read counters > in iptables -vL and compare counts ? Like to read value from > /proc/net/dev compare to count of packets at INPUT chain and > then compare with no of packets in DROP chains. > It could give us better picture where are the packets going to. > > But it seems there is problem with too many connections. The dropping > may work but remote sites will still try to resend the packets and > because you have high number of connections there SYNs and duplicates > will go at least several minutes.yes that it, i do the same thing, i have a ftp server and when it''s on heavy load, and i need some bandwith, i start to "iptables -I INPUT -s ip -j DROP", and the connections are still there for some time (minutes, never looked), beacouse the server thinks it''s a network problem and hope that will be restored. in his case, it''s a client so the servers send him packets, don''t get ACKs so resend (some time) after they drop de connection. you could try with -j REJECT, it''s better, faster C> > devik > > > > > and same ones for port 4661. > > What is happening? > > It looks like Linux is trying to drop these packets, but they are braking down VERY slowly. It seems like linux is unable to handle that and there are still many packets out of iptables control. > > Look at this: > > here you can see ''netstat -n'' output written after (about half of minute) appending iptables DROP rules: > > > > http://josh876.republika.pl/netstat-dropped.txt > > > > modem''s LED is blinkink randomly from time to time but and it is slowing. But MLDonkey is still reporting downloading. > > > > ..and this is after few minutes > > > > http://josh876.republika.pl/netstat-dropped-few-minutes.txt > > > > MLDonkey is generally not reporting downloading, but it is still happening that it will show download for a very short while. > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Mldonkey open many connections, so individually they are very slow. Maybe the TCP timeout is at the maximum (2minutes), so it can take several minutes to close a connection (maybe 5minutes). On Fri, 7 Jun 2002, Martin Devera wrote:> Wow. It is very interesting. Did you tried to read counters > in iptables -vL and compare counts ? Like to read value from > /proc/net/dev compare to count of packets at INPUT chain and > then compare with no of packets in DROP chains. > It could give us better picture where are the packets going to. > > But it seems there is problem with too many connections. The dropping > may work but remote sites will still try to resend the packets and > because you have high number of connections there SYNs and duplicates > will go at least several minutes. > > devik > > > > > and same ones for port 4661. > > What is happening? > > It looks like Linux is trying to drop these packets, but they are braking down VERY slowly. It seems like linux is unable to handle that and there are still many packets out of iptables control. > > Look at this: > > here you can see ''netstat -n'' output written after (about half of minute) appending iptables DROP rules: > > > > http://josh876.republika.pl/netstat-dropped.txt > > > > modem''s LED is blinkink randomly from time to time but and it is slowing. But MLDonkey is still reporting downloading. > > > > ..and this is after few minutes > > > > http://josh876.republika.pl/netstat-dropped-few-minutes.txt > > > > MLDonkey is generally not reporting downloading, but it is still happening that it will show download for a very short while. > > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >-- __o _ \<_ (_)/(_) Saludos de Julián EA4ACL -.- Foro Wireless Madrid http://opennetworks.rg3.net