3. NetReg & BUVS
• All users who wish to the wired residential network (Resnet) must
register their computers with the network.
• NetReg is the web-based tool that allows them to do this.
• NetRegistering a machine creates an association between the
machine, its IP address and, the user, in an IT database.
• NetReg is required because it allows us to know who owns which
computer – if a computer starts attacking other computers, for
example, we know who to contact.
4. So wait, what about BUVS?
• BUVS is the acronym for: Boston University Virus & Security tool.
• It is an online application that all PC users must run before they
can be registered on the network.
• It ensures the security of a machine by forcing patches through
Windows Update and a complete virus scan with current virus
definitions.
• Previously, the BUVS scan was required
but it is NOT required this year.
• Just because BUVS is not required does not mean you won’t be
seeing it.
5. NetReg Play-by-Play
In more detail than the flowchart.
Connect computer to Ethernet port
Boot up the computer & open a web browser
Browser should* be redirected to http://netreg.bu.edu
Login in with username & Kerberos Password
Agree to terms of use
Restart computer (refresh IP address)
*what should happen & what does happen hardly every coincide.
That’s why you are all here & my presentation is supposed to be 45
minutes long.
7. Computer Test
1. Swap the customer’s computer for our known good laptop.
2. Ask if you can use their roommate’s known good computer.
• Just be sure that the roommate’s computer works before
doing this test.
• Again, you want to be sure that the computer is known
good before you use it for a test.
• BE SURE YOU ARE USING THE CUSTOMER’S ETHERNET
CABLE SO THAT YOU ARE ONLY TESTING THE COMPUTER &
NOTHING ELSE!
8. Computer Test
• If the known good computer works, you
know without question that the cable and
jack and everything beyond are working.
• If it doesn’t work, you will need to test the
cable and/or the network jack.
9. Things to look at on a PC
• Event Viewer Look for recurring errors or warnings. Look at
events that occurred around the time of the error, if known.
• Device Manager – Look for a malfunctioning driver, or no
driver. In XP you can roll back a driver if necessary. Try
reinstalling or updating the driver.
• IP Settings – For network cards, see if it’s really a
configuration problem, or a corrupt stack
• Restore Points – In XP you can roll back to a certain date with
restore points. Use this if the customer knows when the
problem started.
10. Things to look at on a PC
Look at the port – Bent pins in a computer’s jack (like what
happens after a telephone or USB cable has been inserted in
place of an Ethernet cable) are not uncommon. Some laptop
manufactures will ship a machine with a port that’s not
connected to anything if the machine is ordered without a NIC.
This can lead to very confused customers, since the port looks
right (and is actually correct) but is missing hardware behind the
scenes.
Test the network cable & the jack – First, be sure they are using
the correct jack in the wall! The nseg-cms.bu.edu links to NSG’s
floor plans which show where the active ports are in a room. See
below for detailed information on testing the jack, & again, keep
in mind the possibility of bent pins.
11. Things to look at on a Mac
• Console (found in /Applications/Utilities, look at system.log or
console.log) –Look specifically for network events & software errors. I
the user knows when a problem started take a look at the events
around that time.
• Network Panel – The Network panel of the System Preferences has a
handy display of all of the configured network ports on the system. It
will show green for an active connection, red for an inactive
(disconnected) connection, and yellow for a partial connection- e.g. a
169.254.x.x address, when DHCP requests have failed.
12. Cable Test
Every time you go out into the field, you will need a known good
Ethernet cable. Start by swapping your known good cable for the
customer’s cable. Be sure to use the same jack and the same
computer. Alternatively, take the customer’s cable and use it with
a known good computer and jack.
If the known good Ethernet cable works, the customer’s cable is
bad. If things still don’t work start looking in other areas - it is not
uncommon for there to be more than one problem with a given
system.
If you’re certain that the computer and cable are fully functional,
the remaining point of failure is the jack or the port in the jack (or
the floor or building’s network, but that’s generally obvious). At
this point, you would make a referral to NSG via the database.
13. Testing for Bad Ports
“Known good” is a term you will hear very often during ResNet. It refers to
hardware (computer, cable, network card, etc.) that has been tested and is
known to be working.
When entering a room and testing for a bad jack immediately assume that
all equipment is malfunctioning. Also keep in mind that NSG is easily
irritated by inaccurate reports of bad jacks – be careful and methodical in
confirming a bad jack.
Start by swapping individual pieces of the setup for known good
replacements. This way you can determine the individual piece that is your
problem.
14. Port Test
In order to test a bad port, you need a known good computer, network card, and
Ethernet cable. Using the known good setup, attempt to get on the network. You
can use our equipment or, if a roommate is available they may have a computer
that’s connected. If so, you can ask if you can borrow their setup in helping
confirm the problem.
Make sure you do a release/renew of the known good system’s IP address. The
system may have an IP address from the last area the machine was in, and that IP
may not work in your current location. (Roommates can sometimes be on different
subnets.)
Note: Sometimes there are more physical ports than active ports. This is especially true in
suites and brownstones where the room designations are not straightforward. You can
check to see where the active ports are in a room by using NSEG floorplans of each room
located at nseg-cms.bu.edu.
15. Configuration Problems
• Incorrect Network connection setting (TCP/IP
settings)
• Interference from third party security software
• Malware
• Routers & WAPs
16. Correct Configuration Settings
• In TCP/IP Settings that “Obtain IP Address
automatically is selected”.
• In TCP/IP Settings that “Obtain DNS Server
address automatically is selected”.
• In TCP/IP Settings -> Configure that the “Link
Speed” or “Duplex Mode” is set to Auto
negotiate (or 10Mbps Half Duplex).
17. Bridged Connections
• Because many machines ship with wired and wireless
adapters, bridging is a common occurrence. Bridging causes
traffic to pass into one interface, and out through the other.
– This can lead to changing MAC addresses, either on the
client as the interfaces shift in priority across reboots, or
on other machines that may be connected through the
machine via wireless (similar in effect to a NAT box or
access point).
• It’s always a good idea to check and make sure that bridging is
off on any system you work on.
18. Third Party Firewalls
Always be on the lookout for third-party firewalls
(Symantec, ZoneAlarm, Kerio…). These helpful little
applications can make your life miserable!
Sometimes turning off the firewall isn’t enough; you
may need to uninstall it to get rid of lingering effects.
19. Malware
Often, malware will force some network activity to a specific
site before going anywhere else. It can also sometimes co-opt
DNS, redirecting all DNS traffic through another site, or all
Web traffic.
This can prevent browsers (especially IE) from connecting to
webpages or completely prevent network traffic due to the
nature of the pre-quarantine environment. When in doubt,
run a scan or even install something like MalwareBytes from
CD or a USB drive.
20. Routers or WAPs
• Consumer Routers and WAPs (Wireless Access Points) can and do cause many
problems for us each year.
• WAPs are against the terms of service for ResNet, and routers are frowned upon.
• Any device that provides NAT (Network Address Translation) functionality can
negatively affect the network.
• The most common problem we see with these is with people plugging the LAN
port into their wall jack. This causes the device to act as a DHCP server for the
subnet, and sometimes worse, causing the router to route all traffic through itself
to the WAN jack, which is probably not connected to anything even vaguely
resembling the Internet.
• The primary symptom of this setup is generally machines getting 10.0.0.x or
192.168.x.x IP addresses - usually, these are the machines owned by people other
than the guilty party, since a floor or even a building can be affected by a rogue
router.
21. Routers or WAPs
• The other, lesser problem we see is with the user’s own machine - they go
through step one of NetReg, but the release/renew stage doesn’t have the
expected result.
• This is because the release/renew does make the client renew, but the NAT device
itself is what actually needs to release/renew, since it’s what NetReg sees. This
means power cycling the device.
• WAPs can be reported to NSG.
22. Tracking Down a Rogue DHCP Server
• You will hear the term “rogue DHCP server” often during ResNet. This is in
reference to a router or WAP that’s handing out bad IP addresses to clients on the
network.
• When you get a call, or are working on an on-site, and the customer’s IP address
is 192.168.x.x or 10.x.x.x (but NOT 10.66.x.x), you can assume a rogue DHCP
server is the culprit.
• It’s not uncommon for a floor or building that’s been afflicted by one of these to
have repeat occurrences.
• The guilty party will often notice that there’s a problem with their device, and
plug it into another port.
• This cycle can run until a given room has had all of its ports deactivated. Because
of this, don’t dismiss a call from a residence where this problem was fixed a few
moments ago - it may actually have returned.
23. Tracking Down a Rogue DHCP Server
To Track it Down
– Open a command prompt : (Start -> Run -> cmd or /Applications/Utilities/Terminal on a
Mac)
– Enter the command: arp –a (then hit enter).
– This command will display the ARP (address resolution protocol) cache. This is how the
computer keeps track of what physical (MAC) address goes with which IP address.
– The one you are after is the one that has an IP which matches the client machine’s IP, but
ends in .1.
– For example, if the client had an IP of 192.168.1.5, you’re looking for the entry with
192.168.1.1.
– Report the MAC address of this device to NSG, and they will be able to disable and/or
locate it, thus solving the problem.
