http-fetch fails with DNS resovle error.

[StrykerKKD]

My system:
Ubuntu 16.04
I use the public google dns(8.8.8.8) for my computer
Ocaml version: 4.02.3
Mirage version: 2.9.1
Run as unix

Steps I did:

mirage configure
make
sudo ip tuntap add name tap0 mode tap
sudo ifconfig tap0 10.0.0.1 up
sudo ./mir-http-fetch

The console log

Netif: plugging into tap0 with mac b2:e8:30:5f:e2:1b
Netif: connect tap0
Manager: connect
Manager: configuring
Manager: Interface to 10.0.0.2 nm 255.255.255.0 gw [10.0.0.1]

ARP: sending gratuitous from 10.0.0.2
Manager: configuration done
Resolving in 1s using DNS server 8.8.8.8
Fetching https://www.google.hu with Cohttp:
ARP: transmitting probe -> 10.0.0.1
ARP: updating 10.0.0.1 -> d6:69:f4:63:e0:e1
Fatal error: exception Protocol.Dns_resolve_error(_)
Raised at file "src/core/lwt.ml", line 789, characters 22-23
Called from file "src/unix/lwt_main.ml", line 34, characters 8-18
Called from file "main.ml", line 281, characters 5-10

[pqwy]

A shot in the dark: try sudo sysctl -w net/ipv4/ip_forward=1 before running the unikernel.

[StrykerKKD]

Unfortunately it doesn't solve it.

[StrykerKKD]

From the documentation:

When we want finer control over the network stack, or simply to test the OCaml networking subsystem, we can use a userspace device facility such as the common Unix tuntap to parse Ethernet frames from userspace. This requires additional configuration to assign IP addresses, and possibly configure a network bridge to let the unikernel talk to the outside world.

So it means that I have to make a network bridge to make it work?

[StrykerKKD]

Well, I tried to solve it with a network bridge, but it just got worse.

[StrykerKKD]

dns example also doesn't work for me:
`
Netif: plugging into tap0 with mac 96:81:ba:f4:d4:58
Netif: connect tap0
Manager: connect
Manager: configuring
Manager: Interface to 10.0.0.2 nm 255.255.255.0 gw [10.0.0.1]

ARP: sending gratuitous from 10.0.0.2
Manager: configuration done
2016-08-20 19:21.31: INF [server] Loading 3107 bytes of zone data
Warning ( line 47): Converting MD to MX
Warning ( line 48): Converting MF to MX
2016-08-20 19:21.31: INF [server] DNS server listening on UDP port 53
2016-08-20 19:21.34: INF [client] Starting client resolver
ARP: transmitting probe -> 10.0.0.1
ARP: updating 10.0.0.1 -> b2:a7:37:6c:3b:6c
2016-08-20 19:21.54: WRN [client] DNS resolution for dark.recoil.org failed: Protocol.Dns_resolve_timeout
`

[paurkedal]

tcpdump -i some-interface host 10.0.0.2 is a great way to find out where packets gets lost.

Not sure how familiar you are with bridges, but note that you need to take down your current network connection, reassign your IP address to the bridge, and add the physical interface to the bridge. Any additional interfaces you add to the bridge will now have direct access to the network without IP forwarding.

One thing which may go wrong with the bridged solution is that your gateway may filter packages coming from networks which it is not set up to handle. This is probably then case if tcpdump tells you that packages leave the physical interface. You might then try to use an IP in the right range but be careful to avoid conflicts, reconfigure the router, or configure your own machine to masquerade the device as itself using iptables. For masquerading I think you may need to use IP forwarding instead of a bridge, at least that's what I'm used to.

(I assume you are running your own router. If not, the only options are getting an IP number from your sysadmin, or using masquerading.)

[StrykerKKD]

Ok, I tried to do it with a bridge:

ip tuntap add tap0 mode tap
ip link set dev tap0 up
brctl addbr br0
brctl addif br0 eth1 tap0
ifconfig eth1 0.0.0.0
ifconfig br0 up
dhclient br0

output:

Netif: plugging into tap0 with mac 06:13:09:27:26:cc
Netif: connect tap0
Manager: connect
Manager: configuring
Manager: Interface to 10.0.0.2 nm 255.255.255.0 gw [10.0.0.1]

ARP: sending gratuitous from 10.0.0.2
Manager: configuration done
Resolving in 1s using DNS server 8.8.8.8
Fetching http://anil.recoil.org with Cohttp:
ARP: transmitting probe -> 10.0.0.1
ARP: retrying 10.0.0.1 (n=1)
ARP: transmitting probe -> 10.0.0.1
ARP: retrying 10.0.0.1 (n=2)
ARP: transmitting probe -> 10.0.0.1
ARP: retrying 10.0.0.1 (n=3)
ARP: transmitting probe -> 10.0.0.1
IP.output: could not send to 8.8.8.8: failed to contact gateway 10.0.0.1
Fatal error: exception Ipv4.Make(Ethif)(Arpv4).Routing.No_route_to_destination_address(_)

[paurkedal]

There is probably no 10.0.0.1 gateway on your net. You can see the default route of your computer with ip route if the dhclient command gave you one, but you should also assign suitable static address for it. If you're on a shared network it's important to get one from your network operator.

[paurkedal]

Since mirage supports dhcp, the easiest is to pass --dhcp=true to mirage configure, which should give the unikernel a working gateway and a correctly assigned address. Your bridge setup seems right. I gave it a try myself now, though I already had the bridge.

[StrykerKKD]

Thanks. I was missing the --dhcp=true flag. Now http-fetch and dns example is working correctly.
I think the documentation should be updated, because a lot of newbs like me don't really know a lot about linux networking in general.