The latest firmware can be loaded onto the device using either FTP or TFTP. If the device has old firmware, it may need to be upgraded twice to get it to the latest. For example, both of our devices had firmware v2.0, and if you are running any firmware older than v5.0, you need to first upgrade to v5.2a and then when that was finished, upgrade it to v5.3 (or higher). If you do have to upgrade to v5.2a before continuing, be sure to read the page about which firmware is needed because there are two different v5.2a firmware files, and you need to pick the right one.
To assemble these adapters, you need to look at the adapter interface end that does not have the silver on it. Hold it up to a light and you will see tiny numbers on it, they are hard to see. If you had a fully assembled adapter and were looking at the interface then the numbers would be:
1 2 3 4 5 6 6 7 8 9
You are inserting the colored wires in the back, where there is less silver, so make sure you have it straight!
The different colored wires that you push into the adapter ends go in very easily, however you do need to push them all the way in so that the metal is flush with the holes. We found that if they weren’t pushed in all the way they didn’t connect properly.
This is the correct order:
1. White - Request To Send (RTS) -> 7 2. Brown - Data Transmit Read (DTR) -> 4 3. Yellow - Transmit+ (Tx+) -> 3 4. Green - Transmit- (Tx-) -> 5 5. Red - Receive- (RX-) -> 5 6. Black - Receive+ In (Rx+) -> 2 7. Orange - Data Set Ready In (DSR) -> 6 8. Blue - Clear to send (CTS) -> 8
There are two things to notice, first, there is no wire that goes in number 1, or in number 9… if you find yourself putting wires in those, re-check the info above! Secondly, notice how Green and Red both go into the number 5 pin on the db9. The way we were able to do this was by breaking off the red tip (but leaving enough metal on it) and then simply jamming both the red and green in together. This works because you can put the green wire part way in, and then there will be a small ridge that you can lay the remaining metal on the red wire on and then you can slide the rest in. Sometimes these don’t go in as flush as the other wires, but if the green is all the way in, and the red metal is touching the green metal, and the wires are secure, then its good. You don’t need to soldier anything!
After making adapters, you need to test them. To test them, take a straight cat5 rj45 cable and plug it into the lantronix, and the other end into your computer’s serial port (you need a computer with db9 serial). Then enable a login to be spit out to the serial port by enabling getty. To do this you need to edit /etc/inittab, and look for these lines:
# Example how to put a getty on a serial line (for a terminal) # #T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100 #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
Remove the comment (# symbol) in front of the serial port that you are connecting to and bump the speed up to 115200, so it looks like this:
# Example how to put a getty on a serial line (for a terminal) # T0:23:respawn:/sbin/getty -L ttyS0 115200 vt100 #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
Then you need to restart init to get this reloaded. You can do that by issuing a ‘sudo kill -1 1’. Then you will need to configure the lantronix port that you are using to test to work at 115200 speed and enable ssh access forwarding to the port and then try to connect to it over ssh. For example, if you plugged the test cable into port 11 you would need to connect to the lantronix over the network to the port the device is plugged into, like follows:
$ ssh firstname.lastname@example.org -p 3011
Then put in the password and you should be able to hit enter a couple of times and see a login prompt for the test machine you have connected to. If you do not see anything, you have a problem. Either the getty isn’t configured right, you didn’t restart init, the cable is bad, the adapter is bad, or the configuration on the lantronix for that port is bad. Make sure all of these are right and eventually you will get a login. Once you get one, then everything is setup right and you can just swap out the adapters as you make them, hit enter a couple times on the ssh connection to test that you get some output/input with no line-noise. Now you are a factory worker!
You connected a serial device and its not working? Try these steps to troubleshoot the connection:
1. Make only one change at a time, documenting what change you made.
2. Check the device baud rate and make sure the port on the lantronix equals those settings (speed, flow control, etc.)
3. Make sure the lantronix is not set to “Enable logins”
4. Disable flow control on both the Lantronix product and the serial device. If you get communication without flow control, but no communication with flow control make sure that both ends of the connection are using the same kind of flow control, or just don’t use flow control.
5. Make sure getty is running on the serial port (ps auxw |grep ttyS) that you are plugged into and running at the speed you expect
6. Try a cable from a serial device that you know works. If the new cable works, discard the old one.
7. Try a different adapter from a serial device that you know works.
8. Make sure your serial cables are not excessively long, especially in electrically noisy environments. In general a serial cable should not be longer than 50’ for communication at 9600bps. Faster speeds require shorter cables, slower speeds allow longer cables. In general, the shorter the cable and the slower the serial speed the more reliable the connection will be.
issuing the magic-sysrq¶
To get the magic-sysrq menu type ESC-B h (thats hit and release escape and then shift-B and then h to get the sysrq menu)
BIOS’ with console redirection¶
Some BIOS’ have “Console Redirection” which can be done over serial. This is really handy because this means you can also get into the BIOS over the SLC. However, there are a few tricks that you have to know to make good use of it.
On a Phoenix BIOS, first of all, you should change the BIOS option ‘Advanced→Console Redirection→Continue C.R. after POST’ to be Off. If you have this on, your grub is going to be really annoying to deal with.
Also on Phoenix BIOS’ during POST you will see the classic “Press
for SETUP”, which would normally prompt you to hit your key to get into the BIOS. However, this doesn’t work over serial. Its not clear if it is the BIOS which is actually not expecting to receive a over the serial connection, or if there is some mangling going on through the layers, but you cannot press to get into the bios over the serial connection. It turns out, there is a poorly documented feature that seems to allow you to hit instead, and it works as a replacement. I dont know if this only works over serial or what the deal is.
If you can select a terminal type, as you can with Phoenix BIOS’, 7-bit ANSI seems to give you the best results for the bios (its even in color!).
Once the device is fully flashed to the latest firmware, the IP/netmask/gateway can be configured via the front-panel display interface. Then you should be able to get at the web interface. The default user/pass for the device is sysadmin/PASS.
Go through the web interface and make configuration decisions about each option that is available. I did these:
- change the password to something better, and note it somewhere
- disable ssh v1 logins
- set ntp server to be enabled
- change the ssh port from 22 to something else (since we cannot disable password logins, moving to a non-standard port is a good alternative)
- disable DHCP for eth2
- add ssh keys
- set console port speed to 115200 (Devices→Console Port)
- obtain the ssh host fingerprint for the device and note it somewhere for future reference
- maybe you will want to send logs to a central log server
- turn off ‘enable logins’ for all ports or it will fight with your getty and cause you pain
Adding a ssh public key¶
This is a little awkward and a little counter-intuitive, but it works. To do this you can go to the ssh keys menu in the web interface, its tricky, so read closely. Put into the “Host” field the hostname of your machine. Put in the “User” field the user on the SLC that you will be connecting to. If that user is ‘sysadmin’ put that in the user box. Now setup a ftp mechanism to pull your public key id. That seems to work. Theoretically, if the username thats in the comment field of the key is the same as the one you are connecting to, it should work without you having to specify a User/Host pair.
If you have two keys, you will need to put them in different files and do them separately, specifying the host specifically.
UPDATE 2015-08: Riseup specific: There is a “slcuser” user on bluejay that you can use for the SCP method. You will need to temp edit the sshd_config, add Port 22, enable password auth, and comment out all the MACs/Cipher stuff. Ask taggart for the password. Run puppet afterwards to clean up.
Connecting a Baytech remote power PDU to the Lantronix SLC¶
Here are the details for creating an RJ45 to RJ45 cable that properly connects a Lantronix Serial Console server to the Baytech RPC-27 device.
,---- | this end plugs into the lantronix (where x is no wire): | x/WBr/WBl/O/x/Bl/WO/x = 1/2/3/4/5/6/7/8 `---- ,---- | and the other end (plugs into the baytech) is the standard 568B: | WO/O/WG/Bl/WBl/G/WBr/Br = 1/2/3/4/5/6/7/8 `---- ,---- | Baytech -> SLC | 1 (DTR) -> 7 (DSR) | 2 (GND) -> 4 (GND) | 3 (RTS) -> x | 4 (Tx) -> 6 (Rx) | 5 (Rx) -> 3 (Tx) | 6 (N/C) -> x | 7 (DSR) -> 2 (DTR) | 8 (DCD) -> x `----
There are probably better ways to wire this, with actually connecting those ‘x’ wires. In fact, after fighting this for some time, we found documentation for wiring rj45-rj45, which may describe a better cable. However, the one above works.