Ok, here’s the output file. Hope this helps. ;D
[attachment deleted by admin]
Thank you! Interesting… Now this is a bit strange, aside from being only DHCP DISCOVER packets, there is this little detail buried down in the bits:
Option: (t=50,l=4) Requested IP Address = 169.254.11.204
Now, whether this is just a filler address (its a parameter, and this is a default of some kind and is to be ignored), or a real live request, depends on what DHCP OFFER and REQUEST packets are using.
So, one more packet capture with Wireshark, getting a DHCP DISCOVER packet, followed by an answering DHCP OFFER, followed by a reply DHCP REQUEST. Same capture detail, total of 3 packets. That should see the IP address change in all that detail.
If the boot is actually looking for an allocation of 169.254.x.x, it’s not going to happen with a server giving out 192.168.0.x. Which would explain why there are only DHCP DISCOVER packets in the Wireshark capture.
From what I understand the 169.254.x.x is part of the automatic private IP addressing (APIPA) feature of XP pro. It seems that it uses it as a default when DHCP fails to correctly assign an IP address…I would guess that is why it would be showing up in the capture. I did make sure to /release the address before running the capture since I have noticed XP assigning that 169.254.x.x address after each failed attempt to get an IP assigned.
Well it seems with comodo’s network monitor on I cannot get a DHCP OFFER unless I allow everything all/all IP.
The latest capture with all IP in/out allowed is attached. Without all IP allowed I get just DISCOVER packets as you saw before. I had forgotten I removed that rule.
[attachment deleted by admin]
Curiouser and curiouser…
The 169.254.x.x “requested address” looks to be just a placeholder in the DISCOVER packet.
DHCP OFFER packet comes back with 192.168.0.151. DHCP REQUEST is confirming that very same 192.168.0.151. But the confirming DHCP ACK doesn’t show… So the handshake is taking place, but it doesn’t complete. The problem looks to be in the server host, maybe.
It’s going to take some time for me to walk the bits and confirm my initial observations. It could be that some request bit isn’t being set properly, and the server is waiting. Or something. But the capture does show that the packet exchange is happening.
I’m past the end of my day here, so it’ll be tomorrow before I can get a chance to see what’s what.
To add another twist to this I tried Comodo out on a different network at home, same problem there. Default install or modified rule list the new setup had the exact same troubles.
Thanks for the efforts and time in this. I know I’m not the only one from looking at the boards so maybe we can get something figured out here to help out future users as well.
I’ve been going thru the Wireshark capture, especially frames 3 and 5. That’s the DHCP OFFER and the confirming reply DHCP REQUEST.
The client got the offer from the server just fine. The client then tries to confirm the details with the server, and server just never answers.
I’ve been checking the DHCP parameters in frames 3 and 5. A bunch of reading in RFC 2131 and 2132, in all the bit detail. Everything is correct. Mostly.
There’s a nit buried down in there that shouldn’t make any difference, in my opinion. But I didn’t write the code.
The server is announcing the local domain name as “mshome.net”. A google search turns up this rather interesting Microsoft KB article: http://support.microsoft.com/kb/309642, which has some description about how mshome.net gets used.
In frame 3, the DHCP OFFER from the server, there is this parameter:
Option: (t=15,l=11) Domain Name = "mshome.net" Option: (15) Domain Name Length: 11 Value: 6D73686F6D652E6E657400
In frame 5, the DHCP REQUEST from the client, there is this parameter:
Option: (t=81,l=10) Client Fully Qualified Domain Name Option: (81) Client Fully Qualified Domain Name Length: 10 Value: 000000676262632D322E Flags: 0x00 0000 .... = Reserved flags: 0x00 .... 0... = Server DDNS: Some server updates .... .0.. = Encoding: ASCII encoding .... ..0. = Server overrides: No override .... ...0 = Server: Client A-RR result: 0 PTR-RR result: 0 Client name: gbbc-2.That's not a fully qualified host name. If it was, it would be "gbbc-2.mshome.net".
According to that Microsoft KB article, ICS has a DNS server that hosting the domain mshome.net.
I have this sneaking suspicion that that DNS server is trying to do a lookup of the unqualified client name “gbbc-2.”, and waiting for an answer. The problem is that the DNS lookup takes longer than the DHCP timeout, so the DHCP stuff fails.
Okay, a lot of words… To test things to see if this is in any remote form of the problem, the client should define the domain name that it is in as being “mshome.net”. To do that, on the client machine, go to Control Panel → Network Connections, right click the Local Area Connection and select Properties. Highlight the Internet Protocol, and click Properties.
That will put you on a tab “General”. Click “Advanced”, and that will give you more tabs. Pick the “DNS” tab. At the bottom of that tab page, there is a fill-in box “DNS Suffix for this Connection”. Fill that in with “mshome.net”, and probably mark the checkbox that says “register in DNS”. Okay all the way out.
And then try the DHCP stuff again. Watch it with Wireshark, and if you see a DHCP ACK, then you’ve got your complete DHCP handshake. And if not, then we have more data about what the problem isn’t.
REQUEST and OFFER only still, no ACK. Guess that tells us one more that that it is not. Though it seems to me eliminating things it is not is like trying to empty the ocean with a teacup. ;D
I appreciate all the help, any other suggestions before I give up on Comodo and go find a different solution?
I have attached another wireshark output of the DHCP connection with Comodo’s Network monitor turned off in case that helps at all. It works perfect as long as I kill the monitor.
[attachment deleted by admin]
Thank you… The working Wireshark capture shows that the domain name stuff doesn’t make a difference. It is good to see a working handshake, even if the context is different.
And it gives me a theory as to the cause, which doesn’t have a solution for you however. The thought is that the ACK is being seen but discarded as a duplicate packet by the stateful packet inspection. Your Wireshark capture shows only a few bits (specifically, 3 bits) difference in the data portions of the server OFFER and ACK packets. Two packets coming in almost together (less than 1.5 sec apart) might be considered to be the same packet, if the checking didn’t get all the way down into the bits.
One last shot, to test that theory, is to use packet checksum verification. This should be able to tell the packets aparts. In CFP, click Security → Advanced, Advanced Attack Detection → Configure, the Miscellaneous tab, and mark the checkbox Do Packet Checksum Verification. Your Wireshark capture had the OFFER checksum as 0xbb19, and the ACK checksum as 0xbb13. Almost the same, but maybe enough to tell the difference.
If that doesn’t do anything, then I’m out of ideas…
Unfortunately no difference. Well, looks like I’ll have to end up finding something other than Comodo that will allow the network to work. Does me no good to use a firewall if it blocks my own access to the computers as well. hehe
Sorry we couldn’t get this figured out, but that you for all the suggestions along the way!
Thank you for all the test runs and Wireshark captures. It’s been educational for me, to shake out some of the details that I haven’t remembered in a long time. And there is likely some very good test case data for the upcoming CFP v3 (which hit RC1 status last week), to see if a test environment can resolve the whatever it is that’s causing the problem. For your situation, though, I guess we can call this one resolved.