Why would I see lots of traffic going to Internet Assigned Numbers Authority (224.0.0.22). I am also seeing lots of checksum errors on the TCP packets. Any thoughts? Regards, Jeffrey asked 31 Jan '11, 07:36  Jeffrey edited 02 Feb '11, 18:37  Guy Harris ♦♦ |
3 Answers:
224.0.0.22 is the multicast address for Internet Group Management Protocol. This is normal traffic, and it stays on your local network. answered 31 Jan '11, 08:31  Jim Aragon |
The connection to 224.0.0.252:5355 with protocol UDP is used by recent versions of Windows for Link Local Multicast Name Resolution (LLMNR) searching for local network computers. If you have no local network you may disable LLMNR with a peculiar registry setting. Create and execute the file "disable-LLMNR.reg" containing: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient] "EnableMulticast"=dword:00000000 answered 29 Oct '15, 11:11  gil06 |
With windows 7 i see broadcasts to, 224.0.0.1, 224.0.0.22, 224.0.0.252, and some crazy 239.235 combinations haha. It doesn't always specify a port for some reason I guess because it is internal broadcast like an above poster said. But still.....kind of gullible feeling. Kind of feeling like u can't trust anyone feeling. Even on my home network nowadays, who knows whats on it spoofing things at any time. Feels like every website and program that exists is already hacked before it gets to my computer. And they tell us torrents have viruses? hahaha Hey look up the Michaelangelo virus and Chernobyl(CIH) virus that ibm was spreading with new pcs years ago....lol Now its 2013 and ten times worse, your oblivious to think otherwise..... Anyways, i have alot of services disabled. upnp, in windows and router(i had to use a secret text link to a hidden page in my Verizon router to shut this off. I guess verizon sees it as people disabling upnp and then calling tech support when their game or voip or w/e device doesn't work, even they don't take security serious or wanna educate their customers....lol). I have ipv6 disabled everywhere you see it in windows settings and firewall and router, ...every once in a while i still see a network broadcast on it. But i have no idea.....which address is for which protocols in the predefined rules. Maybe some nice Microsoft Gentleman will shed some light on the 224.0.0.0 addresses. someone please correct me. but i believe netbios file sharing in windows is ports 137, 138. look for the ip of the computers on your network thats all you need to allow. and i think the only broadcast you would need to allow is most liked 192.168.1.255. This might correlate with your router....mine is default ip. and I believe its the only one i had to allow to share files on my home network. possibly in addition 224.0.0.1. but i would try without it first. Block everything else ip subnet from 224.0.0.0 to 255.255.255.255, 10.0.0.0 - 255, 127.0.0.0-255, 169,254.0.0-, 192.0.0.0-, 198.18.0.0, 198.51.100.0, 203.0.113.0, everything to 255.255.255.255, those are all internal addresses. sometimes when your router doesn't know who you are it will give you a 169.254 internal address. You can set dhcp to w/e you want or do it manually. default is 192.168. good luck. just to add: Sometimes you gotta wonder why so many programs wanna broadcast out to those internal addresses as well......and why so many websites, even major corporations, have so many unknown ip's associated with them. port 80 and 443 and 53 are just becoming flood gates of all streams of servers. These companies are gonna have to start registering every single ip address and domain associated with their site. Even microsoft is like secretive what ips they use specifically for updates!! When the whole web becomes all httpS, they gonna have to let us know who the heck is connecting to my pc. Thats the truth, its getting ridiculous out here. SO many dam viruses. SO many spies, so many ads lol. Their needs to be a public listing, something better then public domain tools. I thought this site is pretty cool tks for letting me post. Rich. answered 10 Apr '13, 19:06  CooloutAC edited 10 Apr '13, 21:36 |
OK thanks. How about the bad checksums, almost everyone has an issue. I was also seeing issues with downloaded files being corrupt and also connections constantly being lost with a VPN. Any thoughts?
If you are capturing on one of the end hosts involved in the communication, then the bad checksums are probably caused by TCP checksum offload. When TCP checksum offload is enabled, calculation of the TCP checksum is done by the NIC driver software, rather than by the computer's CPU. Wireshark sees the packet before it's passed to the NIC driver, so the checksum has not yet been calculated, which results in the error. The correct checksum is calculated before the packet is put on the wire. In this case, the checksum isn't really bad, and the error is cosmetic.
If this is the case, you can eliminate the error display in one of two ways:
Disable TCP checksum offload in the NIC driver. This will force the TCP checksum to be calculated by the computer before the packet is passed to the NIC driver,so Wireshark will see the correct checksum.
Turn off TCP checksum validation in Wireshark. Wireshark still won't see the correct checksum, but the error messages will be suppressed.
If the checksums really were bad, every packet with a bad checksum would be retransmitted or the communication would fail. So, if the communication succeeds, and you don't see retransmissions of the packets with bad checksums, then TCP checksum offload is the cause.
Another clue that TCP checksum offload is involved is that the bad checksums will only appear on packets SENT by the system where the capture was done. Packets received from other systems will show a correct checksum.
If the checksums are really bad, then some device along the path is mangling your packets.
(changed the additional answers to comments to adhere to the Q&A character of this site)