Clearly you cannot read either. Please show me where I said "it's -no way- related to PF". I'm waiting...
I'll do the work for you. "Certainly could be. If this happens consistently around a particular time, you can 'live dangerously' and allow all traffic temporarily to see if the issue is resolved. More safely, use tcpdump(8) to see if you can find the problem." Hm, looks like I said that PF "certainly could be" the problem. That is literally the first thing I said in this thread. I even concluded that initial e-mail with the following: "If it is a pf(4) issue, then it not related to that traffic." Look at the antecedent there. I did not claim PF was not an issue. What I _correctly_ claimed was that the issue was _not_ related to blocking DHCP traffic on UDP port 67. If that claim is wrong, please prove me wrong. I am not being facetious either. I would love to _learn_ where I am wrong. I'll even go to the lengths of showing you how you could go about proving that claim wrong. See if you have any issues with the following rules: # Options. set block-policy drop # Macros. ext_if = <interface_name> # Filtering rules. block in quick on $ext_if inet proto udp to port 68 block out quick on $ext_if inet proto udp to port 67 pass quick If you have issues, then my claim was in fact wrong. Which is great! I get to learn something.
And I think you should learn, too. You must.
I agree which is why I learned about my network topology and what rules in my pf.conf(5) do instead of crossing my fingers and hoping some rules I found on the Internet would work. I even offered to learn how exactly your FreeBSD setup worked despite that being a different OS. You never took me up on that offer on trying to understand what is happening though. Instead you were again lazily content that adding a rule to the likely list of rules you didn't even understand was good enough. I will hopefully learn to have much lower standards for the people on @misc, and perhaps wait until I at least have had a cup of coffee before I reply.
