rtems-libbsd bpf BIOCSRTIMEOUT behaviour

[Nicolas Tsiogkas]

I see thanks.

Any idea or documentation on how to do that on qemu? I'm afraid that my
experience is rather limited.

I'm running on qemu 2.10 using the xilinx_zynq_a9_qemu bsp.

Thank you for your time.

Kind regards,
Niko

On Fri, Jun 29, 2018 at 7:01 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 28/06/18 14:09, Nicolas Tsiogkas wrote:
> > Hi,
> >
> > I have observed a weird behaviour while setting the BIOCSRTIMEOUT for
> > a bpf.
> >
> > When setting it to low values (less than a second) as it can be seen
> > below the bpf is actually blocking instead of waiting and continuing.
> >
> > struct timeval timeout;
> > timeout.tv_sec =  0;
> > timeout.tv_usec = 1;
> > if (ioctl(*bpf, BIOCSRTIMEOUT, &timeout) == -1) {
> > perror("BIOCSRTIMEOUT");
> >   return 0;
> > }
> >
> > This was working with the libbsd 4.11 branch. Is this a known bug?
>
> No, we use the bpf with libpcap on the master. You have to debug this.
>
> >
> > In addition the bpf is not receiving/reading anything incoming while
> > with wireshark I can confirm that there are things on the wire and the
> > bpf is in promiscuous mode. Still this was working on the 4.11 branch.
> > Any idea on how to debug this?
>
> I would set a break point to the network interface receive function and
> then follow the path of the Ethernet frame.
>
> >
> > Thanks in advance.
> >
> > Cheers,
> > Niko
> >
> >
> > _______________________________________________
> > users mailing list
> > users at rtems.org
> > http://lists.rtems.org/mailman/listinfo/users
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180629/2afee255/attachment-0002.html>