All of lore.kernel.org
 help / color / mirror / Atom feed
* get tcp header
@ 2010-08-31 18:26 Nicola Padovano
  2010-08-31 18:35 ` Jan Engelhardt
  0 siblings, 1 reply; 17+ messages in thread
From: Nicola Padovano @ 2010-08-31 18:26 UTC (permalink / raw)
  To: netfilter-devel

Hi guys! i know the skb_transport_header to grab the tcp header of a
packet...so i can write:
struct tcphdr *tcp_header1 = (struct
tcphdr*)skb_transport_header(skb), where skb is a certain packet.

now, studying some source code that i've found some days ago, i've seen this:

struct tcphdr *tcp_header2  = (void*)ip_hdr(skb) + ip_hdrlen(skb);

I immediately thought that the two lines were identical, but but I was
mistaken...in fact if i write this:

printk(KERN_INFO "diff: %d\n",(int)((void*)tcp_header2 - (void*)tcp_header1));

i see, "diff: 20"

so my question is: what's the difference between the two code lines?

thank you!

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-08-31 18:26 get tcp header Nicola Padovano
@ 2010-08-31 18:35 ` Jan Engelhardt
  2010-08-31 18:42   ` Nicola Padovano
  0 siblings, 1 reply; 17+ messages in thread
From: Jan Engelhardt @ 2010-08-31 18:35 UTC (permalink / raw)
  To: Nicola Padovano; +Cc: netfilter-devel

On Tuesday 2010-08-31 20:26, Nicola Padovano wrote:

>Hi guys! i know the skb_transport_header to grab the tcp header of a
>packet...so i can write:
>struct tcphdr *tcp_header1 = (struct
>tcphdr*)skb_transport_header(skb), where skb is a certain packet.
>
>now, studying some source code that i've found some days ago, i've seen this:
>
>struct tcphdr *tcp_header2  = (void*)ip_hdr(skb) + ip_hdrlen(skb);
>
>I immediately thought that the two lines were identical, but but I was
>mistaken...in fact if i write this:
>
>printk(KERN_INFO "diff: %d\n",(int)((void*)tcp_header2 - (void*)tcp_header1));
>
>i see, "diff: 20"
>
>so my question is: what's the difference between the two code lines?


skb_transport_header is also explained in the PDF, especially when it 
can not be used.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-08-31 18:35 ` Jan Engelhardt
@ 2010-08-31 18:42   ` Nicola Padovano
  2010-09-01  9:57     ` Nicola Padovano
  0 siblings, 1 reply; 17+ messages in thread
From: Nicola Padovano @ 2010-08-31 18:42 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

thank you Jan. I know, I'm not very respectful, sorry. I will
carefully read your pdf. and only after the reading I uso this mailing
list: i think that this is the way.
Good book, Jan, great work.

On Tue, Aug 31, 2010 at 8:35 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Tuesday 2010-08-31 20:26, Nicola Padovano wrote:
>
>>Hi guys! i know the skb_transport_header to grab the tcp header of a
>>packet...so i can write:
>>struct tcphdr *tcp_header1 = (struct
>>tcphdr*)skb_transport_header(skb), where skb is a certain packet.
>>
>>now, studying some source code that i've found some days ago, i've seen this:
>>
>>struct tcphdr *tcp_header2  = (void*)ip_hdr(skb) + ip_hdrlen(skb);
>>
>>I immediately thought that the two lines were identical, but but I was
>>mistaken...in fact if i write this:
>>
>>printk(KERN_INFO "diff: %d\n",(int)((void*)tcp_header2 - (void*)tcp_header1));
>>
>>i see, "diff: 20"
>>
>>so my question is: what's the difference between the two code lines?
>
>
> skb_transport_header is also explained in the PDF, especially when it
> can not be used.
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadov.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-08-31 18:42   ` Nicola Padovano
@ 2010-09-01  9:57     ` Nicola Padovano
  2010-09-01 10:53       ` Jan Engelhardt
  0 siblings, 1 reply; 17+ messages in thread
From: Nicola Padovano @ 2010-09-01  9:57 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

"If a packet is handled by a bridge, that is, a component that does not
deal with layer 3 or 4, there is no point in spending time to find the
start of the layer 3/4 header."

Ok, well: great. but in this case (bridge) also the skb_network_header
function is senseless because we don't have to find layer3 header.
isn't it?

in general: when i can use the skb_transport_header function?

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01  9:57     ` Nicola Padovano
@ 2010-09-01 10:53       ` Jan Engelhardt
  2010-09-01 11:48         ` Nicola Padovano
  2010-09-06 18:15         ` Nicola Padovano
  0 siblings, 2 replies; 17+ messages in thread
From: Jan Engelhardt @ 2010-09-01 10:53 UTC (permalink / raw)
  To: Nicola Padovano; +Cc: netfilter-devel

On Wednesday 2010-09-01 11:57, Nicola Padovano wrote:

>"If a packet is handled by a bridge, that is, a component that does not
>deal with layer 3 or 4, there is no point in spending time to find the
>start of the layer 3/4 header."
>
>Ok, well: great. but in this case (bridge) also the skb_network_header
>function is senseless because we don't have to find layer3 header.
>isn't it?

Correct.

>in general: when i can use the skb_transport_header function?

When a transport header pointer has been set. Which is when the 
appropriate layer-X function has processed it. (After ip_rcv for 
example)
On the output path, since it goes in the reverse direction, it will 
always be set.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 10:53       ` Jan Engelhardt
@ 2010-09-01 11:48         ` Nicola Padovano
  2010-09-01 12:15           ` Jan Engelhardt
  2010-09-01 12:18           ` Nicola Padovano
  2010-09-06 18:15         ` Nicola Padovano
  1 sibling, 2 replies; 17+ messages in thread
From: Nicola Padovano @ 2010-09-01 11:48 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

ok, Jan! Perfect.

But there is a last question: i've seen a source code that get a
packet just received from the Net: so -if I understand correctly- it
can't use skb_network_header (IP header) because when i get a packet
just received from the net i should have only the mac_header set.
isn't it?
But, i've seen the usage of skb_network_header...

On Wed, Sep 1, 2010 at 12:53 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Wednesday 2010-09-01 11:57, Nicola Padovano wrote:
>
>>"If a packet is handled by a bridge, that is, a component that does not
>>deal with layer 3 or 4, there is no point in spending time to find the
>>start of the layer 3/4 header."
>>
>>Ok, well: great. but in this case (bridge) also the skb_network_header
>>function is senseless because we don't have to find layer3 header.
>>isn't it?
>
> Correct.
>
>>in general: when i can use the skb_transport_header function?
>
> When a transport header pointer has been set. Which is when the
> appropriate layer-X function has processed it. (After ip_rcv for
> example)
> On the output path, since it goes in the reverse direction, it will
> always be set.
>
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 11:48         ` Nicola Padovano
@ 2010-09-01 12:15           ` Jan Engelhardt
  2010-09-01 12:18           ` Nicola Padovano
  1 sibling, 0 replies; 17+ messages in thread
From: Jan Engelhardt @ 2010-09-01 12:15 UTC (permalink / raw)
  To: Nicola Padovano; +Cc: netfilter-devel

On Wednesday 2010-09-01 13:48, Nicola Padovano wrote:

>ok, Jan! Perfect.
>
>But there is a last question: i've seen a source code that get a
>packet just received from the Net: so -if I understand correctly- it
>can't use skb_network_header (IP header) because when i get a packet
>just received from the net i should have only the mac_header set.
>isn't it?
>But, i've seen the usage of skb_network_header...

By the time ebtables is run, skb_mac_header is valid, by the time 
ip/6tables runs, skb_network_header is valid, and once tcp_rcv gets its 
turn to run (but then there is no more Xtables to do), 
skb_transport_header becomes valid.


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 11:48         ` Nicola Padovano
  2010-09-01 12:15           ` Jan Engelhardt
@ 2010-09-01 12:18           ` Nicola Padovano
  2010-09-01 12:45             ` Nicola Padovano
  2010-09-01 13:13             ` Jan Engelhardt
  1 sibling, 2 replies; 17+ messages in thread
From: Nicola Padovano @ 2010-09-01 12:18 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

maybe because the packet is sent firstly to the router and then the
router sends to my host a ip packet in which network_header is set? i
hope so...

On Wed, Sep 1, 2010 at 1:48 PM, Nicola Padovano
<nicola.padovano@gmail.com> wrote:
> ok, Jan! Perfect.
>
> But there is a last question: i've seen a source code that get a
> packet just received from the Net: so -if I understand correctly- it
> can't use skb_network_header (IP header) because when i get a packet
> just received from the net i should have only the mac_header set.
> isn't it?
> But, i've seen the usage of skb_network_header...
>
> On Wed, Sep 1, 2010 at 12:53 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>> On Wednesday 2010-09-01 11:57, Nicola Padovano wrote:
>>
>>>"If a packet is handled by a bridge, that is, a component that does not
>>>deal with layer 3 or 4, there is no point in spending time to find the
>>>start of the layer 3/4 header."
>>>
>>>Ok, well: great. but in this case (bridge) also the skb_network_header
>>>function is senseless because we don't have to find layer3 header.
>>>isn't it?
>>
>> Correct.
>>
>>>in general: when i can use the skb_transport_header function?
>>
>> When a transport header pointer has been set. Which is when the
>> appropriate layer-X function has processed it. (After ip_rcv for
>> example)
>> On the output path, since it goes in the reverse direction, it will
>> always be set.
>>
>>
>
>
>
> --
> Nicola Padovano
> e-mail: nicola.padovano@gmail.com
> web: http://npadovano.altervista.org
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 12:18           ` Nicola Padovano
@ 2010-09-01 12:45             ` Nicola Padovano
  2010-09-01 13:13             ` Jan Engelhardt
  1 sibling, 0 replies; 17+ messages in thread
From: Nicola Padovano @ 2010-09-01 12:45 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

ok.thanks. now is all clear...so if i write a new target for
NFPROTO_IPV4, the packet that i firstly receive in my target-hook
function is an _IP_ packet. isn't it?

On Wed, Sep 1, 2010 at 2:18 PM, Nicola Padovano
<nicola.padovano@gmail.com> wrote:
> maybe because the packet is sent firstly to the router and then the
> router sends to my host a ip packet in which network_header is set? i
> hope so...
>
> On Wed, Sep 1, 2010 at 1:48 PM, Nicola Padovano
> <nicola.padovano@gmail.com> wrote:
>> ok, Jan! Perfect.
>>
>> But there is a last question: i've seen a source code that get a
>> packet just received from the Net: so -if I understand correctly- it
>> can't use skb_network_header (IP header) because when i get a packet
>> just received from the net i should have only the mac_header set.
>> isn't it?
>> But, i've seen the usage of skb_network_header...
>>
>> On Wed, Sep 1, 2010 at 12:53 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
>>> On Wednesday 2010-09-01 11:57, Nicola Padovano wrote:
>>>
>>>>"If a packet is handled by a bridge, that is, a component that does not
>>>>deal with layer 3 or 4, there is no point in spending time to find the
>>>>start of the layer 3/4 header."
>>>>
>>>>Ok, well: great. but in this case (bridge) also the skb_network_header
>>>>function is senseless because we don't have to find layer3 header.
>>>>isn't it?
>>>
>>> Correct.
>>>
>>>>in general: when i can use the skb_transport_header function?
>>>
>>> When a transport header pointer has been set. Which is when the
>>> appropriate layer-X function has processed it. (After ip_rcv for
>>> example)
>>> On the output path, since it goes in the reverse direction, it will
>>> always be set.
>>>
>>>
>>
>>
>>
>> --
>> Nicola Padovano
>> e-mail: nicola.padovano@gmail.com
>> web: http://npadovano.altervista.org
>>
>
>
>
> --
> Nicola Padovano
> e-mail: nicola.padovano@gmail.com
> web: http://npadovano.altervista.org
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 12:18           ` Nicola Padovano
  2010-09-01 12:45             ` Nicola Padovano
@ 2010-09-01 13:13             ` Jan Engelhardt
  2010-09-01 13:20               ` Nicola Padovano
  1 sibling, 1 reply; 17+ messages in thread
From: Jan Engelhardt @ 2010-09-01 13:13 UTC (permalink / raw)
  To: Nicola Padovano; +Cc: netfilter-devel

On Wednesday 2010-09-01 14:18, Nicola Padovano wrote:

>maybe because the packet is sent firstly to the router and then the
>router sends to my host a ip packet in which network_header is set? i
>hope so...

NH is not stored in the packet.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 13:13             ` Jan Engelhardt
@ 2010-09-01 13:20               ` Nicola Padovano
  2010-09-01 15:23                 ` Nicola Padovano
  0 siblings, 1 reply; 17+ messages in thread
From: Nicola Padovano @ 2010-09-01 13:20 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

discard that mail :)

On Wed, Sep 1, 2010 at 3:13 PM, Jan Engelhardt <jengelh@medozas.de> wrote:
> On Wednesday 2010-09-01 14:18, Nicola Padovano wrote:
>
>>maybe because the packet is sent firstly to the router and then the
>>router sends to my host a ip packet in which network_header is set? i
>>hope so...
>
> NH is not stored in the packet.
>



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 13:20               ` Nicola Padovano
@ 2010-09-01 15:23                 ` Nicola Padovano
  2010-09-01 19:26                   ` Jan Engelhardt
  0 siblings, 1 reply; 17+ messages in thread
From: Nicola Padovano @ 2010-09-01 15:23 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

These are my last questions.

- i've specified in my code NFPROTO_IPV4 (family field in xt_target
struct), this means that my packet is at layer 3? i.e. the layer 2
function has already processed it?

- suppose that we are in layer N: skb->data and skb->tail mark the
beginning and the end of header+data of layer N?

thank you all guys, in primis Jan.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 15:23                 ` Nicola Padovano
@ 2010-09-01 19:26                   ` Jan Engelhardt
  2010-09-01 21:34                     ` Nicola Padovano
  0 siblings, 1 reply; 17+ messages in thread
From: Jan Engelhardt @ 2010-09-01 19:26 UTC (permalink / raw)
  To: Nicola Padovano; +Cc: netfilter-devel

On Wednesday 2010-09-01 17:23, Nicola Padovano wrote:

>These are my last questions.
>
>- i've specified in my code NFPROTO_IPV4 (family field in xt_target
>struct), this means that my packet is at layer 3? i.e. the layer 2
>function has already processed it?

It merely means that the function is only designed to be executed by 
ip4tables.

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 19:26                   ` Jan Engelhardt
@ 2010-09-01 21:34                     ` Nicola Padovano
  2010-09-01 21:50                       ` Jan Engelhardt
  0 siblings, 1 reply; 17+ messages in thread
From: Nicola Padovano @ 2010-09-01 21:34 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

> It merely means that the function is only designed to be executed by
> ip4tables.
yes, but this also means that when i receive a packet (=the skb
pointer of target function) its data pointer points to the beginning
of ip header (remember that skb->data and skb->tail mark the beginning
and the end of header+payload of the layer X).
am i right?


-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 21:34                     ` Nicola Padovano
@ 2010-09-01 21:50                       ` Jan Engelhardt
  0 siblings, 0 replies; 17+ messages in thread
From: Jan Engelhardt @ 2010-09-01 21:50 UTC (permalink / raw)
  To: Nicola Padovano; +Cc: netfilter-devel

On Wednesday 2010-09-01 23:34, Nicola Padovano wrote:

>> It merely means that the function is only designed to be executed by
>> ip4tables.
>yes, but this also means that when i receive a packet (=the skb
>pointer of target function) its data pointer points to the beginning
>of ip header (remember that skb->data and skb->tail mark the beginning
>and the end of header+payload of the layer X).
>am i right?

Yes, that happens to be the case. But that's why you use 
skb_{mac,network,transport}_header anyway, because that is more 
invariant than skb->data. (Provided restrictions on its use are obeyed.)

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-01 10:53       ` Jan Engelhardt
  2010-09-01 11:48         ` Nicola Padovano
@ 2010-09-06 18:15         ` Nicola Padovano
  2010-09-07 11:31           ` Nicola Padovano
  1 sibling, 1 reply; 17+ messages in thread
From: Nicola Padovano @ 2010-09-06 18:15 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

Hi all! Some days ago we said:

ME: in general: when i can use the skb_transport_header function?

JAN: When a transport header pointer has been set. Which is when the
 appropriate layer-X function has processed it. (After ip_rcv for
 example)
 On the output path, since it goes in the reverse direction, it will
 always be set.

so, today i checked this.
this is my iptables rule:

iptables -t filter -A OUTPUT -d 192.168.0.1 -p tcp -j TAR

and this is the code's lines of xt_TAR module

printk(KERN_INFO "xt_TAR-----> tcp header: %p\n",skb_transport_header(skb));
printk(KERN_INFO "xt_TAR-----> ip header: %p\n",skb_network_header(skb));

but the skb_transport_header returns the same value of
skb_network_header, so even though we are on the output path, the
transport_header is not set...........

what's wrong?



-- 
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: get tcp header
  2010-09-06 18:15         ` Nicola Padovano
@ 2010-09-07 11:31           ` Nicola Padovano
  0 siblings, 0 replies; 17+ messages in thread
From: Nicola Padovano @ 2010-09-07 11:31 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: netfilter-devel

(I'm not sure I sent this mail, sorry if you already have one)

ME: in general: when i can use the skb_transport_header function?

JAN: When a transport header pointer has been set. Which is when the
appropriate layer-X function has processed it. (After ip_rcv for
example)
On the output path, since it goes in the reverse direction, it will
always be set.

so, today i checked this.
this is my iptables rule:

iptables -t filter -A OUTPUT -d 192.168.0.1 -p tcp -j TAR

and this is the code's lines of xt_TAR module

printk(KERN_INFO "xt_TAR-----> tcp header: %p\n",skb_transport_header(skb));
printk(KERN_INFO "xt_TAR-----> ip header: %p\n",skb_network_header(skb));

but the skb_transport_header returns the same value of
skb_network_header, so even though we are on the output path, the
transport_header is not set...........

what's wrong?

--
Nicola Padovano
e-mail: nicola.padovano@gmail.com
web: http://npadovano.altervista.org

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2010-09-07 11:38 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-31 18:26 get tcp header Nicola Padovano
2010-08-31 18:35 ` Jan Engelhardt
2010-08-31 18:42   ` Nicola Padovano
2010-09-01  9:57     ` Nicola Padovano
2010-09-01 10:53       ` Jan Engelhardt
2010-09-01 11:48         ` Nicola Padovano
2010-09-01 12:15           ` Jan Engelhardt
2010-09-01 12:18           ` Nicola Padovano
2010-09-01 12:45             ` Nicola Padovano
2010-09-01 13:13             ` Jan Engelhardt
2010-09-01 13:20               ` Nicola Padovano
2010-09-01 15:23                 ` Nicola Padovano
2010-09-01 19:26                   ` Jan Engelhardt
2010-09-01 21:34                     ` Nicola Padovano
2010-09-01 21:50                       ` Jan Engelhardt
2010-09-06 18:15         ` Nicola Padovano
2010-09-07 11:31           ` Nicola Padovano

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.