00:06 <tg> apache2: well what's not a research prototype and still reasonably working? :)

00:36 <apache2> debian, ubuntu, freebsd ;)

00:37 <apache2> no worries, thanks for reporting it :)

10:19 <kakekongen> apache2: ahh, so you think I would need to reinstall it with that particular flag?

10:39 <kakekongen> I have a bridge interface with a number of taps attached. When I attach a new tap, and it wants to send a request, it first broadcasts an arp request for 10.0.0.2 (which is tap0), but there is no reply from the unikernel at tap0. Are there any changes to the networking setup required for ARP to work as I expect it to in Mirage? Because I can't remember ever running into this issue earlier.

10:39 <kakekongen> Another strange thing to me is that initially, all are able to talk to each other, but it seems the new one is not able to get the MAC of the other unikernels, and thus is unable to talk to them

10:40 <kakekongen> Any ideas?

11:11 <hannes> kakekongen: "arp request for 10.0.0.2 (which is tap0)" what does this mean? in MirageOS, the default ip address is 10.0.0.2 -- which means on startup the unikernel broadcasts a gratuitious arp for 10.0.0.2

11:12 <hannes> in MirageOS, as well the default gateway is the 10.0.0.1 -- so you should/could use 10.0.0.1 as IP on your host system (e.g. configured on the bridge) to be able to communicate with the unikernel

11:52 <kakekongen> All my unikernels have their IP set at boot (10.0.0.x/24 at tap(x-2) connected to br0 which has route 10.0.0.0 with src 10.0.0.1), and they all send gratuitous ARP requests. Does that mean that if the new unikernel does not observe the gratuitous request for 10.0.0.2, that it will not know of it?

12:12 <hannes> I don't fully understand. If you observe on your host system the gratuitious arps from your unikernels, you should be able to ping them -- if the host system has an IP configured on the same bridge and there's no firewall involved.

12:31 <kakekongen> I think I may have discovered the issue - 10.0.0.2 requests out to 129.242.181.244 which starts a unikernel and returns 200 OK if successful. It then waits for the new unikernel to register and it to be added to the internal routing table. I now fear that it might be blocking, resulting 10.0.0.2 not being able to respond to the ARP request from 10.0.0.5, meaning it will not be able to make the registration

12:31 <kakekongen> request. Thus; 10.0.0.2 will never find the new unikernel - effectively creating a deadlock.

12:34 <kakekongen> Does that analysis make sense? That each request will be handled fully sequentially, and two requests can't be handled at the same time?

12:59 <hannes> kakekongen: uhm, somewhere in tcpip (https://github.com/mirage/mirage-tcpip/blob/v3.7.2/src/stack-direct/tcpip_stack_direct.ml#L109) Netif.listen is called to start the reading on the network interface.

13:00 <hannes> now, at least the solo5 implementation calls _read_ and then Lwt.async on the configured callback _for each received packet_ https://github.com/mirage/mirage-net-solo5/blob/v0.4.2/src/netif.ml#L123 -- i.e. there's a fresh lwt task created for each incoming frame

13:00 <hannes> (the behaviour in unix/macosx/xen is very much the same last time i looked at the code)

13:01 <hannes> i still don't understand your ip and network configuration.

13:02 <hannes> but then, i'm slightly short on time - at least today... sorry.. you may have better luck by writing a mail to mirageos-devel@lists.xenproject

13:56 <apache2> kakekongen: re: scrypt not working: I'm not sure why it doesn't work :-( It looks like it should work for ocaml-freestanding (hvt etc).

16:04 <kakekongen> apache2 ack

16:06 <kakekongen> Feel like I'm having all of the questions here; but here goes. Merlin does not seem to be able to resolve Key_gen. based on the Key.abstract defined in config.ml. Any solutions for this?

16:07 <Drup> kakekongen: configure your unikernel

16:08 <kakekongen> Ahh, it needs to be built beforehand. I retract my question ^^