Chris said:
Hi Paul,
Thanks for the response. There are wizards to setup different access (eg
web browser) but using them hasn't helped. The puzzle is that I have
only come across 3 maybe 4 websites that I can't access in the 3+ months
I have had this motherboard - everything else (non secure, secure,
plugins etc) has worked fine.
I have run ethereal with firewall on and firewall off and can't really
spot any difference (except for the fact that I can access the problem
websites when it is off) - the only thing is some packet checksum errors
which I guess might cause the packet to be blocked?
Cheers,
Chris
Have you been fiddling with MTU ? Maybe your problem is related to
packet length and the "don't fragment" bit. MTU problems can
results from packets passing through network devices that
encapsulate them (like PPPOE), as the extra header counts as
part of the maximum packet size, so the real payloads have to
be smaller than normal.
I had a problem once, where suddenly my email wouldn't work if
I had an attachment on outgoing email. A short email would get
through, but a large one wouldn't. I phoned tech support at my
ISP, and they were all "oh, sir, it is your crappy misadjusted
equipment causing the problem", when in fact, they had been
changing the email server, and I had to set the MTU on my email
computer, to work with their email server, even though every other
site I connected to worked fine.
The email server was apparently implementing what I believe is
called a "black hole". As I understand it (it has been a while
since I fixed this), normally a computer sends a packet, and
if the packet gets jammed somewhere along the way, the offender
sends something back, and then your node can fragment the packet
into pieces and try again. I think this may involve an ICMP
packet. Well, ICMP is also used for "ping", and ping is
used for buffer overflow attacks on Internet machines. So,
clever IT staff turn off ICMP on a machine (like my email
server), to stop that kind of thing. Everything would have
been fine, if the email server had a normal sized MTU, but
for some reason it didn't. When a too big packet goes to that
machine, no ICMP with the bad news comes back, and TCP in
my case at that point was deadlocked. I would have to kill
my email client to escape.
This thread gives some sample terminology:
http://groups.google.com/groups?threadm=uyjMxjQ7BHA.1684@tkmsftngp04
Now, I tried sniffing to your sample sites, and I don't see
any weird port numbers. My sniffing tool doesn't have the
notion of CRC errors, and you would think my router would
drop an errored packet anyway. I also tried the ping -l
style test, and in fact, had trouble sooner with my own
ISP's web site, than I did with Dabs. So, I'm not convinced
there is a black hole problem here. (Right now, I can ping
two of them, and not the third.)
The three sites are commercial. Is that significant ?
I'm afraid I've run out of ideas. I don't know if your CRC
error observation is significant or not. I don't even
know if CRC is carried through the Internet (end to end
protection), or whether it is point to point. Since
TCP/IP is a reliable protocol, I would think it would be
acceptable for an interface somewhere along the path between
source and dest, for an errored packet to be dropped. I
don't think there is any benefit to carrying an errored
packet all the way to the final receiver. Does that mean
the errors you are detecting are in the final hop to your
computer ?
In your position, I would either play with the MTU or
the black hole detection in the Registry. In any case,
plenty of Googling ahead for you
Hope you can
reach Google
))
Perhaps someone in a networking newsgroup could help ?
Paul
