Networking@MIT Easy Guide
General
Registration
All new machines at MIT using DHCP (Dynamic Host Configuration Protocol) for IP address assignment need to be registered in order to have full access to all MIT networked resources. We have found that anyone using DHCP networking on both wired Ethernet and wireless need to do this. Though wireless may appear to work for a day or two via DHCP, inevitably the net access begins to degrade until the machine is registered and issued an appropriate registered IP address for the appropriate building subnet instead of the generic 18.2.*.* DHCP addresses. To register a machine at MIT you need to go here. MIT machines issued static IP addresses do not need to register.
Wireless Networking
Users need to connect to MIT, MIT N, MIT Secure or MIT Secure N to access MIT resources after network registration. As mentioned before, some machines may work for a few days without network registration. If you experience poor internet connectivity or behavior afterwards and you haven't registered, go ahead and register and it should fix the problem.
The MIT GUEST Wireless network
Please note: MIT Guest WiFi network has NO ACCESS to printer or MIT Administrative site resources. MIT Guest really only gives access to the MIT websites and outside web pages. You should assume on-campus non-web internet resources are locked out including network printers.
How to access the MIT Secure WiFi networks
To access MIT Secure or MIT Secure N you would type in your Kerberos username and password.
Static IP Addresses for Ethernet connected machines
The one exception to the Registration rule is that any machine with assigned static IP Addresses don't need to be registered. They will work the moment the IP addresses are put in.
To request an IP Address go here.
The other pieces of information you will need with a static IP Address are as follows:
Subnet Mask: 255.255.0.0
Gateway: 18.#.0.1 where # is the same number found after 18 in your assigned static IP address.
DNS Servers: 18.71.0.151, 18.70.0.160, 18.72.0.3
Please note the 18.72.0.3 has been associated with some problems resolving IP Addresses so it is best not to have this DNS server listed first or second.
DHCP for Ethernet connected machines
The way DHCP for Ethernet connected machines works at MIT is all unregistered machines are given an IP address in the pool 18.2.*.*
Depending on building, the pattern becomes more specific. For example, if you're Building 4, the pool is 18.2.53.*
The third number 53 is significant because this number is the appropriate subnet for valid static IP Addresses. So if you had an IS&T issued static or properly registered DHCP machine in Building 4 it would be in the 18.53.*.* subnet pool.
DHCP for Wireless connected machines
Wireless devices at MIT are issued a temporary DHCP IP Address that may stop working if the user doesn't register their machine to the MIT network.
Registered wireless devices on central campus at MIT are typically issued IP Addreses in the 18.111.*.* subnet.
Devices that rely on an Ethernet/wired interface but have no web browser
That would be all you console gamers on the Nintendo Wii, Playstation, and XBox, and users in the research areas with scientific wiz-bang doohickeys and apparatuses. You will need to contact IS&T either at computing-help@mit.edu or call the help desk at 3-1101 to have your device's MAC (Media Access Control) address registered.
Devices that DON'T require registration
iPads, smartphones, and most tablets do NOT require registration. The only thing you need is valid Kerberos credentials on the devices to access MIT Secure and MIT Secure N Wireless networks as well as other online administrative apps and library resources. There are some devices that skirt the line between smartphone/tablet and computer like the Windows Surface. If the device's networking doesn't seem to behave correctly unregistered (and you have good WiFi signal strength), go ahead and register it and see if that fixes the problem.
Troubleshooting
Firewalls
Until MIT decides to implement up an Institute-wide firewall, machines on campus are fully accessible and potentially vulnerable from anyone out on the Internet. This has security implications for every section within the school. Hacking attacks should be expected and unnecessary guest accounts and services that use ports should be disabled on individual machines by turning on the machine's built in firewall. Unprotected machines can experience slow performance or slow internet access if they're being attacked. Or at worse, the machine could be compromised if it hasn't had its updates in a while. Though Macs are rarely compromised directly in this way, Windows machines can be, especially unpatched versions of Windows XP and lower. Machines access the internet and each other through numbered ports and firewalls should always be enabled to close down any ports users don't really use.
Broken services
Sometimes there are things that you DO want a computer to do through the protection of a computer firewall, for example file sharing, screen sharing or remote management. On Unix machines like Mac OS X, these services are controlled within System Preferences. But if all your other services are running, like web access and email, but for some reason the file sharing, screen sharing, or remote management doesn't work, the best thing to do is to uncheck these network services to turn them off. Then shut down the machine. After you count to ten, turn the machine back on and turn those services on again. This should hopefully restore those services back into a working state.
Acknowledgements
My thanks to my fellow co-worker Dan Irvine and IS&T collaborator Sparrow French for helping me make sure all the details of this document are as accurate as possible.