nbdname(137), nbdgram(138)
These are NetBIOS entries.
You'll get those time to time if you have NetBIOS service active, but your log is chock full of them! That doesn't look good to me.
This thread is drifting.
Before I reply to the quoted passage, let me explain that I, too, have the "
cmdagent.exe high CPU usage" problem. It is not a spike -- it is an ongoing condition, once triggered, which results in sluggishness so extreme that the PC is basically unusable. USUALLY, exiting the Comodo firewall GUI (cpf.exe) will immediatley 'fix' the problem, but sometimes a reboot is necessary. FWIW (in response to earlier posts, toward trying to find the common denominator / "trigger") I don't have IE7, I don't have eMule or any type of peer-to-peer app installed (nor any IM / messaging apps). Also, the number of events logged by the firewall on my PC are 'minimal' (per my ruleset) ~~ some days none, the max has been fewer than a dozen entries per day.
Okay, those
reported as "NetBIOS entries"...
they might
NOT be Netbios connections at all.
Those entries may well be DNS traffic.
Yes, DNS traffic -- being reported as port 137/138 traffic
Yeah, the screenshot shows all
inbound events; I'm guessing a permit/noLog rule was in effect and the matching outbound events weren't logged. I don't know whether the remote IPs match those of the poster's DNS serevers, but they probably do. Yeah, I can see there are "several" (more than 2) remote IPs involved but, hey, my own ipconfig includes
five DNS server assignments (local DNS proxy + 2 ISP servers + 2 OpenDNS servers, FWIW)
I can't say whether they represent "DNS traffic which has been mis-identified by the firewall and incorrectly labeled/logged" or whether WinXP SP2
actually does, given a certain network configuration, attempt to place DNS queries via port 137 and/or other ports in the Netbios range!
Huh?
Yeah, it sounds wacky, but I followed Alice down the rabbit hole -- searching all over the 'net trying to research and understand this, and that "maybe it actually does" statement (above) is where I wound up.
I found that I can "make the reported Netbios traffic cease", and have the traffic 'correctly' reported as port 53 traffic, if I remove Netbios ( TCP}}Properties ) but then I can't communicate with the other PCs on the LAN here. So what? Well, for starters, this PC hosts a shared printer...
Initially, I really got upset at thinking "rogue Netbios traffic" was going on. Elsewhere in the Comodo forums, I had read "make a rule blah-blah... what you're seeing is 'peer' traffic from old torrent stuff". Naw, even if that were accurate, it is not applicable in my scenario. Then I noticed that my PC was initiating the traffic! After more reading, I followed the advice to "uncheck
register this connection in ControlPanel }} Network Properties. The volume of traffic
did decrease after this, but it didn't cease entirely, and the
only remote IPs logged are those of my assigned DNS servers. (I later discovered that one of my local proxy apps is the source of the periodic {3-4 min intervals} DNS traffic.)
Next I read that upon
net start (Win 2003 server and) WinXP
first try to broadcast via port 445, then fallback to port 138 if any older Win98 (etc) PCs are found on the LAN... and that one "solution"
might be to disable Netbios and employ the NWLink IPX/SPX protocol instead. Well, that wasn't do-able for me. On this LAN, we each have a static IP (no DHCP and WINS in the equation) and (but) there are a few Win98 PCs.
I wound up
working around the issue by creating 4 in/out application-level 'permit' rules -- one for each DNS server --
for each of my 3 browsers (Opera/Firefox/MSIE)
Guess what? (Seems it might be relevant)
To make the 'noise' stop, I found that I also needed a similar set of 4 rules for
Acrobat Reader!
I scratched my head prior to creating application-level rules for the browsers -- they should all be utilizing proxied connections via 127.0.0.1 -- but, from having watched the alert popups and noting their timing, I realized that the proxy is sometimes bypassed. So, AcroReader doesn't respect one's http proxy settings, eh? Good to know, and that adds yet another degree to my disdain for that app.
Anyhow, if you peek inside a DNS packet... AND inside a Netbios packet, you'll find that the data is
remarkably similar. The Comodo firewall is "stateful", but is it actually sniffing the packets as to their content? If so, the 'mis-identified' traffic would be a bug. I don't think packet sniffing is the issue here, though.
I can't believe (er, cringe to imagine) that our NAT router is 'leaking' Netbios traffic. As well as a gateway, it can perform as a DHCP server. Although we're not currently using that router functionality on our LAN, maybe WinXP still recognizes it as such. Heh, I just checked -- yep, the router is still 'enabled' as a DHCP provider for the LAN. On the WAN side, the router in turn has an assigned gateway... but release/renew has never had an effect, so I don't know whether the DHCP is involved between the router and the ISP's assigned gateway.
So, I can't be certain until/unless I disable the DHCP for the LAN at the router, but I suspect the firewall app is
correctly reporting DNS traffic occurring on ports 137/138.
-=-
Observing the firewall report the traffic on port53 (after diabling Netbios, as I mentioned earlier in this post) supports this notion that, yeah, right now WinXP really is using the "Netbios" ports to place DNS requests. Does the port assignment get translated by the router? (I would expect the router is transparent.) I bet the ISPs nameservers are actually listening/responding on those ports in addition to port 53.
https://honor.trusecure.com/pipermail/firewall-wizards/1999-January/004533.htmlThe answer (I think): Windows based machines that try to resolve your
hostname will do a NetBIOS node status request to port 137 (NetBIOS
name service port, see RFC 1001/1002). It has to do with the
'gethostbyaddr()' sockets API function. Whereas a UNIX box might
resolve via DNS and NIS, Microsoft resolves via DNS and NetBIOS. 'gethostbyaddr()' sockets API function^--------- multiple apps concurrently placing these API calls
might be triggering "
cmdagent.exe high CPU usage" problem
Author