Serial Connection in Debian 9 Moxa Device
Hello Debian Team, We are using Linux Debain 9 in our moxa devices. we are connected in a network where we connect with our moxa device via ssh and run the commands with Gauge ip and port and get Data. Now I'm Facing issue from 2, 3 weeks to connect the moxa using ssh and then connect to the serial port and get data as i getting in Telnet. I need Your Help in this Scenario to get the data when i connect through serial cable. please Let me know ASAP. Thanks Faisal
Re: [SOLVED] Serial Connection
On 03/04/11 02:07, Stephen Powell wrote: > On Fri, 01 Apr 2011 06:02:38 -0400 (EDT), MAROUNI Abbass wrote: > I also used to have an IBM PS/2 Model 70. The UART on its motherboard > is a 16550A. According to the manufacturer's specifications, the > 16550A is capable of operating at speeds of up to 256 kbps. Due to the > hardware design of the PC et al, 115 kbps is the maximum bit rate that > can be programmed by software. But by trial and error experimentation, > I found that this UART could be driven at a maximum rate of 38,400 bps. > If I tried to go any faster, I would get garbage or dropped characters. > In this same machine was an expansion board (32-bit microchannel bus) > which contained an extra serial port. It also has a 16550A UART. But I > had no problems driving it at 57,600 bps. Perhaps it would have been > capable of higher speeds than that, but I didn't have a fast enough > device to test it with at the time. > > The point is that all serial ports are not created equal. The most > common PC serial ports use 16550A UARTs, but older and slower UARTs > are used in some older boards. Even if the UARTs are the same, > the actual maximum bit rate can be lower than the manufacturer's > specs, depending on what limitations are imposed by the supporting > circuitry. > Ahh the PS/2! The precise scenario I was thinking of when I said "There are/were some problematic serial chipsets" - I couldn't remember off-hand the exact chipset, and was hoping I wouldn't have to dig through old notes to find it. (thanks Stephen) I owned a number of PS/2s - I still regret parting with the 9595 :-/ It was on those machines that I first used home-made three-wire cabling to transfer data. One day I'll have the time to rebuild my PS/2 collection and make use of MCA cards from IBM mainframes - and maybe fix/update the site in the signature. Cheers -- A site about PS/2s http://www.angelfire.com/sc/ottferguson/ It's old, un-maintained, and you'll need to enable javascript - and wait to get past the IBM diagnostics screen :-) Note: the email address is defunct, as are many of the links. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d97c181.8090...@gmail.com
[SOLVED] Serial Connection
On Fri, 01 Apr 2011 06:02:38 -0400 (EDT), MAROUNI Abbass wrote: > > Sorry forgot to mention that we are in Paris and the datacenter is in > Amsterdam. So no physical access to the servers. For your production environment, perhaps. But you led us to believe that you had two local servers side-by-side for testing purposes that were cabled together by means of a cross-over serial cable or a standard serial cable in conjunction with a null modem. Obviously you don't have a serial cable running all the way from Paris to Amsterdam. You're using modems and phone lines, or ethernet to serial converters, or something similar. Your comments about the cable were misleading. It seems that you either won't supply pertinent information or you supply misleading information. > > But good news : I finally made it. I'm glad you got it working. > > Apparently ttyS0 and ttyS1 are different. I had to use baudrate of > 115200 with vt102 on ttyS0 and a bauderate of 9600 with vt100 on ttyS1. > is that a software or a hardware issue? I always thought that ttyS0 and > ttyS1 are the same. It doesn't matter which serial port is called /dev/ttyS0 and which serial port is called /dev/ttyS1. What matters is the hardware. Years ago, I had an old 486 machine with a 16-bit ISA bus. Installed in one of these bus slots was an 8-bit multi-io card which provided two serial ports, a parallel port, and a joystick port. This card was originally designed for PC and PC/XT clones. It used National Semiconductor (NS) 8250 Universal Asynchronous Receiver/Transmitter (UART) chips, or their hardware clones. According to the manufacturer's specifications, the 8250 UART can operate at speeds up to 56 kilobits per second (kbps). But in actual practice, I found that 9,600 bps was as fast as it could go. Something about the design of the support circuitry limited its speed to 9,600 bps. I don't know what. But if I tried to push it any faster I either got garbage or dropped characters. I also used to have an IBM PS/2 Model 70. The UART on its motherboard is a 16550A. According to the manufacturer's specifications, the 16550A is capable of operating at speeds of up to 256 kbps. Due to the hardware design of the PC et al, 115 kbps is the maximum bit rate that can be programmed by software. But by trial and error experimentation, I found that this UART could be driven at a maximum rate of 38,400 bps. If I tried to go any faster, I would get garbage or dropped characters. In this same machine was an expansion board (32-bit microchannel bus) which contained an extra serial port. It also has a 16550A UART. But I had no problems driving it at 57,600 bps. Perhaps it would have been capable of higher speeds than that, but I didn't have a fast enough device to test it with at the time. The point is that all serial ports are not created equal. The most common PC serial ports use 16550A UARTs, but older and slower UARTs are used in some older boards. Even if the UARTs are the same, the actual maximum bit rate can be lower than the manufacturer's specs, depending on what limitations are imposed by the supporting circuitry. As to a VT100 emulation vs. a VT102 emulation, that is a software issue. The serial port doesn't know or care what kind of terminal you have. Apparently your two servers are not identical, as you led us to believe. As to what my next suggestion was going to be, I had some questions about the procedure you used to comment out the entry in /etc/inittab and kill getty. You didn't provide much information about it. (Perhaps you're noticing a theme here.) Normally, init only reads /etc/inittab during startup. Thus, commenting out the entry for getty in /etc/inittab will not prevent the process from being re-spawned. However, init will re-read /etc/inittab if you tell it to by means of the "telinit q" command. The proper procedure would be (1) Comment out the entry in /etc/inittab (2) Issue "telinit q" (3) Wait a reasonable length of time for init to react (4) Kill getty, if it is still running (5) Wait for getty to die (6) Launch minicom The reverse procedure would be (1) Exit minicom (2) Uncomment the entry in /etc/inittab (3) Issue "telinit q" init should then re-spawn a getty process. Keep in mind that telinit and kill are asynchronous commands. They send a signal to another process, but they do not wait for the requested action to be performed. You must introduce some wait time in your script to give the other process enough time to perform the requested action before going on. > > Thanks for you all. Much appreciated. You're welcome. But next time, please give us the information we ask for and be willing to try the things we suggest, even if you don't think that it will do any good. It motivates us to keep helping you. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas.
Re: Serial Connection -- shielding
Le 01/04/11 01:51, Stephen Powell a écrit : On Thu, 31 Mar 2011 09:14:07 -0400 (EDT), MAROUNI Abbass wrote: In a production environment, this what will happen : Two servers connected with a single serial cable ( Which I need to figure out how?! :) ), ttyS0 on server1 to ttyS0 on server2. getty is always listening to the ttyS0 port on both servers (assured by inittab respawn). Server1 is inaccessible. login to server2 launch a script that will kill getty and comment its entry from inittab then launch minicom toward ttyS0 on server1 login to server1 and find what happened. Finally on server2 quit minicom launch another small script that would put getty on ttyS0 and uncomment its entry from inittab. This way if something wrong happens to server2 I am sure that I have a getty on its ttyS0 and all I need to do is to go to server1 follow the same procedure. Reverse communication assured :) Logical isn't? :) I am still not convinced that the serial cable might have different ends if it's a standard null modem cable, so I don't think that reversing the ends between the two servers might help. OK, now I think I understand. I have some more thoughts, but before I share them I want to address your attitude. Suppose you were a medical doctor. Suppose I came to you with a problem. For the sake of example, let's say that I am complaining of a sore throat. You use a tongue depressor and a flashlight and look at the back of my throat. It's deep red and very swollen. You take my temperature. I have a fever. You think the problem is strep throat. So you write me a prescription for an antibiotic. I thank you and leave your office. Three days later I come back in, complaining that my throat is worse than before. You ask me if I have been taking the medicine that you prescribed according to directions. I say, "No, in fact I didn't even bother to fill the prescription." What would your reaction be? How motivated would you be to continue trying to help me? I dare say, not very motivated. If I had taken the medicine but the problem grew worse, you would be even more motivated to help me. But if I wouldn't even try what you suggested, I dare say your reaction would be, "Fill the prescription and take the medicine according to my directions. If you don't feel better in three days, come back and see me." You are acting just like that. People ask you for specific information. You don't provide it. Someone suggests that you try something, but you don't try it because "you don't think" that that is the problem. Well, if you're so smart, why are you asking for help? How hard is it to reverse the cable, for diagnostic purposes, just to see if it makes a difference? You won't try anything. Now I have an idea of what the problem might be. It might be the solution. Or I might be barking up the wrong tree. But I'm not going to share it with you until you try what I've already suggested. Reverse the cable and see if makes any difference. Let me know the results of the experiment. Then maybe I'll suggest something else to try. Sorry forgot to mention that we are in Paris and the datacenter is in Amsterdam. So no physical access to the servers. But good news : I finally made it. Apparently ttyS0 and ttyS1 are different. I had to use baudrate of 115200 with vt102 on ttyS0 and a bauderate of 9600 with vt100 on ttyS1. is that a software or a hardware issue? I always thought that ttyS0 and ttyS1 are the same. Thanks for you all. Much appreciated. -- Abbass MAROUNI Internet Memory Foundation internetmemory.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d95a2be.9000...@internetmemory.org
Re: Serial Connection -- shielding
On Thu, 31 Mar 2011 09:14:07 -0400 (EDT), MAROUNI Abbass wrote: > In a production environment, this what will happen : > > Two servers connected with a single serial cable ( Which I need to > figure out how?! :) ), ttyS0 on server1 to ttyS0 on server2. > getty is always listening to the ttyS0 port on both servers (assured by > inittab respawn). > > Server1 is inaccessible. login to server2 launch a script that will kill > getty and comment its entry from inittab then launch minicom toward > ttyS0 on server1 login to server1 and find what happened. Finally on > server2 quit minicom launch another small script that would put getty on > ttyS0 and uncomment its entry from inittab. This way if something wrong > happens to server2 I am sure that I have a getty on its ttyS0 and all I > need to do is to go to server1 follow the same procedure. > Reverse communication assured :) > > Logical isn't? :) > > I am still not convinced that the serial cable might have different ends > if it's a standard null modem cable, so I don't think that reversing the > ends between the two servers might help. OK, now I think I understand. I have some more thoughts, but before I share them I want to address your attitude. Suppose you were a medical doctor. Suppose I came to you with a problem. For the sake of example, let's say that I am complaining of a sore throat. You use a tongue depressor and a flashlight and look at the back of my throat. It's deep red and very swollen. You take my temperature. I have a fever. You think the problem is strep throat. So you write me a prescription for an antibiotic. I thank you and leave your office. Three days later I come back in, complaining that my throat is worse than before. You ask me if I have been taking the medicine that you prescribed according to directions. I say, "No, in fact I didn't even bother to fill the prescription." What would your reaction be? How motivated would you be to continue trying to help me? I dare say, not very motivated. If I had taken the medicine but the problem grew worse, you would be even more motivated to help me. But if I wouldn't even try what you suggested, I dare say your reaction would be, "Fill the prescription and take the medicine according to my directions. If you don't feel better in three days, come back and see me." You are acting just like that. People ask you for specific information. You don't provide it. Someone suggests that you try something, but you don't try it because "you don't think" that that is the problem. Well, if you're so smart, why are you asking for help? How hard is it to reverse the cable, for diagnostic purposes, just to see if it makes a difference? You won't try anything. Now I have an idea of what the problem might be. It might be the solution. Or I might be barking up the wrong tree. But I'm not going to share it with you until you try what I've already suggested. Reverse the cable and see if makes any difference. Let me know the results of the experiment. Then maybe I'll suggest something else to try. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1104748067.1862304.1301615492911.javamail.r...@md01.wow.synacor.com
Serial connection; was Re: Serial Connection -- shielding
Abbass, From: MAROUNI Abbass Date: Thu, 31 Mar 2011 15:14:07 +0200 > I am still not convinced that the serial cable might have different ends > if it's a standard null modem cable, ... You haven't ruled out a broken conductor where you can't see it. And there are other cables with the appearance of a DE-9 null modem. I have such a cable with special wiring for a connection to a UPS. > ... so I don't think that reversing the ends between the two servers might > help. 15 minutes of work and you will be certain. Regards, ... Peter E. -- Telephone 1 360 450 2132. Shop pages http://carnot.yi.org/ accessible as long as the old drives survive. Personal pages http://members.shaw.ca/peasthope/ . -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/171056959.42317.32454@cantor.invalid
Re: Serial Connection -- shielding
Stephen Powell put forth on 3/31/2011 6:30 AM: > You can't > reverse the direction of communications without physical access to > *both* servers. That is why you need two serial ports on each server > and two properly-wired cross-over cables. If you only care about > one-way control, then why do you even care about being able to > reverse the direction of communications? This is exactly why all tier one, and some tier 2, vendors ship servers with lights out management boards pre-installed. This is also exactly why their predecessor, rack mount KVM over IP devices, were invented, oh so long ago. I dare say that if you're too cheap to use one of these proven solutions then you have no business running a server that needs uptime and quick diagnosis upon failure. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d94a814.1030...@hardwarefreak.com
Re: Serial Connection -- shielding
MAROUNI Abbass wrote: In a production environment, this what will happen : Two servers connected with a single serial cable ( Which I need to figure out how?! :) ), ttyS0 on server1 to ttyS0 on server2. getty is always listening to the ttyS0 port on both servers (assured by inittab respawn). This may not work as expected. I think you intend to enable kernel and grub serial console too (good idea for remote diagnostics). This way, if you start both servers, one of them starts getty earlier (asking for login/password), while the other still sending its console messages, login prompt, etc., straight into the getty's stdin on the first server. I am still not convinced that the serial cable might have different ends normally... but might be defective... -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d948fb3.4080...@progzmaster.hu
Re: Serial Connection -- shielding
Le 31/03/11 13:30, Stephen Powell a écrit : On Wed, 30 Mar 2011 06:30:59 -0400 (EDT), MAROUNI Abbass wrote: On Tue, 29 Mar 2011 21:27:39 -0400 (EDT), Stephen Powell wrote: As I've said before, the devil is in the details. You need to find out *exactly* how your cross-over cable or null modem is wired. There may be some asymmetry in the wiring that causes the cable to behave differently in opposite directions. The wiring should be symmetrical, ideally as shown in the following URL: http://en.wikipedia.org/wiki/File:D9_Null_Modem_Wiring.png The other possibility is that the serial communications settings are different. For example, minicom (or getty) might not be configured exactly the same on both servers. (Data bits, stop bits, parity, bit rate, type of flow control, etc.) It really is much easier with two serial ports per server and two serial cables. Connect /dev/ttyS0 on server 1 to /dev/ttyS1 on server 2 and connect /dev/ttyS0 on server 2 to /dev/ttyS1 on server 1. Have getty listen on /dev/ttyS0 on both servers. Have minicom open /dev/ttyS1 on both servers. I realize its two cables instead of one, but operationally it's much simpler. You want to do it with one cable? How about TCP/IP over ethernet and ssh sessions? That way, you can connect to any PC in the network with just one cable per server. The Two servers are exactly the same. getty and minicom have the same exact parameters. We need to use the serial connections in case one server is unaccessible or haven't come up after a restart, so we can connect to its pair and pass through the serial connection to see what's happening. The idea of using a single cable is to enconomise. I thought it would be relativley simple since it's logically possible. I migth need to check the cables but I think it's the standard Null modem. I thougth that it had something to do with port0 (ttyS0), but if the OS treats all the serial ports the same then it's not a software issue? As another poster has said, another thing you can try is to physically reverse the two ends of the serial cable to see if its a wiring symmetry issue. But as to using only a single serial cable, either you haven't thought things through well enough or I don't understand something. You say that "We need to use the serial connections in case one server is unaccesible or haven't come up after a restart, so we can connect to its pair and pass through the serial connection to see what's happening. The idea of using a single cable is to enconomise." I understand the desire to save money. But let's think this through. Let's say that things are currently set up for server 1 to login to server 2 via the serial connection. server 1 is running minicom and server 2 is running getty. If there is a problem with server 2, you may be able to use server 1 to diagnose the problem. That is the intention. That's what you want. But suppose its the other way around. Suppose you have a problem with server 1 and you want to use server 2 to diagnose it. The first thing you need to do is to reverse the direction. You can kill getty on server 2, since you presumably have access to its console. But how to you kill minicom on server 1 and start getty on server 1? You don't have access to it, remember? You can't reverse the direction of communications without physical access to *both* servers. That is why you need two serial ports on each server and two properly-wired cross-over cables. If you only care about one-way control, then why do you even care about being able to reverse the direction of communications? In a production environment, this what will happen : Two servers connected with a single serial cable ( Which I need to figure out how?! :) ), ttyS0 on server1 to ttyS0 on server2. getty is always listening to the ttyS0 port on both servers (assured by inittab respawn). Server1 is inaccessible. login to server2 launch a script that will kill getty and comment its entry from inittab then launch minicom toward ttyS0 on server1 login to server1 and find what happened. Finally on server2 quit minicom launch another small script that would put getty on ttyS0 and uncomment its entry from inittab. This way if something wrong happens to server2 I am sure that I have a getty on its ttyS0 and all I need to do is to go to server1 follow the same procedure. Reverse communication assured :) Logical isn't? :) I am still not convinced that the serial cable might have different ends if it's a standard null modem cable, so I don't think that reversing the ends between the two servers might help. Thanks. -- Abbass MAROUNI Internet Memory Foundation internetmemory.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d947e1f.2020...@internetmemory.org
Re: Serial Connection -- shielding
On Wed, 30 Mar 2011 06:30:59 -0400 (EDT), MAROUNI Abbass wrote: > On Tue, 29 Mar 2011 21:27:39 -0400 (EDT), Stephen Powell wrote: >> As I've said before, the devil is in the details. You need to find out >> *exactly* how your cross-over cable or null modem is wired. There may >> be some asymmetry in the wiring that causes the cable to behave differently >> in opposite directions. The wiring should be symmetrical, ideally as >> shown in the following URL: >> >> http://en.wikipedia.org/wiki/File:D9_Null_Modem_Wiring.png >> >> The other possibility is that the serial communications settings >> are different. For example, minicom (or getty) might not be >> configured exactly the same on both servers. (Data bits, stop bits, >> parity, bit rate, type of flow control, etc.) >> >> It really is much >> easier with two serial ports per server and two serial cables. >> Connect /dev/ttyS0 on server 1 to /dev/ttyS1 on server 2 and >> connect /dev/ttyS0 on server 2 to /dev/ttyS1 on server 1. Have >> getty listen on /dev/ttyS0 on both servers. Have minicom open >> /dev/ttyS1 on both servers. I realize its two cables instead >> of one, but operationally it's much simpler. You want to do it >> with one cable? How about TCP/IP over ethernet and ssh sessions? >> That way, you can connect to any PC in the network with just one >> cable per server. > > The Two servers are exactly the same. getty and minicom have the same > exact parameters. > We need to use the serial connections in case one server is unaccessible > or haven't come up after a restart, so we can connect to its pair and > pass through the serial connection to see what's happening. The idea of > using a single cable is to enconomise. I thought it would be relativley > simple since it's logically possible. I migth need to check the cables > but I think it's the standard Null modem. > > I thougth that it had something to do with port0 (ttyS0), but if the OS > treats all the serial ports the same then it's not a software issue? As another poster has said, another thing you can try is to physically reverse the two ends of the serial cable to see if its a wiring symmetry issue. But as to using only a single serial cable, either you haven't thought things through well enough or I don't understand something. You say that "We need to use the serial connections in case one server is unaccesible or haven't come up after a restart, so we can connect to its pair and pass through the serial connection to see what's happening. The idea of using a single cable is to enconomise." I understand the desire to save money. But let's think this through. Let's say that things are currently set up for server 1 to login to server 2 via the serial connection. server 1 is running minicom and server 2 is running getty. If there is a problem with server 2, you may be able to use server 1 to diagnose the problem. That is the intention. That's what you want. But suppose its the other way around. Suppose you have a problem with server 1 and you want to use server 2 to diagnose it. The first thing you need to do is to reverse the direction. You can kill getty on server 2, since you presumably have access to its console. But how to you kill minicom on server 1 and start getty on server 1? You don't have access to it, remember? You can't reverse the direction of communications without physical access to *both* servers. That is why you need two serial ports on each server and two properly-wired cross-over cables. If you only care about one-way control, then why do you even care about being able to reverse the direction of communications? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/790100680.1843209.1301571043112.javamail.r...@md01.wow.synacor.com
Re: Serial Connection -- shielding
MAROUNI Abbass wrote: The Two servers are exactly the same. getty and minicom have the same exact parameters. Which are top secret. :-) I thought it would be relativley simple since it's logically possible. I migth need to check the cables but I think it's the standard Null modem. I thougth that it had something to do with port0 (ttyS0), but if the OS treats all the serial ports the same then it's not a software issue? If you reverse the cable, it works? You can try this tool for hardware-related diagnostics, but it's for windows. I'm using it for electronic development, if anyone knows an equivalent for linux, I'm interested too. https://sites.google.com/site/terminalbpp/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d934cfd.9050...@progzmaster.hu
Null modem cable; was Re (2): Serial Connection -- shielding
Abbass, > I migth need to check the cables but I think it's the standard Null modem. Yes, check the cable wiring with an ohmeter. All the hope in the world won't help. As Stephen said, > You need to find out > *exactly* how your cross-over cable or null modem is wired. There may > be some asymmetry in the wiring that causes the cable to behave differently > in opposite directions. The wiring should be symmetrical ... Symmetrical from end to end. Study this article, check the cable with an ohmeter and sketch the wiring to be sure. "http://en.wikipedia.org/wiki/Null_modem"; Regards, ... Peter E. -- Telephone 1 360 450 2132. Shop pages http://carnot.yi.org/ accessible as long as the old drives survive. Personal pages http://members.shaw.ca/peasthope/ . -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/171056958.34229.31981@cantor.invalid
Re: Serial Connection
Scott Ferguson wrote: The term "balanced" is often confused or mystified by electronic engineers too, but if you drive and receive two wires with equal impedance, and compare the signals to each other and not to (local) GND, that is a balanced transmission. I suspect some of the confusion (in this thread) comes from the difference between an ideal balanced state, and a non-functioning state. [...] More importantly - the 'phone system, particularly the outsiders view of it, is not particularly relevant to the "serial connection" cabling question. :-) [...] Note: the opinions and experiences of telecommunications technicians, and Complex Data Testers may differ from that of textbooks ;-p I don't want to go deeper in this flame, since these things are cleary stated in standards and textbooks, the priciples were invented at least one century ago. The opinons doesn't matter, only the physics. Those who think it's the best idea to transmit RS-232 signals in UTP cables, I recommend further learning in this area. Or if you don't believe in textbooks, just try it! Try unshieled cable, try shielded, wire-by-wire shielded, TP cable, and try the same TP cable with RS485 transceivers (and surprise...) Interconnecting two line-level audio equipment is even more expressive, you obviously will hear the difference! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d934a7d.1090...@progzmaster.hu
Re: Serial Connection -- shielding
Le 30/03/11 03:27, Stephen Powell a écrit : On Tue, 29 Mar 2011 10:18:50 -0400 (EDT), MAROUNI Abbass wrote: I think that the discussion diverted somehow from my original question. My problem was the following : Two identical servers Z0& Z1 and a null modem cable. ttyS0 on Z0 connected to ttyS1 on Z1. on ttyS0 on Z0 I have a getty listening for incoming connections. on ttyS1 on Z1 I launch a minicom toward ttyS0 on Z0 and I login normally. Now When I try to do the inverse : Kill getty on ttyS0 on Z0 and remove it from inittab. Set getty to listen to ttyS1 on Z1. Launch minicom on ttyS0 on Z0 toward ttyS1 on Z1. I can't login all I see is garbage. All the serial parameters are the same on both sides. I thought that logically this setup have to work since I am using the same setup just changing which port on which server. I am trying to do this for a Datacenter with hundreds of servers. This way I can connect two servers together with just one serial cable. Does it have something to do with the ttyS0 port? is it a software problem? Do you have any ideas ? (Apart from theoretical discussions about all the standards) As I've said before, the devil is in the details. You need to find out *exactly* how your cross-over cable or null modem is wired. There may be some asymmetry in the wiring that causes the cable to behave differently in opposite directions. The wiring should be symmetrical, ideally as shown in the following URL: http://en.wikipedia.org/wiki/File:D9_Null_Modem_Wiring.png The other possibility is that the serial communications settings are different. For example, minicom (or getty) might not be configured exactly the same on both servers. (Data bits, stop bits, parity, bit rate, type of flow control, etc.) It really is much easier with two serial ports per server and two serial cables. Connect /dev/ttyS0 on server 1 to /dev/ttyS1 on server 2 and connect /dev/ttyS0 on server 2 to /dev/ttyS1 on server 1. Have getty listen on /dev/ttyS0 on both servers. Have minicom open /dev/ttyS1 on both servers. I realize its two cables instead of one, but operationally it's much simpler. You want to do it with one cable? How about TCP/IP over ethernet and ssh sessions? That way, you can connect to any PC in the network with just one cable per server. The Two servers are exactly the same. getty and minicom have the same exact parameters. We need to use the serial connections in case one server is unaccessible or haven't come up after a restart, so we can connect to its pair and pass through the serial connection to see what's happening. The idea of using a single cable is to enconomise. I thought it would be relativley simple since it's logically possible. I migth need to check the cables but I think it's the standard Null modem. I thougth that it had something to do with port0 (ttyS0), but if the OS treats all the serial ports the same then it's not a software issue? Merci, -- Abbass MAROUNI Internet Memory Foundation internetmemory.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d930663.50...@internetmemory.org
Re: Serial Connection
On 28/03/11 19:15, Moczik Gabor wrote: > Actually telephone is balanced. Yes, most of the time. Most commonly through correction > Telephone does not use the local ground > at your house, Correct-ish, they often use ground from the exchange . Though there's often non-copper sections between the exchange and your house, even if you are on POTS. Even that is not the full picture of the circuit in any given call. > it's inherently balanced. Interesting opinion. :-) Though I'd have to disagree. Balanced cable pairs are not uncommon, whereas *uncorrected balanced pairs* are extremely rare beasts. At a minimum you would expect to find "loss on one leg" at least intermittently, ditto extraneous signals. > > The term "balanced" is often confused or mystified by electronic > engineers too, but if you drive and receive two wires with equal > impedance, and compare the signals to each other and not to (local) GND, > that is a balanced transmission. > > I suspect some of the confusion (in this thread) comes from the difference between an ideal balanced state, and a non-functioning state. Most 'phone systems are extremely robust, and very few these days are pure copper. More importantly - the 'phone system, particularly the outsiders view of it, is not particularly relevant to the "serial connection" cabling question. :-) Note: the opinions and experiences of telecommunications technicians, and Complex Data Testers may differ from that of textbooks ;-p Cheers -- Tuttle? His name's Buttle. There must be some mistake. Mistake? [Chuckles] We don't make mistakes. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d92def5.8070...@gmail.com
Re: Serial Connection -- shielding
On 30/03/11 01:18, MAROUNI Abbass wrote: > Le 28/03/11 10:30, Russell L. Harris a �crit : >> to: >> CC: >> * Stan Hoeppner [110328 06:24]: >>> Moczik Gabor put forth on 3/28/2011 12:01 AM: Stan Hoeppner wrote: > I think that the discussion diverted somehow from my original question. > > My problem was the following : > Two identical servers Z0 & Z1 and a null modem cable. ttyS0 on Z0 > connected to ttyS1 on Z1. > on ttyS0 on Z0 I have a getty listening for incoming connections. > on ttyS1 on Z1 I launch a minicom toward ttyS0 on Z0 and I login normally. > > Now When I try to do the inverse : > Kill getty on ttyS0 on Z0 and remove it from inittab. Set getty to > listen to ttyS1 on Z1. Launch minicom on ttyS0 on Z0 toward ttyS1 on Z1. > > I can't login all I see is garbage. All the serial parameters are the > same on both sides. Which are? > I thought that logically this setup have to work since I am using the > same setup just changing which port on which server. Logically yes, *if* you covered the other half of the possible combinations - it is unclear from my interpretation of your post. (I can only 'assume' you can remove it from inittab) > > I am trying to do this for a Datacenter with hundreds of servers. This > way I can connect two servers together with just one serial cable. > > Does it have something to do with the ttyS0 port? is it a software problem? It could be both - or either, with out knowing the server setup, chipset details etc and security policies I can only guess. > > Do you have any ideas ? (Apart from theoretical discussions about all > the standards) > When I have previously encountered the situation you describe it was on systems using hardware control, and solved by using software control. I suggest you make sure you are using software control on *both* ends. Ensure you are not using -h when setting up the getty session (no hardware control) When starting the minicom session are you using software control? Check the global conf file, somewhere in /etc usually. Are the chipsets identical on both servers? There are/were some problematic serial chipsets. Perhaps if you post the exact commands you are using to start your getty sessions, your minicom global config, and what commands you are entering into minicom it might be easier to diagnose. Output of setserial from both machines might also be instructive. Cheers -- Tuttle? His name's Buttle. There must be some mistake. Mistake? [Chuckles] We don't make mistakes. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d92de0e.9090...@gmail.com
Re: Serial Connection -- shielding
On Tue, 29 Mar 2011 10:18:50 -0400 (EDT), MAROUNI Abbass wrote: > > I think that the discussion diverted somehow from my original question. > > My problem was the following : > Two identical servers Z0 & Z1 and a null modem cable. ttyS0 on Z0 > connected to ttyS1 on Z1. > on ttyS0 on Z0 I have a getty listening for incoming connections. > on ttyS1 on Z1 I launch a minicom toward ttyS0 on Z0 and I login normally. > > Now When I try to do the inverse : > Kill getty on ttyS0 on Z0 and remove it from inittab. Set getty to > listen to ttyS1 on Z1. Launch minicom on ttyS0 on Z0 toward ttyS1 on Z1. > > I can't login all I see is garbage. All the serial parameters are the > same on both sides. > I thought that logically this setup have to work since I am using the > same setup just changing which port on which server. > > I am trying to do this for a Datacenter with hundreds of servers. This > way I can connect two servers together with just one serial cable. > > Does it have something to do with the ttyS0 port? is it a software problem? > > Do you have any ideas ? (Apart from theoretical discussions about all > the standards) As I've said before, the devil is in the details. You need to find out *exactly* how your cross-over cable or null modem is wired. There may be some asymmetry in the wiring that causes the cable to behave differently in opposite directions. The wiring should be symmetrical, ideally as shown in the following URL: http://en.wikipedia.org/wiki/File:D9_Null_Modem_Wiring.png The other possibility is that the serial communications settings are different. For example, minicom (or getty) might not be configured exactly the same on both servers. (Data bits, stop bits, parity, bit rate, type of flow control, etc.) It really is much easier with two serial ports per server and two serial cables. Connect /dev/ttyS0 on server 1 to /dev/ttyS1 on server 2 and connect /dev/ttyS0 on server 2 to /dev/ttyS1 on server 1. Have getty listen on /dev/ttyS0 on both servers. Have minicom open /dev/ttyS1 on both servers. I realize its two cables instead of one, but operationally it's much simpler. You want to do it with one cable? How about TCP/IP over ethernet and ssh sessions? That way, you can connect to any PC in the network with just one cable per server. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1491094980.1812990.1301448459743.javamail.r...@md01.wow.synacor.com
Re: Serial Connection -- handshaking
* MAROUNI Abbass [110329 14:21]: > I think that the discussion diverted somehow from my original question. > > My problem was the following : > Two identical servers Z0 & Z1 and a null modem cable. ttyS0 on Z0 > connected to ttyS1 on Z1. > on ttyS0 on Z0 I have a getty listening for incoming connections. > on ttyS1 on Z1 I launch a minicom toward ttyS0 on Z0 and I login normally. > > Now When I try to do the inverse : > Kill getty on ttyS0 on Z0 and remove it from inittab. Set getty to > listen to ttyS1 on Z1. Launch minicom on ttyS0 on Z0 toward ttyS1 on > Z1. > > I can't login all I see is garbage. All the serial parameters are > the same on both sides. > I thought that logically this setup have to work since I am using > the same setup just changing which port on which server. > > I am trying to do this for a Datacenter with hundreds of servers. > This way I can connect two servers together with just one serial > cable. > > Does it have something to do with the ttyS0 port? is it a software problem? > > Do you have any ideas ? (Apart from theoretical discussions about > all the standards) A "null modem" cable may be simple (three conductors) or complex(seven or more conductors), depending upon whether "handshaking" is accomplished in hardware or software. With hardware handshaking, each end of the connection typically has a "ready" signal and a "clear to send" signal. If you are sending in both directions, these signals must be provided in both directions. The signals are set by the standard "RS-232", which was up to revision "C" the last time I used it (that is, "RS-232C"). Of course, the software may not inspect all of the signals which the hardware provides, and not all hardware provides a complete set of signals. Thus, experimentation may be required. RLH -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110329211922.GB2440@cromwell.tmiaf
Re: Serial Connection -- shielding
Le 28/03/11 10:30, Russell L. Harris a écrit : to: CC: * Stan Hoeppner [110328 06:24]: Moczik Gabor put forth on 3/28/2011 12:01 AM: Stan Hoeppner wrote: We bought DB25 plugs in bags of 100, and used spooled CAT5 as the noise rejection is many times that of CAT3, allowing greater distances across sprawling warehouses. RS-232 uses single-ended signaling and requires shielded cable, twisted pair doesn't help either. Shielding provides immunity (not always perfect) against radio-frequency interference. But shielding (aside from an enclosure or conduit of iron or steel) provides no immunity against magnetic fields. If an RS-232 cable does not run near electric motors or switchgear, or make a long run parallel to power cables, and if radio-frequency interference is not a problem, then CAT5, CAT3, or even multiple strands of lamp cord may be satisfactory, without a shield. In fact, lamp cord -- typically 18 AWG stranded copper -- should allow longer runs, because of its much lower resistance (and thus, lower signal attenuation). And, at some point, capacitance of the circuit can become a problem, because it limits the usable data rate. RLH I think that the discussion diverted somehow from my original question. My problem was the following : Two identical servers Z0 & Z1 and a null modem cable. ttyS0 on Z0 connected to ttyS1 on Z1. on ttyS0 on Z0 I have a getty listening for incoming connections. on ttyS1 on Z1 I launch a minicom toward ttyS0 on Z0 and I login normally. Now When I try to do the inverse : Kill getty on ttyS0 on Z0 and remove it from inittab. Set getty to listen to ttyS1 on Z1. Launch minicom on ttyS0 on Z0 toward ttyS1 on Z1. I can't login all I see is garbage. All the serial parameters are the same on both sides. I thought that logically this setup have to work since I am using the same setup just changing which port on which server. I am trying to do this for a Datacenter with hundreds of servers. This way I can connect two servers together with just one serial cable. Does it have something to do with the ttyS0 port? is it a software problem? Do you have any ideas ? (Apart from theoretical discussions about all the standards) -- Abbass MAROUNI Internet Memory Foundation internetmemory.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d91ea4a.8080...@internetmemory.org
Re: Serial Connection -- shielding
to: CC: * Stan Hoeppner [110328 06:24]: > Moczik Gabor put forth on 3/28/2011 12:01 AM: > > Stan Hoeppner wrote: > >> We bought DB25 plugs in bags of 100, and used spooled CAT5 as the noise > >> rejection is many times that of CAT3, allowing greater distances across > >> sprawling warehouses. > > > > RS-232 uses single-ended signaling and requires shielded cable, twisted > > pair doesn't help either. Shielding provides immunity (not always perfect) against radio-frequency interference. But shielding (aside from an enclosure or conduit of iron or steel) provides no immunity against magnetic fields. If an RS-232 cable does not run near electric motors or switchgear, or make a long run parallel to power cables, and if radio-frequency interference is not a problem, then CAT5, CAT3, or even multiple strands of lamp cord may be satisfactory, without a shield. In fact, lamp cord -- typically 18 AWG stranded copper -- should allow longer runs, because of its much lower resistance (and thus, lower signal attenuation). And, at some point, capacitance of the circuit can become a problem, because it limits the usable data rate. RLH -- Who is this that darkeneth counsel by words without knowledge? - Job 38:2 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110328083033.GB3041@cromwell.tmiaf
Re: Serial Connection
Stan Hoeppner wrote: Moczik Gabor put forth on 3/28/2011 12:01 AM: Stan Hoeppner wrote: We bought DB25 plugs in bags of 100, and used spooled CAT5 as the noise rejection is many times that of CAT3, allowing greater distances across sprawling warehouses. RS-232 uses single-ended signaling and requires shielded cable, twisted pair doesn't help either. Interesting to see you state this, considering the experience of many IT folk stuck supporting legacy serial terminals and printers proves the opposite to be true. Back in 1996/7 I worked for such a legacy equipment using company, a chemical producer in St. Louis. We were routinely (weekly) making 200+ ft. CAT5 UTP (24 AWG solid plenum cable) runs across warehouses and production buildings. The connections were between RS232 Wyse terminals, thermal label printers, and ethernet terminal servers at 9600 bps, using 3 conductors, one twisted pair (orange/white-orange) and one single conductor of another pair (green) for ground. We could reliably run 115,200 bps on runs up to 50 ft. using CAT5 UTP. The cables distances we routinely achieved were obviously many times the RS232 spec maximums. Actually, I regularly use 5..15m (~16..50ft) RS232 cables at 115kbps without problems. Shielded non-TP cables, of course. :-) Twisting RX and TX signals together is the worst that can be done. If it runs long enough, the transmit signal of one end will induced as noise to the transmit signal of other end. Twisting RX and GND (TX and GND) together is maybe acceptable. I'm sure that it is worse than one-by-one shielded wires, but maybe better than two unshieleded. For example, if you replace the RS-232 transceivers with RS-485, you can transmit the same serial port data on the same (TP) cable on the same bitrate, but magnitudes longer distance. 1200m (4000 ft) or maybe more achiveable, even at 115200bps! The common-mode noise rejection of twisted pair only works if the signals connected to a balanced input receiver. Twisted pair cabled achieves its rejection performance against EMI/RFI simply due to its design, not whether the signal is balanced or not. Simply no. Please read about balanced and unbalanced transmission. An unshielded TP cable with unbalanced transmission is nothing better than a single wire. The cable pair wires must be driven AND received with equal impedances to have great common-mode rejection. It doesn't matter that the signal levels according to GND are perfectly symmetrical or not, but the impedances must be equal. Here are two (electronic) articles about balanced transmission (of audio signals, but the principles are the same): http://sound.westhost.com/project51.htm http://sound.westhost.com/project87.htm If any non-negligible length of the cable is in proximity to a noise source, having twisted conductors minimizes the potential pick up area of any one conductor. No. The principle is that BOTH conductors of a pair receives the SAME noise, but the differential receiver substracts the two signals, cancelling noise. If you measure (with oscilloscope) both signals according to GND, you will see that both wires pick up the same polarity and amplitude noise. UTP have been used for telephones for more than 6 decades, and I'm pretty sure everyone knows telephones don't use balanced signals. Actually telephone is balanced. Telephone does not use the local ground at your house, it's inherently balanced. The term "balanced" is often confused or mystified by electronic engineers too, but if you drive and receive two wires with equal impedance, and compare the signals to each other and not to (local) GND, that is a balanced transmission. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9043af.1000...@progzmaster.hu
Re: Serial Connection - balancing
* Stan Hoeppner [110328 06:24]: > The single largest user of twisted pair cable, its inventor and > progenitor actually, was AT&T (the old monopoly AT&T), now known as many > different companies after the 1980s breakup of the AT&T monpoly and the > creation of the "baby Bells", now known as Verizon et al. CAT1 and CAT3 > UTP have been used for telephones for more than 6 decades, and I'm > pretty sure everyone knows telephones don't use balanced signals. You are wrong -- dead wrong. Telephone circuits are balanced; that explains their inherent noise immunity. Perhaps you are being confused by the fact that there are a number of ways to implement a balanced circuit. The broadcast audio gear manufacturers Aphex, Jensen (transformers), and Rane all provide excellent tutorials on balancing which are available freely on their web sites. And the balanced telephone circuit goes back to the very beginning of telephony, before AT&T came into existence. You need to check your facts before you make an assertion. RLH -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110328081456.GA3041@cromwell.tmiaf
Re: Serial Connection
Moczik Gabor put forth on 3/28/2011 12:01 AM: > Stan Hoeppner wrote: >> We bought DB25 plugs in bags of 100, and used spooled CAT5 as the noise >> rejection is many times that of CAT3, allowing greater distances across >> sprawling warehouses. > > RS-232 uses single-ended signaling and requires shielded cable, twisted > pair doesn't help either. Interesting to see you state this, considering the experience of many IT folk stuck supporting legacy serial terminals and printers proves the opposite to be true. Back in 1996/7 I worked for such a legacy equipment using company, a chemical producer in St. Louis. We were routinely (weekly) making 200+ ft. CAT5 UTP (24 AWG solid plenum cable) runs across warehouses and production buildings. The connections were between RS232 Wyse terminals, thermal label printers, and ethernet terminal servers at 9600 bps, using 3 conductors, one twisted pair (orange/white-orange) and one single conductor of another pair (green) for ground. We could reliably run 115,200 bps on runs up to 50 ft. using CAT5 UTP. The cables distances we routinely achieved were obviously many times the RS232 spec maximums. > The common-mode noise rejection of twisted > pair only works if the signals connected to a balanced input receiver. Twisted pair cabled achieves its rejection performance against EMI/RFI simply due to its design, not whether the signal is balanced or not. If any non-negligible length of the cable is in proximity to a noise source, having twisted conductors minimizes the potential pick up area of any one conductor. The single largest user of twisted pair cable, its inventor and progenitor actually, was AT&T (the old monopoly AT&T), now known as many different companies after the 1980s breakup of the AT&T monpoly and the creation of the "baby Bells", now known as Verizon et al. CAT1 and CAT3 UTP have been used for telephones for more than 6 decades, and I'm pretty sure everyone knows telephones don't use balanced signals. You should read about the history of UTP cabling. It's pretty interesting, for a geek anyway. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d90295e.2080...@hardwarefreak.com
Re: Serial Connection
Stan Hoeppner wrote: We bought DB25 plugs in bags of 100, and used spooled CAT5 as the noise rejection is many times that of CAT3, allowing greater distances across sprawling warehouses. RS-232 uses single-ended signaling and requires shielded cable, twisted pair doesn't help either. The common-mode noise rejection of twisted pair only works if the signals connected to a balanced input receiver. Industrial RS-485 communication is one of these solutions, for example. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d901636.5060...@progzmaster.hu
Re: Serial Connection
On 28/03/11 11:46, Stephen Powell wrote: > On Sun, 27 Mar 2011 16:27:08 -0400 (EDT), Stan Hoeppner wrote: >> >> For attaching a terminal all you need to connect are pins 2, 3, and 7 on >> a DB25, or 2, 3, and 5 on a DB9. Reverse 2,3 on one end of each cable >> to get your x-over. All the other pins are for modems only and are not >> used for terminal connections. Serial printers only need 2, 3, 7 as well. > > That would be transmit data (TD), receive data (RD), and signal ground (SG), > respectively. That is the minimum. But it may not be sufficient. > If the terminal is set up for hardware flow control, for example, it > won't be sufficient. Besides, the OP wants to cross-cable two servers > together, it seems, and use a minicom session on one to open a terminal > session > on the other. minicom was written for use with a modem and probably > expects more of these lines to be functional than just TD, RD, and SG. > The devil is in the details. If he uses a full cross-over cable, as > outlined in > >http://en.wikipedia.org/wiki/File:D9_Null_Modem_Wiring.png > > (or a standard serial cable with a similarly wired null modem), it should > work with any DTE-to-DTE connection. > If using hardware control then yes, three wires is not enough (you'll get garbage), if using software control he should have no problems. I use that set up frequently without problems Specifically:- minicom both ends, software control on. (It'll also work for laplink under DOS). For a quick solution when a proper cable is not on hand:- Strip a centimetre or two of insulation off both ends of three lengths of wire, using a nail or toothpick as a former make a wire wrap/coil, cover the wirewrap/coil in tape and carefully slide it off the former onto the serial pin. Works fine - I also use the same setups for quick and dirty serial port logging connections. Haven't tried it for printers. Currently using exactly that setup to monitor an old SGI Octane on the workbench now. Cheers -- > A: Yes. > >Q: Are you sure? > >>A: Because it reverses the logical flow of conversation. > >>>Q: Why is top posting frowned upon? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8fde5f.6090...@gmail.com
Re: Serial Connection
On Sun, 27 Mar 2011 19:30:49 -0400 (EDT), ow...@netptc.net wrote: > On Sun, 27 Mar 2011 14:41:37 -0400 (EDT, Stephen Powell wrote: >> >> That's true. But a properly-wired cross-over cable or null modem >> not only crosses over TD and RD but also crosses over DTR and DSR >> and also crosses over RTS and CTS. Ground, of course, is wired >> to Ground. CD is normally tied to DSR on the same side of the >> interface (on both sides). RI is usually left unconnected. >> >> See, for example, >> >>http://en.wikipedia.org/wiki/File:D9_Null_Modem_Wiring.png > > Yes Stephen that's the "traditional approach". Unfortunately > there are at least half-a dozen non-standard configurations > (e.g. permanent RTS, connecting DSR to DTR) which drive RS-232 > people nuts. I agree that the place to start is with your > traditional cable or with a null modem adaptor (essentially a > black box that does all the interconnections for you, allowing > straight through cables from either side to the boxes) but beware > this may not work in all situations. I agree. Special situations may require special wiring. As I said in another post, the devil is in the details. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2019024296.1757667.1301273806216.javamail.r...@md01.wow.synacor.com
Re: Serial Connection
On Sun, 27 Mar 2011 16:27:08 -0400 (EDT), Stan Hoeppner wrote: > > For attaching a terminal all you need to connect are pins 2, 3, and 7 on > a DB25, or 2, 3, and 5 on a DB9. Reverse 2,3 on one end of each cable > to get your x-over. All the other pins are for modems only and are not > used for terminal connections. Serial printers only need 2, 3, 7 as well. That would be transmit data (TD), receive data (RD), and signal ground (SG), respectively. That is the minimum. But it may not be sufficient. If the terminal is set up for hardware flow control, for example, it won't be sufficient. Besides, the OP wants to cross-cable two servers together, it seems, and use a minicom session on one to open a terminal session on the other. minicom was written for use with a modem and probably expects more of these lines to be functional than just TD, RD, and SG. The devil is in the details. If he uses a full cross-over cable, as outlined in http://en.wikipedia.org/wiki/File:D9_Null_Modem_Wiring.png (or a standard serial cable with a similarly wired null modem), it should work with any DTE-to-DTE connection. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1560657861.1757468.1301273172399.javamail.r...@md01.wow.synacor.com
Re: Serial Connection
- Original Message - From: Stephen Powell To: debian-user@lists.debian.org Sent: 3/27/2011 6:41:37 PM Subject: Re: Serial Connection On Sun, 27 Mar 2011 11:40:40 -0400 (EDT), ow...@netptc.net wrote: > On Sat, 26 Mar 2011 18:52:23 -0400 (EDT, Stephen Powell wrote: >> >> I haven't tried this, but one thing you want to make sure of is that >> you use a "cross-over" cable. The serial ports on PCs have what's known >> as a DTE interface (Data Terminal Equipment). The serial ports on >> modems have what's known as a DCE interface (Data Communications >> Equipment). A standard serial cable is designed to connect a DTE >> interface to a DCE interface (i.e. a computer to a modem). >> What you are trying to do is connect two DTE interfaces together. >> For that you need to use a special serial cable called a "cross-over" >> cable which is specifically designed to connect a DTE interface to >> another DTE interface. If you try to use a regular serial cable, >> one designed to connect a DTE interface to a DCE interface, it won't work. >> >> An alternative to using a cross-over cable is to use a device called >> a "null modem" on one end of your serial cable. A null modem attached >> to a standard serial cable effectively converts it into a cross-over >> cable. >> >> Connecting a serial printer to a computer also requires a cross-over >> cable or a standard cable plus a null modem, since both devices have >> a DTE interface. >> >> You also might have to use two cables and two serial ports. One serial >> port looks like a modem, with you as the terminal. minicom >> allocates it. The other serial port looks like a serial console, >> with you as the host. getty allocates it. The other server sees >> a similar pattern. > > There's usually more than crossing Transmit Data and Receive Data. > There are at least two control signals that are applicable. > Usually one "borrows" what is known as a break-out box to determine > which signals each side of the interface are active. There are > lots of good googles for RS-232 that will help. That's true. But a properly-wired cross-over cable or null modem not only crosses over TD and RD but also crosses over DTR and DSR and also crosses over RTS and CTS. Ground, of course, is wired to Ground. CD is normally tied to DSR on the same side of the interface (on both sides). RI is usually left unconnected. See, for example, http://en.wikipedia.org/wiki/File:D9_Null_Modem_Wiring.png -- .''`. Stephen Powell : :' : `. `'` `- Yes Stephen that's the "traditional approach". Unfortunately there are at least half-a dozen non-standard configurations (e.g. permanent RTS, connecting DSR to DTR) which drive RS-232 people nuts. I agree that the place to start is with your traditional cable or with a null modem adaptor (essentially a black box that does all the interconnections for you, allowing straight through cables from either side to the boxes) but beware this may not work in all situations. Larry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: 835019430.1751010.1301251297388.javamail.r...@md01.wow.synacor.com">http://lists.debian.org/835019430.1751010.1301251297388.javamail.r...@md01.wow.synacor.com
Re: Serial Connection
Stephen Powell put forth on 3/27/2011 1:41 PM: > That's true. But a properly-wired cross-over cable or null modem > not only crosses over TD and RD but also crosses over DTR and DSR > and also crosses over RTS and CTS. Ground, of course, is wired > to Ground. CD is normally tied to DSR on the same side of the > interface (on both sides). RI is usually left unconnected. For attaching a terminal all you need to connect are pins 2, 3, and 7 on a DB25, or 2, 3, and 5 on a DB9. Reverse 2,3 on one end of each cable to get your x-over. All the other pins are for modems only and are not used for terminal connections. Serial printers only need 2, 3, 7 as well. At a previous job about 13 years ago I made so damn many of these serial x-over cables, daily, that "2, 3, 7" intruded on my dreams... We bought DB25 plugs in bags of 100, and used spooled CAT5 as the noise rejection is many times that of CAT3, allowing greater distances across sprawling warehouses. We'd drop an ethernet->serial terminal server in each building and then run our custom RJ45 to DB25 cables to the terminals. The terminal servers had RJ45 jacks for density. We used 16 and 48 port models. Can't recall the brand, been too long (thank God). -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d8f9d9c@hardwarefreak.com
Re: Serial Connection
On Sun, 27 Mar 2011 11:40:40 -0400 (EDT), ow...@netptc.net wrote: > On Sat, 26 Mar 2011 18:52:23 -0400 (EDT, Stephen Powell wrote: >> >> I haven't tried this, but one thing you want to make sure of is that >> you use a "cross-over" cable. The serial ports on PCs have what's known >> as a DTE interface (Data Terminal Equipment). The serial ports on >> modems have what's known as a DCE interface (Data Communications >> Equipment). A standard serial cable is designed to connect a DTE >> interface to a DCE interface (i.e. a computer to a modem). >> What you are trying to do is connect two DTE interfaces together. >> For that you need to use a special serial cable called a "cross-over" >> cable which is specifically designed to connect a DTE interface to >> another DTE interface. If you try to use a regular serial cable, >> one designed to connect a DTE interface to a DCE interface, it won't work. >> >> An alternative to using a cross-over cable is to use a device called >> a "null modem" on one end of your serial cable. A null modem attached >> to a standard serial cable effectively converts it into a cross-over >> cable. >> >> Connecting a serial printer to a computer also requires a cross-over >> cable or a standard cable plus a null modem, since both devices have >> a DTE interface. >> >> You also might have to use two cables and two serial ports. One serial >> port looks like a modem, with you as the terminal. minicom >> allocates it. The other serial port looks like a serial console, >> with you as the host. getty allocates it. The other server sees >> a similar pattern. > > There's usually more than crossing Transmit Data and Receive Data. > There are at least two control signals that are applicable. > Usually one "borrows" what is known as a break-out box to determine > which signals each side of the interface are active. There are > lots of good googles for RS-232 that will help. That's true. But a properly-wired cross-over cable or null modem not only crosses over TD and RD but also crosses over DTR and DSR and also crosses over RTS and CTS. Ground, of course, is wired to Ground. CD is normally tied to DSR on the same side of the interface (on both sides). RI is usually left unconnected. See, for example, http://en.wikipedia.org/wiki/File:D9_Null_Modem_Wiring.png -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/835019430.1751010.1301251297388.javamail.r...@md01.wow.synacor.com
Re: Serial Connection
- Original Message - From: Stephen Powell To: debian-user@lists.debian.org Sent: 3/26/2011 10:52:23 PM Subject: Serial Connection On Mon, 21 Mar 2011 at 17:45:17 +0100, MAROUNI Abbass wrote: > > I have two servers with Debian Lenny installed. > > The two servers have a serial cable connected form Stty0 on Server0 > to Stty1 on Server1. I can use minicom to log into Server0, but when > I try to login to Server1 from Server0 using minicom I get some garbage > and I can't type anything with the keyboard. > > Any Ideas?? I haven't tried this, but one thing you want to make sure of is that you use a "cross-over" cable. The serial ports on PCs have what's known as a DTE interface (Data Terminal Equipment). The serial ports on modems have what's known as a DCE interface (Data Communications Equipment). A standard serial cable is designed to connect a DTE interface to a DCE interface (i.e. a computer to a modem). What you are trying to do is connect two DTE interfaces together. For that you need to use a special serial cable called a "cross-over" cable which is specifically designed to connect a DTE interface to another DTE interface. If you try to use a regular serial cable, one designed to connect a DTE interface to a DCE interface, it won't work. An alternative to using a cross-over cable is to use a device called a "null modem" on one end of your serial cable. A null modem attached to a standard serial cable effectively converts it into a cross-over cable. Connecting a serial printer to a computer also requires a cross-over cable or a standard cable plus a null modem, since both devices have a DTE interface. You also might have to use two cables and two serial ports. One serial port looks like a modem, with you as the terminal. minicom allocates it. The other serial port looks like a serial console, with you as the host. getty allocates it. The other server sees a similar pattern. -- .''`. Stephen Powell : :' : `. `'` `- There's usually more than crossing Transmit Data and Receive Data. There are at least two control signals that are applicable. Usually one "borrows" what is known as a break-out box to determine which signals each side of the interface are active. There are lots of good googles for RS-232 that will help. Larry -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: 1489274790.1739751.1301179943578.javamail.r...@md01.wow.synacor.com">http://lists.debian.org/1489274790.1739751.1301179943578.javamail.r...@md01.wow.synacor.com
Serial Connection
On Mon, 21 Mar 2011 at 17:45:17 +0100, MAROUNI Abbass wrote: > > I have two servers with Debian Lenny installed. > > The two servers have a serial cable connected form Stty0 on Server0 > to Stty1 on Server1. I can use minicom to log into Server0, but when > I try to login to Server1 from Server0 using minicom I get some garbage > and I can't type anything with the keyboard. > > Any Ideas?? I haven't tried this, but one thing you want to make sure of is that you use a "cross-over" cable. The serial ports on PCs have what's known as a DTE interface (Data Terminal Equipment). The serial ports on modems have what's known as a DCE interface (Data Communications Equipment). A standard serial cable is designed to connect a DTE interface to a DCE interface (i.e. a computer to a modem). What you are trying to do is connect two DTE interfaces together. For that you need to use a special serial cable called a "cross-over" cable which is specifically designed to connect a DTE interface to another DTE interface. If you try to use a regular serial cable, one designed to connect a DTE interface to a DCE interface, it won't work. An alternative to using a cross-over cable is to use a device called a "null modem" on one end of your serial cable. A null modem attached to a standard serial cable effectively converts it into a cross-over cable. Connecting a serial printer to a computer also requires a cross-over cable or a standard cable plus a null modem, since both devices have a DTE interface. You also might have to use two cables and two serial ports. One serial port looks like a modem, with you as the terminal. minicom allocates it. The other serial port looks like a serial console, with you as the host. getty allocates it. The other server sees a similar pattern. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1489274790.1739751.1301179943578.javamail.r...@md01.wow.synacor.com
Serial Connection
Hello all, I have two servers with Debian Lenny installed. The two servers have a serial cable connected form Stty0 on Server0 to Stty1 on Server1. I can use minicom to log into Server0, but when I try to login to Server1 from Server0 using minicom I get some garbage and I can't type anything with the keyboard. Any Ideas?? Note : I have disable the respawn getty in inittab (T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100) on both servers and I attach getty manauly to the port that I want (Stty0 or Stty1) but it's not working the other way around (from server0 to server1) Thanks. -- Abbass MAROUNI Internet Memory Foundation internetmemory.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d87809d.80...@internetmemory.org
Serial connection with Samsung V200 mobile phone
With the Samsung V200 phone I received a datacable (serial) with Windows software (EasyGPRS). I have tried to install the software on wine, but did not have success. I would like to be able to download pictures from the phone using the datacable. Does anyone know about Linux software able to do this? Regards Johann -- Johann Spies Telefoon: 021-808 4036 Informasietegnologie, Universiteit van Stellenbosch "Blessed is the man that trusteth in the LORD, and whose hope the LORD is."Jeremiah 17:7 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: zmodem file transfer w/ minicom over serial connection
<...> > > HDD IRQs are unmasked: > > hdparm -u1 # READ the hdparm manpage first! > > At which end? What does this do? both, if possible (may break things with some chipsets), it ensures serial IRQ events are handled in a timely manner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: zmodem file transfer w/ minicom over serial connection
on Wed, Sep 03, 2003 at 12:02:01PM -0600, Bruce Sass ([EMAIL PROTECTED]) wrote:
> --
> On Wed, 3 Sep 2003, Karsten M. Self wrote:
>
> > I'm running minicom over a null-modem serial cable settings: 57600 8N1.
> >
> > File transfer setting is:
> >
> > zmodem /usr/bin/sz -vv -be YUN Y Y
> >
> > I've played with that a bit, the default is /usr/sbin/sz -vv -b.
> >
> > When initiating a transfer, I do:
> >
> > $ rz# on the remote side of the link.
> >
> > Remote side shows:
> >
> > rz waiting to receive.**B010023be50
> >
> > ^AS # in minicom to start the transfer.
> >
> > Select protocol and file to transfer.
> >
> > The zmodem dialog shows:
> >
> > +---[zmodem upload - Press CTRL-C to quit]+
> > |t TIMEOUTB010023be50Retry 0: Got TIMEOUTCRetry 0: Got TIM|
> > |EOUT |
> > |CRetry 0: Got TIMEOUT|
> > | |
> > |Transfer incomplete |
> > | |
> > | READY: press any key to continue... |
> > +-+
> >
> > And back on the remote side I have:
> >
> > [EMAIL PROTECTED]:tmp]$ rz -vvv
> > Retry 0: Got TIMEOUTe.**B010023be50
> > C **B010023be50
> > Transfer incomplete
> >
> > Both sides have the lrzsz package installed.
> >
> > I'm stumped. This doesn't appear to be a frequently used configuration
> > ;-)
> >
> >
> > I've tried setting the blocksize ("-k") and escape control chars ("-e")
> > on send side, as well as connection baud rates of 9600, 19200, 38400,
> > and 57600. None of these appears to make a difference.
> >
> > Assistance appreciated.
> >
> > Peace.
> >
> >
>
> Hi,
>
> I do rz and sz from/to a remote system occasionally...
>
> setup is:
> A zmodem /usr/bin/sz -vv -e Y U N Y Y
> D zmodem /usr/bin/rz -r -U N D N Y Y
> M zmodem download string activates... D
Check on all three.
> (this last bit means that when you start to send, minicom will
> automatically fire up rz)
>
> HDD IRQs are unmasked:
> hdparm -u1 # READ the hdparm manpage first!
At which end? What does this do?
> Get it working at a low speed then work your way up up (if you can, I
> had trouble getting a serial console working reliably at anything
> better than 9600, although the ports speak to a modem at 115200!),
> also make sure minicom and setserial are doing the same thing to the
> ports at both ends.
Hrm.. Given that I can run ascii transfers w/ uuencoded files, I may
stick with that. Frustrating though.
> Hardware flow control will not work if you have a simple 3-wire null
> modem cable, software flow control should always work.
Tried both. Nope.
> I recall (years ago) having trouble getting zmodem transfers to work;
> the solution (iirc) was the -U, a touchy baudbase setting, and to not
> play with blocksize (zmodem handles dynamically) and escapes.
I'll mess w/ it some more in the am.
Thanks.
Peace.
--
Karsten M. Self <[EMAIL PROTECTED]>http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Defeat EU Software Patents! http://swpat.ffii.org/
pgp0.pgp
Description: PGP signature
zmodem file transfer w/ minicom over serial connection
I'm still trying to debug my file transfers between two Debian GNU/Linux
systems using zmodem file transfers from within minicom, over a serial
connection.
I'm running minicom over a null-modem serial cable settings: 57600 8N1.
File transfer setting is:
zmodem /usr/bin/sz -vv -be YUN Y Y
I've played with that a bit, the default is /usr/sbin/sz -vv -b.
When initiating a transfer, I do:
$ rz# on the remote side of the link.
Remote side shows:
rz waiting to receive.**B010023be50
^AS # in minicom to start the transfer.
Select protocol and file to transfer.
The zmodem dialog shows:
+---[zmodem upload - Press CTRL-C to quit]+
|t TIMEOUTB010023be50Retry 0: Got TIMEOUTCRetry 0: Got TIM|
|EOUT |
|CRetry 0: Got TIMEOUT|
| |
|Transfer incomplete |
| |
| READY: press any key to continue... |
+-+
And back on the remote side I have:
[EMAIL PROTECTED]:tmp]$ rz -vvv
Retry 0: Got TIMEOUTe.**B010023be50
C **B010023be50
Transfer incomplete
Both sides have the lrzsz package installed.
I'm stumped. This doesn't appear to be a frequently used configuration
;-)
I've tried setting the blocksize ("-k") and escape control chars ("-e")
on send side, as well as connection baud rates of 9600, 19200, 38400,
and 57600. None of these appears to make a difference.
Assistance appreciated.
Peace.
--
Karsten M. Self <[EMAIL PROTECTED]>http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Defeat EU Software Patents! http://swpat.ffii.org/
pgp0.pgp
Description: PGP signature
Re: Logging a serial connection on both sides
Mike Fedyk said: > How can I read-only log both sides with a program available in debian > (from debian-sid is ok, if required)? I'm sure it's overkill but I use minicom for logging, fire it up in screen, turn on the buffer logging and detach .. never tried doing exactly what your trying though, if it were me I would just use 2 serial cables going between the 2 systems nate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Logging a serial connection on both sides
Hi, I have a null serial cable between two debian linux systems. Niether side has a serial login setup on the serial port. I want to be able to catch an oops on either computer with the other still-working system, and log it to a file. Now, I've tried using ttylog, and found a nice bug (see the BTS), and ended up using cat instead. Now I get a problem when I want to log both sides (I was only logging one side before). Let's say I have comp1 and comp2. They're each logging to a file on their hard drive. comp1 outputs something through the serial cable, comp2 receives it. Now the file on comp1 gets some output that went to comp2, and then proceeds to continuously add newlines to the end. How can I read-only log both sides with a program available in debian (from debian-sid is ok, if required)? Thanks, Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Serial connection to windoze box
Hi, After many mistakes, defective cables, and a lot of help from these people, I have login to my Slink box from a Win95 box. I have: A null modem 9-pin mini cable about 10 meters long. HyperTerminal on Win95 (windows\Start Menu\Programs\Accessories\Hyper Terminal\hypertrm.exe) Direct to COM4 vt100 emulation 9600, 8, None, 1 stop, hardware | None flow ctrl At Slink end, /etc/securetty added lines: "ttyS0, ttyS1, ttyS3" below tty12" /etc/inittab: removed comment "#" from "T1:23:respawn/sbin/getty -L ttyS1 9600 vt100" A click on Send will download a file of your choice to the pwd directory on Linux. Hope this helps. -jw
Re: Serial connection to windoze box
Hello! Here I am again after a long, long time in a galaxy far, far away... Sorry for not replying so long, but I was terribly busy all the time. And thanks for all your work on this issue!! > After reading the .inf (it's in plain text, and commented :)), you don't > use a PPP connection - you use SLIP. It's and older and less flexible > than PPP, but it works rather well. I think I can switch the connection type in the DFUE configuration between PPP, SLIP and others. I think it can handle PPP, as also explained on the homepage of the author. > I'll see if I can get a hold of a Win95 system and play around with this > some later in the week, if you can wait that long. Yeah, that would be very great, but really don't spend hours trying this configuration. I will get a network card from a friend for free in a time, he said to me yesterday. And so the problem will probably be solved. BTW, I think this kermit also needs a PPP or similar connection running (->help files...)?? I don't know how to configure it to work on a serial line without any protocols. What do you think of Paul's suggestion to use minicom and on the win side teraterm PRO to transfer files? I'll try it out because he says it works at his PCs. Now, the net-emulation issue. The problem I seem to have is that I really don't know how to make the linux box react on the signals (which I don't know, too) the W95 dial-up sends over the serial line. Apart from this issue, which seems to be critical for such connections, I will read some magazines about linux networking, I think, because this "try and succeed" way won't work under linux, although I already have some idea about how it works. And, I don't know how to use ifconfig which wants me to specify a network adapter (and I don't know how to handle this serial-emulation device and which name it has). Perhaps it'll become clear but, as I said, don't work too much on this issue, only if it you're interested in it, 'cause I'll get a network card sooner or later. Kind Regards, Stephan Hachinger
Re: Serial connection to windoze box
Hello! Sorry for not replying for a so long time. I'll to get a network adapter soon, so that the problem will be solved. Thanks very much for your suggestion, I'll try it as it sounds quite easy and I'm no linux (network) expert. I'm also talking about the net emulation with Phil, but I think, it won't be very easy... Regards from Munich, Germany, Stephan Hachinger > If it's only to transfer files, I do the same thing with minicom on linux side > and TeraTerm Pro on windows side using the Z-MODEM serial protocol. TeraTerm Pro is > freeware. I use NT, but I'm sure I remember seeing that it works with Win95. > > If the connection is to log in to your slink box and run commands, you'll need to > get someone else's help ... > > Regards from (rainy) Scotland, > Paul >
Re: Serial connection to windoze box
Hello! Thanks very much for your reply. Here's the inf. It installs like a modem, so you really have to make and start a DFUE conection. There is some kind of (ppp?) communication if I start pppd (with options crtscts, home:remote ip, detach (what does that mean??-I've got it from the howtos), /dev/ttyS1) and the DFUE, but there is no successful connect. What, BTW, are the files which determine the ip adress and netmask for the Linux box? Or is the value I give to pppd sufficient? Another thing: The following command is supposed to work with Slackware (from the inf homepage): >>Windows 95 -> Linux This is probably the second most problematic connection. I have less experience with this. I have only connected my copy of Linux up to the CBX, but I have not tried a Win95 -> Lunix connection. Again, I have heard of people performing this connection, but I do not have any advice! Please see the technical description of the file for some hints on getting started. Supposedly, it works fine with Slackware using the following inittab entry to log into the first serial port: s1:45:respawn:/sbin/agetty 38400 ttyS0 network This same entry does not work at all with Debian Linux, however. With the Slackware linux distribution, there is an entry called network which tells agetty that what it sees is what it gets, pass everything straight through and don't try to translate ANYTHING (no special screen formatting characters), so the network keyword in the above statement is essential<< Can you please tell me what this command does, how to set the IP adress with it, and if such a thing works with debian some way?? That was a good start to a solution, I think. Kind Regards, Stephan Hachinger - Original Message - From: Phil Brutsche <[EMAIL PROTECTED]> To: Stephan Hachinger <[EMAIL PROTECTED]> Sent: Wednesday, September 29, 1999 3:49 AM Subject: Re: Serial connection to windoze box > A long time ago, in a galaxy far, far way, someone said... > > > I've now got the inf file, and I'm trying to use the dial-up-networking > > Could you send that file to me? > > > First of all, what protocol would you suggest? TCP/IP or IPX? > > TCP/IP - don't bother with IPX unless you're going to have anything to do > with Novell Netware. > > > Secondly, how can I get the DFUE to send the username and password to the > > Linux box correctly? > > I don't think you do. From the sound of things, what this does is make > the serial port look like another network adapter, like ethernet or token > ring, only a lot slower. > > > > > And, how can I configure the TCP/IP adresses of the Linux box (tried pppd > > (...) home:remote) and what PPPD options are important furthermore? > > > > That's a good question :) I've never actually done Windows <-> Linux > connectivity this way before. > > A good place to start would be the man page for pppd. Asking in some > networking-related newsgroups for settings that would be good for PPP > server software might turn up some solutions. Another good place to look > would be this address (chapter 26 of the PPP howto): > http://www.linuxdoc.org/HOWTO/PPP-HOWTO-26.html > > > > > I know, these all are "RTM"-questions, sorry, but please send me only some > > important tips, or links to the right howto places, if anyone knows about > > this issue. > > Actually, this isn't a RTFM subject - I've been using Linux for two years, > and have seen it come up only four times :). > > You may also want to ask in the newsgroups comp.os.linux.misc and > comp.os.linux.networking - I know as a fact that this question has come up > there before. > > I've also attached a message I sent to a fellow who was in a similar > position as you. He ended up using the Linux box as a sort of 'terminal > server', and using Kermit to transfer files. If all you want to do is > transfer files, this may be a decent alternative. > > -- > -- > Phil Brutsche [EMAIL PROTECTED] > > "There are two things that are infinite; Human stupidity and the > universe. And I'm not sure about the universe." - Albert Einstein > mdmcbx4.inf Description: Binary data
Re: Serial connection to windoze box
Hello! I've now got the inf file, and I'm trying to use the dial-up-networking (German: short: DFUE) to get a PPP connection over the serial line. Now, although I've read some chapters of the PPP FAQ, I've got some problems (don't know which one is the cause of that it doesn't work) First of all, what protocol would you suggest? TCP/IP or IPX? Secondly, how can I get the DFUE to send the username and password to the Linux box correctly? And, how can I configure the TCP/IP adresses of the Linux box (tried pppd (...) home:remote) and what PPPD options are important furthermore? I know, these all are "RTM"-questions, sorry, but please send me only some important tips, or links to the right howto places, if anyone knows about this issue. Kind Regards, Stephan Hachinger BTW: Ethernet cards are very cheap at Germany, too, but I don't have any money left at all :( - Original Message - From: Phil Brutsche <[EMAIL PROTECTED]> To: Stephan Hachinger <[EMAIL PROTECTED]> Cc: Sent: Monday, September 27, 1999 9:40 PM Subject: Re: Serial connection to windoze box > A long time ago, in a galaxy far, far way, someone said... > > > Hello! > > > > I'd like to connect my slink box to my W95 machine over a serial cable. If > > anyone knows a more or less comfortable way to do this, please let me know. > > > > Best solution was of course some network emulation, but I think this isn't > > possible. > > There's two ways of doing this: > > * Using HyperTerminal (or some other program) to make the slink system >act like a terminal server. > * PPP/SLIP over a serial cable. Unfortunately, when Win9x thinks of PPP >or SLIP, it also thinks of a modem. I hear there's a .inf floating >around that lets Win9x use PPP over a null modem. > > The best way of doing things, I think, is ethernet. I don't know how much > things cost in Germany, but here in the US you can get a "home networking > kit" for about US$70. It includes two PCI cards, a hub, and two ethernet > cables. > > -- > -- > Phil Brutsche [EMAIL PROTECTED] > > "There are two things that are infinite; Human stupidity and the > universe. And I'm not sure about the universe." - Albert Einstein > > > -- > Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null >
Re: Serial connection to windoze box
>Used ethernet cards cost pennies and Windows 95 >usually already has a >driver >for them. If you can track down some 50 ohm >terminators, these rest is >usually available for next to nothing. Make sure you get the kind of ethernet cards that have bnc coax connectors on them. RadioShack has coax cables with connectors on them already made up, and you can build your own terminators with 1/4 watt 47 ohm resistors. = Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . __ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com
Re: Serial connection to windoze box
Phil Brutsche wrote: > > The best way of doing things, I think, is ethernet. I don't know how much > things cost in Germany, but here in the US you can get a "home networking > kit" for about US$70. It includes two PCI cards, a hub, and two ethernet > cables. Used ethernet cards cost pennies and Windows 95 usually already has a driver for them. If you can track down some 50 ohm terminators, these rest is usually available for next to nothing. Andrew http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=45690
Re: Serial connection to windoze box
A long time ago, in a galaxy far, far way, someone said... > Hello! > > I'd like to connect my slink box to my W95 machine over a serial cable. If > anyone knows a more or less comfortable way to do this, please let me know. > > Best solution was of course some network emulation, but I think this isn't > possible. There's two ways of doing this: * Using HyperTerminal (or some other program) to make the slink system act like a terminal server. * PPP/SLIP over a serial cable. Unfortunately, when Win9x thinks of PPP or SLIP, it also thinks of a modem. I hear there's a .inf floating around that lets Win9x use PPP over a null modem. The best way of doing things, I think, is ethernet. I don't know how much things cost in Germany, but here in the US you can get a "home networking kit" for about US$70. It includes two PCI cards, a hub, and two ethernet cables. -- -- Phil Brutsche [EMAIL PROTECTED] "There are two things that are infinite; Human stupidity and the universe. And I'm not sure about the universe." - Albert Einstein
Serial connection to windoze box
Hello! I'd like to connect my slink box to my W95 machine over a serial cable. If anyone knows a more or less comfortable way to do this, please let me know. Best solution was of course some network emulation, but I think this isn't possible. Kind Regards, and thanks for any reply, Stephan Hachinger from Munich, Germany -- Sent through Global Message Exchange - http://www.gmx.net
Re: Direct serial connection
On Sun, 25 Apr 1999 18:41:44 -0500 (CDT), Jor-el wrote: >> You need a 2.2.x kernel for this to work or a patched 2.0.x one. Basically >> you use a kernel command-line parameter of "console=ttyS0" to make a serial >> terminal (box A in your setup) hooked to /dev/ttyS0 on machine B the display >> for machine B. You also need a getty running on /dev/ttyS0. > Do you know where to get hold of the patch for the 2.0.x kernels? A quick web search yielded: http://www.linuxhq.com/patch/20-p0100.html ftp://ftp.cistron.nl/pub/os/linux/kernel/v2.0/unoff-patches/ The latter probably is the "canonic" site since this is the domain the author (Mike van Smoerenburg(sp?)) is mailing from. > Also, the kernel command line parameter that you described - is it >for box A or box B? I need the monitor to be a console for Box A as well >as Box B (preferably on different ttys). The kernel command line parameter is for box B. It tells box B to redirect console output to its serial port. You would then start a terminal program like minicom or Seyon on box A that listens on box A's serial port that is connected with a null-modem to box B's serial port. Does that make things clearer to you? Or have I made it worse? :) Ralf -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/The Choice /V\ of a GNU /( )\ Generation ^^-^^
Re: Direct serial connection
On Sun, 25 Apr 1999, Robert Vollmert wrote: > Hi, > > On Sun, Apr 25, 1999 at 11:39:53AM -0500, Jor-el wrote: > > The what I would like to do is to use the monitor that I have as a > > console for both machines A and B. Unfortunately, I cant accomplish this > > via a CPU switch, thanks to the non-standard monitor cable (Aptiva S90) > > that I have. I was thinking that maybe I could hook up B as using a serial > > console, and connect the serial port to the serial port of A, and then > > somehow get the stuff displayed on a separate window / tty on A. > > I'd suggest creating a small network using PPP over your serial ports > (you would need a null-modem cable for this). You can then use telnet > on A to work on B, and can even run X apps on B. There is a section on > this in the PPP HOWTO (packages doc-linux-text or doc-linux-html). > Robert, Thanks for the answer, but you misunderstood my requirement entirely. The two machines are connected via ethernet already, and telnet works perfectly. But this doesnt make the monitor of machine A act as a _console_ for machine B. For instance, how would you monitor the bootup messages of machine B using the setup you described? I think the answer that Ralf Bergs has provided is more suitable. Jor-el
Re: Direct serial connection
On Sun, 25 Apr 1999, Ralf G. R. Bergs wrote: > On Sun, 25 Apr 1999 11:39:53 -0500 (CDT), Jor-el wrote: > > >Is this possible? > > Yes. See /usr/src/linux/Documentation/serial-console.txt. > > I've just done it (after having some trouble due to an incorrect > /dev/console device). > > You need a 2.2.x kernel for this to work or a patched 2.0.x one. Basically > you use a kernel command-line parameter of "console=ttyS0" to make a serial > terminal (box A in your setup) hooked to /dev/ttyS0 on machine B the display > for machine B. You also need a getty running on /dev/ttyS0. > Ralf, Do you know where to get hold of the patch for the 2.0.x kernels? Also, the kernel command line parameter that you described - is it for box A or box B? I need the monitor to be a console for Box A as well as Box B (preferably on different ttys). Jor-el
Re: Direct serial connection
Hi, On Sun, Apr 25, 1999 at 11:39:53AM -0500, Jor-el wrote: > The what I would like to do is to use the monitor that I have as a > console for both machines A and B. Unfortunately, I cant accomplish this > via a CPU switch, thanks to the non-standard monitor cable (Aptiva S90) > that I have. I was thinking that maybe I could hook up B as using a serial > console, and connect the serial port to the serial port of A, and then > somehow get the stuff displayed on a separate window / tty on A. I'd suggest creating a small network using PPP over your serial ports (you would need a null-modem cable for this). You can then use telnet on A to work on B, and can even run X apps on B. There is a section on this in the PPP HOWTO (packages doc-linux-text or doc-linux-html). Good luck, Robert -- Robert Vollmert [EMAIL PROTECTED]
Re: Direct serial connection
On Sun, 25 Apr 1999 11:39:53 -0500 (CDT), Jor-el wrote: >Is this possible? Yes. See /usr/src/linux/Documentation/serial-console.txt. I've just done it (after having some trouble due to an incorrect /dev/console device). You need a 2.2.x kernel for this to work or a patched 2.0.x one. Basically you use a kernel command-line parameter of "console=ttyS0" to make a serial terminal (box A in your setup) hooked to /dev/ttyS0 on machine B the display for machine B. You also need a getty running on /dev/ttyS0. If you need further assistance feel free to ask here in the list or via personal mail to me. Ralf -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/The Choice /V\ of a GNU /( )\ Generation ^^-^^
Direct serial connection
Hi, I have the following setup : --- | | | | |A| | B| | | | | --- | | --- | | | Monitor | | | --- The what I would like to do is to use the monitor that I have as a console for both machines A and B. Unfortunately, I cant accomplish this via a CPU switch, thanks to the non-standard monitor cable (Aptiva S90) that I have. I was thinking that maybe I could hook up B as using a serial console, and connect the serial port to the serial port of A, and then somehow get the stuff displayed on a separate window / tty on A. Is this possible? Does anyone have any clues on how to accomplish this? Ideas / suggestions / alternate ideas are welcome. Thanks, Jor-el
Re: serial connection
> > Ooops, I meant a null-modem connection. > > I have an old PC XT-compatible hooked up to my 486 with a null-modem cable. I added a getty for it (COM2 == ttyS1) in my /etc/inittab file: # ::: 0:23:respawn:/sbin/getty 19200,9600 ttyS1 vt100 --gilbert __ Gilbert Ramirez Jr. [EMAIL PROTECTED] University of Texas http://merece.uthscsa.edu/gram Health Science Center at San AntonioUniversity Health System
serial connection
Ooops, I meant a null-modem connection.
