Port 67 Issue - Resurrected
Hello,
Back in 2020/21 it was reported that Bit Defender (BD) conflicts with port 67 used for BOOTp and there appears no resolution to date as today the issue was encountered trying to access Allen Bradley hardware.
Is there a concerted effort to resolve this issue or at least enable disabling of BD to enable BOOTp? Currently the only option appears to be uninstalling BD, running BOOTp to configue the device then re-installing BD. This is just not a practical solution especially when on customer sites.
Regards, MW
Comments
-
Hello.
You should contact Bitdefender Consumer Support by chat, telephone or e-mail:
Chat is the fastest way to get in touch with Bitdefender Consumer Support.
NOTE: Bitdefender telephone support is not toll-free!
Regards.
0 -
Has this been resolved.....same issue here!
1 -
Welcome to the BD Forums. As @Gjoksi recommended to the original poster, I think you should contact Bitdefender Support.
I am not sure, but @Alexandru_BD , our Forum Administrator, might also be able to provide additional information about this issue tomorrow, if you want to wait before contacting BD Support.
Have a great day.
Regards,
Phil
1 -
I can. This is controlled from Protection => Firewall => Settings by the "Use passive detection mode".
In short, bdntwrk.exe (Network helper and detector) is looking, among other things, for DHCP packets for detecting devices arriving on home network and ethernet connection.
This is done by listening on UDP port 67 as shown in the previous picture, and there are two modes:
- Active mode, which binds on the UDP port 67, but allowing reusing the address for other programs (and here is, probably, where the BOOTp hardware attempts to use e the port for its reasons)
- Passive mode, which does not bind on that port and listen only the broadcasted DHCP packets.
In this case, the solution would be to set the passive mode to ON, which will set bdntwrk.exe in broadcast packet mode and will unbind from the UDP port 67. There is no need to restart anything, bdntwrk.exe will get this on the fly and readjust itself.
See the attached images and the differences between these modes using Sysinternals TCPView.
Let me know if this solves the problem.
Edit: the second image "bdntwrk.exe not using port 67 anymore" is not technically 100% correct; a more accurate text is "bdntwrk.exe not binding to port 67 anymore". It will still get DHCP broadcast packets (unless the BOOTp software will not bind itself exclusively to UDP 67 and prevent packets to reach bdntwrk.exe, which is normal if that is the BOOTp software intention).
4 -
Any time. I think Use Passive default setting that maybe should be set to ON by default instead of OFF, I will ask the team if is not better to use a conservative approach.
Thank you for the feedback!
3
