mirage / charrua Goto Github PK

It's possible to call buf_of_pkt on a Dhcp_wire.pkt with an options field containing so many options that the buffer obtained for write is overrun in buf_of_options:

    (Invalid_argument
  "Cstruct.blit_from_string src=[64] dst=[2039,9](2048) dst-off=0 len=64")
    Raised at file "pervasives.ml", line 33, characters 20-45
    Called from file "lib/dhcp_wire.ml", line 841, characters 4-34
    Called from file "list.ml", line 88, characters 24-34
    Called from file "lib/dhcp_wire.ml", line 1036, characters 15-56
    Called from file "lib/dhcp_wire.ml", line 1124, characters 20-60

It's horrible having to have a dhcp setup to actually test things, we should have regression tests that mock io and simulates a server/client in different cases.

http://mirage.github.io/charrua/api/

So I'm rewriting extunix recvmsg to accept variant ancillary data. It currently works but it needs some finishing touches.

This will be a temporary solution as Anil pointed out it would be easier to have a solo implementation with ctypes.

But since I had begun this already, and talked to ygrek in extunix, I'm finishing it. When this is done I'll rewrite it in ctypes and drop the extunix dependency as suggested in issue #1

When using dhcpcd on archlinux to retrieve an address from the mirage dhcp server. The server does not respond with the correct ClientId.
dhcpc send CliendId with type 0xff,
mirage server answer with CliendId with type 0x00

was merged in November 2017 (see f23de60), but does not appear in the most recent release yet.

The link in the github about description points to http://mirage.github.io/charrua/api/ while the documentation is at http://mirage.github.io/charrua/ (i.e. without /api/ at the end).

See yomimono/charrua-client#6 on charrua-client, which should be merged into this repository.

a dhcp option client_identifier is opaque, the chaddr is not !

I'm configuring a server by assembling a Dhcp_server.Config.t . I have one host included in the list. I was surprised that when there's no Subnet_mask set in the host's list of options, it doesn't inherit one from the more general network configuration in the Dhcp_server.Config.t. Is this a bug, or just a failure of understanding on my part?

When we switched to topkg we inherited -classic-display in ocamlbuild, since topkg changes the default.

So far my solution is to keep my own topkg pinned and remove it.

Since the topkg port, it seems merlin is broken.

It works for me if I removed the following two lines from lib/.merlin for example:
FLG -ppx "../_build/default/.ppx/ppx_sexp_conv+ppx_cstruct/ppx.exe --as-ppx --cookie 'library-name="dhcp_wire"' -no-check"
FLG -w -40 -w -40

Probably the problem is just the first, I've no idea what that is. I can't really code without merlin, does anyone know what's going on ?

https://github.com/ocaml/opam-repository/pull/4938/files#r41636728

I've just noticed that travis is not running charrua-core tests, PACKAGE=charrua-core never shows up in travis.

Take a look at this:
https://travis-ci.org/mirage/charrua-core/builds/260962785

avsm@ already did it, I need to create an account and put my stuff in it.

Any plan for cutting an 0.3 release soon?

Currently the code assumes T1/T2 and IP_LEASE_TIME are included from a DHCPDISCOVER and a DHCPREQUEST, would be nice to tweak collect_replies so that it may answer a DHCPINFORM requesting a T1 for example.

One idea is to make collect_replies take a list of Parameter requests to ignore, so that we may still process them priorly.

Currently we ignore the Requested_ip_address in a DHCPDISCOVER, would be nice to have this.
Some clients wrongly include a Requested_ip_address 0.0.0.0 to specify no preferences, this must be handled too.

The README has a link to http://github.com/haesbaert/charrua-mirage, but it looks like only charrua-core and charrua-unix are present. Is the Mirage example still kicking around somewhere?

Would it be possible to:

1. rename the repository to charrua
2. rename the core library to charrua

Not sure that -core is needed anymore. WDYT?

Currently just to get going on the conversion from hdhcpd->charrua-core I'm installing all necessary modules via opam.

Currently there is a Rawlink.t in Config.subnet.interface, that has to go away so that the mirage version can work.

It's useful to be able to create a DHCP server that serves addresses only in response to "registered" MAC addresses -- in other words, to have no general address range, but serve only fixed addresses that match known hosts. Dhcp_server.Config.t doesn't currently allow this, as range is not an option field.

When answering paramenter requests, we merge config.options and subnet.options, that is wrong.

List options should be concatenated, single options should use only the subnet one.

This is what the cool kids are doing now, we want to be cool.

Somehow after a long sleep, the client sends a discover, we send a reply, but the client does not see the reply. This was observed with charrua-mirage, it might not occur in charrua-unix.

Currently we ignore the incoming checksum, this should be checked and the packet dropped accordingly.

while deploying charrua in africa with no persistent leases, we discovered that a restart of charrua leads to it handing out ip addresses with active lease (from the previous incarnation). -- see also https://tools.ietf.org/html/rfc5227

ways to fix this include:

• ask via arp before handing out an ip address
• randomise (instead of linear search) which ip to hand out

IMHO we should do both.

The https://github.com/mirage/ocaml-tuntap exposes getifaddrs that is parsed into an Ipaddr.t already. That would remove Extunix with a smaller library in the form of tuntap in config_parser.ml

What ever that is.

"A DHCP server library in OCaml http://docs.mirage.io/charrua-core/"

Should be "A DHCP library in OCaml"

Since we have clients and what not.

Also, can I get full permissions for this stuff ? A bit annoying that I can't change it.

Now that basic functionality is in place and works, it's time to move to mirage.

We would ack a wrong address in a DHCPINFORM for instance, not a big deal, but wrong.

Particularly, when given an empty list for options (which I would expect to be an error condition, since DHCP messages aren't valid without at least message-type):

utop # t;;
- : pkt =  {srcmac = <abstr>; dstmac = <abstr>; srcip = <abstr>; dstip = <abstr>;
            srcport = 68; dstport = 67; op = BOOTREQUEST; htype = Ethernet_10mb;
            hlen = 6; hops = 0; xid = 2l; secs = 0; flags = Broadcast; ciaddr = <abstr>;
            yiaddr = <abstr>; siaddr = <abstr>; giaddr = <abstr>; chaddr = <abstr>;
            sname = ""; file = ""; options = []}
utop # let b = Dhcp_wire.buf_of_pkt t;;
val b : Cstruct.t = {Cstruct.buffer = <abstr>; off = 0; len = 342}
utop # Dhcp_wire.pkt_of_buf b (Cstruct.len b);;
- : (pkt, string) result = Error "Invalid cookie"   

float made sense in the past since Unix.time and mirage's clock gave it in floats.

Now it makes no sense anymore, we should use Int32.t which would also avoid a bunch of conversions.