svchost.exe/255.255.255.255/22MB in 15 minutes

Help for v2
1

Hello,

I have read a number of posts on this forum (and a few other forums) about svchost.exe, and a couple posts dealing with the destination IP 255.255.255.255.

What I am wondering is why would it load to my machine 22MB of data? That seems like a lot of stuff.

I saw the svchost.exe for my dynamic IP address, since it listed my own IP, but it came and went quickly.

I put COMODO on Block All for a while (because I also had the issue of the continual ‘initializing’ message, and it was suggested that the Computer Security Level be reset by switching levels and then returning to Custom) and the svchost.exe/255.255.255.255 went away and did not come back.

Should I be concerned?

Thank you for your time,

HousieMousie2
(L)

Sorry, forgot to mention that Windows Updater is Disabled.

2

My first question is, 22 meg of what? I’d guess log information, but that’s me making a guess.

If it is log data, then what are a couple of lines from the log? Just to get a sense for what the problem might be.

If you go to a command prompt, and type “ipconfig /all”, what do you get for an answer? It should be your IP address, among other details.

3

I did not see where it was stashing the data, I will look for that next time I boot, and report back what I find.

Host Name…: (Displays correct info here)
Primary Dns Suffix…: (This field is blank)
Node Type…: Hybrid
IP Routing Enabled…: No
WINS Proxy Enabled…: No

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix: (This field is blank)
Description…: (Lists my NIC)
Physical Address…: (Displays correct info here)
Dhcp Enabled…: Yes
Autoconfiguration Enabled…: Yes
IP Address…: (Displays correct info here)
Subnet Mask…: 255.255.255.0
Default Gateway…: (Displays IP of similar range)
DHCP Server…: ...
DNS Servers…: ...
...
Lease Obtained…: (Date)

Lease Expires…: (Date)

Is the 255.255.255.0 and 255.255.255.255 the ‘same’ or close enough?

Thanks again for your time,

HousieMousie2

4

Hi housiemousie2 :slight_smile:

First things first. The address 255.255.255.255 is known as a Network Broadcast Address. That is, it is used by PC’s attached to TCP/IP networks (the Internet) to communicate with remote machines when the specific address of that machine is not known, i.e. a broadcast.

In your post you mention svchost in the same sentence as the broadcast address. Windows XP uses svchost for many things, one of which is the acquisition of an IP address from your service provider, when you connect to the Internet. svchost works in conjunction with the DHCP (Dynamic Host Configuration Protocol) which is a Win XP service, to find a DHCP server from which it can be issued an IP address. As it does not know the name or the IP address of the DHCP server, initially at least, it uses a broadcast (255.255.255.255).

Is the 255.255.255.0 and 255.255.255.255 the 'same' or close enough?

No, they are not the same thing. As I said, 255.255.255.255 is a broadcast address. In your situation, the 255.255.255.0 is a subnet mask. This is used to specifically identify a machine on a specific part of a network, a subnet. The mechanics of subnetting and superneting are a little too detailed to go into here.

As for the 22Mb, we would really need a few more details regarding this. If it is your log files, perhaps you could upload some details.

For details on how and what to upload, please see this post:

https://forums.comodo.com/help/important_please_read_before_posting-t9388.0.html

Toggie

5

Hi Toggie,

Comodo Version: 2.4.18.184
Data Base: 3.0
ISP: Cable
XP Home/SP2
Currently logged in as Admin
Avira AntiVir Personal Edition Classic: 7.06.00.270, shut down prior to installation of CFP
Windows Defender, disabled before boot, prior to installation of CFP
uh…
I had Zone Alarm, uninstalled it before installing Comodo

Is the attached information suitable?

Thank you for your time.

HousieMousie2

[attachment deleted by admin]

6

The first entry from your log
Date/Time :2007-11-05 10:16:03 Severity :Medium Reporter :Network Monitor Description: Inbound Policy Violation (Access Denied, IP = 10.249.64.1, Port = dhcp(68)) Protocol: UDP Incoming Source: 10.249.64.1:bootp(67) Destination: 255.255.255.255:dhcp(68) Reason: Network Control Rule ID = 5
This looks like a standard boot-up DHCP sequence. This is assuming you’re running a typical NAT/router that has a private LAN address of 10.249.64.1. Since this is a boot time message, I’m presuming then that you’re posting from a second machine, or have set a static address, as you’re obviously making a connection to the Internet. If the DHCP sequence fails, or is blocked in this case, that machine usually has a very hard time making a connection to anything.

On the machine that is trying to boot, you need to let the DHCP sequence complete. That means allowing that DHCP traffic in. Using the above log message as a guide, a rule like this, in place before the existing rule 5, should do the job:

allow in protocol UDP from host 10.249.64.1 to host 255.255.255.255

Then the machine will get an assigned IP address from the DHCP operation, and complete its normal boot up operations.

I didn’t pay that much attention to the timestamps in the log, but the persistence of the DHCP packets surprises me. It’s usually a handful of packets, and that’s it. What kind of NAT/router is this? It may have a configuration error.

7

I am on a cable modem, Arris Touchstone Telephony Modem, with no other equipment in between… I am unfamiliar with the 10.249.64.1 address. It is not Default Gateway, DHCP or DNS Server(s), as listed in the ipconfig /all.
I am using only one machine, the same one that is getting these log entries, and I have a dynamic IP address.
I have not had any connection issues.

What now?

Thanks again,

HousieMousie2

8

Strange… I had presumed this to be the typical NAT/router setup, but obviously it isn’t. My goof.

I’ve just eyeballed the Arris TM502 user guide, presuming it to be representative of the Touchstone product line. It seems to be a straightforward cable modem, with no particular LAN services. I have no idea as to why it would be trying to provide DHCP services to your PC.

Can you use your browser to connect to http://10.249.64.1/ ? I suspect this is the modem, and it will go to a configuration screen. If it does, take a screenshot and post it here. This may be a problem to take up with your ISP.

As to CFP rules, you can ignore my earlier suggestion about allowing host 10.249.64.1. Instead, you would want to block, and not log, any traffic. Very early in your Network Monitor rules, you would have this rule

deny in protocol IP host 10.0.0.0 mask 255.0.0.0 to any

Note that this rule will block everything from the modem, including any browser connections. So check the configuration screen stuff first.

9

Hi grue155,

Neither Firefox nor IE were able to connect to http://10.249.64.1/.

Let me make sure I have the new rule configuration right…

General:
Action: Block
Protocol: IP
Direction: In

Tab:
Source IP:
IP Mask:
IP: 10.0.0.0/ 255.0.0.0

Tab:
Destination IP:
Any

Tab:
IP Details:
IP Protocol: Any

So that the resulting rule looks like this (roughly)
Block | IP In | Mask:10.0.0.0/255.0.0.0 | [Any] | WHERE IPPROTO IS ANY

Correct or not?

I pushed the new rule to be ahead of the first rule dictating inward connections.

Thanks for your time,

HousieMousie2

10

That’s the correct rule, and the proper place to put it.

Whatever this is, it’s something with the modem or out into the ISP network. I’m sure their tech support folks will get queries enough that they’ll run it down and make some changes. Until then, this new blocking rule will keep that traffic from your PC, and won’t be filling up your logs.

11

Thanks for all your help, time and effort, grue155!

I will contact my ISP over it, but lol I doubt they will bother with it… the people I have spoken with in their tech department haven’t been the sharpest tools in the box. But maybe I can get them to pass the info up the chain.

Thanks again!

HousieMousie2

And the honorable mention goes to, Toggie! Thank you!

12

I seem to remember another scenario like this, where an IP address from the reserved 10.0.0.0 range was being offered to the user and they too were on cable. Eventually, it was determined that the IP lease was coming from their ISP.

Apparently on some cable networks, each segment is treated as a private network with all the routing being handled by the ISP.

If I had to hazard a guess, I’d say this is the same. A quick call to your ISP tech support should verify this.

If it is determined that your ISP is offering your PC an address in this range, you will have to allow it.

Toggie

13

I ve been seeing the same traffic all along on a cable modem

the 10.X.X.X net is often used in the boot process for The modem it self. Until seeing it on my CFP 3 logs I was not aware this traffic ever made it past the modem however it is possible as the modem is purely a bridge.
The 10.X.X.X would be the IP addresses on the cable side

Just to qualify my statements
I was a Cable modem tech for Bellsouth and also VOCable/Cable modem Analyst for MediaOne/ATTCable/Comocast for about 6 years

The network I am on now is in Quito Ecuador and I am not currentlly employeed in that capacity however this would explian this traffic.
I’ve always blocked this traffic with no ill affects
I don’t know what the 172.16.32.1 is, its not on my internet net work but I when in doubt I block it.

11/2/2007 23:05 System Idle Process Blocked 10.22.0.1 67 255.255.255.255 68
11/2/2007 23:05 System Idle Process Blocked 172.16.32.1 67 255.255.255.255 68

Just a comment from the peanut gallery

OD
PS
I would bet even most of the engineers at you cable company would tell you that it is not possible to see this any of the private side traffic. I know I always thought you could not. The Bootp must leak through. Most Customer (no) Service reps don´t even know about the two IP ranges on either side of the modem.

and yes some ISPs will use NAT and Private IP Addresses but Iam not sure how common it is.

14

Okay, so you guys are saying that the 10.0.0.0 is likely coming from my ISP, good to know.
Would this be an ‘invisible’ number to me? I ask because I do not see anything like it in the ipconfig /all, nor (obviously) in the System Info/ Adapter in Comodo.

I know this is an off topic question, and feel free to toss it back to me unanswered. Opus Dei mentioned the System Idle Process, I have yet to get a clear answer of what exactly the System Idle Process does and why it has to do it… can’t the computer just sit there quietly, doing nothing, until I call upon it? What is so bloody important that it has to do it every chance it gets?

Back on topic.

My IP lease will expire tomorrow morning. I guess I will find out then if blocking 10.0.0.0 was good idea or not. I don’t feel like releasing it right now… it’s bed time.

Thank you both for your knowledge and time.

HousieMousie2

Sorry, brain dead, DHCP was mentioned and I spaced it… according to my ISP, DHCP should be enabled in the Network settings.

15

housiemousie2

I would hazard a guess and say the IP Address 10.249.64.1 is that of you ISPs DHCP server. DHCP uses two ports for communication, port 67 and port 68. Client-sent packets have source port 68 and destination port 67; all server-sent packets have source port 67 and destination port 68.

Would this be an 'invisible' number to me? I ask because I do not see anything like it in the ipconfig /all, nor (obviously) in the System Info/ Adapter in Comodo.

Not quite sure what you mean by this? Is it that you don’t see a 10.0.0.0 IP address as your IP Address in ipconfig? If so, it’s not really surprising. Even though a DHCP server has a given address, it doesn’t mean it has to lease addresses in the same range.

Opus Dei mentioned the System Idle Process, I have yet to get a clear answer of what exactly the System Idle Process does and why it has to do it.

Lots of misunderstanding about System Idle Process in Task Manager. Essentially what your seeing, indicates what percentage of time the CPU is currently doing nothing but waiting for work.

OD Wrote:

I don't know what the 172.16.32.1 is, its not on my internet net work but I when in doubt I block it.

I’m sure you already know, but just to make the point. 172.16.0.0 is another reserved address block:

10.0.0.0 to 10.255.255.255
172.16.0.0 to 172.31.255.255
192.168.0.0 to 192.168.255.255
169.254.0.0 to 169.254.255.255

These blocks are invalid Internet addresses and are only used on private networks. Internet routers will not route these addresses.

Toggie

16

Interesting, and educational. I’ve worked small company LAN setups, which generally follow the textbook guidelines. What’s being discussed is not the usual kind of textbook stuff.

While it is true that the RFC 1918 address spaces (10.x.x.x, 172.[16-31].x.x, 192.168.x.x) don’t, or shouldn’t, be routed on the Internet, within a corporate LAN like that of an ISP those addresses are reasonable to expect. I’ve seen that kind of use for secured areas, like the bookkeeping department, but I’ve never run into it being exposed to customer space. It makes for chance for customer private allocation collision, or worse, spoofing.

One thing stood out in the log extract that housiemousie2 posted. All that traffic seemed to be just one kind of DHCP packet, from a server out to a booting client.

Wild speculation on my part, is that the ISP is doing some form of DHCP load balancing. This 10.249.64.1 is broadcasting addresses, and as a customer machine boots, that customer sees whatever offered address is in one of these broadcast packets, and then in turn handshakes to the actual DHCP server identified in the packet. That would explain the 22 meg of log data in a matter of minutes. The actual traffic would have to be examined to confirm or deny this is a valid guess or not.

It would also mean that CFP rules for this ISP in particular, and maybe cable modems in general, would be a little different. Maybe something like this:

remembering the DHCP server is port 67, and the booting client is port 68

allow out protocol UDP from host 0.0.0.0 port 68 to host 255.255.255.255 port 67
allow in protocol UDP from host 10.0.0.0 mask 255.0.0.0 port 67 to host 255.255.255.255 port 68

allow out protocol UDP from myhost port 68 to host 255.255.255.255 port 67
allow in protocl UDP from myLAN port 67 to host 255.255.255.255 port 68

allow in&out protocol UDP from myLAN to myLAN

This handles two distinct cases: when the offering DHCP server is outside the LAN, and client renews from inside the LAN, and the customer LAN has multiple hosts.

17

It´s possible these are both for Serving IP to client PCs, however I have been told 2 Bootp servers on the same segment is a no-no.

this is the reason I supect one is for the modems. I don´t suspect the are that there are many clients out ther serving IPs out their internet ports

I could be wrong as to the source of both the Private bootpS addresses But all I know is that in both the Cable LANs(CLANs) For Bell and MediaOne/ATTCable/Comocast the modems were on the 10 net I suspect theThe second address (172.16.32.1) is the DHCP server for the PCs as Toggie mentioned there is no reason they shold have to be on the same network, as the IP they serve,as a matter of fact, it would be good from a security point of view if they were not. I might sniffed my traffic and seesaw what I cancould find out

a lot of this is up to the CMTS (Cable Modem Ternmination System)engineers.

there is anouther convarsation about this here:

but they don’t reach a conclusion

OD
PS
with out sniffing my traffic alot of what I have mentioned is supposition
I have verified this see Ethereal snaps attached
cable_modem _bootp002.jpg The bootp offer to a Arris Cable Modem on this segment of the CLAN
cable_modem _bootp003.jpg The bootp offer to a PC on this segment of the CLAN
with a little work you could find out who the manufacturer of the Ethernet card in the PC was.

Note: This only applies to my particular situation but you will probably find many Cable nets the same

[attachment deleted by admin]

18

Just FYI, blocking the 10.0.0.0 had no noticeable negative effect on my internet connection.

19

Opus Dei. Thank you. I’ve something new and very useful.

housiemousie2, good to hear that blocking 10.x.x.x is okay.

As Opus Dei describes, and backed up by my own reading of Cisco CMTS stuff for my own education, cable networks are unusual in their configuration. The case here seems to be the ISP is using 10.x.x.x for their internal cable modem LAN. Yes, the cable modems are a LAN unto themselves, which have their own DHCP process to download DOCSIS configurations. That CFP was logging all those DHCP packets would seem to mean the ISP has a configuration error, as the cable modem DOCSIS filters should block all that traffic. That would explain why only one kind of DHCP packet was coming in.

Keeping the CFP rule to block incoming 10.x.x.x traffic will keep your logs from filling up. As to the ISP getting their configuration details straightened out, that is a different question.

What should happen, goes something like this.

The cable modem powers up or reboots. It is on a private LAN, 10.x.x.x, and has to get an address on that LAN to complete its boot process. The DHCP server for the cable modem is apparently 10.249.64.1. Once the modem has it’s IP address, the modem downloads a DOCSIS configuration file, does the necessary setup, and begins to pass Internet traffic.

The PC can now reboot, and uses (most likely) a different DHCP server, and gets a public Internet address. The cable modem is functioning as the end-point of a bridge, controlled by the cable network head-end, which receives traffic as routed thru that private cable modem LAN. That private LAN is known as “Cable Management Termination System” CMTS. The CMTS should be completely invisible to the end user customer.

What you were seeing, was traffic intended for that private LAN. Ooppss… Not supposed to happen.

20

No problem Grue,
AS I stated I thought this was not possible as I bet do many engineers.

As I am seeing this traffic On a CLAN in ecuador and housiemousie2 is seeing it where ever they are, and I found other discusions reguarding this on the INET I suspect this a common problem in CLANs.

I can only aseume the similarities indicate it its the same type of source for the traffic. I could not be sure without a packet capture.

OD