Bug 197511 (bpf)

Summary: BPF --> Interactions with Dhclient, Tcpdump, and Network Connections (Ping)
Product: Base System Reporter: Gary Tivey <garytivey512>
Component: binAssignee: Xin LI <delphij>
Status: Closed DUPLICATE    
Severity: Affects Only Me CC: archit, delphij, garytivey512, pi
Priority: ---    
Version: 10.1-STABLE   
Hardware: amd64   
OS: Any   

Description Gary Tivey 2015-02-10 10:55:52 UTC 
Have noticed on a recent install of FreeBSD 10.1 network firewall (pf) ,by accident, that if I enable tcpdump on the external interface, I can easily obtain an IP address via Dhclient on a Comcast cable network. If I close the Tcpdump program, I can no longer ping external ip's such as google dns, or the IPV6 endpoint of a 6-4 tunnel. Once I restart the Tcpdump program, all connectivity is restored. I believe the code in common is the bpf (Berkley Packet Filter). 

Have observed the same behavior using FreeBSD 9.3 on the same hardware.
Seems rather odd that I need to have tcpdump running all the time on this firewall. Condition is persistant through reboots. Devices noted in /dev are bpf, and bpf0. Should there be more bpf devices? I remember a while back the kernel options allowed a number option... is that still the case?
Comment 1 Gary Tivey 2015-02-11 20:31:21 UTC 
network interfaces are RealTek , re0 and re1
Comment 2 Xin LI freebsd_committer freebsd_triage 2022-11-22 22:14:59 UTC 
This may be related to 168268 (I'm closing this PR since there is no updates since 2015, and it's likely that this is no longer actionable).

*** This bug has been marked as a duplicate of bug 168268 ***