On Tue, Jan 29, 2013 at 4:28 AM, Bohdan Tashchuk <btashc...@yahoo.com> wrote:
> --- On Mon, 1/28/13, Andres Perera <andre...@zoho.com> wrote:
>
>> more than that, really, why should you or anybody care
>>
>> using bpf or not should be an implementation detail. no one should
>> be making decisions as far as their pf config goes based upon
>> whether dhclient uses bpf or not
>
> Thanks for your comments on the source code. I briefly looked thru
> /usr/src/sbin/dhclient, but there were 6289 lines of *.c code there.
> I'm not that familiar with networking code so there was too much
> for me to easily comprehend.

in the future, you can use systrace to find out what fd programs are
really writing to. it has saved me enormous amounts of time when
troubleshooting, e.g., cvs slowness. familiarizing myself with cvs's
code base would've undoubtedly been more expensive

>
> I agree that bpf is simply an implementation technique; I don't really care
> *how* dhclient does what it does. But I want to understand the required pf
> rules for two reasons:
>
> 1) there have been people who have said (e.g. in the thread I quoted):
>
>    "Using DHCP is not possible, pf block it, and i don't understand why"
>
> Missing pf rules are one reason why dhcp would fail. Many people search
> for similar problems years later; I don't want them to be confused as I was.
>
> 2) This is the important one for me. I want to be a "good Internet citizen".
> So I try to write my pf rules to be as restrictive as possible. I want to
> keep machines behind my firewall from being "bad Internet citizens".
> Right now my outgoing UDP below port 1024 is restricted to ports domain,
> kerberos, and ntp. I will add dhcp to that list.
>
> I know I'm being a little quixotic (or perhaps pedantic) here. If there's
> a misbehaving machine behind my firewall, I don't think that restricting
> its UDP ports is going to make a whole lot of difference to the Internet
> at large. But I'm trying to do what I can.
>

as it stands, i would wait for an "official" recommendation before
jumping to conclusions. i'm only pointing out the problem. it could be
that routing these unicast messages is useful, which is why they
aren't being written directly to the interface's output buffer via
bpf, or it could very well be that someone is devising a patch to
write them through bpf regardless because the routing isn't
required... that's a problem area i'm not familiar with, but i would
expect $router_network == $dhcpd_network in common configurations...
and even if not, having them potentially route through different
interfaces makes no friggen sense

Reply via email to