Re: expect script with ppp and stty forces reboot Re: expect script with ppp and stty forces reboot. To:. Cc: Debian Users. Subject: Re: expect script with ppp and stty forces reboot. From: Colin Telmer.
Date: Sun, 29 Nov 1998 19:56:53 -0500 (EST). Message-id:. In-reply-to: On 29 Nov 1998 [email protected] wrote: I talk with the modem in the expect script as follows: system 'stty 38400 -echoe -echo raw /dev/ttyS1' spawn -noecho -open open /dev/ttyS1 'r+' Why do you need to do this?
Pppd will just reconfigure the serial port to its satisfaction when it comes up. I did that following the example /usr/doc/ppp/examples/secure-card. I don't know any other way for expect to communicate with the modem.
I was partially wrong about one thing in my previous post - if the first system line is commented out, the script runs (although it connects at 9600 baud) but it also hangs on the second try. If you are just using the expect script to dial and negotiate a connectionit would be much easier to use pppd's 'connect' option. One way to do this is to create a file in /etc/ppp/peers/ just like the ones pppconfig makes (naming it 'myoffice', for example), but replace connect '/usr/sbin/chat -v -f /etc/chatscripts/provider' with connect '/usr/bin/expect /etc/chatscripts/myoffice' Then you will be able to connect to your office with 'pon myoffice' and disconnect with 'poff'.
![]()
I tried this a number of times, but I could not figure out how to get expect to not disconnect the modem connection after exiting. I thought the overlay command would do this, but it explicitly wants a command to 'take the connection'. I would prefer to do it that way - any suggestions? Also, in regards to your first question, even if I could get it going in this preferable fashion, wouldn't I still need to point expect at the serial port using the system and spawn commands above? overlay -0 $spawnid -1 $spawnid /usr/sbin/pppd /dev/ttyS1 38400 Do you really need to run as slow as 38400? No, I should have changed that. However, when the connection is first established, it comes up as 38400 in the expect script output.
Does pppd have the ability to speed this up? Also, if I leave out the stty command from above, the connection is established at 9600 baud.
![]()
This works fine (as far as I can tell), but after disconnecting using poff. Which kills pppd, causing it to put the serial port back the way it found it, i.e., as your stty command set it up. I don't understand that. I can issue the stty command any number of times before the ppp connection and it always returns. Only after the ppp connection is disconnected using poff is when the stty command hangs. Given my lack of understanding of this stuff, I thought that I was doing something analogous to leaving the serial port busy so I could not access it again, but I don't know how to figure that out. Thanks again for your help, I really appreciate it.
This would be a great deal easier if I didn't need to have an interactive script to ask for a one-time passphrase. Cheers, Colin. Colin Telmer, Ottawa, Ontario, Canada Reply to:. References:. From: [email protected]. Prev by Date:.
Next by Date:. Previous by thread:. Next by thread:. Index(es):.
![]()
Sergey Okhapkin - Re: Serial port access under expect This is the mail archive of the [email protected] mailing list for the. Index Nav: Message Nav: Other format: Re: Serial port access under expect.
From: 'Sergey Okhapkin'. To: 'Chirag Kantharia',. Date: Sun, 19 Jan 2003 07:18:49 -0500. Subject: Re: Serial port access under expect. References: Don't you try to open a serial port from two processes? You can't do that on Windows, Windows don't allow to share the serial ports. Sergey Okhapkin Somerset, NJ - Original Message - From: 'Chirag Kantharia' To: Sent: Sunday, January 19, 2003 6:50 AM Subject: Serial port access under expect HelloI have a simple terminal emulation program, through which I am able to access an embedded board, through serial port.
This works fine from the bash prompt; but however, if I try to do the same from within an expect script, the program fails with 'Permission denied' message, for the open call (to open the serial port). The expect script snippet is something like the below: set timeout 60 spawn tinycom -n -b 9600 /dev/ttyS0 sleep 2 send ' r r' expect '$' I'd looked up the mailing list archives, and found some mails related to psuedo-tty functionality not stable in expect, and consequently the expect would not be able to `talk' to spawned processes well (well that's what I could conclude; corrections are welcome). But from the error message which I get, that doesn't seem to be the problem. However, I tried an ftp script which would login into a local machine and download a file.
The expect script ran fine and didn't have problems `talking' to ftp. I wonder what could be problem with my setup.
Does anybody have any idea, as to what could I be doing wrong? Thankschyrag. - Unsubscribe info: Bug reporting: Documentation: FAQ: - Unsubscribe info: Bug reporting: Documentation: FAQ:. References:. From: Chirag Kantharia Index Nav: Message Nav:.
Posted by Custard (Custard), 29 July 2005Hi, The telnet protocol is slightly clever in that the client negotiates with the server what terminal type to use, and also sends other bits of vital information from the environment. Since you are spawning telnet from within expect, these pieces of information don't appear to be available to send, so the telnet server (telnetd) is asking for them (or actually, probably the.profile script sees that they are not present and asks for them). So, you could try setting the environment before spawning telnet, or handling the new prompt you have identified and sending the hostname to the server.
I haven't tested this, and I will have a play later, but this.looks. like what is happening.
I'have to send CTRL+P through serial port, to activate some functions. How can i send CTRL+P with TCL? Assuming you are talking about this: ASCII 1/0 is decimal 016, hex 10, octal 020, bits 00010000: called ^P, DLE Official name: Data Link Escape You could do: puts x10 Does that work? Welton Consulting: Personal: Free Software: Apache Tcl: Sun, 27 Aug 2006 18:45:49 GMT. HiI've to make a script with TCL to open a serial port in read/write mode. I've found a good script to help me, that use fconfigure -mode to set baudrate, parity check etc on a serial port.
![]() Parallel Port
But seems that in TCL 8.4 -mode switch is not supported. How can I set baudrate for a serial port with TCL? (A) You don't find the doc's for fconfigure -mode: It's a known pitfall that fconfigure -mode is not documented in the the fconfigure manual-page, but in the open manual. I changed that when I was implementing the TIP#35 stuff for Tcl8.4, but after a few complaints it was moved back to open:-( (B) fconfigure -mode returns an 'unknown option' error: The means the channel you opened has not been recognized as a serial port (isatty0).
If I recall correctly that was the case for a few invalid Tcl builts distributed with Suse and/or Redhat Linux. The solution was to download afresh Tcl binary or to rebuilt Tcl. See for serial port code samples. Regards, Rolf.
Rolf Schroedter, German Aerospace Center Mon, 28 Aug 2006 16:35:05 GMT. (A) You don't find the doc's for fconfigure -mode: It's a known pitfall that fconfigure -mode is not documented in the the fconfigure manual-page, but in the open manual. I changed that when I was implementing the TIP#35 stuff for Tcl8.4, but after a few complaints it was moved back to open:-( fconfigure is the generic entry to the ioctls that the driver implements, it knows nothing of the specific type of channel driver it is operating on. The command that created the channel is the place where the fconfigures for that channel type should be documented. This issue has come up a few times in the past and the docs have been broken and subsequential fixed at least two times. I hope in the future the fconfigure docs can keep saying STRONGLY that options specific to the channel type are found elsewhere, with all the jumps in the 'see also' section and sprinkled liberally all over the rest of it. Go see socket.
Repeat see socket for -peername and -sockname. See socket for -peername and -sockname. See socket for -peername and -sockname.
See socket for -peername and -sockname. So when I release channel drivers in extensions, should I modify fconfigure.n to reflect my extension??
- species: human; planet: earth,milkyway(western spiral arm),alpha sector Mon, 28 Aug 2006 17:07:25 GMT. I agree with you, but anyway it.is a pifall. for many users not knowing Tcl's internals. They take some sample code, see a fconfigure -mode statement, look into the fconfigure man-page and think that their Tcl version doesn't support it.
For your channel driver extension you'll probably have a man-page saying: 'My foo extension adds the following fconfigure options.' The user is usually aware that he's using an extension. But IMO for standard (core) channels fconfigure options should be documented or at least referenced in fconfigure.n. For serial ports the situation is different from sockets, because sockets have their own command, serial ports don't. Same as you, I don't like to modify the open.n manpage when adding something to the serial port driver. The solution could be to have a separate serial.n page referenced in both fconfigure.n and open.n. Regards, Rolf.
(A) You don't find the doc's for fconfigure -mode: It's a known pitfall that fconfigure -mode is not documented in the the fconfigure manual-page, but in the open manual. I changed that when I was implementing the TIP#35 stuff for Tcl8.4, but after a few complaints it was moved back to open:-( fconfigure is the generic entry to the ioctls that the driver implementsit knows nothing of the specific type of channel driver it is operating on. The command that created the channel is the place where the fconfigures for that channel type should be documented. This issue has come up a few times in the past and the docs have been broken and subsequential fixed at least two times. I hope in the future the fconfigure docs can keep saying STRONGLY that options specific to the channel type are found elsewhere, with all the jumps in the 'see also' section and sprinkled liberally all over the rest of it. Go see socket. Repeat see socket for -peername and -sockname.
See socket for -peername and -sockname. See socket for -peername and -sockname. see socket for -peername and -sockname. So when I release channel drivers in extensions, should I modify fconfigure.n to reflect my extension?? - - Rolf Schroedter, German Aerospace Center Mon, 28 Aug 2006 18:40:24 GMT. I agree with you, but anyway it.is a pifall.
for many users not knowing Tcl's internals. They take some sample code, see a fconfigure -mode statement, look into the fconfigure man-page and think that their Tcl version doesn't support it. For your channel driver extension you'll probably have a man-page saying: 'My foo extension adds the following fconfigure options.' The user is usually aware that he's using an extension.
But IMO for standard (core) channels fconfigure options should be documented or at least referenced in fconfigure.n. For serial ports the situation is different from sockets, because sockets have their own command, serial ports don't. Same as you, I don't like to modify the open.n manpage when adding something to the serial port driver. The solution could be to have a separate serial.n page referenced in both fconfigure.n and open.n. Regards, Rolf.
Expect Spawn Command
(A) You don't find the doc's for fconfigure -mode: It's a known pitfall that fconfigure -mode is not documented in the the fconfigure manual-page, but in the open manual. I changed that when I was implementing the TIP#35 stuff for Tcl8.4, but after a few complaints it was moved back to open:-( fconfigure is the generic entry to the ioctls that the driver implementsit knows nothing of the specific type of channel driver it is operating on. The command that created the channel is the place where the fconfigures for that channel type should be documented. This issue has come up a few times in the past and the docs have been broken and subsequential fixed at least two times. I hope in the future the fconfigure docs can keep saying STRONGLY that options specific to the channel type are found elsewhere, with all the jumps in the 'see also' section and sprinkled liberally all over the rest of it. Go see socket.
Repeat see socket for -peername and -sockname. See socket for -peername and -sockname. See socket for -peername and -sockname. see socket for -peername and -sockname.
So when I release channel drivers in extensions, should I modify fconfigure.n to reflect my extension?? - - Rolf Schroedter, German Aerospace Center Mon, 28 Aug 2006 18:41:21 GMT. I agree with you, but anyway it.is a pifall. for many users not knowing Tcl's internals. They take some sample code, see a fconfigure -mode statement, look into the fconfigure man-page and think that their Tcl version doesn't support it.
For your channel driver extension you'll probably have a man-page saying: 'My foo extension adds the following fconfigure options.' The user is usually aware that he's using an extension. But IMO for standard (core) channels fconfigure options should be documented or at least referenced in fconfigure.n.
For serial ports the situation is different from sockets, because sockets have their own command, serial ports don't. Same as you, I don't like to modify the open.n manpage when adding something to the serial port driver. The solution could be to have a separate serial.n page referenced in both fconfigure.n and open.n. Regards, Rolf.
(A) You don't find the doc's for fconfigure -mode: It's a known pitfall that fconfigure -mode is not documented in the the fconfigure manual-page, but in the open manual. I changed that when I was implementing the TIP#35 stuff for Tcl8.4, but after a few complaints it was moved back to open:-( fconfigure is the generic entry to the ioctls that the driver implementsit knows nothing of the specific type of channel driver it is operating on. The command that created the channel is the place where the fconfigures for that channel type should be documented. This issue has come up a few times in the past and the docs have been broken and subsequential fixed at least two times. I hope in the future the fconfigure docs can keep saying STRONGLY that options specific to the channel type are found elsewhere, with all the jumps in the 'see also' section and sprinkled liberally all over the rest of it. Go see socket.
Repeat see socket for -peername and -sockname. See socket for -peername and -sockname. See socket for -peername and -sockname. see socket for -peername and -sockname. So when I release channel drivers in extensions, should I modify fconfigure.n to reflect my extension??
- - Rolf Schroedter, German Aerospace Center Mon, 28 Aug 2006 18:41:44 GMT. I agree with you, but anyway it.is a pifall. for many users not knowing Tcl's internals. They take some sample code, see a fconfigure -mode statement, look into the fconfigure man-page and think that their Tcl version doesn't support it.
For your channel driver extension you'll probably have a man-page saying: 'My foo extension adds the following fconfigure options.' The user is usually aware that he's using an extension. But IMO for standard (core) channels fconfigure options should be documented or at least referenced in fconfigure.n. For serial ports the situation is different from sockets, because sockets have their own command, serial ports don't. Same as you, I don't like to modify the open.n manpage when adding something to the serial port driver. The solution could be to have a separate serial.n page referenced in both fconfigure.n and open.n.
Regards, Rolf. (A) You don't find the doc's for fconfigure -mode: It's a known pitfall that fconfigure -mode is not documented in the the fconfigure manual-page, but in the open manual. I changed that when I was implementing the TIP#35 stuff for Tcl8.4, but after a few complaints it was moved back to open:-( fconfigure is the generic entry to the ioctls that the driver implementsit knows nothing of the specific type of channel driver it is operating on. The command that created the channel is the place where the fconfigures for that channel type should be documented. This issue has come up a few times in the past and the docs have been broken and subsequential fixed at least two times. I hope in the future the fconfigure docs can keep saying STRONGLY that options specific to the channel type are found elsewhere, with all the jumps in the 'see also' section and sprinkled liberally all over the rest of it.
Go see socket. Repeat see socket for -peername and -sockname. See socket for -peername and -sockname. See socket for -peername and -sockname. see socket for -peername and -sockname.
So when I release channel drivers in extensions, should I modify fconfigure.n to reflect my extension?? - - Rolf Schroedter, German Aerospace Center Mon, 28 Aug 2006 18:42:02 GMT. I agree with you, but anyway it.is a pifall. for many users not knowing Tcl's internals. They take some sample code, see a fconfigure -mode statement, look into the fconfigure man-page and think that their Tcl version doesn't support it. For your channel driver extension you'll probably have a man-page saying: 'My foo extension adds the following fconfigure options.' The user is usually aware that he's using an extension.
But IMO for standard (core) channels fconfigure options should be documented or at least referenced in fconfigure.n. For serial ports the situation is different from sockets, because sockets have their own command, serial ports don't. Same as you, I don't like to modify the open.n manpage when adding something to the serial port driver. The solution could be to have a separate serial.n page referenced in both fconfigure.n and open.n. Regards, Rolf.
(A) You don't find the doc's for fconfigure -mode: It's a known pitfall that fconfigure -mode is not documented in the the fconfigure manual-page, but in the open manual. I changed that when I was implementing the TIP#35 stuff for Tcl8.4, but after a few complaints it was moved back to open:-( fconfigure is the generic entry to the ioctls that the driver implementsit knows nothing of the specific type of channel driver it is operating on. The command that created the channel is the place where the fconfigures for that channel type should be documented. This issue has come up a few times in the past and the docs have been broken and subsequential fixed at least two times. I hope in the future the fconfigure docs can keep saying STRONGLY that options specific to the channel type are found elsewhere, with all the jumps in the 'see also' section and sprinkled liberally all over the rest of it.
Serial Port To Usb Port Adapter
Go see socket. Repeat see socket for -peername and -sockname. See socket for -peername and -sockname. See socket for -peername and -sockname. see socket for -peername and -sockname.
So when I release channel drivers in extensions, should I modify fconfigure.n to reflect my extension?? - - Rolf Schroedter, German Aerospace Center Mon, 28 Aug 2006 18:42:37 GMT. If I recall correctly that was the case for a few invalid Tcl builts distributed with Suse and/or Redhat Linux. But this has been fixed in one of the 8.3.x releases, so that the Tcl build systen now always finds the system's tty API (and hence compiles in tty support) even in build environments like SuSE and Red Hat have them where none of the standard channels points to a tty. So this should definitely not be an issue with 8.4 anymore. Cu Reinhard Wed, 30 Aug 2006 18:46:42 GMT Page 1 of 1 11 post.
Some research seems to indicate that the fconfigure command doesn't offer the -mode switch when it doesn't recognize the channel in question as being a true serial port (though I don't see this mentioned in the docs). Ultimately, that decision seems to rely on an 'isatty' system call, which is apparently failing to report the channel as a TTY. More info can be found here: According to the above thread, this could be due to a misconfigured Tcl. I see the serial configuration options (including -mode) are documented with the open command. There, it mentions that fconfigure can be used to query or set the additional options specific to serial ports. The fconfigure docs should probably be updated to reflect that fact also.
Bottom line, Tcl doesn't think your port really is a serial port under Ubuntu, though I don't know why.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |