| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
packets instead of allowing the protocol stack to pick a random source port.
This fixes the behaviour where dhclient would never transition from RENEWING
to BOUND without going through REBINDING in networks which are paranoid about
DHCP spoofing, such as most mainstream cable-broadband ISP networks.
Reviewed by: brooks
Obtained from: OpenBSD (partly - I'm not convinced their solution can work)
MFC after: 1 week (pending re approval)
|
|
|
|
|
|
|
|
| |
directly rather than bogusly sending it out as a link layer broadcast
(which fails to be received on some networks).
PR: bin/96018
MFC after: 2 weeks
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
length != BPF_WORDALIGN(length)
This meeans that it is possible for this to be true:
interface->rbuf_offset > interface->rbuf_len
Handle this case in the test for running out of packets. While
OpenBSD's solution of setting interface->rbuf_len to
BPF_WORDALIGN(length) is safe due to the size of the buffer, I think
this solution results in less hidden assumptions.
This should fix the problem of dhclient running away and consuming 100%
CPU.
PR: bin/102226
Submitted by: Joost Bekkers <joost at jodocus.org>
MFC after: 3 days
|
|
|
|
| |
versions when dealing with user problems.
|
| |
|
|
|
|
|
|
| |
is properly aligned when we move to the next packet.
Obtained from: ISC dhclient via krw at OpenBSD
|
|
|
|
|
|
|
|
| |
capture. Zero length captures caused an infinte loop and short captures
probably caused memory corruption and a crash.
Reported by: many
MFC After: 3 days
|
|
|
|
| |
Submitted by: sam
|
|
OPENBSD_3_7).
|