dhcpv4/server.go binding to interface not working properly on macOS

[begetan]

I have switched finally my test server implementation from https://github.com/krolaw/dhcp4/conn to this library and found that it is not serving incoming requests properly. Current implementation is strightforward derived from the example from book Network programming in Go. I looks like krolaw spent enough time to create working bindings for servers in different OS-es.

What is the problem? When you bind server using net.ListenUDP("udp4", &s.localAddr) with specific local address it cannot capture packet at all. If you set localAddr = 0.0.0.0 it can capture packets, but from all system's interfaces of course, which isn't acceptable for real operation. The workaround is to bind to all interfaces with address 0.0.0.0 but make a filter with interface ID and discard unnecessary packets on low level. Here is exactly that this code does: https://github.com/krolaw/dhcp4/blob/master/conn/filter.go

For linux they are using sys call option: syscall.SetsockoptString(s, syscall.SOL_SOCKET, syscall.SO_BINDTODEVICE, interfaceName) For FreeBSD there is a long story about introduction of IP_SENDIF option as well as IP_RECVIF which is not completed yet.

In general it is reasonable working approach, so I wonder if we can adopt it until find better solution?

Regarding this particular issue there are two question from me:

1. Could we resolve this issue: Split client and server from parsing #231 without waiting any solutions for FreeBSD/MacOS?

2. Is it acceptable to implement krolaw/dhcp4/conn solution for server bindings?

[insomniacslk]

hey @begetan , we know of this limitation. The same problem has been addressed for the client, and I have a local branch with a partial solution implemented for the server, too. The binding is implemented in https://github.com/insomniacslk/dhcp/blob/master/dhcpv4/bindtodevice_linux.go (same goes for darwin), so this is just matter of time.

Issue #231 can be prioritized - the only thing to decide is whether to have this structure:

dhcp/client/{Client6,Client4}

or this structure:

dhcp/dhcpv6/client/Client
dhcp/dhcpv4/client/Client

Both have advantages and disadvantages. The same has to be done for server code.

I would like some input from @pmazzini and @hugelgupf on which structure to use, we can discuss it on #231.

[pmazzini]

I think it would be better to have:

dhcp/dhcpv6/client/Client
dhcp/dhcpv4/client/Client

[begetan]

A little update. With local addr = 0.0.0.0 server able to capture broadcast packets, but not able to send. Here is a failed code:

        if _, err := conn.WriteTo(r.ToBytes(), peer); err != nil {
                glog.Infof("Cannot reply to client: %v", err)
        }

There is no error message nor packet replied to requestor. For that reason I've update my proposal and focused it on final separation of Server code: #190

[pmazzini]

Is this still an issue after PR #260?

[pmazzini]

If you set localAddr = 0.0.0.0 it can capture packets, but from all system's interfaces of course, which isn't acceptable for real operation.

This is being looked at in #310

[pmazzini]

@begetan Is this still an issue?

[pmazzini]

I think this is done. Otherwise, feel free to reopen it.