Bug 480215 - Review Request: slsnif - Serial line sniffer
Review Request: slsnif - Serial line sniffer
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: manuel wolfshant
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2009-01-15 13:29 EST by Fabian Affolter
Modified: 2009-06-23 03:56 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-07 11:15:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Fabian Affolter 2009-01-15 13:29:43 EST
Spec URL: http://fab.fedorapeople.org/packages/SRPMS/slsnif.spec
SRPM URL: http://fab.fedorapeople.org/packages/SRPMS/slsnif-0.4.4-1.fc9.src.rpm

Project URL: http://slsnif.sourceforge.net/

Description:
Serial line sniffer (slsnif). slsnif is a serial port logging utility. It
listens to the specified serial port and logs all data going through this
port in both directions.

Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1055945

rpmlint output:
[fab@laptop024 i386]$ rpmlint slsnif*
2 packages and 0 specfiles checked; 0 errors, 0 warnings.

[fab@laptop024 SRPMS]$ rpmlint slsnif-0.4.4-1.fc9.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Comment 1 manuel wolfshant 2009-01-16 01:11:37 EST
I'll review it a bit later. Looks pretty muck alike logserial which I maintain and use...
Comment 2 manuel wolfshant 2009-01-16 05:55:40 EST
"Serial line sniffer (slsnif). slsnif is a serial port logging utility." is not OK. I suggest "Serial line sniffer (slsnif) is a serial port logging utility."

How can I test the applications, short of manually creating /dev/pty? strace says:
open("/dev/ptyp0", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/ptyp1", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/ptyp2", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/ptyp3", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/ptyp4", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/ptyp5", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
[...]
open("/dev/ptyTe", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
open("/dev/ptyTf", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or directory)
dup(2)                                  = 4
fcntl(4, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(4, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 5), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaaad000
lseek(4, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(4, "Failed to open a pty: No such fi"..., 48Failed to open a pty: No such file or directory

and the application dies
Comment 3 manuel wolfshant 2009-01-16 05:58:03 EST
Uhm, and it cannot use different parity types ? My PBX requires very specific settings, defaults never work...
Comment 4 Fabian Affolter 2009-02-04 05:31:49 EST
I will look deeper into this after FOSDEM.
Comment 5 Fabian Affolter 2009-03-07 11:15:39 EST
logserial is nice.  I will mark this review request as FE-DEADREVIEW because at the moment I don't want to go on with this package.
Comment 6 Tsvi Mostovicz 2009-06-23 03:56:41 EDT
(In reply to comment #2)
> "Serial line sniffer (slsnif). slsnif is a serial port logging utility." is not
> OK. I suggest "Serial line sniffer (slsnif) is a serial port logging utility."
> 
> How can I test the applications, short of manually creating /dev/pty? strace
> says:
> open("/dev/ptyp0", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or
> directory)
> open("/dev/ptyp1", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or
> directory)
> open("/dev/ptyp2", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or
> directory)
> open("/dev/ptyp3", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or
> directory)
> open("/dev/ptyp4", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or
> directory)
> open("/dev/ptyp5", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or
> directory)
> [...]
> open("/dev/ptyTe", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or
> directory)
> open("/dev/ptyTf", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or
> directory)
> dup(2)                                  = 4
> fcntl(4, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
> fstat(4, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 5), ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x2aaaaaaad000
> lseek(4, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
> write(4, "Failed to open a pty: No such fi"..., 48Failed to open a pty: No such
> file or directory
> 
> and the application dies  

Use the -u switch to "use SYSV (unix98) ptys instead of BSD ones".

Note You need to log in before you can comment on or make changes to this bug.