At 12:20 PM -0700 2002/05/01, Guy Harris wrote:
> Given that
>
> 1) it's a quick test program, not an end-user program
>
> and that
>
> 2) it is *NOT* necessarily the case that you have to be root to
> run it
>
> I don't see any need to do that.
Fair enough.
However, in that case you may want to either modify the error
message generated, to include a note to try running the program as
root if you did not previously do so, or to check permissions on any
/dev/bpf devices that may be present.
Or, include some sort of warning to this effect when you hand out
the program to other people (such as myself), who may not be aware of
this issue.
>> Anyway, I now have a version of xprobe that is modified to avoid
>> the casting problem in pcap_iface.c, and linked against my
>> "libnpcap", and it seems to mostly work. Only, it doesn't appear to
>> be able to always choose the right interface:
>
> What do you mean by 'the right interface"?
Well, ifconfig finds three interfaces on the system:
% ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
en1: flags=8863<UP,BROADCAST,b6,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.1.14 netmask 0xffffff00 broadcast 10.0.1.255
ether 00:30:65:14:0e:2d
media: autoselect status: active
supported media: autoselect
en0: flags=8822<BROADCAST,b6,SIMPLEX,MULTICAST> mtu 1500
ether 00:30:65:c4:8c:da
media: autoselect (<unknown type>) status: inactive
supported media: none autoselect 10baseT/UTP <half-duplex>
10baseT/UTP <full-duplex> 100baseTX <half-duplex> 100baseTX
<full-duplex>
And your iflist program finds that two of them are actually running:
# iflist
Password:
en1
Loopback: no
Address Family: #18
Address Family Name: Unknown
Address Family: #2
Address Family Name: AF_INET
Address: 10.0.1.14
Netmask: 255.255.255.0
Broadcast Address: 10.0.1.255
Address Family: #16
Address Family Name: Unknown
lo0
Loopback: yes
Address Family: #18
Address Family Name: Unknown
Address Family: #2
Address Family Name: AF_INET
Address: 127.0.0.1
Netmask: 255.0.0.0
Preferred device name: en1
Preferred device is on network: 10.0.1.0/255.255.255.0
It seems to me that, if the iflist program can detect the
associated IP addresses and netmasks of these two active interfaces,
it should be fairly obvious that any packets addressed to the 127.*
network probably should not be routed to the en1 interface. At
least, not with these routing tables:
% netstat -nr
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.0.1.1 UGSc 5 44 en1
10.0.1.0 ff:ff:ff:ff:ff:ff UHLWb 0 2169 en1 =>
10.0.1/24 link#2 UC 0 0 en1
10.0.1.1 0:60:1d:21:6a:b7 UHLW 1 0 en1 1117
10.0.1.14 127.0.0.1 UHS 0 0 lo0
10.0.1.255 ff:ff:ff:ff:ff:ff UHLWb 0 25 en1
127.0.0.1 127.0.0.1 UH 9 25123 lo0
IMO, this is likely to be a failure of xprobe to find the correct
interface for a particular target IP address, and probably not a
failure in any of the libpcap routines.
> "pcap_lookupdev()" is documented to choose "a network device suitable
> for use with pcap_open_live() and pcap_lookupnet()", not anything more
> specific.
>
> In practice, it will probably pick the lowest-numbered non-loopback
> device, which, if your system has "en1" and "en2" but no "en0", would be
> "en1" - and that's what it appears to pick.
There is an en0, but it is not live. For live, non-loopback
networks, en1 is the only one that exists. But when generating
traffic explicitly targeted at an address clearly on the loopback
network, the program should not be selecting a non-loopback network
to use for transmitting those packets.
--
Brad Knowles, <[EMAIL PROTECTED]>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
