MARK-Operations problems

MARK-Operations problems

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 958 bytes --]

Hi

I seem to be having some problem with the MARK-operations patch from
pom-ng.

I have applied a few patches together on a debian 2.6.7

nf_reset
policy
MARK-operations
REJECT
proc-no-internal-targets init_conntrack-optimize ipt_helper-invert-fix nf-log connlimit dstlimit mport nth raw
TARPIT CLASSIFY CLASSIFY_more-hooks comment dstlimit 
iprange
dropped-table
pool
osf

I build a static linked iptables for testing but when I attempt to run
this command 

iptables -t mangle -I PREROUTING 1  -j MARK  --or-mark 0x1
I get iptables: Target problem
and this is dmesg MARK: targinfosize 8 != 4


interesting is when i run this command against the static link iptables
iptables -t mangle -I PREROUTING 1  -j MARK  --set-mark 0x1
I get the same error, but it works okay when I use the orginial (unpatch
iptables command)

any suggestions on how to track down the error or where might be the
best place to look

Thanks
Alex

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: MARK-Operations problems

[Henrik Nordstrom]

On Wed, 7 Jul 2004, Alexander Samad wrote:

> I build a static linked iptables for testing but when I attempt to run
> this command 
> 
> iptables -t mangle -I PREROUTING 1  -j MARK  --or-mark 0x1
> I get iptables: Target problem
> and this is dmesg MARK: targinfosize 8 != 4

Looks to me like you are running a patched iptables userspace command on
an unpatched kernel...

Regards
Henrik

Maintaining MARKs on packets throughout the network

[sami]

I am sorry if this question has been asked on the list before, but is it 
possible to maintain the mark on packets even when they leave the router. I 
want to recieve packet with the same mark value that was assigned to it at the 
ingress router.
regards

Re: Maintaining MARKs on packets throughout the network

[Henrik Nordstrom]

On Thu, 8 Jul 2004 sami@ccse.kfupm.edu.sa wrote:

> I am sorry if this question has been asked on the list before, but is it
> possible to maintain the mark on packets even when they leave the
> router. I want to recieve packet with the same mark value that was
> assigned to it at the ingress router.

Not unless you can fully replicate the rules deducing the mark to all 
places where the mark is needed.

nfmark is local to the router/server only and not visible within the
packet contents. If you want some kind of packet marks actually visible on
the network you basically have two choices:

  a) Use the TOS/DS field

  b) Write a extension adding a custom IP option carrying the information
you need to preserve about the packet.

Regards
Henrik

Re: MARK-Operations problems

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 799 bytes --]

On Thu, Jul 08, 2004 at 02:10:40AM +0200, Henrik Nordstrom wrote:
> On Wed, 7 Jul 2004, Alexander Samad wrote:
> 
> > I build a static linked iptables for testing but when I attempt to run
> > this command 
> > 
> > iptables -t mangle -I PREROUTING 1  -j MARK  --or-mark 0x1
> > I get iptables: Target problem
> > and this is dmesg MARK: targinfosize 8 != 4
> 
> Looks to me like you are running a patched iptables userspace command on
> an unpatched kernel...

Double checked this and I am pretty sure its pacthed all the right
modules are there (the ones that are created with the patch), the
strange bit is even a working command -j MARK --set-mark 0x01 fails with
the same error, but the unpatched iptables doesn't on the same patches
kernel

> 
> Regards
> Henrik
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: MARK-Operations problems

[Henrik Nordstrom]

On Thu, 8 Jul 2004, Alexander Samad wrote:

> Double checked this and I am pretty sure its pacthed all the right
> modules are there (the ones that are created with the patch), the
> strange bit is even a working command -j MARK --set-mark 0x01 fails with
> the same error, but the unpatched iptables doesn't on the same patches
> kernel

The fact that the unpatched iptables works is a quite clear indication 
that the running kernel is not patched, at least not with the MARK 
operations patch.

When iptables is built it is using the same headers as the kernel. If the 
headers used when building iptables is different from those used when 
building the running kernel then operations on matches/extensions will 
fail with size errors.

Another occation when such errors can happen is in special cases on 64-bit
machines with split personality, with kernel running in 64-bits and
userspace in 32-bits. This is maybe seen on SPARC-64 and Opteron I think,
but is not very likely to be the cause of errors with the MARK operation.


Regards
Henrik

Re: MARK-Operations problems

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

On Thu, Jul 08, 2004 at 08:57:51AM +0200, Henrik Nordstrom wrote:
> On Thu, 8 Jul 2004, Alexander Samad wrote:
> 
> > Double checked this and I am pretty sure its pacthed all the right
> > modules are there (the ones that are created with the patch), the
> > strange bit is even a working command -j MARK --set-mark 0x01 fails with
> > the same error, but the unpatched iptables doesn't on the same patches
> > kernel
> 
> The fact that the unpatched iptables works is a quite clear indication 
> that the running kernel is not patched, at least not with the MARK 
> operations patch.
> 
> When iptables is built it is using the same headers as the kernel. If the 
> headers used when building iptables is different from those used when 
> building the running kernel then operations on matches/extensions will 
> fail with size errors.
Okay will rebuild and retest!

> 
> Another occation when such errors can happen is in special cases on 64-bit
> machines with split personality, with kernel running in 64-bits and
> userspace in 32-bits. This is maybe seen on SPARC-64 and Opteron I think,
> but is not very likely to be the cause of errors with the MARK operation.
> 
> 
> Regards
> Henrik
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]