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

[Thomas Leonard <talex5@xxxxxxxxx>]

On 3 June 2015 at 20:02, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> 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.

I've added one here:

  https://github.com/mirage/mirage/issues/414

(note that the problem seems to be trying to handle the same interface twice)


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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