Re: Can I be able to use Libpcap for capturing packets on Unix socket by the following way described in the body of the mail

[<santosh.soule () wipro com>]

-----Original Message-----
From: tcpdump-workers-owner () lists tcpdump org
[mailto:tcpdump-workers-owner () lists tcpdump org] On Behalf Of Jefferson
Ogata
Sent: Tuesday, March 21, 2006 3:26 AM
To: tcpdump-workers () lists tcpdump org
Subject: Re: [tcpdump-workers] Can I be able to use Libpcap for
capturing packets on Unix socket by the following way described in the
body of the mail

On 03/13/2006 01:28 AM, Santosh wrote:
> I need a clarification regarding Libpcap library. What I am doing is
> instead of writing the packets on to ethernet interface, I am writing
> on to the Unix socket.
> I am using Libnet library for building and injecting the packets. I
> have modified the Libnet library for supporting Unix sockets. For
> capturing the packets on unix sockets I am thinking of using Libpcap
library.

The concept of "capturing" on UNIX-domain sockets doesn't really make
much sense. One doesn't use libpcap to capture on an Internet-domain
socket; one captures on an interface. Traffic from multiple
Internet-domain sockets, as well as non-socket-based traffic (e.g. ICMP
messages), is multiplexed over an interface by necessity, since the
interface is the egress for network traffic from the host. The interface
thus provides the observation point for capturing to occur.

There is no parallel with UNIX-domain sockets. There is no API I know of
for a third party to observe UNIX-domain datagrams as they traverse from
socket to socket.

In short, I don't understand what you are trying to achieve. If you want
to monitor stream-based UNIX-domain socket activity, the only way I know
of is to act as a proxy between your client and server.

If you want to write a traffic log from your server or client, and wish
simply to use libpcap format, well, what's the point? There are no IP or
other protocol headers on UNIX-domain messages, so it's not as if you
will then be able to use other existing tools to analyze the traffic,
since your messages aren't IP packets.

> > Thanks for the response. My scenario is I want to communicate between
a server(which is my DSLAM or u can call it as Central Office
Equipment). This I have got a simulator of which actually acts as the
DSLAM(I don't know whether you have any idear about DSLAM ie Digital
Service Line Access Manager).
And I have got one of my application which is basically a traffic
generator(it can pump both type of traffic ATM & Ethernet). Right now I
have made it to support ETH, ICMP, IGMP, PPP, PPPoE, IP, BOOTP-DHCP,
L2CP, RIP, RADIUS". My application uses Libnet library to build the
packet and Packet capturing library to capture the packtes.

And I had clearly mentioned in my previous mail how I will be capturing
the packets.
My application act's as the Client and host(which is a simulator or we
can say it a DSLAM) is a server and both are running on the same
machine. There's a requirement that both these process should use Unix
socket to communicte with each other. And as I had mentioned, I am using
libnet library to build the packets. With this library I build all the
required headers for the particular protocol and write it on to the unix
socket.
Now server application will read the request and will respond back on to
the unix socket and this response must be captured. For capturing this
instead of writing new library my idea was to modify the libpcap
library(which supports capturing only on hardware interface)to support
unix socket.
As per your comment there are no IP or other protocol headers on UNIX
domain messages. I am building the packet and I am writing it on to the
unix socket. I have the whole packet(including all the
headers),basically a buffer. I can parse that buffer and apply the
respective filters.

When the server responds with its message, it will write on to the unix
socket which is just going to be the hex dump. I need to convert it to
the libpcap file format which I will be passing to the
pcap_open_offline() function. I don't see any problem here. And I don't
think I will require BPF also because BPF basically is used to filter
the unwanted packtes on the hardware interface instead of capturing all
the packets and storing it in a buffer.

Once I have the packet in a  tcpdump format I can apply any filter on to
that by parsing the packet.

DSLAM: DSLAM sits in the telephone exchange.
In the real life scenario setup will be something like, User logged in
to a PC which is connected to a Modem and modem is connected to
DSLAM(which will be in any telephone exchange). Basically DSLAM will
parse the voice and data coming from the modem. Voice will be
transmitted to the PSTN network and data will be forwarded to the ATM
backbone which is connected to some ISP. This is what is real time
scenario.

Now in my case, I have got DSLAM simulator and traffic generator both
running on the same Linux PC.

--
Jefferson Ogata <Jefferson.Ogata () noaa gov> NOAA Computer Incident
Response Team (N-CIRT) <ncirt () noaa gov> "Never try to retrieve anything
from a bear."--National Park Service
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


The information contained in this electronic message and any attachments to this message are intended for the exclusive 
use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately 
and destroy all copies of this message and any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for 
the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

www.wipro.com
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.