Re: [MirageOS-devel] Routing.No_route_to_destination_address running Mirage web server

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 1 Jun 2015, at 19:45, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> 
> On 1 June 2015 at 18:02, Carlos Oviedo <psxlco@xxxxxxxxxxxxxxxx> wrote:
>> Hi,
>> 
>> I have a similar problem, please find the code (a revised http-fetch
>> version) in the following repo:
>> https://github.com/lcoviedo/mirage-http-fetch
>> 
>> The unikernel only works fine when runs as a unix backend using socket
>> network stack, otherwise I get the errors below (DHCP full process is run
>> twice, and crashes after ARP timeout).
>> 
>> Interestingly, packet capture on eth0 shows the gw replying to arp requests.
>> Also, removing ctx from HTTP.get that makes use of default resolver builds
>> and runs but results in "name resolution failed unknown endpoint type",
>> however the arp timeout and twice-dhcp process problems do not persist.
>> 
>> Help is much appreciated.
>> 
>> 
>> Parsing config from http-fetch.xl
>> Xen Minimal OS!
>>  start_info: 00000000004f6000(VA)
>>    nr_pages: 0x10000
>>  shared_inf: 0x96cf4000(MA)
>>     pt_base: 00000000004f9000(VA)
>> nr_pt_frames: 0x7
>>    mfn_list: 0000000000476000(VA)
>>   mod_start: 0x0(VA)
>>     mod_len: 0
>>       flags: 0x0
>>    cmd_line:
>>       stack: 0000000000455780-0000000000475780
>> MM: Init
>>      _text: 0000000000000000(VA)
>>     _etext: 000000000025b1ff(VA)
>>   _erodata: 00000000002d3000(VA)
>>     _edata: 0000000000419460(VA)
>> stack start: 0000000000455780(VA)
>>       _end: 0000000000475780(VA)
>>  start_pfn: 503
>>    max_pfn: 10000
>> Mapping memory range 0x800000 - 0x10000000
>> setting 0000000000000000-00000000002d3000 readonly
>> skipped 1000
>> MM: Initialise page allocator for 57f000(57f000)-10000000(10000000)
>> MM: done
>> Demand map pfns at 10001000-0000002010001000.
>> Initialising timer interface
>> Initialising console ... done.
>> gnttab_table mapped at 0000000010001000.
>> getenv(OCAMLRUNPARAM) -> null
>> getenv(CAMLRUNPARAM) -> null
>> getenv(PATH) -> null
>> Unsupported function lseek called in Mini-OS kernel
>> Unsupported function lseek called in Mini-OS kernel
>> Unsupported function lseek called in Mini-OS kernel
>> getenv(OCAMLRUNPARAM) -> null
>> getenv(CAMLRUNPARAM) -> null
>> getenv(TMPDIR) -> null
>> getenv(TEMP) -> null
>> Netif: add resume hook
>> Netif.connect 0
>> Netfront.create: id=0 domid=0
>> MAC: aa:aa:aa:aa:aa:aa
>> Attempt to open(/dev/urandom)!
>> Manager: connect
>> Manager: configuring
>> DHCP: start discovery
>> 
>> Sending DHCP broadcast (length 552)
>> DHCP response:
>> input ciaddr 0.0.0.0 yiaddr 10.0.20.67
>> siaddr 0.0.0.0 giaddr 0.0.0.0
>> chaddr aaaaaaaaaaaa00000000000000000000 sname  file
>> DHCP: offer received: 10.0.20.67
>> DHCP options: Offer : Broadcast(10.0.20.255), DNS
>> servers(10.0.21.232,10.0.21.233,10.0.21.234,10.0.20.29), Routers(10.0.20.1),
>> Subnet mask(255.255.255.0), Lease time(7200), Server identifer(10.0.23.135)
>> Sending DHCP broadcast (length 552)
>> DHCP response:
>> input ciaddr 0.0.0.0 yiaddr 10.0.20.67
>> siaddr 0.0.0.0 giaddr 0.0.0.0
>> chaddr aaaaaaaaaaaa00000000000000000000 sname  file
>> DHCP: offer received
>>                    IPv4: 10.0.20.67
>>                                       Netmask: 255.255.255.0
>>                                                             Gateways:
>> [10.0.20.1]
>> sg:true gso_tcpv4:true rx_copy:true rx_flip:false smart_poll:false
>> ARP: sending gratuitous from 10.0.20.67
>> DHCP offer received and bound to 10.0.20.67 nm 255.255.255.0 gw [10.0.20.1]
>> Manager: configuration done
>> Attempt to open(/dev/urandom)!
>> Manager: connect
>> Manager: configuring
>> DHCP: start discovery
>> 
>> Sending DHCP broadcast (length 552)
>> DHCP response:
>> input ciaddr 0.0.0.0 yiaddr 10.0.20.67
>> siaddr 0.0.0.0 giaddr 0.0.0.0
>> chaddr aaaaaaaaaaaa00000000000000000000 sname  file
>> DHCP: offer received: 10.0.20.67
>> DHCP options: Offer : Broadcast(10.0.20.255), DNS servers(10.0.21.232),
>> Routers(10.0.20.1), Subnet mask(255.255.255.0), Lease time(7200), Server
>> identifer(10.0.23.135)
>> Sending DHCP broadcast (length 552)
>> DHCP response:
>> input ciaddr 0.0.0.0 yiaddr 10.0.20.67
>> siaddr 0.0.0.0 giaddr 0.0.0.0
>> chaddr aaaaaaaaaaaa00000000000000000000 sname  file
>> DHCP: offer received
>>                    IPv4: 10.0.20.67
>>                                       Netmask: 255.255.255.0
>>                                                             Gateways:
>> [10.0.20.1]
>> ARP: sending gratuitous from 10.0.20.67
>> DHCP offer received and bound to 10.0.20.67 nm 255.255.255.0 gw [10.0.20.1]
>> Manager: configuration done
>> Resolving in 1s using DNS server 8.8.8.8
>> Fetching http://anil.recoil.org with Cohttp:
>> Attempt to open(/dev/urandom)!
>> ARP: transmitting probe -> 10.0.20.1
>> ARP: updating 10.0.20.1 -> 00:1b:d5:f4:1d:c4
>> ARP: transmitting probe -> 10.0.20.1
>> ARP: updating 10.0.20.1 -> 00:1b:d5:f4:1d:c4
>> ARP: retrying 10.0.20.1 (n=1)
> 
> It looks like you're running two instances of the TCP/IP stack. One is
> working and the other is failing. This is probably a bug in the mirage
> tool, because you only created a single stack in your config.ml, but
> check the generated main.ml to see what it actually did...
> 
> As a work-around, you could just pass the stack to your unikernel and
> have it create conduit and the resolver.

Is there an upstream bug for this on GitHub?  If not, creating one
would be appreciated Carlos -- we do need to make sure that the Mirage
tool handles multiple interfaces cleanly.

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