When I get home from work today, I will post a section from my old WIN XP SP3 firewall log that clearly shows inbound port 68 being blocked from 192.168.x.x to port 67 dest. 255.255.255.255. These trans. can only be DHCP offer, renewal, or ack..
More likely extraneous traffic. If you’re on a cable network you will see other peoples requests unless you block it.
From the DHCP rfc
DHCP uses UDP as its transport protocol. DHCP messages from a client
to a server are sent to the 'DHCP server' port (67), and DHCP
messages from a server to a client are sent to the 'DHCP client' port
(68). A server with multiple network address (e.g., a multi-homed
host) MAY use any of its network addresses in outgoing DHCP messages.
BOOTP (Bootstrap Protocol) is a protocol that lets a network user be automatically configured (receive an IP address) and have an operating system booted (initiated) without user involvement.
For starters, I use DSL and my ISP is AT&T aka Bellsouth.net.
I have also seen those same articles and depending on your network configuration, they are somewhat correct when referring to a separate DHCP server box on your internal network. However, when you are connecting to a router on your LAN that creates a virtual DHCP server internally, the rules change. It might also have something to do with the two network interfaces that exist on a router; one for the LAN side and one for the WAN side. Every article I have seen for other software firewalls interfacing with a router state rules for DHCP outbound from port 68 to port 67 and for inbound port 68 to 67.
Below is the last entries for my WIN XP Pro SP3 firewall log prior to my conversion to Comodo’s 3.9 firewall. My network card IP address at that time was 192.168.1.97:
#Version: 1.5 #Software: Microsoft Windows Firewall #Time Format: Local #Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2009-05-30 13:45:59 DROP UDP 192.168.1.97 255.255.255.255 68 67 328 - - - - - - - RECEIVE
2009-05-30 13:46:02 DROP UDP 192.168.1.97 255.255.255.255 68 67 328 - - - - - - - RECEIVE
2009-05-30 14:35:28 DROP TCP 91.199.212.149 192.168.1.97 443 1357 40 FA 2175705189 3605759766 7504 - - - RECEIVE
2009-05-30 14:35:29 DROP TCP 91.199.212.149 192.168.1.97 443 1359 40 FA 2168744904 4235835981 7504 - - - RECEIVE
2009-05-30 14:35:43 DROP TCP 91.199.212.149 192.168.1.97 443 1365 40 FA 2201221352 3707414692 6432 - - - RECEIVE
2009-05-30 14:36:12 DROP TCP 91.199.212.149 192.168.1.97 443 1369 40 FA 2223985115 2625777508 6672 - - - RECEIVE
2009-05-30 14:36:41 DROP TCP 91.199.212.149 192.168.1.97 443 1372 40 FA 2262665390 2523772532 6456 - - - RECEIVE
2009-05-30 14:39:53 DROP TCP 91.199.212.149 192.168.1.97 443 1379 40 FA 2450552395 1317354079 6432 - - - RECEIVE
2009-05-30 14:40:24 DROP TCP 91.199.212.149 192.168.1.97 443 1383 40 FA 2489259353 3949317636 6432 - - - RECEIVE
2009-05-30 14:40:50 DROP TCP 91.199.212.149 192.168.1.97 443 1387 40 FA 2521763466 2304694916 7672 - - - RECEIVE
2009-05-30 14:50:06 DROP TCP 85.255.19.28 192.168.1.97 443 1498 48 SA 879239458 84969609 4224 - - - RECEIVE
2009-05-30 14:50:30 DROP TCP 85.255.19.28 192.168.1.97 443 1498 48 SA 879239458 84969609 4224 - - - RECEIVE
2009-05-30 15:01:34 DROP UDP 192.168.1.97 255.255.255.255 68 67 328 - - - - - - - RECEIVE
2009-05-30 15:01:37 DROP UDP 192.168.1.97 255.255.255.255 68 67 328 - - - - - - - RECEIVE
Hopefully, this is my last post to this thread since I finally got DHCP to work right! Trumpets, flourishes, and all that ■■■■!
First thing I additionally did was apply the Microsoft hotfix, KB953761, that I mentioned in a previous post in this thread. This hotfix only applies to XP SP3 - to correct the DHCP server offer option 43 problem.
Next, I activiated uPnP on my router. I was hesitant to do that given uPnP’s hacking record but I also know enough about network to know many routers require it for full functionality.
I then rebuilt TCP/IP and did some additional fooling around with network settings. In the process of fooling around, I finally got uPnP configured properly on my PC as evidenced by a Comodo alert informing me it was learning on 239.255... I also observed additional uPnP ■■■■ in my Comodo logs. I did not observe any bad guy port 5000 or 1900 UDP nPnP inbound traffic in the logs. I take that with a grain of salt since I am convinced that Comodo’s inbound logging capability leaves a lot to be desired.
Finally, I stripped out any special DHCP firewall rules I previously created leaving only the trusted network rules Saul suggested in a prior post in this thread. As far as my Trusted Network goes, it’s my LAN including my router gateway and the .255 broadcast IP, the AIPPA IP range, and finally the 239.255.. uPnP IP range.
As I somewhat expected, I finally resolved my DHCP problems and Comodo had nothing to do with the problem. After doing a lot of research and examining my .inf file for my installed nForce4 ethernet driver, I came to the conclusion that something was hosed in that driver. This driver was from the latest nForce4 15.23 release from the nVidia web site. I uninstalled it and reinstalled the ethernet driver from the nForce4 package from my motherboard manufacturer, MSI, web site. Low and behold, all the DHCP issues disappeared.
Moral of this long story is new is not necessarily better. This is especially true of ethernet drivers since motherboard manufacturers do a lot of custom stuff to onboard NIC chips. Mine happens to be a Marvell Yukon chip.