guy keren wrote:
on my system, this works fine. i'm using redhat's kernel, 2.4.18-17.7.x .
did you:
1. look in /var/log/messages while running this command?
2. strace this command?
if not - shame on you
Shame on me, indeed. So I punished myself a bit...
At some stage I upgraded iptables to 1.3.3, which is the fresh version.
It looked like it could solve something. It didn't.
To begin with, nothing happens in /var/log/messages. strace gave
something to bite on, but ltrace got even more specific. It ends with:
4891 setsockopt(3, 0, 64, 0x08057988, 4968) = -1
4891 free(0x08055058) = void
4891 free(0x08057988) = void
4891 free(0x08058cf8) = void
4891 __errno_location() = 0x42130b60
4891 strerror(22) = Invalid argument
4891 fprintf(0x4212dc80, iptables: %s\n, Invalid argument) = 27
Aha, I said, let's see who does it. The string setsockopt appears
twice in the entire iptables source, and I could narrow it down to
libiptc/libiptc.c, line 2102:
if (setsockopt(sockfd, TC_IPPROTO, SO_SET_REPLACE, repl,
sizeof(*repl) + repl-size) 0) {
free(repl-counters);
free(repl);
free(newcounters);
return 0;
}
This means absolutely nothing to me. The function is called TC_COMMIT,
and it deals with some counters. Other keywords: Replace, map.
In short, I have still no idea what to do.
Guy, is this enought punishment? Can I go playing now? ;)
Eli
--
Web: http://www.billauer.co.il
--
Haifa Linux Club Mailing List (http://www.haifux.org)
To unsub send an empty message to [EMAIL PROTECTED]
