From: Jeff D. <jd...@ka...> - 2001-09-10 15:53:18
|
h.n...@se... said: > How do I do that? > Probably I need some way to pass the information which serial line to > choose to the driver. How do you access the serial line? If it's through ioctls, it may just be a matter of adding them to the ssl drivers. I just hooked a UML serial line up to the host's modem and tried running minicom on it. It didn't work - I got a bunch of complaints about unimplemented ioctls. But I bet it would work if they were implemented. So, if you're just doing ioctls (and I don't really see anything else that you could be doing), this shouldn't be hard to get working. Jeff |
From: Jeff D. <jd...@ka...> - 2001-09-11 13:18:00
|
h.n...@se... said: > If I understand this right I should look at my application, see which > ioctls() are used and then come back to discuss further details? Yes. > Does it suffice to do a grep for "ioctl" on the chipcard library? Not necessarily. You also want to have the driver print out ioctls that it doesn't understand (as it does now) and keep adding ioctls until it stops complaining. > This gives me the following two different ioctls: > 1) ioctl (fd, TIOCMGET, &modem_lines) > 2) ioctl (fd, TIOCMSET, &modem_lines) These and probably all the others can be implemented by just doing the same ioctl on the drivers /dev/ttyS0 file descriptor. > I see that there is a function ssl_ioctl() in ssl.c with some switch() > statement. Is this the place to add those TIOCMGET/TIOCMSET cases ? Yup, that's the place. > But I also see that if this code is called then some error printing > should appear which does not happen so far. Is there something one > must set to see those message (for the "default:" case)? If ioctls are the problem, ssl_ioctl should be complaining. If not, there's another problem. Check the kernel log with dmesg after trying to run your app. > Hmm, I just found some tc* (termios) functions: > 1) tcflush ( int fd, int queue_selector ) > 2) tcsetattr ( int fd, struct termios *termios_p ) > 3) tcgetattr ( int fd, int optional_actions, struct termios *termios_p ) > Are these calls built up on ioctl()s, too? I think so. Jeff |
From: Heiko N. <h.n...@se...> - 2001-09-12 08:35:04
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 11 September 2001 16:34, Jeff Dike wrote: > h.n...@se... said: > > If I understand this right I should look at my application, see which > > ioctls() are used and then come back to discuss further details? > > Yes. > > > Does it suffice to do a grep for "ioctl" on the chipcard library? > > Not necessarily. You also want to have the driver print out ioctls that > it doesn't understand (as it does now) and keep adding ioctls until it > stops complaining. > Ok. Incremental completion ... ;-) > > This gives me the following two different ioctls: > > 1) ioctl (fd, TIOCMGET, &modem_lines) > > 2) ioctl (fd, TIOCMSET, &modem_lines) > > These and probably all the others can be implemented by just doing the > same ioctl on the drivers /dev/ttyS0 file descriptor. > > > I see that there is a function ssl_ioctl() in ssl.c with some switch() > > statement. Is this the place to add those TIOCMGET/TIOCMSET cases ? > > Yup, that's the place. > > > But I also see that if this code is called then some error printing > > should appear which does not happen so far. Is there something one > > must set to see those message (for the "default:" case)? > > If ioctls are the problem, ssl_ioctl should be complaining. If not, > there's another problem. Check the kernel log with dmesg after trying to > run your app. > So I have to use some "normal" file system for that (one with dmesg on it which the CD image does not have). tracing thread pid = 22534 Linux version 2.4.9-3um (root@snsrv053) (gcc version 2.95.3 20010315 (SuSE)) #3 Mon Sep 10 13:31:38 MEST 2001 On node 0 totalpages: 4096 zone(0): 0 pages. zone(1): 4096 pages. zone(2): 0 pages. Kernel command line: ubd0=/opt/Source-Archive/System/UserModeLinux/root_fs_suse_6.4_small ssl=pty ssl0=tty:/dev/ttyS0 root=/dev/ubd0 Calibrating delay loop... 17.98 BogoMIPS Memory: 16100k available Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 4096 (order: 2, 16384 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Starting kswapd v1.8 block: 64 slots per queue, batch=8 RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 1024 bind 1024) ip_tables: (c)2000 Netfilter core team NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Initializing stdio console driver Initializing software serial port version 1 mconsole initialized on /tmp/uml/Pwc43o/mconsole VFS: Mounted root (ext2 filesystem) readonly. INIT: version 2.78 booting [snip] I wonder why I don't see any messages from the ssl driver. Are these messages (like in ssl_announce()) only printed when the driver is accessed? I've done a grep for CONFIG_SSL in my .config and found CONFIG_SSL=y I did a 'strings -a linux | grep "Unimplemented"' and found the string used in ssl_ioctl(). So what could be the reason that almost no output of the ssl driver appears? The message "Initializing software serial port version 1" appears as you can see. But nothing else ... is this normal. [snip] - -- Heiko Nardmann (Dipl.-Ing.), h.n...@se..., Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7nx4Gpm53PRScYygRAmCBAJ9UDjjV5583Ybg5t0C/54u68X61lgCfae6o /T5OI8O3OvS5LzD3msm8sFE= =zt6W -----END PGP SIGNATURE----- |
From: Heiko N. <h.n...@se...> - 2001-09-12 09:11:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 12 September 2001 10:34, Heiko Nardmann wrote: > On Tuesday 11 September 2001 16:34, Jeff Dike wrote: > > h.n...@se... said: > > > If I understand this right I should look at my application, see which > > > ioctls() are used and then come back to discuss further details? > > > > Yes. > > > > > Does it suffice to do a grep for "ioctl" on the chipcard library? > > > > Not necessarily. You also want to have the driver print out ioctls that > > it doesn't understand (as it does now) and keep adding ioctls until it > > stops complaining. > > Ok. Incremental completion ... ;-) > > > > This gives me the following two different ioctls: > > > 1) ioctl (fd, TIOCMGET, &modem_lines) > > > 2) ioctl (fd, TIOCMSET, &modem_lines) > > > > These and probably all the others can be implemented by just doing the > > same ioctl on the drivers /dev/ttyS0 file descriptor. > > > > > I see that there is a function ssl_ioctl() in ssl.c with some switch() > > > statement. Is this the place to add those TIOCMGET/TIOCMSET cases ? > > > > Yup, that's the place. > > > > > But I also see that if this code is called then some error printing > > > should appear which does not happen so far. Is there something one > > > must set to see those message (for the "default:" case)? > > > > If ioctls are the problem, ssl_ioctl should be complaining. If not, > > there's another problem. Check the kernel log with dmesg after trying to > > run your app. > > So I have to use some "normal" file system for that (one with dmesg on it > which the CD image does not have). > > tracing thread pid = 22534 > Linux version 2.4.9-3um (root@snsrv053) (gcc version 2.95.3 20010315 > (SuSE)) #3 Mon Sep 10 13:31:38 MEST 2001 > On node 0 totalpages: 4096 > zone(0): 0 pages. > zone(1): 4096 pages. > zone(2): 0 pages. > Kernel command line: > ubd0=/opt/Source-Archive/System/UserModeLinux/root_fs_suse_6.4_small > ssl=pty ssl0=tty:/dev/ttyS0 root=/dev/ubd0 > Calibrating delay loop... 17.98 BogoMIPS > Memory: 16100k available > Dentry-cache hash table entries: 2048 (order: 2, 16384 bytes) > Inode-cache hash table entries: 1024 (order: 1, 8192 bytes) > Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes) > Page-cache hash table entries: 4096 (order: 2, 16384 bytes) > POSIX conformance testing by UNIFIX > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Starting kswapd v1.8 > block: 64 slots per queue, batch=8 > RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP: Hash tables configured (established 1024 bind 1024) > ip_tables: (c)2000 Netfilter core team > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > Initializing stdio console driver > Initializing software serial port version 1 > mconsole initialized on /tmp/uml/Pwc43o/mconsole > VFS: Mounted root (ext2 filesystem) readonly. > INIT: version 2.78 booting > [snip] > > > I wonder why I don't see any messages from the ssl driver. Are these > messages (like in ssl_announce()) only printed when the driver is accessed? > > I've done a grep for CONFIG_SSL in my .config and found > CONFIG_SSL=y > > I did a 'strings -a linux | grep "Unimplemented"' and found the string used > in ssl_ioctl(). > > So what could be the reason that almost no output of the ssl driver > appears? The message "Initializing software serial port version 1" appears > as you can see. But nothing else ... is this normal. > > [snip] Now I copied some chipcard test application to the root fs and added strace, too. So now I see inside the strace messages the following failing call: open("/dev/ttyS0", O_RDWR|O_NONBLOCK|O_NOCTTY) = -1 ENODEV (No such device) In /dev I see the entry for ttyS0: crw-rw---- 1 root uucp 4, 64 Mar 24 2000 /dev/ttyS0 Any idea? - -- Heiko Nardmann (Dipl.-Ing.), h.n...@se..., Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7nyaCpm53PRScYygRAuaIAJ9HSv2e0FlLgY+3Kh9bKOwKqt6/eACfVRgc FsW9zXzXwvs+tpGW8oMKpCk= =BtXy -----END PGP SIGNATURE----- |
From: Jeff D. <jd...@ka...> - 2001-09-12 15:04:08
|
h.n...@se... said: > In /dev I see the entry for ttyS0: > crw-rw---- 1 root uucp 4, 64 Mar 24 2000 /dev/ttyS0 > Any idea? The ssl driver sets itself up as major 5, which is the equivalent of /dev/cua0. I think /dev/ttyS0 and /dev/cua0 are different, but related, and I don't know the details. But for now, if you give ttyS0 major 5, minor 64, you should at least start hitting the ssl driver. Jeff |
From: Heiko N. <h.n...@se...> - 2001-09-12 15:46:21
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 12 September 2001 18:21, Jeff Dike wrote: > h.n...@se... said: > > In /dev I see the entry for ttyS0: > > crw-rw---- 1 root uucp 4, 64 Mar 24 2000 /dev/ttyS0 > > Any idea? > > The ssl driver sets itself up as major 5, which is the equivalent of > /dev/cua0. I think /dev/ttyS0 and /dev/cua0 are different, but related, and > I don't know the details. > > But for now, if you give ttyS0 major 5, minor 64, you should at least start > hitting the ssl driver. > > Jeff Yep, that was it. Here is some output when running my test application: Unimplemented ioctl in ssl_ioctl : 0x5415 Unimplemented ioctl in ssl_ioctl : 0x5418 and so on ... I only see those two different ioctl codes. Both are defined in /usr/include/asm/ioctls.h: #define TIOCMSET 0x5418 #define TIOCMGET 0x5415 So the next thing is probably adding those two to the switch() statement and implement the ioctls by calling an appropriate function or just code it in place. Do you agree? How is this done? Do I just call ioctl() with the real file descriptor? Is the real file descriptor available in this situation already or do I have to open the device before? According to struct chan in chan.h there is a file descriptor. Is this the one to use? Do I have to do something special like sanity checks for any of {fd, hung_up, init_pri, raw, tty_state} ? OT: where do I find some documentation about these control codes? The header file and some man pages which I have checked weren't very helpful. Any other source? - -- Heiko Nardmann (Dipl.-Ing.), h.n...@se..., Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7n4MRpm53PRScYygRAqAaAJ9/8ViDSAd8i4mpn8Xmyw7qEi1nDACg2NP5 1h2oLatB+J2pZ/EI7ZMPjV4= =CLwc -----END PGP SIGNATURE----- |
From: Jeff D. <jd...@ka...> - 2001-09-12 17:12:22
|
h.n...@se... said: > How is this done? Do I just call ioctl() with the real file > descriptor? Is the real file descriptor available in this situation > already or do I have to open the device before? According to struct > chan in chan.h there is a file descriptor. Is this the one to use? Yup, that's the one to use. Just invoke the same ioctl on it and return the same return value. If there are structures passed in as arguments, then it gets a bit more complicated, but if it's just the command and a non-pointer argument, then it's pretty simple. > OT: where do I find some documentation about these control codes? The > header file and some man pages which I have checked weren't very > helpful. Any other source? They are not well documented. I usually locate a driver that implements the one I'm interested in and see what it does. Jeff |
From: Heiko N. <h.n...@se...> - 2001-11-07 07:52:07
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 03 October 2001 18:38, Heiko Nardmann wrote: > On Wednesday 12 September 2001 20:29, you wrote: > > h.n...@se... said: > > > How is this done? Do I just call ioctl() with the real file > > > descriptor? Is the real file descriptor available in this situation > > > already or do I have to open the device before? According to struct > > > chan in chan.h there is a file descriptor. Is this the one to use? > > > > Yup, that's the one to use. Just invoke the same ioctl on it and return > > the same return value. If there are structures passed in as arguments, > > then it gets a bit more complicated, but if it's just the command and a > > non-pointer argument, then it's pretty simple. > > What do you mean with "more complicated" if structures are passed? My understanding of ioctl() is really limited ... > > > OT: where do I find some documentation about these control codes? The > > > header file and some man pages which I have checked weren't very > > > helpful. Any other source? > > > > They are not well documented. I usually locate a driver that implements > > the one I'm interested in and see what it does. > > > > Jeff > > Now I am back and have time to do the ioctl() implementation. > > My problem just is where to get access to the struct chan which holds the > file descriptor for the target. The function ssl_ioctl() only gets a > pointer to struct tty and a struct file but no one to struct chan. A few days ago I added the following lines to 2.4.10-7:arch/um/drivers/ssl.c (attached as a unified diff against UML 2.4.10-7: ssl.c.diff). Do you think these lines are enough to access to a chipcard reader attached to the serial line /dev/ttyS0 ? Are there any settings (e.g. raw flag) to be set additionally? I currently get a different behaviour when running the test program from the normal host. For testing I use the filesystem root_fs.rh71.pristine.bz2. This is how I start UML: linux ubd0=/home/nardmann/UML/root_fs.rh71.pristine ssl=pty ssl0=tty:/dev/ttyS0 I have a dynamically linked test file which tries to access the chip card readers. I copied this file to the root fs stated above. I have the following entry as ttyS0 in /dev in the root fs: crw-rw-rw- 1 root root 5, 64 Nov 6 17:21 dev/ttyS0 Notice that I set the major value according the info in one of your last emails to me. I do not get any messages like unimplemented ioctls on the screen. Here is the expected output of the test program: - ---------------------------------------------- Test-CTAPI ========== Verwendeter Port: 1 CT_init: 0 second CT_init: -1 CT_data (resetCT): 0 (len=2) 9000 CT_data (activate ICC): 0 (len=12) 9001 CT_data (deactivate ICC): 0 (len=2) 6700 CT_close: 0 second CT_close: -1 CT_init again: 0 CT_data (resetCT): 0 (len=2) 9000 CT_data (activate ICC): 0 (len=12) 9001 CT_data (deactivate ICC): 0 (len=2) 6700 CT_close: 0 - ---------------------------------------------- Here is what I get: - ---------------------------------------------- Test-CTAPI ========== Verwendeter Port: 1 CT_init: 0 second CT_init: -1 CT_data (resetCT): -8 (len=2) 0000 CT_data (activate ICC): -128 (len=1024) 1200 CT_data (deactivate ICC): -128 (len=1024) 1200 CT_close: 0 second CT_close: -1 CT_init again: 0 CT_data (resetCT): -8 (len=1024) 1200 CT_data (activate ICC): -128 (len=1024) 1200 CT_data (deactivate ICC): -128 (len=1024) 1200 CT_close: 0 - ---------------------------------------------- Attached is 1.: test_api.uml.strace.log: the strace output which I get when running the test program inside UML 2.: test_api.strace.log: the strace output which I get when running the test program on the normal host Any idea what to change inside uml additionally? I noticed that in the UML logfile there is no occurrence of shmat() which is really curious since it appears in the source code of this test program and also in the logfile of the test on the real host. - -- Heiko Nardmann (Dipl.-Ing.), h.n...@se..., Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE76Odppm53PRScYygRAs5ZAJ0X2ILWvr9ZZc/puTCafs1ucCnP8gCdFHp6 wX0LD7V2+5LWXRwtulq4uRU= =s1my -----END PGP SIGNATURE----- |
From: Heiko N. <h.n...@se...> - 2001-09-11 06:47:37
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 10 September 2001 19:09, Jeff Dike wrote: > h.n...@se... said: > > How do I do that? > > Probably I need some way to pass the information which serial line to > > choose to the driver. > > How do you access the serial line? If it's through ioctls, it may just be > a matter of adding them to the ssl drivers. > > I just hooked a UML serial line up to the host's modem and tried running > minicom on it. It didn't work - I got a bunch of complaints about > unimplemented ioctls. But I bet it would work if they were implemented. > > So, if you're just doing ioctls (and I don't really see anything else that > you could be doing), this shouldn't be hard to get working. > > Jeff If I understand this right I should look at my application, see which ioctls() are used and then come back to discuss further details? Does it suffice to do a grep for "ioctl" on the chipcard library? This gives me the following two different ioctls: 1) ioctl (fd, TIOCMGET, &modem_lines) 2) ioctl (fd, TIOCMSET, &modem_lines) I see that there is a function ssl_ioctl() in ssl.c with some switch() statement. Is this the place to add those TIOCMGET/TIOCMSET cases ? But I also see that if this code is called then some error printing should appear which does not happen so far. Is there something one must set to see those message (for the "default:" case)? Hmm, I just found some tc* (termios) functions: 1) tcflush ( int fd, int queue_selector ) 2) tcsetattr ( int fd, struct termios *termios_p ) 3) tcgetattr ( int fd, int optional_actions, struct termios *termios_p ) Are these calls built up on ioctl()s, too? - -- Heiko Nardmann (Dipl.-Ing.), h.n...@se..., Software Development secunet Security Networks AG - Sicherheit in Netzwerken (www.secunet.de), Weidenauer Str. 223-225, D-57076 Siegen Tel. : +49 271 48950-13, Fax : +49 271 48950-50 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7nbNWpm53PRScYygRAsEbAJ9XctX+wvTlYk3j/eu/H3NgDBjDMgCgne2I s8b5yA1zwmoU53FWPMWVn3A= =MtVZ -----END PGP SIGNATURE----- |