ICMP conntrack

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Antony Stone wrote:
> =

> On Friday 18 October 2002 10:05 am, Cedric Blancher wrote:
> =

> > Le ven 18/10/2002 =E0 10:28, Antony Stone a =E9crit :
> > > > I was wondering why I'm not getting any conntrack entires for icm=
p
> > > > connections?
> > >
> > > There is no concept of a "connection" for ICMP.
> >
> > Yes it's true, but for some, you have a request/reply concept.
> =

> Yes, I realised that was the only exception after I posted my reply.
> =

> > > A single ICMP packet is sent to indicate some situation has occurre=
d.
> > > There's no reply, there's no follow-up packet, therefore there's no=
 need
> > > to keeptrack of a "connection" for something which consists of only=
 a
> > > single packet.
> >
> > Two cases :
> >
> >       request/reply : echo, timestamp, address mask and info
> >               First packet (request) is NEW, others (replies) are
> >               ESTABLISHED ; entries have a 30s timeout.
> >               If a unsolicitated reply is received, then INVALID.
> =

> Indeed.
> =

> >       ICMP erros : ICMP payload is a quotation extracted from the IP
> >               packet that has generated the error. This quotation is
> >               used to identify the related session in conntrack table=
=2E
> >               If ICMP match an active entry, then it's RELATED. If
> >               not, it's INVALID.
> =

> Although I agree with what you've said here, it's not really relevant t=
o the
> original poster's question, because in these cases you'll still never s=
ee an
> ICMP entry in the connection tracking table.   Because the ICMP packets=
 are
> RELATED to the original connection, it's the original packet which you'=
ll see
> in the conntrack table - the ICMP replies simply get through because of=
 their
> relationship to the original packet.
> =

> > So, for ICMP requests, you have some kind of conntrack, based on ICMP=

> > sequence number. For ICMP errors, conntrack tries to associate them t=
o
> > an existing entry.
> =

> ICMP sequence number ???   What's that ?

Results of a ping to www.ncftpd.com :

64 bytes from ncftpd.com (209.197.102.38): icmp_seq=3D11055 ttl=3D44
time=3D311.029 msec
64 bytes from ncftpd.com (209.197.102.38): icmp_seq=3D11056 ttl=3D44
time=3D308.126 msec
64 bytes from ncftpd.com (209.197.102.38): icmp_seq=3D11057 ttl=3D44
time=3D308.430 msec
64 bytes from ncftpd.com (209.197.102.38): icmp_seq=3D11058 ttl=3D44
time=3D302.321 msec

And the entries in conntrack related to the above is:
icmp     1 29 src=3D192.168.1.229 dst=3D209.197.102.38 type=3D8 code=3D0
id=3D59475 src=3D209.197.102.38 dst=3D192.168.1.229 type=3D0 code=3D0 id=3D=
59475
use=3D1 =


However if I try to ping a nearer host, there would be no entry in the
conntrack table at all.

-- =

Vincent Lim
Software Engineer
NESTAC Solution Sdn Bhd
vincent.lim@nestac.com | +(6012) 659-6609



[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux