Comment 5 for bug 96753

Revision history for this message
Jim Cheetham (jim.cheetham) wrote :

My scapy (1.0.4-1) cannot be invoked from the command line without crashing :-
$ scapy -h
/usr/bin/scapy:3101: Warning: 'with' will become a reserved keyword in Python 2.6
/usr/bin/scapy:3103: Warning: 'with' will become a reserved keyword in Python 2.6
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump()
Traceback (most recent call last):
  File "/usr/bin/scapy", line 10647, in <module>
    class Conf(ConfClass):
  File "/usr/bin/scapy", line 10693, in Conf
    route = Route()
  File "/usr/bin/scapy", line 1911, in __init__
    self.resync()
  File "/usr/bin/scapy", line 1915, in resync
    self.routes = read_routes()
  File "/usr/bin/scapy", line 2234, in read_routes
    ifreq = ioctl(s, SIOCGIFADDR,struct.pack("16s16x",iff))
IOError: [Errno 99] Cannot assign requested address

I have one interface up, and one interface unconfigured (no cable present at boot time)
$ ifconfig
eth0 Link encap:Ethernet HWaddr <DELETED>
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
          Interrupt:9 Base address:0x2c00

eth1 Link encap:Ethernet HWaddr <DELETED>
          inet addr:<DELETED> Bcast:<DELETED> Mask:255.255.255.192
          inet6 addr: <DELETED>/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:474 errors:0 dropped:0 overruns:0 frame:0
          TX packets:233 errors:0 dropped:0 overruns:0 carrier:0
          collisions:25 txqueuelen:1000
          RX bytes:214769 (209.7 KiB) TX bytes:22745 (22.2 KiB)
          Interrupt:11 Base address:0x8800

/proc/net/route doesn't seem to offer any differentiation between eth0 and eth1 ... I have no idea if this is correct/valid or not.

$ cat /proc/net/route
Iface Destination Gateway Flags RefCnt Use Metric Mask MTU Window IRTT
eth1 <DELETED> 00000000 0001 0 0 0 C0FFFFFF 0 0 0
eth0 0000FEA9 00000000 0001 0 0 0 0000FFFF 0 0 0
eth1 0000FEA9 00000000 0001 0 0 1000 0000FFFF 0 0 0
eth1 00000000 <DELETED> 0003 0 0 0 00000000 0 0 0
eth0 00000000 00000000 0001 0 0 1000 00000000 0 0 0

(This seems to be the same as the output of netstat)
$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
<DELETED> 0.0.0.0 255.255.255.192 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
0.0.0.0 <DELETED> 0.0.0.0 UG 0 0 0 eth1
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 eth0

scapy tests each interface for the flag RTF_UP (around line 2232)
        for l in f.readlines()[1:]:
            iff,dst,gw,flags,x,x,x,msk,x,x,x = l.split()
            if int(flags,16) & RTF_UP == 0:
                continue
            ifreq = ioctl(s, SIOCGIFADDR,struct.pack("16s16x",iff))

The ioctl call on that last line fails on my eth0. As mentioned above, if I manually give eth0 an address, the ioctl call will work ...

$ sudo ifconfig eth0 10.10.10.10
$ scapy -h
/usr/bin/scapy:3101: Warning: 'with' will become a reserved keyword in Python 2.6
/usr/bin/scapy:3103: Warning: 'with' will become a reserved keyword in Python 2.6
INFO: Can't import PyX. Won't be able to use psdump() or pdfdump()
Usage: scapy.py [-s sessionfile]

So somehow we have to convince scapy to leave the unconfigured interface alone.

It looks like the udev attribute {carrier} is the right thing to query
$ udevinfo -p /sys/class/net/eth0 -a|grep carrier
    ATTR{carrier}=="0"
$ udevinfo -p /sys/class/net/eth1 -a|grep carrier
    ATTR{carrier}=="1"
but how can scapy (upstream) know that it is in a udev environment?

I see from dmesg that there is a test for the link state of an interface :-
ADDRCONF(NETDEV_UP): eth0: link is not ready

This message comes via netdevice.h in the kernel, and that's getting beyond me, sorry.

The workaround is to make sure that you don't have any unconfigured interfaces when you want to run scapy.
I've logged this issue onto the scapy upstream ticketing, http://trac.secdev.org/scapy/ticket/40