[GSoC] Progress Report 1

[GSoC] Progress Report 1

[Rohan Prinja]

Hi Guix,

Here is my long-overdue first progress report for my Summer of Code
project to write a DHCP client in Scheme and integrate it with Guix
and dmd.

Pre-coding activities completed:
1 Read RFCs (1541+2131 - DHCPv4, 826 - ARP, 5227 - IP address conflict
detection through ARP, 1497+1533+2132 - DHCP options, 4039 - Rapid
Commit, 3679+3942 - clarifying the usage of some DHCP options)
2 Looked at the source for lwip's implementation of DHCP and ISC's dhclient
3 Revised socket programming and read the Guile manual

Code written thus far (the source is at
http://git.savannah.gnu.org/cgit/guix/dhcp.git):
1 Wrote classes for DHCP packets, network interfaces, DHCP options and
DHCP configuratiion instances.
2 Wrote code to read the system's network interfaces and populate the
network-interface instances' fields (name, hwaddr, family).
3 Refactored the above to records on the advice given by Ludo (who
pointed out that OOPS is unidiomatic and in any case not really needed
here).
4 Wrote incomplete testing code for the the items in 1 (incomplete
because the tests did not test the serialisation of DHCP message
records into bytevectors).
5 Began writing code to send a bytevector to a specified sockaddr, and
began the skeleton of the main client module.

Current focus:
1 Test the code to send and receive packets
2 Code to make and send ARP messages on the link layer, and
corresponding unit tests
2 Complete the (dhcp client) module (this includes the implementation
of the main DHCP client algorithm, and lease storage), and complete
the (dhcp *) modules' tests
3 Read the dhcpd server source (this package:
http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/admin.scm#n378)
to figure out how to have a server for test the client

Questions:
1 Ludo: I looked at the implementations of packed structs. DHCP
packets are in general variable-length because of the options field,
while packed structs require need to have the field lengths known
ahead of time. So do you recommended making some changes to the packed
structs implementations to accomodate the variable-length options
field (I'll have to think about how to do this) or simply refactor the
serializer/deserializer I wrote back when the code was in GOOPS to use
records?
2 Ludo: please could you clarify exactly what the Copyright header for
a source file should look like when it uses code from another project?
For example, (dhcp interfaces) copies code from (guix build syscalls)
(a couple of variable definitions that (guix build syscalls) didn't
export).

Thank you,
Regards,
Rohan

Re: [GSoC] Progress Report 1

[Ludovic Courtès]

Hi Rohan,

Rohan Prinja <rohan.prinja@gmail.com> skribis:

> Code written thus far (the source is at
> http://git.savannah.gnu.org/cgit/guix/dhcp.git):
> 1 Wrote classes for DHCP packets, network interfaces, DHCP options and
> DHCP configuratiion instances.
> 2 Wrote code to read the system's network interfaces and populate the
> network-interface instances' fields (name, hwaddr, family).
> 3 Refactored the above to records on the advice given by Ludo (who
> pointed out that OOPS is unidiomatic and in any case not really needed
> here).
> 4 Wrote incomplete testing code for the the items in 1 (incomplete
> because the tests did not test the serialisation of DHCP message
> records into bytevectors).
> 5 Began writing code to send a bytevector to a specified sockaddr, and
> began the skeleton of the main client module.

Neat!

> Current focus:
> 1 Test the code to send and receive packets
> 2 Code to make and send ARP messages on the link layer, and
> corresponding unit tests

Have you tried sending DISCOVER packets to a real server so far?  Is
there something blocking that?

> 2 Complete the (dhcp client) module (this includes the implementation
> of the main DHCP client algorithm, and lease storage), and complete
> the (dhcp *) modules' tests
> 3 Read the dhcpd server source (this package:
> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/admin.scm#n378)
> to figure out how to have a server for test the client

OK.

> Questions:
> 1 Ludo: I looked at the implementations of packed structs. DHCP
> packets are in general variable-length because of the options field,
> while packed structs require need to have the field lengths known
> ahead of time. So do you recommended making some changes to the packed
> structs implementations to accomodate the variable-length options
> field (I'll have to think about how to do this) or simply refactor the
> serializer/deserializer I wrote back when the code was in GOOPS to use
> records?

I’m not sure exactly.  packed-struct.scm in Guile-OpenGL is not a
perfect fit, for other reasons as well, so I guess it may have to be
adjusted.

Actually I’m just realizing that we also have a packed-struct thing in
(guix build syscalls), called ‘define-c-struct’, which can handle
endianness (see the examples there.)  It does not handle variable-length
fields though.  Would it work for you?

Are variable-length fields in the middle of the packet, or rather at the
end?  In the latter case, you could still use define-packed-struct for
the packet header, and then handle the rest manually.  In the former
case, define-packed-struct probably won’t help.

> 2 Ludo: please could you clarify exactly what the Copyright header for
> a source file should look like when it uses code from another project?
> For example, (dhcp interfaces) copies code from (guix build syscalls)
> (a couple of variable definitions that (guix build syscalls) didn't
> export).

Just keep the copyright and license header as-is, adding a copyright
line for yourself if/when you modify something.

Regarding that module, I see that some of the tests use (guix build
syscalls), so perhaps it would make sense to use that consistently
everywhere?

Also, we should add bindings to libc’s getifaddrs in (guix build
syscalls) so that interfaces.c is no longer needed.  Could you try that,
using ‘define-c-struct’ to define the ‘ifaddrs’ structure?

Besides, I’ll see if I can add a minimal autotools setup to the repo, to
facilitate things.

Thanks, and happy hacking!  :-)

Ludo’.

Re: [GSoC] Progress Report 1

[Ludovic Courtès]

ludo@gnu.org (Ludovic Courtès) skribis:

> Besides, I’ll see if I can add a minimal autotools setup to the repo, to
> facilitate things.

Done, and renamed to old Makefile to Makefile.old (probably we’ll just
remove it once we have FFI bindings to getifaddrs.)

So you can run:

  autoreconf -vfi
  ./configure -C && make

and, for now:

  make -f Makefile.old

Ludo’.