08-18-2011, 08:07 PM
Hey Lindross, how did things work out for you? Hope you got everything taken care of ok.
You may have missed something in an earlier post perhaps? His results are saying he\'s able to reach the destination 100% without loss. So he can ping from his end. He\'s just not receiving a reply back from the destination host.
I def agree on that for sure. I would hope something like that wouldn\'t have changed lol. Although I\'m not really seeing anything in what i posted that could have implied my reason to have him try another browser would be related to ping being browser specific?
Even still there are many reasons for a user to try another browser in a situation like this.
(obviously some things wouldn\'t apply to this situation since it\'s one specific site he cannot connect to. Plus the fact he is able to send ICMP requests out to the site with zero loss)
Using a different browser could very well enable him to connect to the site properly, and help rule out client side network connectivity or IE specific issues. It would provide a very good direction to figure out the problem if another browser did the same thing. There could be a number of things wrong within IE, or how a browser application along with system files or network configurations are interfacing with one another.
In his case the problem could very well have been caused from a recent update to IE, a recent IE add-on installation/update or a virus could have caused a problem within the IE LAN settings. Installing FF would would allow the ability to compare settings between the two and rule out wether or not the IE application itself has the issue or all browsers in general
It could be a bad or expired cookie that wont clear from IE. Since his problem started sometime after MM.net went down, certain configuration changes server side during repairs could require his IE to have a new cookie, since it would be recalling the cache from a cookie that is no longer viable to the site. Resetting IE for example could be a solution to clear a corrupt cookie. If not returning to a previous restore point or last known good configuration might be an idea as well.
Or maybe it\'s something that has to do with a new PHPbb version/update on the server side that won\'t support older versions at all, or could likely cause errors with the a browser if IE was under say IE9 for example.
The site may also have decided to set requirements that don\'t allow machines under certain versions to access the site, helping to reduce server load for users that IE versions that are no longer supported by current software and/or changes in server platforms. Users would have to upgrade their browsers to access the site that way. No sense in having 1000 users who cannot view or load the site properly stress the server and crash the site without being on a dedicated server. Possible a warning message to display any new restrictions to a user isn\'t being displayed. Only thing that would show would be the "unable to connect to site" message window.
Or in a more complex situation not having any browsing capabilities at all, no matter which website or destination we try (yet we are still able to send the ICMP echo request successfully to any host) That could be related to a problem from a MS system update. A service pack or other major system update could very well cause an error or corruption within winsock and could cause IE or a default browser to not work right. If windows doesn\'t know how to access certain network services properly for that application, then there would be an issue in interfacing the TCP/IP client and the TCP/IP protocol stack properly.
Trying a different browser could help you rule this out. If a new browser works and the default does not, we have a good idea that the problem with the default browser very well lies somewhere between the transport and application layers. Run a winsock repair and move up from there.
Again after all he is able to successfully send his ICMP echo request to the destination without any loss or timeout. The problem here is zero packets being received by his machine from MM.net. If it had anything to do with a break in the routing path from his machine or gateway to the destination host, he wouldn\'t be able to send that ICMP request with zero packet loss. It would show a loss in his packets sent. Then with that result use Tracert to see where the packet is being dropped in the request.
I don\'t follow? The Tracert made it because it\'s established already that all echo request packets sent from his end are reaching the destination 100%, with zero packet loss.
He would have received some sort of packet loss if there were a break in the ICMP request forwarding path between his gateway and their gateway. Packets dropping at any router in the forwarding path from the initial request would have its IP excluded from the current routing table once TTL expired the first time around. Any time there after that he tries to connect to the site, an attempt at a new routing path is made to avoid said break that has occurred in the original ICMP request. Until the ICMP reply returns to him 100% successful, an updated routing table with a working path would not be created, telling us by sent packet loss the destination host is not reachable from a down router.
In either case whether it zero packets or 2 packets that were received by him, Tracert wouldn\'t even be a viable option. It\'s only going to show issues in one direction from user A to host B unless Tracert was sent back from MM.net\'s side to his machine. The machine getting from A to B is not the issue. It\'s B back to A.
The Pathping cmd would verify a break in the return from host B to user A because that cmd sends the packet roundtrip to the destination then back to the user if it\'s not possible to run a Tracert from both sides.
I see you edited your one reply to me for whatever reasons that originally stated
"I could tell you have some experience in IT."
All I was doing was trying to help someone. I don\'t see why comments like that were really called for or even close to necessary? Also factoring in this is a Horror forum and someones personal place of business who cares who comes up with the solution or what it was that fixed it, as long as it gets solved and everyone goes back to enjoying masks and Horror. It\'s why we are here correct? It\'s cool though. It is what it is is cyberland.
There is a certain type of camaraderie that most with careers in IT stand by no matter how much or how little experience they have. And part of that is maintaining some level of professionalism that carries a bit of respect for another as a simple common courtesy, let alone generally.
When one IT person is trying to help someone in situations like this, why not just offer some input that would benefit the actual situation at hand? Or If the only meaning behind chiming in to help is just another opportunity for soothing ones ego, why not just keep the comments to yourself then? I don\'t get it that sometimes. It doesn\'t reflect a persons vast knowledge or experience at all. In fact generally comes off just the opposite or something else entirely.:/
There will always be millions of people out there who have more knowledge of something than someone else. That fact will never change and like most I myself know this, as facts are concrete. If I couldn\'t accept that as fact I most likely would have been the type to start this entire post with something like "I could tell you have some help desk experience"
Instead of ending with it...
Take care,~Jonny
(01-01-1970, 12:00 AM) link Wrote:Good suggestions so far! I\'m an IT tech for a living, so I figured I should chime in.
If you can\'t ping the site..
You may have missed something in an earlier post perhaps? His results are saying he\'s able to reach the destination 100% without loss. So he can ping from his end. He\'s just not receiving a reply back from the destination host.
(01-01-1970, 12:00 AM) link Wrote:it won\'t matter what browser you try to use as the ping command is not browser specific
I def agree on that for sure. I would hope something like that wouldn\'t have changed lol. Although I\'m not really seeing anything in what i posted that could have implied my reason to have him try another browser would be related to ping being browser specific?
Even still there are many reasons for a user to try another browser in a situation like this.
(obviously some things wouldn\'t apply to this situation since it\'s one specific site he cannot connect to. Plus the fact he is able to send ICMP requests out to the site with zero loss)
Using a different browser could very well enable him to connect to the site properly, and help rule out client side network connectivity or IE specific issues. It would provide a very good direction to figure out the problem if another browser did the same thing. There could be a number of things wrong within IE, or how a browser application along with system files or network configurations are interfacing with one another.
In his case the problem could very well have been caused from a recent update to IE, a recent IE add-on installation/update or a virus could have caused a problem within the IE LAN settings. Installing FF would would allow the ability to compare settings between the two and rule out wether or not the IE application itself has the issue or all browsers in general
It could be a bad or expired cookie that wont clear from IE. Since his problem started sometime after MM.net went down, certain configuration changes server side during repairs could require his IE to have a new cookie, since it would be recalling the cache from a cookie that is no longer viable to the site. Resetting IE for example could be a solution to clear a corrupt cookie. If not returning to a previous restore point or last known good configuration might be an idea as well.
Or maybe it\'s something that has to do with a new PHPbb version/update on the server side that won\'t support older versions at all, or could likely cause errors with the a browser if IE was under say IE9 for example.
The site may also have decided to set requirements that don\'t allow machines under certain versions to access the site, helping to reduce server load for users that IE versions that are no longer supported by current software and/or changes in server platforms. Users would have to upgrade their browsers to access the site that way. No sense in having 1000 users who cannot view or load the site properly stress the server and crash the site without being on a dedicated server. Possible a warning message to display any new restrictions to a user isn\'t being displayed. Only thing that would show would be the "unable to connect to site" message window.
Or in a more complex situation not having any browsing capabilities at all, no matter which website or destination we try (yet we are still able to send the ICMP echo request successfully to any host) That could be related to a problem from a MS system update. A service pack or other major system update could very well cause an error or corruption within winsock and could cause IE or a default browser to not work right. If windows doesn\'t know how to access certain network services properly for that application, then there would be an issue in interfacing the TCP/IP client and the TCP/IP protocol stack properly.
Trying a different browser could help you rule this out. If a new browser works and the default does not, we have a good idea that the problem with the default browser very well lies somewhere between the transport and application layers. Run a winsock repair and move up from there.
(01-01-1970, 12:00 AM) link Wrote:A traceroute to MM.net\'s IP address should show you where the disconnect is happening between your computer\'s network card and their server)At that point wouldn\'t one agree Traceroute would be redundant?
Again after all he is able to successfully send his ICMP echo request to the destination without any loss or timeout. The problem here is zero packets being received by his machine from MM.net. If it had anything to do with a break in the routing path from his machine or gateway to the destination host, he wouldn\'t be able to send that ICMP request with zero packet loss. It would show a loss in his packets sent. Then with that result use Tracert to see where the packet is being dropped in the request.
(01-01-1970, 12:00 AM) link Wrote:Your traceroute made it all the way to the site...I would like to connect to you remotely to see what\'s going on...would that be an option?
I don\'t follow? The Tracert made it because it\'s established already that all echo request packets sent from his end are reaching the destination 100%, with zero packet loss.
He would have received some sort of packet loss if there were a break in the ICMP request forwarding path between his gateway and their gateway. Packets dropping at any router in the forwarding path from the initial request would have its IP excluded from the current routing table once TTL expired the first time around. Any time there after that he tries to connect to the site, an attempt at a new routing path is made to avoid said break that has occurred in the original ICMP request. Until the ICMP reply returns to him 100% successful, an updated routing table with a working path would not be created, telling us by sent packet loss the destination host is not reachable from a down router.
In either case whether it zero packets or 2 packets that were received by him, Tracert wouldn\'t even be a viable option. It\'s only going to show issues in one direction from user A to host B unless Tracert was sent back from MM.net\'s side to his machine. The machine getting from A to B is not the issue. It\'s B back to A.
The Pathping cmd would verify a break in the return from host B to user A because that cmd sends the packet roundtrip to the destination then back to the user if it\'s not possible to run a Tracert from both sides.
I see you edited your one reply to me for whatever reasons that originally stated
"I could tell you have some experience in IT."
All I was doing was trying to help someone. I don\'t see why comments like that were really called for or even close to necessary? Also factoring in this is a Horror forum and someones personal place of business who cares who comes up with the solution or what it was that fixed it, as long as it gets solved and everyone goes back to enjoying masks and Horror. It\'s why we are here correct? It\'s cool though. It is what it is is cyberland.
There is a certain type of camaraderie that most with careers in IT stand by no matter how much or how little experience they have. And part of that is maintaining some level of professionalism that carries a bit of respect for another as a simple common courtesy, let alone generally.
When one IT person is trying to help someone in situations like this, why not just offer some input that would benefit the actual situation at hand? Or If the only meaning behind chiming in to help is just another opportunity for soothing ones ego, why not just keep the comments to yourself then? I don\'t get it that sometimes. It doesn\'t reflect a persons vast knowledge or experience at all. In fact generally comes off just the opposite or something else entirely.:/
There will always be millions of people out there who have more knowledge of something than someone else. That fact will never change and like most I myself know this, as facts are concrete. If I couldn\'t accept that as fact I most likely would have been the type to start this entire post with something like "I could tell you have some help desk experience"
Instead of ending with it...
Take care,~Jonny