On 6 June 2015 at 23:54, Anil Madhavapeddy <[email protected]> wrote:
> On 6 Jun 2015, at 15:49, Justin Cormack <[email protected]>
> wrote:
>
>
>
> On Jun 6, 2015 4:56 PM, "Anil Madhavapeddy" <[email protected]> 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.
Justin
_______________________________________________
MirageOS-devel mailing list
[email protected]
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
