2. We used "telnet www.ntscmp.com 80" to test from a Netvigator connection, and we can connect to the site for a very short moment, and then the connection was closed gracefully. So it is most possible that the end site (ntscmp.com) accepts and then closes the connection."FIN", presumably means "Finish". Yes? That's to say, when you point and click your browser (A) you send a "GET" command to ntscmp.com (B) -- but somewhere on the return trip between (or at) B and A a "FIN" command is issued and closes the connection, hence the blank screen. Yes?
3. Normally, such situation of a connection being caused to terminate gracefully is due to the end site trying to block certain IP addresses from accessing it, most usually because they know they are from hackers or their messages may contain viruses. (But we cannot say definitively that this is the case here.)
4. We were not blocked from accessing the end site (because it did connect momentarily), so it is definitive that Netvigator did not block the end site's IP address from its end (i.e. firewall blocking).
5. On reading tcpdump log from the connection to ntscmp.com, we found that the instruction to close the connection was a "FIN" packet that was issued from somewhere every time we made a connection to ntscmp.com.
6. Such a "FIN" packet can be issued by any privileged user from any of the segments between ntscmp.com and Netvigator (or HGC). The only way to find out would be for us to be able to put a sniffer on first ntscmp.com and then on possible each segment in better Netvigator (or HGC) and ntscmp.com. But, since ntscmp.com is in the U.S., and we do not have any way to actually put a sniffer on the network segment, we are unable to try to identify the source of the "FIN" packet.
But why is the return trip "FIN" command at or before B only seeming to kick in after a "GET" command from A, that A being Netvigator and Hutchison Global Communications IP addresses? Why isn't the return trip "FIN" command at or before B kicking in after a "GET" command from other IP addresses elsewhere on the planet? That isn't happening.
That puzzles me. Can anyone clarify for this semi-educated online user why "FIN" kicks in for some IP addresses but not for others?
And, given that for every problem. . . people say. . . there is a solution. . . can what has been "done" with FIN be "undone"? Can we, in a manner of speaking, finish with FIN?
Thank you. Mister Bijou salutes you.
2 comments:
Have been enlarging my understanding of http and the modalities of the Internet this past week or so. So I much appreciate the time you spent and explanations given in your comments above. Facts are a lot clearer in my mind as a result.
I didn't know, for instance, that Netvigator had acquired other ISPs, and thus has a hodge podge of IP addresses. Hence some Netvigator subscribers can access NTSCMP while others cannot.
Still. it looks as if NTSCMP's IP address has been interfered with. And whoever did it didn't leave any fingerprints. Moreover, the NTSCMP webserver has more holes in it than a Swiss cheese -- you recently posted an item that included a scan by dshield.org (courtesy of Steve Wong). According to that scan, a number of NTSCMP's ports are open and have been entered. Yes, if NTSCMP had more sense he would move the website to a more reliable and secure web hosting company.
Again, many thanks.
Mister B
Post a Comment