Note: Also see the FAQ on lab experiments and the list of errata. Report new problems, if possible with solutions, by sending email to jorg@cs.virginia.edu. 1. Ethernet hubs vs.
Ethernet switches When setting up the lab equipment,
it is strongly recommended to use Ethernet hubs instead of Ethernet
switches. In some lab exercises, two machines are connected
by a hub, and a third machine "eavesdrops" on this traffic and displays
the trafffic using ethereal. This only works with an Ethernet hub (See
the textbook p. 228). 2. Comment on Dual Speed Ethernet hubs With dual speed hubs, devices that connect to the hub will connect either at 10Mbps or 100 Mbps. When devices connect to the same hub with different rates, i.e., some connect at 10 Mbps and others connect at 100 Mbps, then the hub performs buffering between the 10 Mbps ports and the 100 Mbps ports. Also, the hub forwards data between ports at different speeds only if the destination MAC address is at a port with a different speed. This has two consequences. First, the hub does not necessarily create a broadcast medium (Example: Two routers with 10 Mbps Ethernet and one PC with 100 Mbps Ethernet NICs connect to the same hub. Here, the PC cannot observe the traffic between routers). Second, there are no collisions between traffic on 10 Mbps ports and 100 Mbps ports. The Linux PCs will generally connect to a dual-port switch at 100 Mbps and the routers (unless they have "Fast Ethernet " interfaces) connect at 10 Mbps. It is possible to force an Ethernet NIC to always run at 10 Mpbs. However, the configuration depends on the brand of the Ethernet card. One can avoid the above issues by having only 10 Mbps ports. In this case, an Ethernet NIC detects that the hub does not run at 100 Mbps, and will switch to 10 Mbps.
2. Problem with some Intel Pro 100+ NICs (721283-008) in Lab 6 There may be a problem with Lab 6, when using some older Intel Pro 100+ NICs (with product line number Intel 721283-008). When running gbrctl (see Lab 6) on Redhat 9.0 with these cards, the PCs stall when receiving traffic. Strangely, this occurs on Redhat 9.0 systems, but not on Redhat 8.x or earlier versions with identical hardware. Any insight on this problem is appreciated. (Source: Jianping Wang, Matt Spear, UVA ) 3. Problem with Belkin OmniView SE Port 4 Port KVM switch (frozen mouse) On Belkin OmniView SE Port 4 Port KVM switch, when switching to a PC and finding the mouse (sometimes Keyboard also) frozen, try the command "Ctrl + Alt + F1", which switches to text window 1 of the current PC, and then try "Alt + F7", which will switch back to graphical window of the current PC. In most cases, it solves the frozen mouse problem. (Source: Jianping Wang, UVA ) The Belkin OmniView SE
Port 4 Port KVM Switch has notoriously bad compatibility with XFree86
with regards to mouse behavior, which ships with RedHat 9.0. On the
Belkin KVM switches, switching to another PC meant that the mouse no
longer worked. A user would have to type Control-Alt-F1 to the
virtual console, and then type control-alt-F7 to return back to the
xserver. (Source: Armen Babikya, UMass) 5. . Problem with Zebra on Fedora Core 3
Regarding Fedora Core 3 distribution of Linux, the default zebra (Source: Prof. Kamil Sarac, UT Dallas) (END) |