* ipq_get_packet receives proper TCP and IP headers but the rest of payload is junk
[not found] <9010780e0707060538r3c754988ibebe5fa7d0c11ff2@mail.gmail.com>
@ 2007-07-06 12:39 ` Nick Landry
2007-07-06 13:00 ` Christian Gorecki
0 siblings, 1 reply; 6+ messages in thread
From: Nick Landry @ 2007-07-06 12:39 UTC (permalink / raw)
To: netfilter-devel
I have a simple program that just reads packets off of ip_queue and
dumps them. I setup my rules as follows:
Chain FORWARD (policy ACCEPT)
target prot opt source destination
QUEUE tcp -- anywhere anywhere
QUEUE udp -- anywhere anywhere
Everything runs fine on my 32-bit RHEL4 box and on another 64-bit
RHEL4 box. However, when running on (yet another) 64-bit RHEL4 box I
notice that that TCP and IP header part of the payload is the same,
but the rest of the payload looks like junk (mostly null, even though
this is HTTP GET messages).
I realize I'm using an older version of iptables:
iptables-1.2.11-3.1.RHEL4
iptables-devel-1.2.11-3.1.RHEL4
But I don't see any mention of this problem for any version of iptables.
Any help would be greatly appreciated.
Nick
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: ipq_get_packet receives proper TCP and IP headers but the rest of payload is junk
2007-07-06 12:39 ` ipq_get_packet receives proper TCP and IP headers but the rest of payload is junk Nick Landry
@ 2007-07-06 13:00 ` Christian Gorecki
2007-07-06 14:12 ` Nick Landry
0 siblings, 1 reply; 6+ messages in thread
From: Christian Gorecki @ 2007-07-06 13:00 UTC (permalink / raw)
To: Nick Landry; +Cc: netfilter-devel
Recently I have had some similar observations. For me the solution was
to disable the Accept-Encoding header field the browser had set.
So I guess on your first configuration the browser did not accept
encoding and in the second scenario the browser does.
Cheers,
Christian
Nick Landry schrieb:
> I have a simple program that just reads packets off of ip_queue and
> dumps them. I setup my rules as follows:
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
> QUEUE tcp -- anywhere anywhere
> QUEUE udp -- anywhere anywhere
>
> Everything runs fine on my 32-bit RHEL4 box and on another 64-bit
> RHEL4 box. However, when running on (yet another) 64-bit RHEL4 box I
> notice that that TCP and IP header part of the payload is the same,
> but the rest of the payload looks like junk (mostly null, even though
> this is HTTP GET messages).
>
> I realize I'm using an older version of iptables:
> iptables-1.2.11-3.1.RHEL4
> iptables-devel-1.2.11-3.1.RHEL4
>
> But I don't see any mention of this problem for any version of iptables.
>
> Any help would be greatly appreciated.
>
> Nick
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ipq_get_packet receives proper TCP and IP headers but the rest of payload is junk
2007-07-06 13:00 ` Christian Gorecki
@ 2007-07-06 14:12 ` Nick Landry
2007-07-06 14:41 ` Patrick McHardy
0 siblings, 1 reply; 6+ messages in thread
From: Nick Landry @ 2007-07-06 14:12 UTC (permalink / raw)
To: Christian Gorecki; +Cc: netfilter-devel
Thanks, I checked that but the issue is that I am sending the exact
same GET request (Accept-Encoding is the same as well) for when the
message passes through any of the machines. The read from ip_queue
for one machine is headers + ascii which is what I'd expect. The
other machine outputs headers + junk.
Here's a hex dump for the machine that isn't working (payload length
is 1500 bytes but I'll only print a small part):
--> 45 00 05 78 02 37 40 00 42 06 18 5b 0a b3 00 0c
--> 0a 2b 04 05 c5 3a 00 50 26 a2 08 34 a8 d5 7c f7
--> 80 10 4f b0 de f3 00 00 08 0a e4 eb 14 02 d5 6e
--> e4 1c 00 00 08 00 01 00 06 00 0f f7 b5 9b 00 00
--> 00 00 00 00 00 00 00 00 30 00 00 00 00 00 00 00
--> 45 00 00 30 bf 76 40 00 7c 06 d4 35 0a b1 2c 0f
--> 0a b3 29 a9 13 4b 01 bd 29 7a 9e 75 00 00 00 00
--> 70 02 40 00 fb 0b 00 00 02 04 05 b4 01 01 04 02
--> 01 01 04 02 00 15 17 29 49 62 08 00 45 08 00 34
--> 64 1b 40 00 40 06 be 0d 0a 2a 02 21 0a 2a 02 1f
--> 80 03 bb 06 8c bc 41 58 79 bb 93 af 80 10 80 00
--> 62 96 00 00 01 01 08 0a 00 2d 7d cc 19 d0 cd 3f
--> b1 18 40 00 7e 00 40 00 00 00 00 00 82 00 16 00
--> 38 18 04 00 7e 00 40 00 00 00 08 00 00 00 00 00
--> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
--> 00 00 00 00 00 00 00 00 b1 18 40 00 54 00 40 00
--> 01 00 01 00 80 00 01 00 01 00 01 00 01 00 14 00
--> 3b 03 05 00 7e 00 40 00 00 00 00 00 00 00 00 00
--> 82 00 16 00 3e 00 07 00 b1 18 40 00 73 00 40 00
--> 7e 00 40 00 00 00 00 00 00 00 00 00 82 00 16 00
[....]
And it just goes on like that. The NULLs are what leads me to believe
that I'm getting back data that the kernel copied from the wrong part
of memory (that and the output is different every time I run it, even
though it's the same GET message).
Nick
On 7/6/07, Christian Gorecki <christian.gorecki@post.rwth-aachen.de> wrote:
> Recently I have had some similar observations. For me the solution was
> to disable the Accept-Encoding header field the browser had set.
>
> So I guess on your first configuration the browser did not accept
> encoding and in the second scenario the browser does.
>
> Cheers,
> Christian
>
> Nick Landry schrieb:
> > I have a simple program that just reads packets off of ip_queue and
> > dumps them. I setup my rules as follows:
> >
> > Chain FORWARD (policy ACCEPT)
> > target prot opt source destination
> > QUEUE tcp -- anywhere anywhere
> > QUEUE udp -- anywhere anywhere
> >
> > Everything runs fine on my 32-bit RHEL4 box and on another 64-bit
> > RHEL4 box. However, when running on (yet another) 64-bit RHEL4 box I
> > notice that that TCP and IP header part of the payload is the same,
> > but the rest of the payload looks like junk (mostly null, even though
> > this is HTTP GET messages).
> >
> > I realize I'm using an older version of iptables:
> > iptables-1.2.11-3.1.RHEL4
> > iptables-devel-1.2.11-3.1.RHEL4
> >
> > But I don't see any mention of this problem for any version of iptables.
> >
> > Any help would be greatly appreciated.
> >
> > Nick
> >
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ipq_get_packet receives proper TCP and IP headers but the rest of payload is junk
2007-07-06 14:12 ` Nick Landry
@ 2007-07-06 14:41 ` Patrick McHardy
2007-07-06 15:38 ` Nick Landry
0 siblings, 1 reply; 6+ messages in thread
From: Patrick McHardy @ 2007-07-06 14:41 UTC (permalink / raw)
To: Nick Landry; +Cc: Christian Gorecki, netfilter-devel
Nick Landry wrote:
> Thanks, I checked that but the issue is that I am sending the exact
> same GET request (Accept-Encoding is the same as well) for when the
> message passes through any of the machines. The read from ip_queue
> for one machine is headers + ascii which is what I'd expect. The
> other machine outputs headers + junk.
>
> Here's a hex dump for the machine that isn't working (payload length
> is 1500 bytes but I'll only print a small part):
>
> --> 45 00 05 78 02 37 40 00 42 06 18 5b 0a b3 00 0c
> --> 0a 2b 04 05 c5 3a 00 50 26 a2 08 34 a8 d5 7c f7
> --> 80 10 4f b0 de f3 00 00 08 0a e4 eb 14 02 d5 6e
> --> e4 1c 00 00 08 00 01 00 06 00 0f f7 b5 9b 00 00
> --> 00 00 00 00 00 00 00 00 30 00 00 00 00 00 00 00
> --> 45 00 00 30 bf 76 40 00 7c 06 d4 35 0a b1 2c 0f
> --> 0a b3 29 a9 13 4b 01 bd 29 7a 9e 75 00 00 00 00
> --> 70 02 40 00 fb 0b 00 00 02 04 05 b4 01 01 04 02
> --> 01 01 04 02 00 15 17 29 49 62 08 00 45 08 00 34
> --> 64 1b 40 00 40 06 be 0d 0a 2a 02 21 0a 2a 02 1f
> --> 80 03 bb 06 8c bc 41 58 79 bb 93 af 80 10 80 00
> --> 62 96 00 00 01 01 08 0a 00 2d 7d cc 19 d0 cd 3f
> --> b1 18 40 00 7e 00 40 00 00 00 00 00 82 00 16 00
> --> 38 18 04 00 7e 00 40 00 00 00 08 00 00 00 00 00
> --> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> --> 00 00 00 00 00 00 00 00 b1 18 40 00 54 00 40 00
> --> 01 00 01 00 80 00 01 00 01 00 01 00 01 00 14 00
> --> 3b 03 05 00 7e 00 40 00 00 00 00 00 00 00 00 00
> --> 82 00 16 00 3e 00 07 00 b1 18 40 00 73 00 40 00
> --> 7e 00 40 00 00 00 00 00 00 00 00 00 82 00 16 00
> [....]
>
> And it just goes on like that. The NULLs are what leads me to believe
> that I'm getting back data that the kernel copied from the wrong part
> of memory (that and the output is different every time I run it, even
> though it's the same GET message).
Possibly related to ip_queue TSO handling bugs in old kernels. Are
you using TSO?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ipq_get_packet receives proper TCP and IP headers but the rest of payload is junk
2007-07-06 14:41 ` Patrick McHardy
@ 2007-07-06 15:38 ` Nick Landry
2007-07-06 17:48 ` Nick Landry
0 siblings, 1 reply; 6+ messages in thread
From: Nick Landry @ 2007-07-06 15:38 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Christian Gorecki, netfilter-devel
Checked TSO, and it turns out it is disabled at startup. I'm really
stumped on this one.
Nick
On 7/6/07, Patrick McHardy <kaber@trash.net> wrote:
> Nick Landry wrote:
> > Thanks, I checked that but the issue is that I am sending the exact
> > same GET request (Accept-Encoding is the same as well) for when the
> > message passes through any of the machines. The read from ip_queue
> > for one machine is headers + ascii which is what I'd expect. The
> > other machine outputs headers + junk.
> >
> > Here's a hex dump for the machine that isn't working (payload length
> > is 1500 bytes but I'll only print a small part):
> >
> > --> 45 00 05 78 02 37 40 00 42 06 18 5b 0a b3 00 0c
> > --> 0a 2b 04 05 c5 3a 00 50 26 a2 08 34 a8 d5 7c f7
> > --> 80 10 4f b0 de f3 00 00 08 0a e4 eb 14 02 d5 6e
> > --> e4 1c 00 00 08 00 01 00 06 00 0f f7 b5 9b 00 00
> > --> 00 00 00 00 00 00 00 00 30 00 00 00 00 00 00 00
> > --> 45 00 00 30 bf 76 40 00 7c 06 d4 35 0a b1 2c 0f
> > --> 0a b3 29 a9 13 4b 01 bd 29 7a 9e 75 00 00 00 00
> > --> 70 02 40 00 fb 0b 00 00 02 04 05 b4 01 01 04 02
> > --> 01 01 04 02 00 15 17 29 49 62 08 00 45 08 00 34
> > --> 64 1b 40 00 40 06 be 0d 0a 2a 02 21 0a 2a 02 1f
> > --> 80 03 bb 06 8c bc 41 58 79 bb 93 af 80 10 80 00
> > --> 62 96 00 00 01 01 08 0a 00 2d 7d cc 19 d0 cd 3f
> > --> b1 18 40 00 7e 00 40 00 00 00 00 00 82 00 16 00
> > --> 38 18 04 00 7e 00 40 00 00 00 08 00 00 00 00 00
> > --> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > --> 00 00 00 00 00 00 00 00 b1 18 40 00 54 00 40 00
> > --> 01 00 01 00 80 00 01 00 01 00 01 00 01 00 14 00
> > --> 3b 03 05 00 7e 00 40 00 00 00 00 00 00 00 00 00
> > --> 82 00 16 00 3e 00 07 00 b1 18 40 00 73 00 40 00
> > --> 7e 00 40 00 00 00 00 00 00 00 00 00 82 00 16 00
> > [....]
> >
> > And it just goes on like that. The NULLs are what leads me to believe
> > that I'm getting back data that the kernel copied from the wrong part
> > of memory (that and the output is different every time I run it, even
> > though it's the same GET message).
>
>
> Possibly related to ip_queue TSO handling bugs in old kernels. Are
> you using TSO?
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ipq_get_packet receives proper TCP and IP headers but the rest of payload is junk
2007-07-06 15:38 ` Nick Landry
@ 2007-07-06 17:48 ` Nick Landry
0 siblings, 0 replies; 6+ messages in thread
From: Nick Landry @ 2007-07-06 17:48 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Christian Gorecki, netfilter-devel
I had also forgot to mention that when running tethereal, the packet
contents looked fine. Not sure what the differences are between how
tethereal captures packets and how ip_queue reads packets.
Nick
On 7/6/07, Nick Landry <nick.landry@gmail.com> wrote:
> Checked TSO, and it turns out it is disabled at startup. I'm really
> stumped on this one.
>
>
>
> Nick
>
> On 7/6/07, Patrick McHardy <kaber@trash.net> wrote:
> > Nick Landry wrote:
> > > Thanks, I checked that but the issue is that I am sending the exact
> > > same GET request (Accept-Encoding is the same as well) for when the
> > > message passes through any of the machines. The read from ip_queue
> > > for one machine is headers + ascii which is what I'd expect. The
> > > other machine outputs headers + junk.
> > >
> > > Here's a hex dump for the machine that isn't working (payload length
> > > is 1500 bytes but I'll only print a small part):
> > >
> > > --> 45 00 05 78 02 37 40 00 42 06 18 5b 0a b3 00 0c
> > > --> 0a 2b 04 05 c5 3a 00 50 26 a2 08 34 a8 d5 7c f7
> > > --> 80 10 4f b0 de f3 00 00 08 0a e4 eb 14 02 d5 6e
> > > --> e4 1c 00 00 08 00 01 00 06 00 0f f7 b5 9b 00 00
> > > --> 00 00 00 00 00 00 00 00 30 00 00 00 00 00 00 00
> > > --> 45 00 00 30 bf 76 40 00 7c 06 d4 35 0a b1 2c 0f
> > > --> 0a b3 29 a9 13 4b 01 bd 29 7a 9e 75 00 00 00 00
> > > --> 70 02 40 00 fb 0b 00 00 02 04 05 b4 01 01 04 02
> > > --> 01 01 04 02 00 15 17 29 49 62 08 00 45 08 00 34
> > > --> 64 1b 40 00 40 06 be 0d 0a 2a 02 21 0a 2a 02 1f
> > > --> 80 03 bb 06 8c bc 41 58 79 bb 93 af 80 10 80 00
> > > --> 62 96 00 00 01 01 08 0a 00 2d 7d cc 19 d0 cd 3f
> > > --> b1 18 40 00 7e 00 40 00 00 00 00 00 82 00 16 00
> > > --> 38 18 04 00 7e 00 40 00 00 00 08 00 00 00 00 00
> > > --> 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > --> 00 00 00 00 00 00 00 00 b1 18 40 00 54 00 40 00
> > > --> 01 00 01 00 80 00 01 00 01 00 01 00 01 00 14 00
> > > --> 3b 03 05 00 7e 00 40 00 00 00 00 00 00 00 00 00
> > > --> 82 00 16 00 3e 00 07 00 b1 18 40 00 73 00 40 00
> > > --> 7e 00 40 00 00 00 00 00 00 00 00 00 82 00 16 00
> > > [....]
> > >
> > > And it just goes on like that. The NULLs are what leads me to believe
> > > that I'm getting back data that the kernel copied from the wrong part
> > > of memory (that and the output is different every time I run it, even
> > > though it's the same GET message).
> >
> >
> > Possibly related to ip_queue TSO handling bugs in old kernels. Are
> > you using TSO?
> >
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2007-07-06 17:48 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <9010780e0707060538r3c754988ibebe5fa7d0c11ff2@mail.gmail.com>
2007-07-06 12:39 ` ipq_get_packet receives proper TCP and IP headers but the rest of payload is junk Nick Landry
2007-07-06 13:00 ` Christian Gorecki
2007-07-06 14:12 ` Nick Landry
2007-07-06 14:41 ` Patrick McHardy
2007-07-06 15:38 ` Nick Landry
2007-07-06 17:48 ` Nick Landry
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.