* [GSoC] Progress Report 1
@ 2015-06-11 7:54 Rohan Prinja
2015-06-12 8:02 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Rohan Prinja @ 2015-06-11 7:54 UTC (permalink / raw
To: guix-devel
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [GSoC] Progress Report 1
2015-06-11 7:54 [GSoC] Progress Report 1 Rohan Prinja
@ 2015-06-12 8:02 ` Ludovic Courtès
2015-06-12 8:21 ` Ludovic Courtès
0 siblings, 1 reply; 3+ messages in thread
From: Ludovic Courtès @ 2015-06-12 8:02 UTC (permalink / raw
To: Rohan Prinja; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [GSoC] Progress Report 1
2015-06-12 8:02 ` Ludovic Courtès
@ 2015-06-12 8:21 ` Ludovic Courtès
0 siblings, 0 replies; 3+ messages in thread
From: Ludovic Courtès @ 2015-06-12 8:21 UTC (permalink / raw
To: Rohan Prinja; +Cc: guix-devel
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’.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-06-12 8:21 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-06-11 7:54 [GSoC] Progress Report 1 Rohan Prinja
2015-06-12 8:02 ` Ludovic Courtès
2015-06-12 8:21 ` Ludovic Courtès
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).