Re: Rx packets are not captured on physical

[Lakshmana Reddy <rvlreddy.tech () gmail com>]

 Aaron,

Thanks for the pointer..
I did further investigation and figured that the PF_PACKET socket does not
capture the Rx packets , it always captures the Rx packets..
I did a try a small socket program to sniff the packets below is the code
snippet..

-----------------
...
....
if ( (sock=socket(PF_PACKET, SOCK_RAW,
                    htons(ETH_P_ALL)))<0) {
    perror("socket");
    exit(1);
  }

/* Get Interface index */
  strncpy((char *)ifr.ifr_name, device, IFNAMSIZ);
  if((ioctl(sock, SIOCGIFFLAGS, &ifr)) == -1) {
                perror("ioctl");
                printf("Error getting Interface index !\n");
                close(sock);
                exit(1);
        }
if (ioctl(sock, SIOCGIFINDEX, &ifr) < 0){
        perror("ioctl");
        close(sock);
        exit(1);
 }

/* Set flags */
  sll.sll_family = AF_PACKET;
  sll.sll_ifindex = ifr.ifr_ifindex;
  sll.sll_protocol =htons(ETH_P_ALL);

/* bind to interface */
  if((bind(sock, (struct sockaddr *)&sll, sizeof(sll)))== -1) {
         perror("Error binding raw socket to interface\n");
         exit(1);
   }


  while (1) {
    printf("----------\n");
    n = recvfrom(sock,buffer,2048,0,NULL,NULL);
    printf("%d bytes read\n",n);
...
...
}
----------------
below is the output i get...its is clear from the output that on eth2 only
TX packets are captured where as from veth0 all the packets are captured..
I am wondering if there is any .config parameter need to be configured for
PF_PACKET family to capture all the packets on physical interface when
bonded.
Any comment or pointers are much appreciated..

-----------
-bash-3.00# ifconfig veth0
veth0     Link encap:Ethernet  HWaddr 00:15:17:29:F7:80
          inet addr:192.168.11.144  Bcast:192.168.11.255  Mask:255.255.252.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:41489453 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15600 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:4232122294 (3.9 GiB)  TX bytes:5797281 (5.5 MiB)

-bash-3.00# ./pf_socket eth2
sniffing device: eth2
interface index :6211
----------
98 bytes read
Source MAC address: 00:21:a1:4a:74:00
Destination MAC address: 00:15:17:29:f7:80
Source host 192.168.11.144
Dest host 10.24.29.16
Source,Dest ports 0,30147
Layer-4 protocol 1
----------
98 bytes read
Source MAC address: 00:21:a1:4a:74:00
Destination MAC address: 00:15:17:29:f7:80
Source host 192.168.11.144
Dest host 10.24.29.16
Source,Dest ports 0,32194
Layer-4 protocol 1
----------
98 bytes read
Source MAC address: 00:21:a1:4a:74:00
Destination MAC address: 00:15:17:29:f7:80
Source host 192.168.11.144
Dest host 10.24.29.16
Source,Dest ports 0,33985
Layer-4 protocol 1
----------

-bash-3.00# ./pf_socket veth0 | grep -C 4 10.24
----------
98 bytes read
Source MAC address: 00:15:17:29:f7:80
Destination MAC address: 00:21:a1:4a:74:00
Source host 10.24.29.16
Dest host 192.168.11.144
Source,Dest ports 2048,24995
Layer-4 protocol 1
----------
98 bytes read
Source MAC address: 00:21:a1:4a:74:00
Destination MAC address: 00:15:17:29:f7:80
Source host 192.168.11.144
Dest host 10.24.29.16
Source,Dest ports 0,27043
Layer-4 protocol 1
----------
60 bytes read
--
----------
98 bytes read
Source MAC address: 00:15:17:29:f7:80
Destination MAC address: 00:21:a1:4a:74:00
Source host 10.24.29.16
Dest host 192.168.11.144
Source,Dest ports 2048,26786
Layer-4 protocol 1
----------
98 bytes read
Source MAC address: 00:21:a1:4a:74:00
Destination MAC address: 00:15:17:29:f7:80
Source host 192.168.11.144
Dest host 10.24.29.16
Source,Dest ports 0,28834
Layer-4 protocol 1
----------

Thanks in advance,
Lakshmana


On Fri, Jun 19, 2009 at 9:58 AM, Aaron Turner <synfinatic () gmail com> wrote:

> On Thu, Jun 18, 2009 at 11:30 PM, Lakshmana
> Reddy<rvlreddy.tech () gmail com> wrote:
>
> [snip]
>
> > I walked through the tcpdump/pcap code to see what going on.. so far my
> > understanding is that the pcap_loop(), to capture the packets on the
> given
> > device invokes the recvfrom() sys call to get the raw packets from the
> > kernel and parses them before passing to a call back. I am wondering
> where
> > would the Rx packets lost in this code path.
> >
> > Can somebody shed some light on this..
>
>
> You'd need to look at the Linux kernel's PF_PACKET implementation to
> understand why this is happening.  tcpdump uses libpcap which uses the
> PF_PACKET socket API to read frames.
>
> --
> Aaron Turner
> http://synfin.net/
> http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix &
> Windows
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety.
>    -- Benjamin Franklin
> -
> This is the tcpdump-workers list.
> Visit https://cod.sandelman.ca/ to unsubscribe.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.