Re: [MirageOS-devel] tuntap on linux

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 7 Jun 2015, at 03:33, Justin Cormack <justin@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> On 6 June 2015 at 23:54, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> On 6 Jun 2015, at 15:49, Justin Cormack <justin@xxxxxxxxxxxxxxxxxxxxx>
>> wrote:
>> 
>> 
>> 
>> On Jun 6, 2015 4:56 PM, "Anil Madhavapeddy" <anil@xxxxxxxxxx> wrote:
>>> 
>>> I'm just testing out tuntap.1.3 for release on Linux, and am having some
>>> trouble getting it to work.  Just wanted to check if others are using it ok.
>>> I've done:
>>> 
>>>    $ sudo tunctl
>>>    $ sudo ifconfig tap0 10.0.0.1 netmask 255.255.255.0 up
>>>    $ sudo ./_build/test/nonblock_read.native tap0
>>>    read: 0
>>>    read: 0
>>>    ...
>>> 
>>> This results in a stream of 0 byte reads.
>>> 
>>> If I change the Lwt_unix.of_unix_file_descr in mirage-net-unix to be
>>> blocking:true instead of blocking:false, then it works as expected on Linux,
>>> and all the tap networking is ok.  Tracing through the Lwt code shows that
>>> blocking:false should work, but for some reason the tap device on Linux is
>>> always readable and so EWOULDBLOCK never happens.
>>> 
>>> Anyone else having this problem on Linux, or is it just me? I don't often
>>> use tap networking there, so I don't want to apply the above workaround
>>> without understanding it.
>> 
>> I had what sounds like the same problem with tap devices and rump kernel.
>> 
>> I haven't yet filed a bug but I think there is one... 0 length reads should
>> not happen. I am not sure if it changed in recent versions but I think it
>> may have. Planning to investigate. If you do the first open with nonblock it
>> seems to work but fcntl does not
>> 
>> Tracked it down -- looks like a Linux 3.19 regression:
>> https://bugzilla.kernel.org/show_bug.cgi?id=96381
> 
> Ah, doesn't look like it is in a hurry to be fixed though, will try to
> bisect it.
> 
> If you apply this:
> 
> diff --git a/lib/tuntap_stubs.c b/lib/tuntap_stubs.c
> index dbccc79..e6fc6a1 100644
> --- a/lib/tuntap_stubs.c
> +++ b/lib/tuntap_stubs.c
> @@ -58,7 +58,7 @@ tun_alloc(char *dev, int kind, int pi, int persist,
> int user, int group)
>   struct ifreq ifr;
>   int fd;
> 
> -  if ((fd = open("/dev/net/tun", O_RDWR)) == -1)
> +  if ((fd = open("/dev/net/tun", O_RDWR | O_NONBLOCK)) == -1)
>     tun_raise_error("open", -1);
> 
>   memset(&ifr, 0, sizeof(ifr));
> 
> I think it should work, but it does change the default to nonblocking.
> For some reason the bug does not manifest if the original fd is opened
> nonblock.

Yes, this seems to work fine for me as well.  I'll cut a release of
tuntap and mirage-net-unix that enforce this non-blocking initialisation
and use just as soon as Travis passes here:
https://github.com/mirage/ocaml-tuntap/pull/15

-anil
_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel