Best of Tech Support

I have a 3Com 3C905B-TX network card installed on my server. Unfortunately, the NIC operates only at 10Mbps with either a Lantech FE-1601 or a DLink DES-1005D switch. Can someone help me to turn this NIC into full duplex 100Mbps?

—David Desscan, davidcyberletters@rocketmail.com

Try mii-diag from www.scyld.com/diag/index.html and see what your link partner is advertising. If you don't see 100BaseTx-FD in there, your switches are not configured correctly or the autonegotiation is failing for whatever reason. Your next bet is to force 100Mbit and FD as indicated at www.scyld.com/network/vortex.html. You can try to unload the module and reload it with

insmod 3c59x debug=1 options=4 full_duplex=1

—Marc Merlin, marc_bts@valinux.com

Is there a way to set up an SSH connection so that HTTP content from my company's internal site goes through the tunnel to a browser running on my home machine?

—Michael Kaneshige, mjkanes@comcast.net

For one web site, you can redirect a local port on your machine to the web site on the other side of the SSH connection:

ssh -L1234:intranetserver:80

Then point your browser to http://localhost:1234/. Note that some of this may be against your company's security policy. Check with them first.

—Marc Merlin, marc_bts@valinux.com

If you want to browse a lot of internal sites from the outside, you can set up an Apache server with mod_proxy on your work system, run the SSH tunnel as above and set your web browser's proxy preference to localhost, port 1234. Apache mod_proxy can be found at httpd.apache.org/docs/mod/mod_proxy.html. If your company's security people give you crap about this, tell them we said it's okay.

—Don Marti, dmarti@ssc.com

We have several HS-8/112 tapes from an old Banyan network we had. They were recorded on an Exabyte 8200. I am trying to retrieve some data off these tapes via a Linux box and a SCSI Exabyte 8505 tape drive. tar told me that it was not a tar archive. Do you know of any free way of retrieving the Banyan data off this tape via Linux?

—Craig Johnson, cjohnson@eypae.com

Yours is not a trivial case. A few pointers for reading other system's tapes on Linux are available. They may not apply directly to your case, but they can provide you with good ideas and pointers. For reading tapes from other UNIX systems on your Linux box, see meteora.ucsd.edu/~pierce/linux_tape.html. Another old but worthwhile HOWTO for getting ideas can be found at www.linux.org/docs/ldp/howto/Ftape-HOWTO.html. The first thing you need to find out is the format the data was saved into the tape. From the hardware standpoint, finding out if there was some data compression mechanism while writing data would help. From the operating system and software standpoint, it could be a UNIX typical format like a tar, a cpio or a dd dump; on the other hand, it could be a proprietary format that was used to dump the data to tape. Also, is it a multivolume backup (more than one tape for all the data) or not? Assuming one of these UNIX-type commands was used for data backup, it is common to find some differences in the default behavior of the command used on the writing machine to the one used on the reading machine. For instance, on Linux, tar giving -o as one of the options causes the command to try using older (V7) data formats when writing.

—Felipe Barousse Boué, fbarousse@piensa.com

I have been running a Linux-based server at a high school for about five years. Twice in the last three months our network tech has traced multicast packets that appear to be originating from this server. They are flooding the LAN and essentially bringing legitimate traffic to a stop.

I am running the latest SuSE distribution. I can find nothing that could be causing this problem. I have been using tcpdump for the past three weeks to monitor the server in a standalone LAN environment, but I see no multicast traffic. I also have monitored /proc/net/dev and /proc/net/dev_mcast, and see no multicast traffic.

Is there anything else I can do? The network tech will not let me put the server back on-line until I can assure them the problem will not arise again. Is there a process that runs intermittently that could cause this problem?

—George Moreno, ccgmoreno455@netscape.net

It's hard to say what's causing this traffic, but you may be able to persuade your admin that it will not happen again by filtering outgoing multicast traffic. This can be done with iptables:

/sbin/iptables -I OUTPUT -d 224.0.0.0/4 -j DROP

You'll still need to determine the source of this problem, but this will at least keep these packets off your network.

—Robert Connoy, rconnoy@penguincomputing.com

If your admin says that your machine is to blame, did he capture what type of traffic he is seeing? This will help find the culprit, whether it's your machine or someone else's.

—Christopher Wingert, cwingert@qualcomm.com