dslreports logo
 
    All Forums Hot Topics Gallery
spc
uniqs
21

mattei
Moderated, now muzzled
join:2001-03-19
Canada

mattei to Hall

Member

to Hall

Re: Web/HTTP access doesn't work, PING does

What do
netsh dump
 
and
netdiag /test:winsock
 
tell you? Anything interesting?

Hall
MVM
join:2000-04-28
Germantown, OH

Hall

MVM

'netsh dump'

Interesting to whom ? I piped it's results to a logfile and read through it and nothing glaringly wrong jumps out (to me).

'netdiag /test:winsock'

command not found

mattei
Moderated, now muzzled
join:2001-03-19
Canada

1 edit

mattei

Member

:)

I missed the part where you followed through on resetting winsock. Likely, nothing interesting to be seen. I was interested in IP/IPSec routing, transports, and proxies. You've tried:
netsh winsock reset
netsh int ip reset reset.log
 
right?

May as well complete the trifecta:
netsh firewall reset
 
Then enable logging (advanced tab on the FW dialog) and see what you can see in %systemroot%\Pfirewall.log.

Back to winsock. A system service (hidden, injected, or sitting in plain sight) could be adding to the catalog after reset. Try
netsh winsock show catalog >xsp.txt
 
An obvious sign would be the presence of something removed by the reset (check the reset log Edit: no reset log is generated for winsock - use a clean machine's catalog or Google and a fine tooth comb). Resetting winsock removed non-default Layered Service Provider registry keys. Unless one of the third-party repair tools claims to do more they're not going to help.

Sorry about the second one. netdiag is part of the support tools package (on the CD and a free download) but now that I've read all the steps you have and have not taken I see it's pointless.

AU uses BITS. BITS uses HTTP and HTTPS to transfer files. Another tool in the support tools package, bitsadmin.exe, will allow you to create jobs, add files to a job, and monitor progress. There's also a BITS MMC snap-in if you want a GUI but I don't know which editions, if any, have it installed. Never used it.

The presence of successful MS Automatic Update downloads means HTTP transport is working for the Update Agent but I'm fuzzy on the circumstances. Have any of these downloads occurred in Normal mode or were they all in Safe/Clean Boot modes? If I've read what you've reported clearly, ICMP (Ping) and UDP (DNS) seem unaffected.

The next thing that pops into my head is Group Policy restrictions. GPResult.exe might help. Myself, I'd probably have Process Explorer and NetMon running at this point as well as a copious supply of "Admin fuel" aka beer.

Hall
MVM
join:2000-04-28
Germantown, OH

1 edit

Hall

MVM

Will try the add'l 'netsh' commands you suggest.

As for the AU downloads, it seems to me that they're occurring while the PC is sitting at the login/welcome screen. It can be there for a long time. I'm working on this thing off and on (more off than on, mind you !). Also goes along with why I thought it was something related to the user's profile since 'net access (HTTP) works in Safe Mode.

I did try "Run as..." and signing in as admin but that's not allowed on XP Home it seems.
Hall

Hall to mattei

MVM

to mattei
said by mattei:

Then enable logging (advanced tab on the FW dialog) and see what you can see in %systemroot%\Pfirewall.log.
What would one look for in that log file ? All it contains (after attempting to access the 'net) is a bunch of "OPEN" and "DROP" UDP connections and they're all from "internal" IP addresses, i.e. 192.168.1.x addresses. Actually, since I launch the web browser -- wait, the XP firewall doesn't block outgoing connections anyway, does it ? -- the firewall shouldn't interfere.

mattei
Moderated, now muzzled
join:2001-03-19
Canada

mattei to Hall

Member

to Hall
said by Hall:

As for the AU downloads, it seems to me that they're occurring while the PC is sitting at the login/welcome screen.
When booting normally?
said by Hall:

It can be there for a long time.
Auto-login / login that seems slow or Hall is busy and it can wait?
said by Hall:

I did try "Run as..." and signing in as admin but that's not allowed on XP Home it seems.
Only in Safe mode (blank default password).
mattei

mattei to Hall

Member

to Hall
We're looking for something specific...and we'll know it when we see it :D. XP SP2+ has a stateful firewall that does not block outbound traffic but we can use it to help troubleshoot the network stack.

OPEN, good.
DROP, good, if the RECEIVE flag is shown. Probably port 1900?
UDP only, bad.

We should be seeing TCP connection OPENs when you attempt to access the Internet. Sorry that I forgot to mention this but did you check both logging options (dropped and successful)? If so, we've almost confirmed TCP protocol IP stream sockets aren't making it to the firewall. If that's not the case we'll move on to WinHTTP.

Could you try FTP or POP or SMTP or all three, then check the firewall log again? You said FTP didn't work but I'd like to confirm the lack of TCP entries in the log.

Afterwards,
netsh interface ip show tcpstats
 
Oddities like zero's, much > than zero for In Errors, Out Resets equaling or approaching Out Segments?

If netsh complains about the Routing and Remote Access Service you'll probably have to change the service startup mode from disabled to manual before you can start it.

Hall
MVM
join:2000-04-28
Germantown, OH

Hall to mattei

MVM

to mattei
said by mattei:

Auto-login / login that seems slow or Hall is busy and it can wait?
When there was only (1) account on the machine, it logged in automatically. At one point I added a "test" user account so when it boots, it stops at the Welcome screen.
Hall

Hall to mattei

MVM

to mattei
Let me stop the logging and get a fresh logfile to look at. Once I initiate it, I will attempt to access the internet with a browser and take a snapshot of the logfile at that point.
Hall

Hall to mattei

MVM

to mattei
pfirewall.log
2,898 bytes
The firewall logfile is attached. I actually cleared the logfile, restarted the firewall, and had to leave the PC.

.122 is the laptop itself. .50 is my PC. .104 is probably my wife's laptop.
Hall

1 edit

Hall to mattei

MVM

to mattei
tcpstats.txt
675 bytes
said by mattei:

[code]
netsh interface ip show tcpstats
[/code] Oddities like zero's, much > than zero for In Errors, Out Resets equaling or approaching Out Segments?
Here's the results of that command.

mattei
Moderated, now muzzled
join:2001-03-19
Canada

mattei to Hall

Member

to Hall
The UDP DROPs are just NetBIOS/SMB broadcasts and a few DHCP packets. Could you lather, rinse, repeat for FTP? I'd like to verify, via the log, that it's not just HTTP running over TCP that's blocked. All we're doing is proving the earlier assertions of a third-party component forcibly knocking all TCP connections down.

tcpstats;
I'm trying not to look at the obvious correlations and stick to RFC definitions but, well, eew. It looks like an ornery LSP where there shouldn't be one (or firewall hook, filter hook, intermediate NDIS driver ). I'll get back to those once the FTP test confirms it's TCP in general and not just HTTP but that's looking like a formality at this point.

Hall
MVM
join:2000-04-28
Germantown, OH

Hall

MVM

Will try FTP in a few minutes.

Remember, this still occurs when I disable XP's firewall so that leaves "filter hook" and "intermediate NDIS driver" from your list.

Doesn't one of the 'netsh' commands wipe out LSPs and make things start over ?

mattei
Moderated, now muzzled
join:2001-03-19
Canada

1 edit

mattei

Member

said by Hall:

Doesn't one of the 'netsh' commands wipe out LSPs and make things start over ?
Yes, but
said by mattei:

A system service (hidden, injected, or sitting in plain sight) could be adding to the catalog after reset. Try
netsh winsock show catalog >xsp.txt
 
An obvious sign would be the presence of something removed by the reset (check the reset log Edit: no reset log is generated for winsock - use a clean machine's catalog or Google and a fine tooth comb).