Computer Services Centre

The CSC creates user accounts only upon receiving authorization and user data from the respective sections through ACSS in electronic form. Such authorizations and data are created by E-I for faculty, E-II for staff, IRD section for IRD staff, UG and PG sections for students and by faculty members for visitors. Once the data is created the ACSS transfers the data electronically to CSC where the pending accounts are created several times a day during working hours with the click of a button. For visitors, we also require the signed forms to reach us before creating the accounts.

If you are a new faculty member or a visiting faculty member who has just joined the institute, we will be happy to bypass the above process and create an account immediately. We request you to download this form, fill it up and obtain an authorization from your HOD/HOC. Please send the filled form over to us, or drop by for a cup of tea and we will create your account immediately. We will update your account information when a more formal authorization becomes available from the E-I section.

It will not be possible for us to follow the above procedure for others, and we will require a formal authorization. We are sorry about this. You can find out from the CSC reception counter (Phone: 1771) during working hours whether your data and authorization have reached the CSC. If not, we will pass on your request to the respective sections. In the interim you can request a faculty member of the Institute to create a temporary guest account for you through an interactive form available at https://www.cc.iitd.ernet.in/usermanage/guest-account.html

For new students at the beginning of an academic year the passwords are usually distributed at the time of registration.

All other users are requested to collect the passwords in person from the CSC reception counter during working hours. Users are requested to carry their identity cards.

Through the interactive web-page at https://userm.iitd.ernet.in/usermanage/pwchange.html

No, it is against the CSC policy to send passwords over email. You will have to visit the CSC reception counter during working hours with your identity card. An explanation may be sought if it is felt that the request is frivolous and you may be requested to obtain an authorization from your course advisor/supervisor. The CSC has over 10000 users and frequent such requests put the CSC staff under undue pressure. We request all users to cooperate and be careful with their passwords.

It is nearly impossible for your account to be hacked unless you have been careless. We use the highest industry grade encryption standards for all facilities where you are required to provide your password - the same that is used by most commercial banks. The only ways in which your account can be hacked are i) you have not installed the IITD CA-certificate as instructed on our web-page at http://www.cc.iitd.ernet.in and have accepted a false certificate presented by an attacker ii) have set an easy to guess password, or iii) have keyed in your password in an untrustworthy machine.

If indeed your password has been stolen then the third method above is most likely. Any machine which has been configured as a single user machine and is being used as a public multi-user machine, perhaps through a common account, is not safe. If you enter your password in the browser of such a machine it can possibly be read off by the next user, even if you have not permanently stored your password in the browser. Also, it is fairly easy to install a malicious program like a key logger on such machines, and such instances are fairly common in IITD. If in doubt, please don't use such a machine and use the CSC lab machines instead - these are safe. Even if you use such a machine, make sure that you have deleted your password from the browser's memory and have closed the browser properly after you are done. Also, please request the person in-charge of the facility to configure the machines as proper multiuser machines as per the guideline of the OS vendor. As a general precaution you should also change your password frequently.

We can almost surely trace any person who may have used your account, but we may not always be motivated. There are 10000 users in IITD and we don't have the bandwidth to investigate every case. As far as we are concerned keeping the password safe is a user's responsibility.  We will investigate only when there are strong reasons for us to do so or when we are instructed by the IITD administration.

Please see above. No, it will not be reset unless you can give a satisfactory explanation.

Setting your machine to use Dynamic Host Configuration Protocol (DHCP) should be sufficient in the wired LAN to automatically obtain an IP address and other network parameters.

Alternatively, you can obtain a fixed IP address and other necessary network setting parameters (netmask, gateway address and name server details) from your local network administrator of your department or centre and configure the network settings manually.

Please see our web-page for the procedure for getting connected to the wireless LAN.

Getting on to the IITD network does not automatically enable you to access the Internet. For that, you need to configure your browser to use one of the IITD proxy servers. Accessing IITD email does not require proxy. Please see our web-page at http://www.cc.iitd.ernet.in for details.

You have to determine which part of the network you are unable to access.

1. First you should check whether you can access your gateway by trying ping 10.x.1.1 where x is the number corresponding to your VLAN (you can determine this from your IP address, which should be of the form 10.x.y.z).
2. If the ping fails then you should determine whether others near your physical location are able to ping the gateway. If everybody in your block is facing the same problem then there may be a problem with the network switch in your block - most likely the UPS to which it is connected is down. In such a case this would be visible in the network management console at the CSC which is manned by an engineer from HCL during office hours. He/she would most probably be on the job, but you can call and check at 7126 or 7185, which are the phone numbers of the network support desk at the CSC. Please also make sure that the HCL engineer can access the switch and the UPS, the physical access of which are with the department or center occupying the block.
3. If ping fails only for you then most likely your network settings may be wrong. Please verify that the settings are correct.
4. If you are reasonably certain that your network settings are correct, then you should check whether the network port you are using is faulty. You should do the following basic checks before deciding that it is the port that is faulty:
   1. The patch cord/network cable is in working condition. Check this by using it on another working networked computer
   2. The patch cord/ network cable is properly inserted/locked at both ends. Please ensure that there are no loose connections.
   3. You can connect your computer to the network through another working  port nearby.
5. The port may indeed be faulty if you have carried out the above basic checks and
   1. There is no indication of network connection. Network Connectivity is shown as crossed or there is no light on network port.
   2. Network connection is successful, but it is one way, i.e., the computer is able to send, and but not receive, check this in the network status.
   3. There is obvious evidence of damage to the network port - like it visibly damaged, the backbone cable is cut or its connector is filled with dust (perhaps due to white washing or disuse).

6. If you determine that your port is faulty, then you should register a complain at https://internal.iitd.ernet.in/slats/ (or by phone  call to 7126) and we will forward your complain to the Estate and Works section. Please identify the exact location of the port, its number and self while lodging the complain. Please note that CSC does not maintain the passive network infrastructure likes ports and network cables, the Estate section is responsible for those.

7. If you are able to ping your gateway then you should check whether you can reach the CSC servers. You can try to ping one of the proxy servers by ping 10.10.78.81. If this fails but you can ping your gateway you should  let us know immediately. You can register your complain at https://internal.iitd.ernet.in/slats (or call 7126).  When you do so we will appreciate if you can make the information as complete as possible and include the ping results, the port and room number, your IP and MAC addresses and the time of the day when you tried. We will try to get back to you within a few working hours. Please note that it may not be possible for us to attend to these complains outside working hours as we don't have an engineer available to us for 24x7.

8. If you are able to access the IITD LAN, read your IITD emails but are unable to access Internet sites, then you need to check your proxy settings - please see http://www.cc.iitd.ernet.in for details. If your proxy settings are also correct then the external ISP links may be temporarily down - you can check this at http://proxy03.cc.iitd.ac.in/mrtg/reliance.html (also linked from the CSC web-page). Clicking on the graphs will give you the current link status.
9. Otherwise, of course, our proxy servers may be down. In that case you can be reasonably certain that we already know about this and are on the job. However, you are then welcome to add to the deluge of phone calls at 7126 and 7185 or drop a mail to sysadm@cc.iitd.ernet.in - in fact you probably should! Please do not call on personal mobile phone numbers of the CSC staff or send emails to individuals, which will not help us to forward the complain to the  concerned person in a timely manner.

Please follow the procedure outlined above to determine that indeed it is the network port that is faulty. If the port is not a backbone port and has been wired by your department or centre, please contact your laboratory in-charge. If the faulty port is a backbone port then please register a complain at https://internal.iitd.ernet.in/slats/ and we will forward it to  the Estate section. This may involve changing the port or changing the backbone cable.

Please note that the CSC does not and cannot attend to physical damage to ports and cables. We do not  have physical access to the backbone switches in your locations, we only program them remotely. Please follow up the problem with the Estate and Works section.

The ADSL connections to faculty homes are maintained by the telephone department which is under the Estate and Work section. Please register your complain at https://internal.iitd.ernet.in/slats/ and we will forward it to them (you can also call 7126).

Reliable ADSL connectivity crucially depends on quality of cabling. For ADSL to work at all the noise margin should be > 10 db and the attenuation should be within 0 - 40 db. However, to get the full speed of 6144 Kbps downstream and 640 Kbps upstream the noise margin should be > 20 db and the attenuation < 30 db. Please ensure that the ADSL maintenance team can demonstrate these levels at your location for ADSL to work reliably.

The quotas are fixed according to the groups/category and we would not like to make individual exceptions which are hard to keep track of or manage. A committee consisting the Dean (PG), Dean (UG), Dean (Students) and Head (CSC) is responsible for fixing the quota and you can make an appeal to increase the group quota at a suitable forum.

The current group/category quotas are as follows:

Notes:

For Quota Assignments: 1GB=1000MB=1000000KB=1000000000B (4GB is equivalent to 3.90625GB)

For Quota Reporting:      1GB=1024MB=1048576KB=1073741824B

(e.g. 4GB quota assigned is equivalent to proxy quota use up to 3.90625GB)

1 Week = Last 7 days, 1 Month = Last 30 days, 1 Year = Last 365 days

The CSC has a special proxy server reserved for urgent research needs and you can make an application (through your supervisor) to get access on this. In such a case we may present the record of your past usage to your supervisor and request him/her to certify that usage was primarily academic in nature before granting you access to the special proxy server.

In the automatic proxy configuration URLs (http://www.cc.iitd.ernet.in/cgi-bin/proxy.*), we have explicitly programmed that accesses  *.iitd.ac.in, *.iitd.ernet.in and 10.*.*.* are not routed through the proxy. All internal sites within IITD can be accessed without the proxy server. Your proxy quota may be getting consumed for internal downloads because you have explicitly set the proxy for internal download, which is not required.

Upon successful authentication the proxy server programs your browser to send a ``I am alive'' heartbeat message to the server once every three minutes. The proxy server terminates the session if two successive messages are missed.

The proxy servers have been tested for continuous connectivity from standard web browsers for weeks together. Almost certainly it is a local problem at your end.  The most common reasons are:

1. You are using an IP address which is also in use by somebody else in your network.
2. Your network settings are incorrect.
3. Javascript is not configured properly in your browser.
4. An incorrectly configured firewall (perhaps a virus scanner) which is preventing your browser from sending the ``heartbeat'' messages to the server.
5. The is a virus in your machine which is generating excessive CPU load or network traffic.
6. The network traffic in your network is unusually high, perhaps because of a rogue machine,  causing the the CPU load of the network switch to shoot up and thereby dropping packets. You can check the load on the switches at http://proxy03.cc.iitd.ac.in/mrtg/vlantraffic.html, http://proxy03.cc.iitd.ac.in/mrtg/switchUplink.html and http://proxy03.cc.iitd.ac.in/mrtg/switches.html.

If even after all the basic checks the problem persists then there is some problem in your connectivity to the switch and you are dropping packets. You'll need to get this checked up. Please contact 7185 or send an email to sysadm@cc.iitd.ernet.in. We will get back to you within a few working hours.

You will need to set  proxy{xx}.iitd.ernet.in:3128 as your proxy server inyour non-browser application. Your can find proxy{xx} from the successful login page when you connect to the proxy server.

Of course, you will need to be logged on to the proxy server through a browser for the non-browser applications to work.

If this is happening frequently (several times a day) then it would almost certainly be a local problem - please see the answers to the FAQ on The proxy server logs me out frequently. What may be the problem?

Otherwise, the mail server may be down because of a power outage - you can check this by ping mailstore.iitd.ernet.in from the command prompt. It can also be an intermittent problem. You can be certain that we will hear about it pretty soon if the mail server is down for any significant length of time, but you can always call us at 7185 or 1771.

Please see the page on mail forwarding.

1. From the link Users and mailing lists in the Resources menu of the CSC webpage. For reasons of privacy, this link can be accessed only from within IITD.
2. You can set your favourite email client to automatically complete the name and email address of a person even as you type the name. This has already been set as default in the IITD webmail interface. For other email clients you can set ldap1.iitd.ernet.in as the ldap server in the Composition and Addressing settings and set the root dn of the ldap as dc=iitd,dc=ernet,dc=in. You can set the port to 389.
3. Of course, asking around is a reasonable third option.

axxxx, eez09xxxx and so on are your login ids which you have to use for authenticating yourselves to the email server. However you can always set an alternate email id by editing the email alias field of your LDAP profile. If it is not already in use, your chosen email id will be assigned to you. For students we insist upon appending your group id to your chosen alternate email id, just to avoid complications like a first year student with an email alias neha@ee..... receiving a love letter intended for a person who may have just passed out and was using the same email alias.

If you set an email alias you should also change the From: and the Reply to: fields of your outgoing emails as well to enable people to reply to you using your alternate id. You can set these from the Preferences menu of your favourite email software - all of them let you change these.

Of course, your original email id (your login id) will also continue to work.

Our smtp server requires authentication for sending. So, script mailing is not possible unless you are willing to put your password in clear text in the script. We will not recommend it and the risk is entirely yours.

Please try again after disabling the firewall on your machine completely. On Windows machine this can be usually be done from the settings of your virus scanner. If it works, the problem is with your firewall which will need to be configured correctly.

We will need to see the header of the bounced messages, the possibilities are too many.

A few of the common reasons due to which this may be happening are:

1. We cannot resolve the IP address of the sending machine to a valid internet name by querying the sender's DNS (DNS reverse lookup fails), or the reverse lookup doesn't match the sending machine's IP address. This means that the sender's DNS server is not properly configured.
2. The sending IP is blacklisted in one or more of the SPAM blacklists that we refer to.
3. The SPF record of the sending domain doesn't authorize the sender to use the sending IP address.
4. The digital signature (Domainkeys or DKIM)  of the mail message doesn't match that of the sender's domain (as per the sender's DNS record).

The most common reason would be 1. above. We reject approximately 15 Lakh mails a week due to this reason, and only a handful of these are genuinine. Though the mail RFC doesn't mandate that both forward and reverse lookups are necessary before accepting mails, it is  definitely a recommended setting for all mail servers (as per the mail RFC). We have an aggressive setting for mail acceptance. Most mail servers, including us, insist on reverse lookup before mail acceptance  and this is an effective strategy for combating SPAM.  Not only us but many others would be bouncing mails from such domains.  We can make an exception for such a  domain, but that would be an adhoc solution. We would suggest that you  advise administrators of such domains to configure their DNS properly and let us know if that  doesn't work. 

In all cases the header of the bounced message should contain the exact reason.

1. If the sender receives  a bounced message notification, then please request the sender to provide the header of the bounced message if possible.
2. Please check your SPAM folder just in case some mails are misclassified as SPAM.
3. The only situation where  we outright purge an email without even sending a notification to the sender are when our virus scanner detects the mail to contain a virus. Almost all .exe and .zip attachments are classified as viruses by most virus scanners.