On Fri, 24 Aug 2007 20:17:17 +0200 Hans-Werner Hilse <[EMAIL PROTECTED]> wrote:
> Hi, > > On Thu, 23 Aug 2007 12:55:06 -0500 > Dan Farrell <[EMAIL PROTECTED]> wrote: > > > > It usually means that the other side of the TCP > > > connection reduced the window to zero size, thus leading stupid > > > TCP stacks to save information on a basically starved connection. > > > The kernel just sends an information to the log, so in case if you > > > recognize the IP and are in charge of the sender, you'll know > > > that it has a veeeeery broken TCP stack. Essentially: Just ignore > > > it, if the sender IP doesn't belong to one of your own networks. > > > > > I found a line in my Treason-related output that pointed to an > > internal IP on a distcc port. Should I be worried about this > > computer? It's running a brand new gentoo install and is solely > > for the purpose of distcc. > > Hm. I don't think so, but I'm not that deep into TCP that I could > easily tell some circumstances when such things can happen and if it > indicates a bug by all means. > > There might be a slight possibility that the packet sender was forged. > Additionally, when inside a potentially hostile LAN, you can't trust > any IP adresses. > > If it's just a single line, I'd ignore it, I think. But there's no > good reason I could give for that proposal, except of some absent > feeling that anything would be wrong. > > -hwh OK, Thanks. I am going to put | iptables -I INPUT -s 192.168.0.0/16 -i eth1 -j DROP into my firewall and see if any packets hit it I guess. It would be good to know > It depends on your uplink whether such packets can get through. whether or not that applies to mine (comcast); I thought I tested it but I suppose it probably depends on the other side of the connection as well. -- [EMAIL PROTECTED] mailing list
