Serial Over RJ-45
RJ-45 plugs with 8-conductor flat satin cabling are usually more convenient than the DE-9 connectors found on most equipment, being easier to wire your own way. There are many ways to wire a DE-9 to RJ-45 adapter. Many vendors have their own wirings, and obviously any wiring will work for a straight-through cable. Since a serial port uses nine wires and an RJ-45 plug only has eight conductors, at least one wire must be dropped.
Selecting signal wires
Which signals can be left unconnected is a critical discussion. Not only are we already short one wire, but sometimes fewer than 8 wires are available. Perhaps you need to run three serial cables over an existing Cat5 cable (three pairs for TX/RX and one pair for a shared ground). Also, to accommodate our goal below of making null-modem easy we'll have to select pins carefully.
RI (Ring Indicator) is the most useless signal and the most obvious one to drop. Communication software can detect an incoming call without it: Incoming calls only happen when CD is down, and the modem is always in command mode when CD is down, and the modem will send "RING" on RX when the phone rings. Furthermore, the only time software can get away without understanding the command language is when the modem is set to automatically answer, in which case CD will be the pertinent signal, not RI. So RI is not necessary or sufficient to answer a call.
Dropping CD is a common practice, but doing so is problematic. While one can often work around lacking CD, detecting CD drop is the only reliable way to detect when a modem leaves data mode, for example when a call is terminated. Without CD, when a call is terminated unexpectedly, the software will keep the session for the call open. If the modem is configured to automatically answer, this results in a security hole because the next caller will pick up the unterminated session. When the modem is not configured to automatically answer, the situation is only a little better: after a terminated call, the software will not reset, so next time the modem rings, the software will not understand that the "RING" sent from the modem is not data.
An important use-case for CD is calling into Unix TTYs. It's easiest to set this up by configuring a modem to automatically answer, then configuring getty to offer a terminal on the TTY device. TTY devices in Unix typically only operate when CD is up, so getty will wait until the modem automatically answers and raises CD before presenting the login prompt, and when the call is terminated, the modem will lower CD, the kernel will hang-up the session (SIGHUP, EOF, and revoke the controlling terminal). Imagine that if your wiring always asserts CD or if you reconfigure the serial port to ignore CD, then when you lose a phone call another caller may assume your open session!
DTR and DSR are less important. If the computer lowers DTR, most modems respond by switching to command mode or dropping the call, depending on their configuration. This is a good way for software to get the modem back into command mode, although this can also be done by sending "+++" surrounded by a pause, then "ATH\r" to hang up. DSR doesn't seem to have much utility at all; communication software doesn't need it and in null-modem wireing it makes more sense to match DTR with CD than with DSR.
Sometimes the ground pin may be dropped. This works if the equipment you're connecting shares a common ground through the AC wiring and the serial port uses that for its reference.
Different signals are important in different situations, but a reasonable ordering of decreasing importance is: TX/RX, GND, RTS/CTS, CD, DTR, DSR/RI.
Dave Yost describes a brilliant wiring. I won't restate everything here; the essence is that with a roll-over cable and two DE-9F/RJ45 connectors you get a null-modem cable, and by replacing one end with a DE-9M connector you get a straight-through wiring that's missing only DSR and RI, the two useless signals. Adapting all the devices to this common wiring reduces the fiddling required to connect things together in the machine room.
Note that DCE devices (modems) receive data on TX, while DTE devices (computers) transmit on TX. Also don't forget that the RJ45 cable is rolled-over between DTE and DCE.
|Name||DE-9F||DB-25F||RJ-45 - Yost|
|GND||5||7||4 (red) + 5 (green)|
|DSR||6||6||2 (orange) or NC|
|Name||DE-9M||DB-25M||RJ-45 - Yost||DE-9M for apcupsd ("smart" cable)|
|GND||5||7||4 (red) + 5 (green, optionally)||9|
RJ45 jacks on Cisco's and HP's (and likely most other's) network equipment nearly use the Yost wiring, but in reverse. They should work if you use a straight-through cable instead of a roll-over. Their stock cables wire DSR to pin 2, which a straight-through cable will connect to CD. However, if you happen to use software that cares then you really wanted DSR to raise CD anyway, so it'll work out. Cisco does not wire CD into the device at all, and HP carries it on pin 4, which the Yost wiring will short to pin 5 and ground, but that should make no material difference.
Many Cisco devices come with a male DE-9 jack on the back. However, this jack is wired for DCE, not DTE, so you probably want to attach a gender-bender to these. Then attach the normal Yost adapter for DCE-side equipment. That'll probably result in less confusion than wiring special DE-9F adapters.
## apcupsd.conf v1.1 ## UPSNAME ups0 UPSCABLE smart UPSTYPE apcsmart DEVICE /dev/cuau0 NETSERVER on NISIP 0.0.0.0 NISPORT 10000
- The USB-16COM-RM is a nice USB-based device based on the FT2232C chip that provides 16 serial ports for under $400. It works in FreeBSD 6.1 with the uftdi driver. (Remember to load the module; as of 6.1, FreeBSD can't load it automatically for this device yet.) It probes as two USB hubs and eight FTDI serial adaptors, each of which provides two serial ports.
- RJ45 Adaptor supplies from Jameco: