On Thu, Oct 01, 2009 at 01:28:59PM +0200, Vincent Lefevre wrote: > Thu Oct 1 09:38:46 2009: guessnet: Guessnet 0.51 starting... [...] > Thu Oct 1 09:38:46 2009: guessnet: Trying MII detection > Thu Oct 1 09:38:46 2009: guessnet: Interface eth0 was down: initializing for > broadcast > Thu Oct 1 09:38:47 2009: guessnet: Trying MII detection [...] > Thu Oct 1 09:38:48 2009: Unknown pcap error. Context: > Thu Oct 1 09:38:48 2009: getting a new packet from the network. > Quitting NetWatcher thread. > Thu Oct 1 09:38:52 2009: No such process. Context: > Thu Oct 1 09:38:52 2009: Cancelling generic thread when shutting down > NetWatcher
On Thu, Oct 01, 2009 at 10:07:29PM +0200, Vincent Lefevre wrote:
> On 2009-10-01 13:28:59 +0200, Vincent Lefevre wrote:
> > While guessnet works fine after booting, it always fails at boot time.
>
> I've done tests, and in fact, the problem occurs only when the
> interface is down. For instance, if I do the following, I get
> the pcap error:
>
> /etc/init.d/networking stop
> echo 'home peer 192.168.0.1 00:00:c5:b4:98:74' | guessnet --debug -v eth0
>
> I've also tried the --init-time=10 and --init-delay=10 options,
> but they have no effect.
>
> The error disappears after typing "ifconfig eth0 up".
This is odd: guessnet does try to bring the interface up if it is down:
> Thu Oct 1 09:38:46 2009: guessnet: Interface eth0 was down: initializing for
> broadcast
so apparently the method that guessnet is using is somehow not working
for your network interface. I think I took the code from ifconfig, even.
After bringing the interface up, guessnet polls it to see when it comes
up, and if it doesn't it will complain. The code is in src/IFace.cc, in
IFace::initBroadcast.
Or it could be that pcap in your case fails if the interface is
configured for broadcast. After you do "ifconfig eth0 up", do you have
an IP address assigned to the interface? What if you instead do
"ifconfig eth0 0.0.0.0 up": would it still work?
What is happening here is that when guessnet says "Unknown pcap error",
it means that it asked pcap about why it returned a NULL for a packet,
and the error description returned by pcap is the empty string.
The manpage for pcap_next seems to document a case in which it's ok to
return NULL:
pcap_next() returns a pointer to the packet data on success, and returns
NULL if an error
occured, or if no packets were read from a live capture (if, for
example, they were dis‐
carded because they didn't pass the packet filter, or if, on platforms
that support a read
timeout that starts before any packets arrive, the timeout expires
before any packets
arrive, or if the file descriptor for the capture device is in
non-blocking mode and no
packets were available to be read), or if no more packets are available
in a ``savefile.''
Unfortunately, there is no way to determine whether an error occured or
not.
So in src/utils/netwatcher.cc, maybe you can try and see what happens by
replacing this code:
unsigned char* packet = (u_char *)pcap_next (pcap_interface,
&pcap_header);
if (packet == 0)
throw wibble::exception::Pcap (pcap_geterr(pcap_interface),
"getting a new packet from the network");
With something like this:
unsigned char* packet = (u_char *)pcap_next (pcap_interface,
&pcap_header);
if (packet == 0)
{
string errmsg = pcap_geterr(pcap_interface);
if (errmsg.empty()) continue;
throw wibble::exception::Pcap (errmsg, "getting a new packet from
the network");
}
Unfortunately, pcap_geterr doesn't document that the empty string means
no error, so this code would be rather brittle, but it's a simple change
and it's worth a try to see if it would solve the problem.
If it would solve the problem, still looking at the pcap_next manpage,
that routine should then be rearranged to use pcap_next_ex, or
pcap_dispatch, instead of pcap_next. I would welcome a patch from
someone who's read pcap's documentation more recently than I did,
though.
Ciao,
Enrico
--
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
signature.asc
Description: Digital signature
