Re: [MirageOS-devel] hdhcpd working.

["Christiano F. Haesbaert" <haesbaert@xxxxxxxxxxxxx>]

On 26 August 2015 at 18:19, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 26 Aug 2015, at 16:58, Christiano F. Haesbaert <haesbaert@xxxxxxxxxxxxx> 
> wrote:
>>
>> Awesome, I think I get it, I'll need something analogous to the IO
>> module of Cohttp, should be fairly easy.
>> After some more reading, the Dhcp_server should require only an "IO"
>> module and a "Logger" module.
>
> That sounds about right.  Your IO module is a little different from
> Cohttp's since its only sending UDP packets, whereas Cohttp (and indeed
> Conduit) assume a reliable stream transport.  Perhaps call it DATAGRAM
> or something?

Ack ! DATAGRAM is more sensible.

> Incidentally, is there any DHCP-over-TCP standard?

Not really, DHCP has one tricky thing though, it must be able to
unicast ethernet frames before arp resolution, that's why just relying
on UDP without building the full datagram is not enough.
There are cases where the spec wants you to unicast the datagram
before the client actually has the address, so if you just use a
normal UDP stack, it will try arp resolution and fail, in this case
you unicast to the mac and ip address.

>
>> By the way, although stdout and stderr work on Mirage-unix, I assume
>> it is only cause stdout and stderr are not closed ?
>> I believe that doesn't work on Xen, Or is somehow the stdout/stderr
>> output functions redirected to the default CONSOLE instance ?
>> If that is not the case, then I don't need to functorize over a Logger
>> module, I don't have a xen setup yet.
>
> stdout/stderr will always go to somewhere sensible on all backends,
> but not somewhere explicitly designed for logging -- it will be a console
> device.  Having a LOGGER is a good idea to ensure that DHCP events
> can be redirected would be good to do from day 1.  It could just be a
> simple prerr_endline for now.

Great, I can adapt the log module too.

>
> We just had this discussion on the Mirage call as well -- I'm bolting
> something similar on top of the Cohttp_*_servers so that HTTP-level
> events can be sent to a backend like an Apache-format logfile (ideally
> backed on Irmin).
>
>>> My idea so far was to release hdhcp as a library, having a Dhcp_server
>>> module, and another package with a mirage usage of this module as a functor.
>>> Basically it needs to be specialized on how to send/receive packets and
>>> read/write to disk.
>>>
>>>
>>> I think that's spot on.  The functor only needs to be parameterised by
>>> modules for which there is genuinely more than one implementation.  So for
>>> example, config file parsing doesnt need to be there as it can be
>>> represented by a record type and supplied to the library.  If you post some
>>> patches/branch I can take a look.
>>
>> Great, I'm shuffling some code in order to only need to functorize
>> over IO and possibly over a Logger module.
>> There isn't much stuff to do actually, the main issue is I'm just
>> getting familiar with mirage now.
>>
>> By the way, I'm considering renaming the project to Charrua, a
>> reference to: https://en.wikipedia.org/wiki/CharrÃa_people
>>
>
> A fine name for a nomadic protocol! :-)
>
> -a

Great !

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