Jan Lokpal Bill - Jan Lokpal Bill – Standing Comitte Invites Memoranda, Trapped

Refer to the notification regarding inviting memoranda containing views / suggestions from individuals / organizations interested in the subject matter of the Jan Lokpal Bill and also to hear select oral evidence on the subject matter of the bill

The UPA government which has been functioning as a dictator and taking arbitrary decisions, appointed First Woman President completely ignoring the public mandate (refer the statement of Mr. Pranab Mukherjee, "Do not go by SMS polls and popularity ratings. The people of India don't elect the President, it is the elected representatives who elect him"
Take a note that, people of India elected those representatives to voice their opinions at parliament and to take decisions in the interest, welfare and growth of the nation. Those representatives had no reluctance in taking undue advantage of the designation, privilege, rights and power which people of India granted having full faith in democracy. These representatives had cheated poor and innocent people of India and took arbitrary decisions at their own will and only in their vested individual or party interests.
आप बताएं कि इन जन प्रतिनिधियों पर पद एवं अधिकार के दुरूपयोग तथा जनता के साथ विश्वासघात का मुकद्दमा क्यों नहीं चलाया जाना चाहिए

Though there are many more references on record, but just this one is mentioned for the sake of lack of time. In the light of such past arbitrary acts of these representatives, the standing committe must first clarify how and why should people of India trust the honesty and transparency of this initiative of inviting memoranda from the public.

If the government has really sincere, serious, honest and transparent views, it must first revoke the election of First Woman President, or ensure that the Election of President 2012 onwards will be by the people of India then talk about inviting memoranda from people of India.

In fact, the government is of the ideologies that:
People of India were gifted to 10, Janpath as economic slaves by british government at the time of Independence on day 15th August 1947

Please furnish your reply within 7 days. Also take a serious note that:

• Entire correspondence is published on various blogs, social sites and search engines across internet, keeping full transparency for the people of India whom the government is once again trying to deceive.
• Concerned authorities will be declared Absconders in the event of non-reply
  

जय हिंद
अशोक
सत्यमेव जयते

Govt. of India restricts Internet Access for Public – Test Report

UPA in an attempt to suppress the movement against corruption, has resorted to restricting internet access for the public. Partially though, but this has been noticed and thoroughly tested. Refer to the following post in which I raised the issue:

Govt of India blocks internet to suppress India Against Corruption

I apologize for not being able to publish the report produced by thorough diagnostic. For some reasons I can not disclose, I couldn’t be able to publish this post in time. But the following report leaves no doubt about the facts that internet access is being restricted deliberately.
Those are from Network or IT Profession, may read the test output added between (**********) line at the bottom

1. The public IP 70.86.183.2 was reachable
2. The domain thedotcomoffice.com failed to be resolved
3. The root DNS 4.2.2.2 was reachable
4. The DNS servers (203.196.128.5 & 203.196.128.4) of tata communications were reachable
5. The DNS servers (203.94.243.70 & 59.179.243.70) of MTNL were also reachable
6. The DNS server (218.248.255.139) of BSNL was also reachable
7. DNS query for domain google.com “Query refused” With the default DNS (203.196.128.5)
8. DNS query for domain google.co.in “Query refused”  With the default DNS (203.196.128.5)
9. DNS query for domain google.com  “Query refused” With the default DNS (4.2.2.2) which is root DNS

Before arriving any conclusion, I carried out further test on the DNS servers queried and the test output is also described below:
Root DNS sever (4.2.2.2) was listening on port 53 UDP that means the DNS  server was both reachable and running in good health
D:\Profiles\Ashok>portqry -n 4.2.2.2 -p udp -e 53 -i
Querying target system called:
4.2.2.2
UDP port 53 (domain service): LISTENING
DNS sever of Tata Communications (203.196.128.5) MTNL () & BSNL were all listening on port 53 UDP that means the DNS  servers were reachable and running in good health
D:\Profiles\Ashok>portqry -n 203.196.128.5 -p udp -e 53 -i
Querying target system called:
203.196.128.5
UDP port 53 (domain service): LISTENING
D:\Profiles\Ashok>portqry -n 218.248.255.139 -p udp -e 53 -i
Querying target system called:
218.248.255.139
UDP port 53 (domain service): LISTENING
D:\Profiles\Ashok>portqry -n 59.179.243.70 -p udp -e 53 -i
Querying target system called:
59.179.243.70
UDP port 53 (domain service): LISTENING
Conclusion:

1. None of the route was down. All the devices involved were reachable
2. There was no bandwidth related issue
3. There was no issue regarding device failure or resource over-utilization.
4. DNS servers were responding to the query on port 53 DUP
5. At the same time, using an internet connection of another ISP, all these domains were being resolved and websites were accessible too…

The DNS query by the client i.e. an internet user was not restricted. It was allowed to pass through to the DNS server. But the response from the DNS server which was from port 53 UDP to any high port was restricted by an intermediary device (firewall). There can be no other reason why a client shouldn’t receive the DNS query resolved.
For obvious reasons, this was done deliberately to deny internet access to the subscriber. I have noticed this problem scenario on Airtel Broadband connections, not once but on many occassions during the last 2 years and conducted the same tests. On this issue, senior technical personnel from Airtel were also challenged and similar report were produced before them. Airtel people were speechless and never reverted back with a solution. Since, in fact Airtel has been cheating on its Broadband Internet subscribers by overselling bandwidth.
But this time, the same problem scenario was noticed with BSNL connections. It is for obvious reasons, done by political influence.
It must be noticed that these restrictions have been applied based on 2 factors i.e. Time and Region. These restrictions are applied on randomly chosen time period and subnet ranges. Most probably, time based ACLs have been applied on internet traffic passing through the ISP network.
Since UDP is a connection-less protocol, it would be really hard to identify whether the remote server or the route was down or was it really being restricted by a firewall. Experts’ opinions are welcome on this report. Please send your comments or send me an email.
In case you find any website or any other internet services inaccessible, carry out the test to confirm the same. For non-technical internet users I shall publish another post with easy Step-by-Step instructions and commands used to diagnose the internet connection, DNS servers, websites or other services
************************************************************
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
D:\Profiles\Ashok>ping 70.86.183.2
Pinging 70.86.183.2 with 32 bytes of data:
Reply from 70.86.183.2: bytes=32 time=321ms TTL=54
Reply from 70.86.183.2: bytes=32 time=312ms TTL=54
Reply from 70.86.183.2: bytes=32 time=312ms TTL=54
Reply from 70.86.183.2: bytes=32 time=320ms TTL=54
Ping statistics for 70.86.183.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 312ms, Maximum = 321ms, Average = 316ms
D:\Profiles\Ashok>ping thedotcomoffice.com
Ping request could not find host thedotcomoffice.com. Please check the name and
try again.
D:\Profiles\Ashok>ping 4.2.2.2
Pinging 4.2.2.2 with 32 bytes of data:
Reply from 4.2.2.2: bytes=32 time=307ms TTL=240
Reply from 4.2.2.2: bytes=32 time=308ms TTL=240
Reply from 4.2.2.2: bytes=32 time=309ms TTL=240
Ping statistics for 4.2.2.2:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 307ms, Maximum = 309ms, Average = 308ms
Control-C
^C
D:\Profiles\Ashok>ping 203.196.128.5
Pinging 203.196.128.5 with 32 bytes of data:
Reply from 203.196.128.5: bytes=32 time=89ms TTL=55
Reply from 203.196.128.5: bytes=32 time=96ms TTL=55
Ping statistics for 203.196.128.5:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 89ms, Maximum = 96ms, Average = 92ms
Control-C
^C
D:\Profiles\Ashok>ping 203.196.128.4
Pinging 203.196.128.4 with 32 bytes of data:
Reply from 203.196.128.4: bytes=32 time=91ms TTL=55
Reply from 203.196.128.4: bytes=32 time=91ms TTL=55
Reply from 203.196.128.4: bytes=32 time=90ms TTL=55
Ping statistics for 203.196.128.4:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 90ms, Maximum = 91ms, Average = 90ms
Control-C
^C
D:\Profiles\Ashok>ping 203.94.243.70
Pinging 203.94.243.70 with 32 bytes of data:
Reply from 203.94.243.70: bytes=32 time=90ms TTL=245
Ping statistics for 203.94.243.70:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 90ms, Maximum = 90ms, Average = 90ms
Control-C
^C
D:\Profiles\Ashok>ping 59.179.243.70
Pinging 59.179.243.70 with 32 bytes of data:
Reply from 59.179.243.70: bytes=32 time=76ms TTL=245
Reply from 59.179.243.70: bytes=32 time=78ms TTL=245
Ping statistics for 59.179.243.70:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 76ms, Maximum = 78ms, Average = 77ms
Control-C
^C
D:\Profiles\Ashok>ping 218.248.255.139
Pinging 218.248.255.139 with 32 bytes of data:
Reply from 218.248.255.139: bytes=32 time=26ms TTL=249
Reply from 218.248.255.139: bytes=32 time=24ms TTL=249
Reply from 218.248.255.139: bytes=32 time=25ms TTL=249
Ping statistics for 218.248.255.139:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 24ms, Maximum = 26ms, Average = 25ms
Control-C
^C
D:\Profiles\Ashok>nslookup
Default Server:  ns1.direct.net.in
Address:  203.196.128.5
> server 203.196.128.5
Default Server:  ns1.direct.net.in
Address:  203.196.128.5
> set type=a
> google.com
Server:  ns1.direct.net.in
Address:  203.196.128.5
*** ns1.direct.net.in can’t find google.com: Query refused
> google.co.in
Server:  ns1.direct.net.in
Address:  203.196.128.5
*** ns1.direct.net.in can’t find google.co.in: Query refused
> server 4.2.2.2
DNS request timed out.
timeout was 2 seconds.
Default Server:  [4.2.2.2]
Address:  4.2.2.2
> set type=a
> google.com
Server:  [4.2.2.2]
Address:  4.2.2.2
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to [4.2.2.2] timed-out
> google.co.in
Server:  [4.2.2.2]
Address:  4.2.2.2
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to [4.2.2.2] timed-out
>
************************************************************