dhcpcd.git, branch dhcpcd-8.1.0 DHCP / IPv4LL / IPv6RA / DHCPv6 client Release dhcpcd-8.1.0 2019-10-11T10:37:10+00:00 Roy Marples roy@marples.name 2019-10-11T10:37:10+00:00 ca87fad681e3822933b3facc7d5c10138b05e35d 






BPF: Move validation logic from BPF to consumers
2019-10-11T10:24:38+00:00

Roy Marples
roy@marples.name

2019-10-11T10:24:38+00:00

8baf5c7ce7bb047d4d766fdfd95f5eee1baeaebe

Even though we program the BPF filter should we trust it?
On Linux at least there is a window between opening the socket,
binding the interface and setting the filter where we receive data.
This data is NOT checked OR flushed and IS returned when reading.
We have no way of flushing it other than reading these packets!
But we don't know if they passed the filter or not ..... so we need
to validate each and every packet that comes through ourselves as well.
Even if Linux does fix this sorry state, who is to say other kernels
don't have bugs causing a similar effect?

As such, let's strive to keep the filters just for pattern matching
to avoid waking dhcpcd up.





Even though we program the BPF filter should we trust it?
On Linux at least there is a window between opening the socket,
binding the interface and setting the filter where we receive data.
This data is NOT checked OR flushed and IS returned when reading.
We have no way of flushing it other than reading these packets!
But we don't know if they passed the filter or not ..... so we need
to validate each and every packet that comes through ourselves as well.
Even if Linux does fix this sorry state, who is to say other kernels
don't have bugs causing a similar effect?

As such, let's strive to keep the filters just for pattern matching
to avoid waking dhcpcd up.







Minor optimisation and fix to prior.
2019-10-10T11:00:46+00:00

Roy Marples
roy@marples.name

2019-10-10T11:00:46+00:00

dfd2abf17313e7aa99cd2e0606d66f029b51be85












BSD: Add IFT_TUNNEL
2019-10-10T10:54:47+00:00

Roy Marples
roy@marples.name

2019-10-10T10:54:47+00:00

0a1d3deedc1a18d9e89fe1968abcb33a60eaefeb

Requires explicit support but shouldn't log a code.





Requires explicit support but shouldn't log a code.







DHCP6: Remove 0 sla and 0 prefix means whole prefix.
2019-10-10T10:20:09+00:00

Roy Marples
roy@marples.name

2019-10-10T10:20:09+00:00

0bb6508ca46a3bc6be355b12943e26fbceafd864

If we get a /48 we can still use /64 with a sla of 0.
It's all valid, my bad.





If we get a /48 we can still use /64 with a sla of 0.
It's all valid, my bad.







man: some virtual interfaces ....
2019-10-09T16:39:48+00:00

Roy Marples
roy@marples.name

2019-10-09T16:39:48+00:00

f6a471fccb55813d934d44b318a7a49b31947d8c

For example dummy on Linux still works by default.
There could be others....





For example dummy on Linux still works by default.
There could be others....







man: Note the default ignoring of virtual interfaces.
2019-10-09T13:58:09+00:00

Roy Marples
roy@marples.name

2019-10-09T13:58:09+00:00

b56876b97efda239f09bffe39954d47184cf4dd9












BSD: Ignore bridge interfaces
2019-10-09T13:20:23+00:00

Roy Marples
roy@marples.name

2019-10-09T13:20:23+00:00

49cc1aa4e255dbf3ac7ee2317f4bef0c12a2f3dd












Linux: Ignore TAP and Bridge interfaces by default
2019-10-09T13:09:20+00:00

Roy Marples
roy@marples.name

2019-10-09T13:09:20+00:00

70b44b0e72dda95bf58185d06a366590c4025472

We can check these places:
  /sys/class/net/tap0/tun_flags
  /sys/class/net/br0/bridge





We can check these places:
  /sys/class/net/tap0/tun_flags
  /sys/class/net/br0/bridge







BSD: Ignore the firewire interface as well.
2019-10-09T12:37:12+00:00

Roy Marples
roy@marples.name

2019-10-09T12:37:12+00:00

52f11049d2f05e3cf98089fb918e6786ca39ad0b