Alle mercoledì 19 novembre 2008, Guy Harris ha scritto:
> On Nov 17, 2008, at 1:46 PM, Giovanni Venturi wrote:
> > To make the pcap_next/pcap_ex non blocking under Linux I use:
> >
> >FD_ZERO(&m_fdset);
> >FD_SET(m_pcap_fd, &m_fdset);
> >m_fdtimeout.tv_sec = 0;
> >m_fdtimeout.tv_use
On Nov 17, 2008, at 1:46 PM, Giovanni Venturi wrote:
To make the pcap_next/pcap_ex non blocking under Linux I use:
FD_ZERO(&m_fdset);
FD_SET(m_pcap_fd, &m_fdset);
m_fdtimeout.tv_sec = 0;
m_fdtimeout.tv_usec = CAP_READ_TIMEOUT*1000;
selRet = select(m_pcap_fd+1, &m_fdset, NULL, NU
On Nov 18, 2008, at 1:06 PM, Giovanni Venturi wrote:
I don't have hardware problem, so we have just the second
possibility. I used
gcc (GCC) 4.2.4 . What compiler have you used to compile libpcap
1.0.0?
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
-
This is the tcpdump-w
Alle martedì 18 novembre 2008, Guy Harris ha scritto:
> If you *truly* set a variable to, say, 9, and then later set it from
> the return value of a function, and immediately after setting it from
> the return value of the function it still has the value you originally
> set it to, then either
>
>
On Nov 17, 2008, at 3:24 PM, Giovanni Venturi wrote:
int result = 9;
result = pcap_next_ex(m_pcapfp, &hdr, (const u_char **)&p);
Sometimes I get 9, sometimes I get 1, ...
How can it be possible that the return value doesn't change result
variable?
If you *truly* set a variable to, say, 9,
Alle lunedì 17 novembre 2008, Guy Harris ha scritto:
> On Nov 16, 2008, at 1:28 PM, Giovanni Venturi wrote:
> > Hello,
> > I'm the author of ksniffer a GUI interface under KDE 3 to capture
> > network
> > packet.
> > Till libpcap < 1.0.0 (the last stable you released) all was ok in
> > the packet
>
Alle lunedì 17 novembre 2008, Guy Harris ha scritto:
> On Nov 16, 2008, at 1:28 PM, Giovanni Venturi wrote:
> > Hello,
> > I'm the author of ksniffer a GUI interface under KDE 3 to capture
> > network
> > packet.
> > Till libpcap < 1.0.0 (the last stable you released) all was ok in
> > the packet
>
On Nov 16, 2008, at 1:28 PM, Giovanni Venturi wrote:
Hello,
I'm the author of ksniffer a GUI interface under KDE 3 to capture
network
packet.
Till libpcap < 1.0.0 (the last stable you released) all was ok in
the packet
capture, but now I get the following error message:
This appears to
On Nov 17, 2008, at 10:27 AM, Giovanni Venturi wrote:
memory-mapped capture support? I guess that this is used in libpcap
1.0.0,
right?
It's supported by libpcap 1.0.0, but not *required* by libpcap 1.0.0.
What kernel option do I have to check?
CONFIG_PACKET_MMAP.
However, as indicated
Alle lunedì 17 novembre 2008, Guy Harris ha scritto:
> On Nov 16, 2008, at 2:11 PM, Guy Harris wrote:
> > 4) somehow that causes pcap_open_live() to fail, rather than just
> > falling back on reading from the PF_PACKET socket in the normal
> > fashion.
> >
> > If so, that's a libpcap bug; I'll
On Nov 16, 2008, at 2:11 PM, Guy Harris wrote:
4) somehow that causes pcap_open_live() to fail, rather than just
falling back on reading from the PF_PACKET socket in the normal
fashion.
If so, that's a libpcap bug; I'll try debugging it.
pcap_open_live() doesn't seem to be failing in th
On Nov 16, 2008, at 1:09 PM, Giovanni Venturi wrote:
Till libpcap < 1.0.0 (the last stable you released) all was ok in
the packet
capture, but now I get the following error message:
can't create rx ring on packet socket 4: 92-Protocol not available
What does it mean?
It means that
12 matches
Mail list logo
