#30 can't read "hup(POTS)": no such variable

[Anonymous]

My ncid is giving me this error after HUP with FAX tone: can't read "hup(POTS)": no such variable. It kills the process by the way. Any clue? Thanks.

[John L. Chmielewski]

You can make a small change to /usr/bin/ncid or /usr/local/bin/ncid to fix the problem.
The change is to add the regsub line and replace cidline with lineid in the array line.

Change these lines:

# hup array used to restore normal color to $linetype
array set hup "{$cidline} $display_line_num"

to these lines:

# hup array used to restore normal color to $linetype
regsub {\s+$} $cidline {} lineid
array set hup "{$lineid} $display_line_num"

I can post a modified ncid if you rather not make the changes. I need to know if ncid is in /usr/bin or in /usr/local/bin.

Let me know if the above fixes your problem. The fix will go into release NCID 1.11.

[Anonymous]

Just had this issue on my Mint 18 box and the fix worked. Thank you!

Lee

[Anonymous]

Thanks a lot. It has fixed my problem. Let you know further issues. BR.

[John L. Chmielewski]

Problem fixed.

[Anonymous]

Hi, one more event, different code line:

can't read "hup(POTS)": no such variable
while executing
"lindex $hup($lineinfo) 0"
(procedure "getCID" line 300)
invoked from within
"getCID"

[John L. Chmielewski]

The line does have a problem.

Change this line in /usr/bin/ncid or /usr/local/bin/ncid:

set displine [lindex $hup($lineinfo) 0]

To this line:

set displine $hup($lineinfo)

If problem still exists, run client in verbose mode and send the output to me when it dies again.:

ncid -v 5

Edit: changed -v4 tp -v5

[Anonymous]

Hi
Something wrong yet. It happens when receiving a call. I was running the ncid-page as service this time...
Thx.

mar 18 16:50:30 raspberrypi ncid[489]: can't read "hup(POTS)": no such variable
mar 18 16:50:30 raspberrypi ncid[489]: while executing
mar 18 16:50:30 raspberrypi ncid[489]: "set displine $hup($lineinfo)"
mar 18 16:50:30 raspberrypi ncid[489]: (procedure "getCID" line 300)
mar 18 16:50:30 raspberrypi ncid[489]: invoked from within
mar 18 16:50:30 raspberrypi ncid[489]: "getCID"
mar 18 16:50:30 raspberrypi ncid[489]: TCL LOOKUP VARNAME
mar 18 16:50:30 raspberrypi systemd[1]: ncid-page.service: Main process exited, code=exited, status=1/FAILURE
mar 18 16:50:30 raspberrypi systemd[1]: ncid-page.service: Unit entered failed state.
mar 18 16:50:30 raspberrypi systemd[1]: ncid-page.service: Failed with result 'exit-code'.

[John L. Chmielewski]

Try the client in the attached ncid-1.10.1.1.tar.gz file from my post below. Should fix the problem. If you did install the attached file, make sure it is running:

$ ncid -V
ncid (NCID) 1.10.1.1

[Anonymous]

Hi,
Did it and looks like it's solved now. However, after the 1.10.1.1, noticed that the ncid-page is sending me emails only when the caller is a known number (in my whitelist). Otherwise, it does not send me the email. Any connection with this last version? Previouly, it was doing the job for every received call.
Thx.

[John L. Chmielewski]

Not sure what the problem is but it is but check /etc/ncid/ncid.conf. The fix should not have effected ncid-page.

The default is to execute ncid-page as soon as Caller ID is detected. Make sure this line or a variation of the line is still a comment.

# set ncid_page {set Ring 4}

You can run the client manually in log mode in a terminal window:

ncid -P ncid-page -v 3

The output should give an indication of when ncid calls ncid-page. You can capture it to a file and attach it to a post. Make sure it does a few calls where your email is sent and not sent.

[Anonymous]

Hi, here you go. You can see the first number 01143663404, not in my whitelist, and the second number 01143663403, which is in my whitelist.
For the second number I always receive the email. For the first one, never.

Client: ncid-page [raspberrypi] NCID 1.10.1.1
Server address: 127.0.0.1:3333
Verbose Level: 3
Script executed: /usr/local/bin/ncid
Config file: /etc/ncid/ncid.conf
HostnameFlag: 0
lineName: ncid
loginName: pi
Delay between reconnect tries to the server: 15 (seconds)
Country Code: NONE
Date Format: DD/MM/YYYY
Using output Module: /usr/share/ncid/modules/ncid-page
No optional "ncid_page" variable in ncid.conf
Will execute /usr/share/ncid/modules/ncid-page when CID arrives
Not using a PID file
HELLO: IDENT: client ncid-page (NCID) 1.10.1.1
Connected to 127.0.0.1:3333
Sent: HELLO: CMD: no_log
200 Server: ncidd [raspberrypi:3333] (NCID) 1.10.1
Client: ncid-page [raspberrypi] NCID 1.10.1.1
Server: ncidd [raspberrypi:3333] (NCID) 1.10.1
251 Call log not sent
OPT: LineIDS: POTS
option added to svrOption: LineIDS: POTS
OPT: hangup-2
option added to svrOption: hangup-2
OPT: hupmode-2
option added to svrOption: hupmode-2
300 End of connection startup
Phone line label "POTS" not found
using a module
Sent /usr/share/ncid/modules/ncid-page 28/03/2019 13:31 01143663404 {NO NAME} POTS HUP {} {}
using a module
Sent /usr/share/ncid/modules/ncid-page 28/03/2019 13:37 01143663403 {LEO} POTS CID {} {}

[John L. Chmielewski]

The reason the first one is never sent is because the call type, HUP, is not sent by default.

Edit /etc/ncid/conf.d/ncid-page.conf and add HUP to allowed_types::

Change line 68 from: allowed_types="CID MSG"
To:                  allowed_types="CID HUP MSG"

[Anonymous]

Thanks. Currently it is:
allowed_types="CID BLK MSG"
And it worked for a while as I said. Don't know why it stoped now. Wierd.
I'll include the HUP type and will test it. Let you know.
Thanks again.

[Anonymous]

*stopped * weird

Worked. The type HUP solved my problem.
Thanks.

[John L. Chmielewski]

If you look at the lines sent to ncid-page in the log you sent, you can see the type for the call not in your whitelist is HUP.

[Anonymous]

Ok, wil do it. Thanks.

[Anonymous]

Hi, different anonymous guy here, same "getCID" line 300 error as above. I am running 2 clients on the same localhost as the daemon (Pi 3, raspian stretch). The main gui client and a no gui mysql. I changed my /usr/bin/ncid file for both fixes above and my gui client seems to stay running now (only tested twice so far), but my non gui still stops. Is there a different line to change for non gui client? It logs the data into mysql and then is gone after the CIDINFO is sent.
CIDINFO: LINEPOTSRING0TIME19:32:11*
Client 7 pos 3 from 127.0.0.1 [localhost] nodialout {client ncid-mysql (NCID) 1.10.1} disconnected 03/09/2019 19:32:11

Thank you

[Anonymous]

Because of the request for the other guy do run ncid with -v 5, I have decided to as well.
Client: ncid-mysql [raspberrypi] NCID 1.10.1
Server address: 127.0.0.1:3333
Verbose Level: 5
Script executed: /usr/bin/ncid
Config file: /etc/ncid/ncid.conf
HostnameFlag: 0
lineName: ncid
loginName: root
Delay between reconnect tries to the server: 15 (seconds)
Country Code: NONE
Date Format: MM/DD/YYYY
Using output Module: /usr/share/ncid/modules/ncid-mysql
No optional "ncid_mysql" variable in ncid.conf
Will execute /usr/share/ncid/modules/ncid-mysql when CID arrives
Not using a PID file
HELLO: IDENT: client ncid-mysql (NCID) 1.10.1
Connected to 127.0.0.1:3333
Sent: HELLO: CMD: no_log
200 Server: ncidd [raspberrypi:3333] (NCID) 1.10.1
Client: ncid-mysql [raspberrypi] NCID 1.10.1
Server: ncidd [raspberrypi:3333] (NCID) 1.10.1
Assigned type 0 for Server: ncidd [raspberrypi:3333] (NCID) 1.10.1
Assigned type 0 for 210 API: 1.8 Feature Set 1 2 3 4 5
Assigned type 0 for
251 Call log not sent
0 entries in 21 milliseconds
Assigned type 0 for 251 Call log not sent
Assigned type 0 for
OPT: LineIDS: POTS
option added to svrOption: LineIDS: POTS
Assigned type 0 for OPT: LineIDS: POTS
OPT: hangup-2
option added to svrOption: hangup-2
Assigned type 0 for OPT: hangup-2
OPT: hupmode-2
option added to svrOption: hupmode-2
Assigned type 0 for OPT: hupmode-2
OPT: ignore1
option added to svrOption: ignore1
Assigned type 0 for OPT: ignore1
300 End of connection startup
Assigned type 0 for
Assigned type 3 for CIDINFO: LINEPOTSRING1TIME20:00:07
Phone line label "POTS" not found
Assigned type 0 for
Assigned type 1 for HUP: DATE03092019TIME1959LINEPOTSNMBRxxxxxxxxxxMESGNONENAMESome City,USA
using a module
Sent /usr/share/ncid/modules/ncid-mysql 03/09/2019 19:59 xxxxxxxxxx {Some City,USA} POTS HUP {} {}
Assigned type 0 for
Assigned type 3 for CIDINFO: LINEPOTSRING-4TIME20:00:21*

---This was not in the normal output which I saved to a file, it was the error after the crash---

root@raspberrypi:/etc/ncid# /usr/bin/ncid --no-gui -v 5 --program ncid-mysql > temp.txt
BGError: can't read "hup(POTS)": no such variable
can't read "hup(POTS)": no such variable
while executing
"set displine $hup($lineinfo)"
(procedure "getCID" line 301)
invoked from within
"getCID"
TCL LOOKUP VARNAME

It looks the same to me except it says line 301 instead of 300, but I commented out the previous line and just added the line you suggested below it. I hope that makes sense.

[John L. Chmielewski]

Attached is ncid-1.10.1.1.tar.gz. Let me know if it works. This fix will be in NCID release 1.11.

$ tar -xavf ncid-1.10.1.1.tar.gz
$ sudo cp ncid /usr/bin/.
$ ncid -V
ncid (NCID) 1.10.1.1

Edit: fixed file name typo on the tar command

[Anonymous]

I have tested it only once but yes both client's continue to run. BTW the tar command is not complete, or mistyped since the file is a tar.gz, however this worked "tar zxvf ncid-1.10.1.1.tar.gz".
Thank you for the file.

[mmartz]

Encountered this particular crash with the client today while trying out NCID from a Mercurial checkout of this project (I had to do a checkout because the ncid_1.10.1-1_amd64.deb and the ncid-1.10.1-src.tar.gz wasn't all that stable with this system for some reason for the past few days).

Applied the patch recommended above of:

--- a/client/ncid.sh    Tue Jan 22 13:08:18 2019 -0500
+++ b/client/ncid.sh    Thu Sep 05 02:47:46 2019 -0600
@@ -1295,7 +1295,8 @@
                 # set temperory color to $linetype

                 # hup array used to restore normal color to $linetype
-                array set hup "{$cidline} $display_line_num"
+                regsub {\s+$} $cidline {} lineid
+                array set hup "{$lineid} $display_line_num"

                 if $NightMode {
                     set ctcolor white

... which seems to have fixed the client crash when I block CID and am observing in the client. Not sure if I'll need the other patches or not yet.

System stats:

• Zoom Modem Model 3095 (Voice/Fax/Modem) ... finally get to use this thing after years.
• US locale

$ uname -a
Linux machine 5.0.0-27-generic #28~18.04.1-Ubuntu SMP Thu Aug 22 03:00:32 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

$ which ncid
/usr/bin/ncid

$ which ncidd
/usr/sbin/ncidd

Did have to modify/set ncidd.conf to:

# optional debugging
set verbose = 5

# required
set ignore1 = 1
set hangup = 3
set announce = NotInService.rmd
set ttyport = /dev/ttyACM0 
set lockfile = /var/lock/LCK..ttyACM0

... with special emphasis on the lock file location. Without setting the lockfile the modem never "picks up or hangs up" and everything becomes highly unpredictable.

Anyhow I just wanted to say a HUGE THANK YOU to everyone here, including @jlc for the fixes, for this totally awesome project. Keep up the good work and hope to see some of these fixes in release 1.11, as mentioned above, soon. I have a client that I'm trying to wean off of Windows 7 to Linux and this project is a superb step towards that goal. :) I also plan on utilizing it for my purposes as well.

Again THANK YOU!

P.S. Still figuring a bit out on this project so I might be back for some more if that's okay. Probably new tickets though unless I find an existing one.

[Ed Attfield]

I'm puzzled by the part about having to set the lockfile in the ncidd.conf file.
1) If you've done make ubuntu at the top level of the ncid source file tree, the path should be /var/lock/LCK..ttyACM0 when the modem is /dev/ttyACM0.
2) It shouldn't matter what the path is, because it only checks for the lock file as a courtesy to other tools -- ncidd does not create this lock file. -- It should work as well with set lockfile=/rubbish/and/more.

I think you may be seeing something else, perhaps a modem problem.

[mmartz]

If you've done make ubuntu at the top level of the ncid source file tree...

You mean both at https://sf.net/p/ncid/code/ci/ac7d23/tree/Makefile#l25 and https://sf.net/p/ncid/code/ci/ac7d23/tree/Makefile#l26 currently.

... the path should be /var/lock/LCK..ttyACM0 when the modem is /dev/ttyACM0.

As per the ncidd.conf it should be however it was not. It mimicked the # Fedora : /var/lock/lockdev/LCK..modem path which doesn't exist and was reported as a failure in the logs (which have since been cleared because I was testing all kinds of things and now I'm on a production test atm). The udev rules defined currently in here didn't pick up the modem either. Luckily the CDC ACM detection is consistant on the ttyACM0, so far, since I also have a USRobotics 5637 (which has its own set of issues also mentioned throughout the repo here... but it does work in mode 1 of hangup when I was testing it out. It too was only on the ttyACM# train for udev rules).

It should work as well with set lockfile=/rubbish/and/more.

Not willing to try that just yet because I'm heading out for a while but I'll give that a shot when I get back, but since I had to force it to /var/lock/... and not what it was choosing with /var/lock/lockdev/... as a default automatically it might be doubtful that "rubbish" strings would work.

... perhaps a modem problem

Modem works perfectly under Windows XP and 7... still awaiting to test it in 8, 8.1, and 10 at some point. Modems do have different firmware as well as some are PROM types and others are EEPROM types. I haven't had this thing out of the box other than a quick test to see if it was working since I bought it many, many, many years ago. My client has the exact same one (hopefully since we bought them at the same time).

If you are interested on compatibility comparison, this is what is detected:

$ lsusb
...
Bus 002 Device 005: ID 0803:3095 Zoom Telephonics, Inc. V.92 56K Mini External Modem Model 3095

.... and as I stated only shows up in /dev as ttyACM0.

I think you may be seeing something else...

There's always a chance there's a bug in bionic or some supporting package interfering but the logs told me what the error was and the documentation embedded in the ncidd.conf told me how to force it to the correct path... which cleared the error. :)