DLink DFE-530TX+

I recently bought a D-Link DFE-530TX+ to connect up two of my machines. I bought it specifically because they listed Linux support on the box. I was a little disturbed when Red Hat 7.3 didn’t quite autodetect it. Here is what I found.

Installing my DFE-530TX+ was actually quite easy once I hit the internet. I found a couple of things.

  • The drivers on the cdrom reportedly don’t work. They certainly didn’t look like there was enough code. I must admit I didn’t double check once I found stories of problems.
  • My kernel had a module for the chipset on this line of cards. I believe it is the realtek 8139 chipset. The module is named “8139too”.
  • Once I added the following line to my modules.conf file and restarted the network everything worked great. (Note that in my case this was eth1, but in most instances it would be eth0).
    alias eth1 8139too

Supercheap Ethernet Network

When I first got into networking I thought that to connect to Ethernet machines you had to plug them into a hub or a switch. It turns out there is a much cheaper way to do this if you are only connecting two machines.

But what if you don’t want to pay for a hub or a switch. After all you’ve only got two machines. Well, under normal conditions if you wire two ethernet cards directly into one another, they will not understand how to talk to each other. A cross-over-cable takes care of this. It swaps the position of a couple of wires in the plug from end to the other so that each end of the connection sees the correct wires from its perspective.

Using this what you can do then is get two network cards for $20 each (Less if you are brave) and connect them with a cross-over-cable. Thats all it takes. Using a switch you would need the two network cards, a $50 switch, and two normal cables to connect everything.

What’s even cooler is that the cross over cable is the fastest possible ethernet connection. Switches have buffers, hubs have collissions, cross-over-cables don’t have either. They transmit immediately and correctly every time.

Finally, if you want to connect a cable modem to this two machine network you might think you have to invest in a cable router. While they are terrifically handy devices, you don’t absolutely have to get one. You can add a second ethernet adapter to one machine and set it up as a simple a firewall/router. (That however is beyond the scope of this article.) The advantage of this setup is the 2nd NIC costs about half what a cable router would cost.

How to change users with “su” and have your path work correctly.

It is best to do all your day to day tasks as a user with the minimum privileges to accomplish those tasks. This prevents you from accidentally making drastic changes to your install or inadvertantly running a trojan horse that listens on a privileged port. But what happens when you want to su to root and none of your root commands are in your path. All the sudden you have to run locate or find just to run a program. Whats worse is that the user you were previously using has their path installed so if that account is compromised they could add a trojan horse to their path in the hopes that root would eventually run it.

For the solution, read on…

If you use

su -

You are telling the su command to give you a “login” shell which basically acts like you just logged in. It will create your path correctly, change to your home directory, and generally act like you weren’t logged in before. This is super convenient for all those utilities that live in /sbin and /usr/sbin that you probably don’t keep in the path of the user you use for your actual work.

The values in /proc

Ever noticed that nobody on the web documents the /proc filesystem very well. Well guess what. There is a man page for it.

I’ve always been extremely frustrated with the fact that /proc has thousands of values in there and I didn’t know what any of them meant. Well, it turns out that running

man proc

will actually give to the man page for the entire /proc file system. I know this eliminated one of my huge sources of frustration with Linux documentation.

Installing the NVIDIA GeForce 3d accelerated linux driver.

Up until last year NVIDIA had the fastest video cards around. Even now they are right at the top, and they get serious karma points for providing such easy to install linux 3d drivers.

  • go to www.nvidia.com
  • At the bottom of the screen click drivers
  • There will be three lists. Complete as follows and click go.
    • From the first list choose graphics drivers
    • From the second list choose geforce & tnt2
    • From the the final list choose linux ia32
  • You will be presented with instructions for downloading/installing the driver.
  • One of the instructions will be to save the .run file which has the driver embedded in it.
  • su to root
  • Change your inittab to boot in level 3 (text instead of graphics) & reboot
  • Run the .run file
  • Read through the readme file for post installation instructions
  • Run startx to test out X before making it the default.
  • If X starts up without trouble then edit you inttab to boot in level 5(graphical)

SSH Port forwarding

Do you have ssh access to your office network, but you need http access. Here is a way to tunnel your traffic over the secure connection to your office web server. Now you can surf the office Intranet from home!

Don’t try this without getting permission first!! Your employer might not have understood how much access they had given you when they gave you that ssh login.The feature that you need to use is called port forwarding. The idea is that your local ssh program captures traffic to a port on your machine on forwards it to a machine (any machine) on the other side of the connection.

For example, I could forward port 8080 on 127.0.0.1 to go to intranet.mycompaniesinternalnetwork.com port 80. Pretty cool eh. Again, as I mentioned at the top, whoever granted you ssh access probably didn’t realize that you can forward everything else once you log in. Make sure they understand what you intend to do!

First, in the home directory of the machine you are connection from create/edit a file named ~/.ssh/config. This file will specify what ports to listen to and what machines to forward them to. Lets pretend we want to ssh into a machine will nickname ted. Here is an example ~/.ssh/config file that connections for firewall.mycompaniesinternalnetwork.com and then starts forwarding port 8080 of your machine:

host ted
hostname firewall.mycompaniesinternalnetwork.com
localforward 8080:intranet.mycompaniesinternalnetwork.com:80

That’s all it takes! The connection only works when you are ssh’d in to the remote machine. So to test it you would run

ssh ted

and then once you logged in you could point your browser to http://127.0.0.1:8080/ to go to http://intranet.mycompaniesinternalnetwork.com/But wait! We can do one better. Rather than referring always using 127.0.0.1 we can add a entry to our /etc/hosts file to make intranet.mycompaniesinternalnetwork.com always resolve to 127.0.0.1. That entry would look like this:

127.0.0.1   intranet.mycompaniesinternalnetwork.com

Now, we can connect to http://intranet.mycompaniesinternalnetwork.com:8080/ and its just like connecting to port 80 of the real site. (It ultimately does, after all.) In case you are curious, only root can configure your local machine to accept connections on low numbered (so called well-known) ports. That is the reason for the 8080 port number.

How the Email System Works

In a few days when I get a better handle on it myself I’ll post several independant articles on fetchmail, procmail, sendmail, spamassassin, etc. However, the problem I had when I was just getting into all of this was where to start. Indeed, the email system is a convoluted mess to say the least. However, if you understand the high level functions of each component things start to make a little more sense. Let me share what I know so far.

Note since original article: I found a link that explains this far better than my little story. Check out ZDNet UK’s story For a real good read on the basic components. Then read mine if theirs makes too much sense. 🙂

So you sit at your desktop and compose and email. For the sake of clarity lets pretend it is to somebody in a distant organization with no affiliation to yourself. In that circumstance your email program will help you draft a pretty little email. It will then ship it off to port 25 on some fairly close server to do the actual work. Usually this is with your office or ISP.

This not so distant machine gets the email on port 25 and says,”hey, who was it that asked for all the traffic to port 25. Oh yes, I remember it was Sendmail“. (The first piece of the puzzle.) Sendmail knows how to transfer mail from a local machine on port 25 to a distant machine on port 25. It turns out that sendmail is a real patient program. If the remote machine is down it will make all the right decisions to give the email the best chance of arriving at its intended destination. In our case everything is fine. The not so distant sendmail machine grabs the email and passes it along to the distant sendmail machine.

So the distant sendmail machine gets an email on port 25. Linux on that machine says, “as I recall sendmail had some interest in port 25. I think I’ll make it handle this data.” Sendmail wakes up and says,” oh yes, not only do I speak sendmailese (also known as SMTP), but this message appears to be for one of the users that I so benevolently serve.” So sendmail says, well, I’ve done my part, I’ll run some subordinate to actually store this email

Sendmail looks in its hideous configuration file and decides that procmail is a pretty good program for filing emails. So it forks off a procmail process and says, “hey, here is an email for you to file.$quot; Upon hearing which, procmail cheerfully springs into action.

Procmail says, what does my configuration want done with this message? Should I just file it in the inbox? Well, in our case our SysAdmin set procmail up to ask SpamAssassin how likely it is that this message is spam.

Procmail forks off a SpamAssassin program and passes it a raw message. SpamAssassin consults databases, does some math, checks some blacklists, maybe does some Bayesian filters, and after all that work adds a simple header (Like a From: header only with a different name) to the email. This new header is how likely SpamAssassin says it is that this message is spam.

SpamAssassin finishes and passes its data back to Procmail. Procmail says, “I see you’ve classified this as on of the few peices of non-spam we see around here. As per my configuration, I’m going to file this in the Inbox.”

Now, your distant friend is sitting at his desktop wondering, “I wonder if I’ve received any new spam?”. So he loads up his email client. If your friend is cool they are checking with IMAP which allows for cool stuff like folders. For imap to work your friend’s mail server needs a program called (drum roll please) imapd! Bet you didn’t see that one coming. Your distant friends email program connects to port 143, talks some IMAP, and ultimately gets the email you sent.

Was that so bad? … Ok it was. Don’t blame me, I didn’t build it. 🙂 But you’ve probably got a sense for how it all fits together. The best/worst part of this is that at any stage you could swap out one of the programs I mentioned and use a different program that is functionally equivalent. Its cool to have all those choices, but investigating half a dozen choices just to send email can be a pain. Thats my .02 on the matter. More later as I learn it. 🙂

Blocking all traffic to an outbound IP

Normally I would say that blocking an outbound IP is pointless since there are billions of different IP’s that your users can go to. However, today Versign pointed *.com, *.net at themselves for a search page that they intend to derive revenue from. Since they are not the legal owners of *.com and *.net (rather they are stewards over it) they have no business doing this.

Note:Since this article was originally posted Verisign has returned the *.com and *.net space back to their correct behavior. Nevertheless, iptables are good to know so I’ll leave this article on the site

To make matters there is a Web bug pasted on the page which is no doubt recording what domains are valuable, probably so that Verisign can turn around and sell those domains at a higher rate.

Then there is the spam. I got 200 peices of spam in one day today. Thats double the normal rate. My ISP must have been filtering them out before, but now all my spam has these bogus domains in the email envolope.

Finally, my registrar godaddy.com does not appear to have been ready for this which is probably costing them a great deal of money. This rubs me the wrong way just enouigh that I’m going to block the only outbound IP I’ve ever blocked.

I’ve always deplored cybersquatters and this cybersquatting to the extreme. So, I can’t do much about Versign’s actions, but I can keep anybody on my little network from being sucked into this garbage. The ip we are seeking to block is 64.94.110.11. Just for fun we’ll pretend that it is a 32 bit network address and a 0 bit host.

So, how do we block an outbound IP. Depending on your linux version you are probably running IP Chains or IP tables.

For IP Chains the statement is

/sbin/ipchains -I output -d 64.94.110.11/32 -j REJECT

for iptables it should be something like

/sbin/iptables -I OUTPUT -d 64.94.110.11/32 -j REJECT

Test out a few of your common destinations, test a bogus destination, and if that works then add the appropriate line to your system start up.

Setting your hardware clock with a new date and time

The Linux system clock runs seperate from the actual clock hardware on the motherboard. Some programs may directly read from the hardware clock instead of the system clock which could lead to trouble. Here is how you can set and sync them.

First to set the hardware clock, you use the date command. date tries to be really intelligent about the date strings you feed it. The following was sufficient to set the date on my machine:

date --set "12:24am Dec 14,2003"

Once you set your system clock the only thing you have to worry about is what happens when you reboot. That is where the hardware clock comes in. It keeps track of the time when your machine is turned off. Your OS will pull the time from the hardware clock when it boots up. You can sink to/from the hardware clock at will with the commands below:

To set the hardware to match the system clock.

hwclock --systohc

To set the system clock to match the hardware clock.

hwclock --hctosys

Note:Thanks to Daniel Farinha for pointing out that the original article had –systohc and –hctosys backwards.

Trouble Defining Hotkeys

Recently Linux desktops have made a lot of progress, but since they are always in a state of flux it can be difficult to find a universal way to map keys to programs. Enter xbindkeys a quick and dirty way of adding hotkeys even if your desktop doesn’t support it.

First, you’ll need to obtain the xbindkeys executable. I like to build mine from source. The code for xbindkeys is extremely small. You can obtain it at http://hocwp.free.fr/xbindkeys/xbindkeys.html

Extract the files then go through the usual cycle

configure
make
make install

They also have Debian and Redhat packages although I had dependancy problems with libc on Redhat 7.3 so source worked better for me.

Now to configuration. The website above will have a couple of simple example files. The general idea is to capture X key events before your desktop and window manager ever see them. You can run xbindkeys –key to have xbindkeys output these values for a single key.

1 Next create a .xbindkeysrc file in your user’s home directory. The format is really straightfoward. Put the command line in quotes on one line and then one the second line indent and list the key that executes it. For example to have my calculate key open the xcalc I use:

"xcalc &"
    m:0x0 + c:161

Then just run xbindkeys and voila. Your keys are mapped. You may want to find a permanent way to always run xbindkeys when you start X. I add mine to the start of my gnome-session, but to each his own.