rtems-libbsd bpf BIOCSRTIMEOUT behaviour
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?
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?
Thanks in advance.
Cheers,
Niko
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour
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@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour
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.hu...@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@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.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour
On 29/06/18 09:14, Nicolas Tsiogkas wrote: 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. You can run the xilinx_zynq_a9_qemu with QEMU_AUDIO_DRV=none qemu-system-arm -serial null -serial mon:stdio -net none -nographic -M xilinx-zynq-a9 -m 256M -kernel app.exe -s -S It waits for a GDB client connection on localhost:1234. -- 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.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour
Thanks! Shouldn't net have some device though since I want to debug the networking stack? For now I run it with -nographic -serial stdio -serial mon:tcp:localhost:12456 -M xilinx-zynq-a9 -net nic,model=cadence_gem,macaddr=0e:b0:ba:5e:ba:11 -net tap,ifname=tap0,script=no,downscript=no -m 256M -kernel slaveinfo.exe I'll check soon and report back. Thanks again! Cheers, Niko On Fri, Jun 29, 2018 at 9:32 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote: > On 29/06/18 09:14, Nicolas Tsiogkas wrote: > > 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. > > You can run the xilinx_zynq_a9_qemu with > > QEMU_AUDIO_DRV=none qemu-system-arm -serial null -serial mon:stdio -net > none -nographic -M xilinx-zynq-a9 -m 256M -kernel app.exe -s -S > > It waits for a GDB client connection on localhost:1234. > > -- > 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.hu...@embedded-brains.de > PGP : Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour
Hi,
So I have done some debugging.
there were 2 issues.
First issue regarding the timer is the way the timeout is calculated. It
requires at least 11 milliseconds of timeout to be able to handle it.
Second issue that I faced is that flags were not passed correctly to the
bpfopen function so the bpf was not opened in read/write mode. That's why
packets were not received.
Attaching a patch.
Thanks for the help!
Cheers,
Niko
On Fri, Jun 29, 2018 at 9:40 AM Nicolas Tsiogkas wrote:
> Thanks!
>
> Shouldn't net have some device though since I want to debug the networking
> stack?
>
> For now I run it with -nographic -serial stdio -serial
> mon:tcp:localhost:12456 -M xilinx-zynq-a9 -net
> nic,model=cadence_gem,macaddr=0e:b0:ba:5e:ba:11 -net
> tap,ifname=tap0,script=no,downscript=no -m 256M -kernel slaveinfo.exe
>
> I'll check soon and report back. Thanks again!
>
> Cheers,
> Niko
>
> On Fri, Jun 29, 2018 at 9:32 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 29/06/18 09:14, Nicolas Tsiogkas wrote:
>> > 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.
>>
>> You can run the xilinx_zynq_a9_qemu with
>>
>> QEMU_AUDIO_DRV=none qemu-system-arm -serial null -serial mon:stdio -net
>> none -nographic -M xilinx-zynq-a9 -m 256M -kernel app.exe -s -S
>>
>> It waits for a GDB client connection on localhost:1234.
>>
>> --
>> 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.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>>
diff --git a/freebsd/sys/net/bpf.c b/freebsd/sys/net/bpf.c
index 259a253..520712b 100644
--- a/freebsd/sys/net/bpf.c
+++ b/freebsd/sys/net/bpf.c
@@ -2907,7 +2907,7 @@ bpf_imfs_open(rtems_libio_t *iop, const char *path, int oflag, mode_t mode)
{
struct bpf_d *d;
- d = bpfopen(NULL, 0, 0, NULL);
+ d = bpfopen(NULL, oflag+1, 0, NULL);
iop->data1 = d;
if (d != NULL) {
___
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
Re: rtems-libbsd bpf BIOCSRTIMEOUT behaviour
On 03/07/18 12:00, Nicolas Tsiogkas wrote: Second issue that I faced is that flags were not passed correctly to the bpfopen function so the bpf was not opened in read/write mode. That's why packets were not received. Attaching a patch. Thanks, I checked in the patch: https://git.rtems.org/rtems-libbsd/commit/?id=e6f6b5e619ab741327db656fe16ca1765c43817d You can generate complete commits (author, message and changes) with the "git format-patch" command. -- 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.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
