[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nfr-users
Subject:    Re: TCP packet assembly
From:       Fredrik Widlund <fredrik.widlund () defcom-sec ! com>
Date:       2000-03-22 10:02:08
[Download RAW message or body]

X-Mozilla-Status2: 00000000
Message-ID: <38D7EF40.C1FCD364@defcom-sec.com>
Date: Tue, 21 Mar 2000 22:53:05 +0100
From: Fredrik Widlund <fredrik.widlund@defcom-sec.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; OpenBSD 2.6 i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Van Epp <vanepp@sfu.ca>
Subject: Re: TCP packet assembly
References: <200003181635.IAA03743@fraser.sfu.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The natural solution is even higher up in the hierarki. libpcap only triggers a \
function for each packet. The function is called intfPacket() and lives in intf.c in \
the nfrd. The problem is that you need to use multiple libpcap handlers, and that \
libpcap is blocking.

One solution is to modify libpcap to use poll or select to handle multiple \
interfaces. Another to bypass it and use bpf directly. If you want to avoid a \
hardcoded solution intf.c also needs to be modified.

A third is to hardcode it into the kernel... probably the most simple and ugly \
solution.

Fredrik Widlund
Defcom Security

Peter Van Epp wrote:

> > 
> > In theory Yes, of course. That is what TCP re-assemble queue meant for. Basically \
> > if packets comes from different routes (interfaces), it is more than likely they \
> > would be out of order, they will stay in the re-assemble queue until the segment \
> > "hole" been patched. But in practical, it is not possible unless you are running \
> > some sort of multilink PPP. Because you can't have both FE interfaces share the \
> > same IP address, and the packet destinates to THE IP address will always coming \
> > from the same interface. In case of multilink PPP, the packet reassemble is down \
> > at link layer, TCP doesn't have to worry about. 
> > huizhao
> > 
> 
> I don't think the adapter IP addresses are a problem since both
> adapters will be in promiscuous mode their addresses are irrelevant. Since
> this is a full duplex link one adapter will capture the "to" packets as normal
> the other receive side is capturing the "from" traffic the real router is
> sending. The MAC addresses in the packets will be correct (on "to" the
> router MAC will be the destination, on "from" the router MAC will be the
> source). The result (at the libpcap layer) is as if there was a single
> interface capturing a half duplex stream with the exception that the time
> stamps for the packets could be identical for transmit and receive or could be
> overlapping each other (which is likely less exciting). I think what wants to
> happen is a mod at the libpcap level to allow one libpcap interface to specify
> data from the two interface cards is one data stream to the normal libpcap
> output stream which should then just work as far as NFR (or Argus) is
> concerned. This may already be in libpcap, since it seems like such an obvious
> need (unless there is something I'm not seeing).
> Since I'm far
> from an expert in this area, but am interested in trying to implement this
> I'd appreciate an explaination of where I'm wrong here (if I am).
> 
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
> 
> ****************************************************************
> TO POST A MESSAGE on this list, send it to nfr-users@lists.nfr.net.
> TO UNSUBSCRIBE from this list, send the following text in the
> message body (not subject line) to majordomo@lists.nfr.net
> 
> unsubscribe nfr-users Your-Email-Address
> ****************************************************************


****************************************************************
TO POST A MESSAGE on this list, send it to nfr-users@lists.nfr.net.
TO UNSUBSCRIBE from this list, send the following text in the
message body (not subject line) to majordomo@lists.nfr.net

unsubscribe nfr-users Your-Email-Address
****************************************************************


[prev in list] [next in list] [prev in thread] [next in thread]