Re: pkg/55446: scapy function send() does not work

[tmp%bh0.amt.ru@localhost]

The following reply was made to PR pkg/55446; it has been noted by GNATS.

From: tmp%bh0.amt.ru@localhost
To: gnats-bugs%netbsd.org@localhost
Cc: tmp%bh0.amt.ru@localhost
Subject: Re: pkg/55446: scapy function send() does not work
Date: Fri, 3 Jul 2020 16:35:09 +0300

 Hello.
 
 I'd like to clarify the environment of the bug:
 (1) I have no active Ethernet or SLIP interfaces;
 (2) I have active Wi-Fi and tun interfaces.
 
 According to the "man 4 bpf": "A packet can be sent out on the network
 by writing to a bpf file descriptor.  The writes are unbuffered, meaning
 only one packet can be processed per write.  Currently, only writes to
 Ethernets and SLIP links are supported."
 
 So I included "conf.use_pcap=True" to the script, ran it, the packet was
 sent, but the tcpdump showed the packet not on the lo0 interface but on
 the Wi-Fi interface iwi0:
 
 # tcpdump -s 1700 -l# -n -e -tttt -i iwi0 icmp 
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on iwi0, link-type EN10MB (Ethernet), capture size 1700 bytes
     1  2020-07-03 15:08:35.862011 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 46: 127.0.0.1 > 127.0.0.1: ICMP echo request, id 0, seq 0, length 12
 
 # ifconfig -a
 bge0: flags=0x8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
         capabilities=3f00<IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx,TCP4CSUM_Tx>
         capabilities=3f00<UDP4CSUM_Rx,UDP4CSUM_Tx>
         enabled=0
         ec_capabilities=3<VLAN_MTU,VLAN_HWTAGGING>
         ec_enabled=0
         address: 02:00:00:00:00:21
         media: Ethernet autoselect (none)
         status: no carrier
 iwi0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         ssid TEST nwkey:[cut]
         powersave off
         bssid 02:00:00:00:00:01 chan 1
         address: 02:00:00:00:00:11
         media: IEEE802.11 autoselect (OFDM54)
         status: active
         inet 192.0.2.103/24 broadcast 192.0.2.255 flags 0x0
 lo0: flags=0x8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33176
         inet 127.0.0.1/8 flags 0x0
 tun4: flags=0x51<UP,POINTOPOINT,RUNNING> mtu 1143
         inet 198.51.100.29/32 -> 198.51.100.29 flags 0x0
 
 # netstat -rn -f inet
 Routing tables
 Internet:
 Destination        Gateway            Flags    Refs      Use    Mtu Interface
 default            198.51.100.29      UGS         -        -      -  tun4
 198.51.100/24      198.51.100.29      UGS         -        -      -  tun4
 198.51.100.29      198.51.100.29      UH          -        -      -  tun4
 192.0.2/24         link#2             UC          -        -      -  iwi0
 192.0.2.103        link#2             UHl         -        -      -  lo0
 192.0.2.1          02:00:00:00:00:01  UHL         -        -      -  iwi0
 1.1.1.1            192.0.2.1          UGHS        -        -      -  iwi0
 127/8              127.0.0.1          UGS         -        -  33176  lo0
 
 Also I tried to use without success remote IP address:
 
 # cat .BUG.NetBSD-8.2.scapy.send.py 
 #! /usr/pkg/bin/python3.7
 
 from scapy.all import *
 
 conf.use_pcap=True
 p=IP(dst="203.0.113.11")/ICMP()/"test"
 p.show()
 send(p)
 
 
 # ./.BUG.NetBSD-8.2.scapy.send.py
 ###[ IP ]### 
   version   = 4
   ihl       = None
   tos       = 0x0
   len       = None
   id        = 1
   flags     = 
   frag      = 0
   ttl       = 64
   proto     = icmp
   chksum    = None
   src       = 198.51.100.29
   dst       = 203.0.113.11
   \options   \
 ###[ ICMP ]### 
      type      = echo-request
      code      = 0
      chksum    = None
      id        = 0x0
      seq       = 0x0
 ###[ Raw ]### 
         load      = 'test'
 
 .
 Sent 1 packets.
 
 
 The tcpdump showed the packet not on the tun4 interface but on the Wi-Fi
 interface iwi0 as before:
 
 # tcpdump -s 1700 -l# -n -e -tttt -i iwi0 icmp 
 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on iwi0, link-type EN10MB (Ethernet), capture size 1700 bytes
     1  2020-07-03 16:11:04.396154 00:00:00:00:00:00 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 46: 198.51.100.29 > 203.0.113.11: ICMP echo request, id 0, seq 0, length 12
 ^C
 1 packet captured
 49 packets received by filter
 0 packets dropped by kernel
 
 
 PS. tun4 is an "openconnect" (http://www.infradead.org/openconnect/) VPN
 interface so the traffic via the default route is encrypted on the Wi-Fi
 interface iwi0.
 
 
 --
 Alexei
 
 
 On 07/02/20 14:55, gnats-admin%netbsd.org@localhost wrote:
 > Thank you very much for your problem report.
 > It has the internal identification `pkg/55446'.
 > The individual assigned to look at your
 > report is: pkg-manager. 
 >
 >> Category:       pkg
 >> Responsible:    pkg-manager
 >> Synopsis:       scapy function send() does not work
 >> Arrival-Date:   Thu Jul 02 11:55:00 +0000 2020