zmtrigger.pl when using telnet from a file fails

[patmansf]

Hi -

If I directly telnet to the IP address and port that zmtrigger.pl is running on and send commands, it works as expected and I can trigger alarms via telnet.

But, if I script it as shown in the documentation or have telnet read from a file it does not work, and no errors are logged.

For example this does nothing:

Code: Select all

$ cat for_zm
17|on+10|10|goodbye|goodbye|
$ telnet 192.168.1.1 6802 < for_zm 
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
Connection closed by foreign host.

But if I run telnet on the command line and cut and paste that same text, it works fine.

I see this in strace output of zmtrigger.pl when telnet reads from a file - when it works this is not seen:

Code: Select all

pselect6(8, [4 6], NULL, NULL, {tv_sec=0, tv_nsec=250000000}, NULL) = 1 (in [4], left {tv_sec=0, tv_nsec=80817028})
accept4(4, {sa_family=AF_INET, sin_port=htons(45702), sin_addr=inet_addr("192.168.1.1")}, [4096 => 16], SOCK_CLOEXEC) = 13
fcntl(13, F_SETFD, FD_CLOEXEC)          = 0
ioctl(13, TCGETS, 0x7ffe87a8a2e0)       = -1 ENOTTY (Inappropriate ioctl for device)
lseek(13, 0, SEEK_CUR)                  = -1 ESPIPE (Illegal seek)
fcntl(13, F_SETFD, FD_CLOEXEC)          = 0
ioctl(13, TCGETS, 0x7ffe87a8a2e0)       = -1 ENOTTY (Inappropriate ioctl for device)
lseek(13, 0, SEEK_CUR)                  = -1 ESPIPE (Illegal seek)
sendto(5, "\1\0\0\0\16", 5, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 5
recvfrom(5, "\7\0\0\1\0\0\0\2\0\0\0", 16384, MSG_DONTWAIT, NULL, NULL) = 11
pselect6(16, [4 6 13], NULL, NULL, {tv_sec=0, tv_nsec=250000000}, NULL) = 1 (in [13], left {tv_sec=0, tv_nsec=249993784})
read(13, "", 8192)                      = 0
close(13)                               = 0
sendto(5, "\1\0\0\0\16", 5, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 5

Any ideas on how to get this to work?

ZM: v1.36.33

Running on up to date Fedora 39, kernel 6.8.10-200.fc39.x86_64

Thanks

-- Patrick

[burger]

Try echo not cat. There is an example here:

https://wiki.zoneminder.com/ZMTrigger

[patmansf]

Try echo not cat. There is an example here:

https://wiki.zoneminder.com/ZMTrigger

I'm not using cat, but using echo it still fails the same way.

[patmansf]

I used perl -d:Trace, and it looks like nothing is even making it back to the perl code - to the select call in zmtrigger.pl in my code at line 135.

[mikb]

Try echo not cat. There is an example here:

https://wiki.zoneminder.com/ZMTrigger

The "cat" is just to dump the contents of the file for exposition of the contents, not as part of the failing command!

Sometimes things like this don't work because of timing problems, and you have to start getting a bit more creative using "expect" to wait for some kind of response from the far end before blasting it with data.

[patmansf]

Try echo not cat. There is an example here:

https://wiki.zoneminder.com/ZMTrigger

The "cat" is just to dump the contents of the file for exposition of the contents, not as part of the failing command!

Sometimes things like this don't work because of timing problems, and you have to start getting a bit more creative using "expect" to wait for some kind of response from the far end before blasting it with data.

Per the strace, it doesn't look like a timing problem as it's getting an ENOTTY. That seems really odd as it should be a network connection no matter how telnet gets it input data.

I saw some perl issues similar to this but no solutions for them.

Yeah I'll try using expect, hopefully it won't have the ENOTTY issue.

[patmansf]

[Yeah I'll try using expect, hopefully it won't have the ENOTTY issue.

expect hits the same issue.

[mikb]

Ummm, not to state the obvious that I should have mentioned in the first place

ENOTTY is correct. It's not a TTY. You are redirecting input from a file. So it's not a TTY.

I don't suppose that is actually really an error, as such.

[patmansf]

ENOTTY is correct. It's not a TTY. You are redirecting input from a file. So it's not a TTY.

Sure, but I don't know why it's sending an lseek only when I do not have a tty.

That is, when I use telnet directly I don't see any lseek calls.

This is based on an example zoneminder script.

[mikb]

ENOTTY is correct. It's not a TTY. You are redirecting input from a file. So it's not a TTY.

Sure, but I don't know why it's sending an lseek only when I do not have a tty.

That is, when I use telnet directly I don't see any lseek calls.

This is based on an example zoneminder script.

I'm really not sure what is failing here specifically.

There's a possibility that the error you're seeing there isn't even an error.

It could be a "probe", in the software. e.g. "Try seeking my input to the beginning, can I do that?" If yes, do one thing. If no, do things another way.

For example, strace-ing some programs gives a slew of "errors" (can't stat /xxx/xxxx/xx: No Such File Or Directory) just because the program is groping around for possible config files at locations ... e.g. trying to load /usr/system/default, /usr/local/default /home/YOU/.local/defaults -- zero, one, or more of which may exist. It then integrates what it finds internally and now knows what settings to apply.

Or it tests to see if a directory/file exists: "ERROR, no it doesn't!" -- not an error, I'll create it then!

They are not errors, and the program works fine.

However, if the program goes on to "not work" -- attention may be drawn to the "look at all these errors!" from strace, and things get sidetracked into trying to "fix" the missing files. Program still won't work, because something else is *actually* wrong

Debugging is like that sometimes.

[patmansf]

I was able to use nc, and had to add a new line at the end of the input text.

So this works:

Code: Select all

myipaddr=192.168.1.1
myport=6802

monitor=$1
shift
m1=$1
shift
m2=$1
shift

data="${monitor}|on+10|10|${m1}|${m2}|
"

echo "Sending ${data} to zoneminder at ${myipaddr} port ${myport}"
# telnet does not work unless stdin is used so use nc.
# The extra new line is required.
# telnet $myipaddr $myport << EOF
nc $myipaddr $myport << EOF
${monitor}|on+10|10|${m1}|${m2}|

EOF