NF_STOLEN effect on TCP

NF_STOLEN effect on TCP

[A K A]

(include my address in the replies, i am not
subscribed to the list).


hello all,



Ok I have been stuck on this for tooo long and cant
figure it out. I have made an LKM which registers to
NF_POST_ROUTING hook. it gets a packet and if matches
a certain criterion then it puts it on to my private
Queue and returns NF_STOLEN. By putting the packet on
the Queue I am delaying the packets by arround 4 ms.

Now here is the problem for the case of a TCP packet:
A TCP SYN was selected to be delayed. So my hook
returns NF_STOLEN and the packet is sent 4 ms latter
using ip_send(), initated by an ioctl called from a
user application. next my host receives a syn+ack
and imediately sends an ack. However the first data
packet is sent out at a delay arround 4ms also. which
is very odd. cuz in the user application the send
function is called right after connect. I was
expecting only the syn packet to be affected because
of my delay, but there is some sort of reaction.

I dont think that its because of some RTT calculations
because when i send the SYN packet imdediately and
delay it at the peer then the first data packet goes
on fine.

Now I have been stuck with this damn thing for a long
while and cant figure out---is it the stealing that
results in this. is this some expected behavior of
TCP. .. please can u help me with this soon.


regards,

Asad

ps: i can send you a trace plot of the tcp seq vs time
as an attachment if you would like to see it.

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

Problem with FORWARD hook

[Leonid Veytser]

When I dump the output of all the packets traveling thru my machine, I
notice that none go thru FORWARD hook. So, I tried to make a packet have
to go thru the FORWARD hook (ie by changing the packet dest at PREROUTING
hook), but the packet never goes to the FORWARD hook, but disappears.

Can there be some incorrect configuration on my machine that would cause
it not to be able to forward packets?

Thanks.

RE: Problem with FORWARD hook

[Stuart J. Browne]

>-----Original Message-----
>From: netfilter-admin@lists.netfilter.org 
>[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of 
>Leonid Veytser
>Sent: Wednesday, 12 November 2003 07:59
>To: netfilter@lists.netfilter.org
>Subject: Problem with FORWARD hook
>
>
>When I dump the output of all the packets traveling thru my machine, I
>notice that none go thru FORWARD hook. So, I tried to make a 
>packet have
>to go thru the FORWARD hook (ie by changing the packet dest at 
>PREROUTING
>hook), but the packet never goes to the FORWARD hook, but disappears.
>
>Can there be some incorrect configuration on my machine that 
>would cause
>it not to be able to forward packets?


When you say "FORWARD hook", do you mean the FORWARD chain on the filter
table?

If so, you need to understand when packets would normally go throughte
FORWARD chain.

If the packet is sourced from another machine (physically, not
logically), and destined for another machine (once again, not
logically), it will go through the FORWARD chain.

If it comes from the local machine, or is destined for the local
machine, it will not touch the FORWARD chain.

I beleive this is detailed in the netfilter FAQ and HOWTO's.  They've
got some nice flow diagrams there too!

bkx

Re: Problem with FORWARD hook

[Antony Stone]

On Tuesday 11 November 2003 9:59 pm, Leonid Veytser wrote:

> When I dump the output of all the packets traveling thru my machine, I
> notice that none go thru FORWARD hook.

There's no other way packets are going to get routed through your machine 
except by passing through the FORWARD chain.

> So, I tried to make a packet have
> to go thru the FORWARD hook (ie by changing the packet dest at PREROUTING
> hook), but the packet never goes to the FORWARD hook, but disappears.

Show us an example of your rules so we can see what you are trying to do.

> Can there be some incorrect configuration on my machine that would cause
> it not to be able to forward packets?

There are many ways of (mis)configuring a machine so that it doesn't forward 
packets.   Some people might say this is a highly secure router :)

Antony.

-- 

Your email has been returned due to insufficient voltage.
                                                     Please reply to the list;
                                                           please don't CC me.

NF_QUEUE target and ip_queue.c

[Leonid Veytser]

Could someone explain this from ip_queue.c at ipq_mangle_ipv4 function:

/*
 * Extra routing may needed on local out, as the QUEUE target never
 * returns control to the table.
 */

Thanks.

Re: Problem with FORWARD hook

[Leonid Veytser]

I have figured out what my problem was. My machine had ip forwarding
disabled.

Thanks for you help.

On Tue, 11 Nov 2003, Antony Stone wrote:

> On Tuesday 11 November 2003 9:59 pm, Leonid Veytser wrote:
> 
> > When I dump the output of all the packets traveling thru my machine, I
> > notice that none go thru FORWARD hook.
> 
> There's no other way packets are going to get routed through your machine 
> except by passing through the FORWARD chain.
> 
> > So, I tried to make a packet have
> > to go thru the FORWARD hook (ie by changing the packet dest at PREROUTING
> > hook), but the packet never goes to the FORWARD hook, but disappears.
> 
> Show us an example of your rules so we can see what you are trying to do.
> 
> > Can there be some incorrect configuration on my machine that would cause
> > it not to be able to forward packets?
> 
> There are many ways of (mis)configuring a machine so that it doesn't forward 
> packets.   Some people might say this is a highly secure router :)
> 
> Antony.
> 
> -- 
> 
> Your email has been returned due to insufficient voltage.
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
> 

Checksumming Issues

[Leonid Veytser]

A general question about checksumming. If I change the destination address
in the IP header, then of course I need to recalculate the IP header
checksum. But do I have to recalculate the checksum of the next protocol
header (ie TCP, UDP, etc)?

Thanks.

Re: Checksumming Issues

[Antony Stone]

On Friday 21 November 2003 8:15 pm, Leonid Veytser wrote:

> A general question about checksumming. If I change the destination address
> in the IP header, then of course I need to recalculate the IP header
> checksum.

"You" the user (or system administrator) do not need to recalculate any 
checksums - the SNAT or DNAT code does this for you.

> But do I have to recalculate the checksum of the next protocol
> header (ie TCP, UDP, etc)?

No.   Everything is handled for you in the background.   Anyway, if you only 
change the IP address (source and/or destination), the TCP or UDP checksum 
remains valid.

Antony.

-- 

Feeling bad at breakfast because you don't have a hangover is evidence of a 
complex emotional life it can take many years to perfect.

 - Pete McCarthy, The Road to McCarthy
                                                     Please reply to the list;
                                                           please don't CC me.