Doug Mitton <doug_mitton@hotmail.x.com> writes:


>>It's switched to autoconf too, and it seems you're getting ipv6 like
>>it or not (no disable switch). I don't think the distros have picked
>>up on this yet as Google has nothing about 2.6.24/iptables. There's
>>going to have to be some serious reworking done if people are going to
>>start using 2.6.24. I really hate when the kernel people change
>>everything and pull the floor out from under all other
>>projects...don't they realize a kernel does not an operating system
>>alone make?
>
> I can't comment on the issue above except to say that I just upgraded
> from 2.6.23 to 2.6.24 with no problems regarding iptables at all. I
> didn't use the patch, I downloaded the entire source tree. Then I
> copied over my old .config and did a `make oldconfig` and selected all
> default replies to the differences.

Which iptables did you rebuild with? This was iptables--20080127
(snapshot). Some of the stuff did build, but a good chunk of it
didn't. If it bombed or not would depend on if you tried to compile
the extensions that had trouble. Did you notice if yours did build any
of those that are shown erroring out from my log? Maybe I could have
made a go at it, but I saw alot of nat/conntrack stuff fail. Like this
one: libxt_conntrack.c. I'd think that would nix any -m conntrack
rules.


> I use a lot of Rules and it is working just fine.

I don't see how, with such basic values being redefined, sometime's
got to break some place. For example:

The system's idea of INADDR_ANY:
/usr/include/netinet/in.h:#define INADDR_ANY ((in_addr_t) /0x00000000)


Redefined in 2.6.24:
/usr/src/linux-2.6.24/include/linux/in.h:#define INADDR_ANY ((unsigned long int) 0x00000000)

There's about 12 such similar issues with all the INADDR_* stuff.


> The only issue I'm having with the new kernel is with the new core
> scheduler and `dnetc` (Distributed Computing Client) as the default
> rules make my system almost unuseable when the load goes up to nearly
> 100%. Still investigating this.

I didn't even boot it. I'd have liked to, as there seemed to be alot
of new features.


--
[** America, the police state **]
Whoooose! What's that noise? Why, it's US citizen's
rights, going down the toilet with Bush flushing.
http://www.theregister.co.uk/2008/01..._nsa_internal/
http://www.wired.com/politics/securi...007/08/wiretap
http://www.hermes-press.com/police_state.htm
http://www.privacyinternational.org/...D=x-347-559597

jayjwa <jayjwa@vdrl.ath.cx.invalid> wrote:

>Doug Mitton <doug_mitton@hotmail.x.com> writes:
>
>>>It's switched to autoconf too, and it seems you're getting ipv6 like
>>>it or not (no disable switch). I don't think the distros have picked
>>>up on this yet as Google has nothing about 2.6.24/iptables. There's
>>>going to have to be some serious reworking done if people are going to
>>>start using 2.6.24. I really hate when the kernel people change
>>>everything and pull the floor out from under all other
>>>projects...don't they realize a kernel does not an operating system
>>>alone make?
>>
>> I can't comment on the issue above except to say that I just upgraded
>> from 2.6.23 to 2.6.24 with no problems regarding iptables at all. I
>> didn't use the patch, I downloaded the entire source tree. Then I
>> copied over my old .config and did a `make oldconfig` and selected all
>> default replies to the differences.
>
>Which iptables did you rebuild with? This was iptables--20080127
>(snapshot). Some of the stuff did build, but a good chunk of it
>didn't. If it bombed or not would depend on if you tried to compile
>the extensions that had trouble. Did you notice if yours did build any
>of those that are shown erroring out from my log? Maybe I could have
>made a go at it, but I saw alot of nat/conntrack stuff fail. Like this
>one: libxt_conntrack.c. I'd think that would nix any -m conntrack
>rules.
>
>> I use a lot of Rules and it is working just fine.
>
>I don't see how, with such basic values being redefined, sometime's
>got to break some place. For example:
>
>The system's idea of INADDR_ANY:
>/usr/include/netinet/in.h:#define INADDR_ANY ((in_addr_t) /0x00000000)
>
>Redefined in 2.6.24:
>/usr/src/linux-2.6.24/include/linux/in.h:#define INADDR_ANY ((unsigned long int) 0x00000000)
>
>There's about 12 such similar issues with all the INADDR_* stuff.
>
>> The only issue I'm having with the new kernel is with the new core
>> scheduler and `dnetc` (Distributed Computing Client) as the default
>> rules make my system almost unuseable when the load goes up to nearly
>> 100%. Still investigating this.
>
>I didn't even boot it. I'd have liked to, as there seemed to be alot
>of new features.


Hmmm, it looks like you are talking about the user utility itself not
just the kernel. Sorry, I didn't update the client this time so I
didn't see the issues. I just implemented my original firewall rules,
verified them and didn't go any further.

--
------------------------------------------------
http://www3.sympatico.ca/dmitton
SPAM Reduction: Remove "x." from my domain.
------------------------------------------------

Doug Mitton <doug_mitton@hotmail.x.com> writes:

> Hmmm, it looks like you are talking about the user utility itself not
> just the kernel. Sorry, I didn't update the client this time so I
> didn't see the issues. I just implemented my original firewall rules,
> verified them and didn't go any further.

Yes, both. I usually do the kernel, then iptables + ipset from the new
kernel and kmods. Be careful if you're still using the old with a new
kernel: some stuff may not work like it should. I'll try a new
snapshot in awhile, see if anything's changed.



--
[** America, the police state **]
Whoooose! What's that noise? Why, it's US citizen's
rights, going down the toilet with Bush flushing.
http://www.theregister.co.uk/2008/01..._nsa_internal/
http://www.wired.com/politics/securi...007/08/wiretap
http://www.hermes-press.com/police_state.htm
http://www.privacyinternational.org/...D=x-347-559597