dhcp: handle multiple DHCP servers

The client was not being careful enough and could be confused by
multiple DHCP servers on a network.

After sending a DISCOVER, the client would recieve two OFFERs.
It would Read() the first, send a REQUEST, and then Read() again
waiting for an ACK. The first thing the second Read() got was a
second OFFER. This was being mis-interpreted as a bad ACK, and
the process started over. A successful DHCP connection required
everything to be negotiated with one server before the other
responded, which could take minutes.

This CL explicitly checks the incoming message types, so
subsequent OFFER messages can be ignored.

It also fixes a small server bug: an incoming REQUEST for a
different server should be ignored, not NAKed.

This deals with the first problem in NET-43.

Change-Id: I133b1183c2a019041cd47d9bfaf4e09eb97cfcd3
3 files changed
tree: 003afaa7512c8686e3e2e155a120f7ef160765a7
  1. dhcp/
  2. dns/
  3. ilist/
  4. tcpip/
  5. tmutex/
  6. waiter/
  7. AUTHORS
  8. CONTRIBUTING.md
  9. CONTRIBUTORS
  10. LICENSE
  11. README.md
README.md

Netstack

Netstack is a network stack written in Go.

Getting started

Try it out on Linux by installing the tun_tcp_echo demo:

go install github.com/google/netstack/tcpip/sample/tun_tcp_echo

Create a TUN device with:

[sudo] ip tuntap add user <username> mode tun <device-name>
[sudo] ip link set <device-name> up
[sudo] ip addr add <ipv4-address>/<mask-length> dev <device-name>

Then run with:

tun_tcp_echo <device-name> <ipv4-address> <port>

Contributions

We would love to accept contributions, but we have not yet worked out how to handle them. Please contact us before sending any pull requests.

Whatever we do decide on will require signing the Google Contributor License. Please see CONTRIBUTING.md for more details.

Disclaimer

This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google.