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 -
I have the same problem with UDP port 67
But I am using "Bitdefender Antivirus" and I cannot find any setting regarding firewalls and UDP-Ports. Any help would be appreciated
0 -
bdntwrk.exe is a Bitdefender process listening for DHCP connections.
The setting is in Firewall > Settings > Use passive detection mode, which, from the fact it is listening on 0.0.0.0, is set to OFF as opposed to active, which will bind to the DHCP server port 67 and might interfere with existing DHCP server software.
0 -
Thank you for your quick answer. I am using "Bitdefender Antivirus Plus" and I cannot find any setting regarding firewall.
0 -
Hello,
Bitdefender Antivirus Plus does not include the firewall component, so there aren't any settings in that regard. Bitdefender Internet Security and Total Security do have that module.
All other firewall settings would have to be done through the Windows firewall settings.
Kind regards.
All Bitdefender Home Product User Guides: https://www.bitdefender.com/consumer/support/user-guides/
1 -
Ah, correct. That setting is custom to the product and is not available in the Windows Firewall. But the setting is non-intrusive, although it is detecting DHCP anyways, only in non-listening server mode.
0 -
Many thanks to all of you for your help.
I used Windows Firewall to prevent "bdntwrk.exe" from starting at system start. That works fine, but after a while
"bdntwrk.exe" is back again. I have another PC in my Lab with the same Bitdefender, where I never saw a
"bdntwrk.exe". Are there some "Config Files" that Bitdefender uses?
Kind Regards
0 -
To be more specific, "bdntwrk.exe" is not there after system start. Then I start my application, that uses Port 67. This works fine, but when I terminate my application "bdntwrk.exe" is back again.
0 -
bdntwrk.exe is not a service, but rather is controller via a service plugin (specifically, bdservicehost.exe instance running as Virus Shield service; this one loads bdntwrksp.dll - SP = service plugin - and launches bdntwrk.exe during the service startup and and controls the running instance).
I suppose your application performs a bind on the port 67 for the application reasons, and I suppose this prevents bdntwrk.exe from port listening.
When you say '"bdntwrk.exe" is back again' do you mean it does not appear anymore in the netstat -ano | findstr :67 output, or bdntwrk.exe is not running at all?0 -
@camarie wrote:
I suppose your application performs a bind on the port 67 for the application reasons, and I suppose this prevents bdntwrk.exe from port listening.
No it is just the opposite, bdntwrk.exe performs a bind on port 67 and this prevents my application to listen on port 67 and therefor start the bootp process. As camarie wrote in an earlier message, this problem can be solved in "Bitdefender Total Security" by switching to "passive mode". As I am using "Bitdefender Antivirus Plus", this switching cannot be done. Maybe someone can point me to a possibility to do this switch to "passive mode" also in "Bitdefender Antivirus Plus". If not I will try to upgrade to "Bitdefender Total Security".
Thank you for help.
0 -
Well, the binding is happening anyways.
bdntwrk.exe binds on port 67, the difference being- in passive mode is using RAW sockets and binds on broadcast IP 255.255.255.255:67
- in active mode is using UDP socket and binds on 0.0.0.0:67, which is less consuming but interferes with bootp software.
Having firewall allows the changing of the setting, but you do not have one. The setting can be changed manually, but it requires opening of a support ticket, schedule of a remote, the intervention of a support colleague - the whole stuff.
But this is indeed a problem, since the setting might revert inadverdently due to an error, an update process etc.
What I am going to do is to talk to the guys and open an internal issue for this, since obviously this is not correct to have a setting that needs to be changed, but placed in a module which is not available. Let me check with the team and come up with a fix.
Meanwhile, please continue to stress me about this, since I want it to get it fixed.
1 -
Thank you very much for your support. I will wait for your fix.
1 -
Appreciate. Issue opened, noticed everyone about this issue.
In this very moment we are in the middle on an update and probably until the next week I won't be able to bring this up. But I'm on to it.2 -
Hi Camarie
Has any progress been made in solving the "Port 67" problem? I need a solution to get my bootp server up and running.
Best Regards
0 -
It is on my next todo list. I understand you need this done, I asked the support guys if there is an alternate solution until a fix would be released.
1 -
This is not ideal, but what I used to do before the fix above helped me out was reboot my computer and as soon as it would boot up, I would open up BootP. That way it would grab port 67 before bitdefender did. Again, not ideal, but it got me by.
0 -
True, it is not ideal. That is why I want to come up with a fix.
0 -
Hi Killercal,
thank you for your work-around. It will not work for me, because there are more than one program to use BootP. So i keep waiting for the fix from camarie.
0