TCP kernel msg changed in 11.2

in 11.1 (2.6.27*) there were occasional kernel msgs generated in the “messages” log:

May 26 21:57:28 blkdragon kernel: TCP: Treason uncloaked! Peer 188.48.28.209:18769/58845 shrinks window 2778476289:2778478629. Repaired.

had to do with torrents/java and azureus/utorrent, with the outside ip number/port assignments easily understood and parsed if necessary.

in 11.2 (2.6.31.5) the same type of entry is:

00:24:23 blkdragon kernel: [258668.819024] TCP: Peer 0000:0000:0000:0000:0000:ffff:54b6:489e:10858/44949 unexpectedly shrunk window 3076383191:3076383869 (repaired)

which is not useful. (at least not easily)

anything to be done about this short of a kernel rebuild?

this is scaling/shrinking in the TCP ipv4 stack. It could happen in various occasions… spam, broken client, syn flooding, etc and it can even happen due to buggy driver on the client’s side. It’s possible that someone is spoofing your IP so you may want to block this IP

Go to /etc/sysconfig/scripts and open the ‘SuSEfirewall2-custom’ file. At the very top, there’s a function called ‘fw_custom_before_antispoofing()’

Place inside that function the following:

iptables -A INPUT -j DROP --src 188.48.28.209
iptables -A OUTPUT -j DROP --dst 188.48.28.209

Save it and as root on console type ‘SuSEfirewall2’ to reload the FW

gmta, microchip. :slight_smile:

the entry seemed to be limited to specific version of utorrent clients, but to be safe, previously i had captured the entry in “messages” and sent the ip number to azureus’ filter list.

problem is this type of event seems report some other identifier now , instead of the ip number if you look at my original post.

i’m not getting that eureka moment here, just not seeing it.

might also be possible that it is just passing an output snippet from azureus/java which may have changed during upgrade that i didn’t notice.

I’ve ran the 2.6.31.x kernels but I don’t know what has changed in them which may make them behave that way, reporting something different than the IP. A long time ago, there was a bug in the 2.6.x series which resulted in such “treason uncloakded” messages but this was long time ago, somewhere in the early 2.6 series, and it was the bug causing it and not someone trying to spoof IPs. I’m currently on 2.6.32.2 and haven’t seen such things when using p2p.

Maybe there’s a bug in uTorrent or something which makes it look as if someone is spoofing. I don’t know really. I run a bittorrent tracker myself and found out that often Azureus clients will behave a bit odd. When turning redirection on the tracker side so if someone visits its address he’ll get redirected to its website instead, Azureus clients “think” that they should connect to the webserver instead of the tracker and my webserver logs get flooded with Vuze clients trying to connect to it, trying to announce & scrape with info_hash. Turning off redirection in the tracker makes this go away… And no, there’s nothing wrong on the tracker’s side as I’ve gone over the code many times and it’s correct. So this is a Vuze thing (prolly a bug somewhere) and it’s only Vuze clients that do such things.

to wrap this up, the kernel msg to syslog was due to an out-of-bounds request from the outside connection, flagged and corrected. seems limited to older utorrent clients (not verified).

the resolution had to do with the ipv6 bug in 11.2 in which the yast2 setting to disable ipv6 does not in reality do so, and the manual modification of /etc/sysctl.conf to add the line:

net.ipv6.conf.all.disable_ipv6 = 1

is necessary.

this changes the reported syslog entry from a ipv6 style address to ipv4, which suits my purpose of capturing and then blocking if required.