It might be a good idea to check for permissions, a sane cu.modem should look like this:

# ls -l /dev/cu.modem
crw-rw-rw- 1 root wheel 8, 1 14 Mar 11:38 /dev/cu.modem

Check before and after using different apps opening the device, some may monkey with ownership or permissions.

Good point, Voldenuit. I'm pretty sure ncidd will touch the modem, but doesn't change anything. I had to reboot after deleting /dev/cu.modem because I was impatient and couldn't get `mknod` to do what I wanted. But a reboot will recreate the device with proper major/minor node numbers.

Hi kahuna,

That's interesting. I have two Macs, one G4@400 and an iMac G5. On the iMac ncidd seems to work, after I set the modem to /dev/cu.modem and sttyclocal to 1 in the config file. On the G4 I get the same results no matter what I do, even after deleting /dev/cu.modem. This is ncidd's output on the G4:

sudo ncidd -vD
Password:
Configured to send 'cidlog' to clients.
Configured to send 'cidinfo' to clients.
Processed config file: /usr/local/etc/ncidd.conf
CID logfile: /var/log/cidcall.log
Modem logfile: /var/log/cidmodem.log
Modem port opened: /dev/cu.modem
Modem lock file: /Users/ths/lock/LCK..cumodem
Modem control signals disabled
No modem found: /dev/cu.modem

And here the output on the iMac:

sudo ncidd -vD
Password:
Configured to send 'cidlog' to clients.
Configured to send 'cidinfo' to clients.
Processed config file: /usr/local/etc/ncidd.conf
CID logfile: /var/log/cidcall.log
Modem logfile: /var/log/cidmodem.log
Modem port opened: /dev/cu.modem
Modem lock file: /var/lock/LCK..cu.modem
Modem control signals disabled
AT Z S0=0 E1 V1 Q0
OK
Modem initialized.
AT+VCID=1
OK
Modem set for CallerID.

I installed the ncid package from the source 0.50 version on both Macs.

The G4's modem reacted fine when using minicom. I haven't enabled caller id, so when I call I only get the RING message. As for the init string it's still set to the default setting. Actually all settings are still the default settings except for the modem which is set to /dev/cu.modem.

ths, do you have any idea why the lockfile gets written to two different locations on the two machines while you said both installations were identical ?

The iMac picks a place that looks a lot more unix-like...

Hi voldenuit,

Oh, must have missed that one. Well, I've been toying around a little with the config file and thought maybe it's a permission thing or something, so I changed the location of the lock file. But it's the same wherever I put the lock file.

you don't happen to use the modem to dial the internet do you?

Hi kahuna,

No, I'm using Ethernet and Airport to connect to the internet. And before you ask, no, I don't have the fax server running, either.

Sorry, I was kinda thinking out loud. I'm mystified--are there any other messages in console or cidmodem.log? The only clue that looks helpful is the lock file location. Does minicom create the lock file in the same place?

I'm out of good ideas now.

For the mini, either the line current is not in the range it likes or CID-support is not stable with that modem.
For the G4 unable to open it, other than tracing the source or asking on the ncidd-delevopers mailing-list, no other approaches I could think of.

Good luck to you, keep us posted if you make progress...

ths,

Have you tried running ktrace on your ncidd process? Maybe it will have some other clue.

Hi kahuna,

Sorry for the delay, I've been on holiday :-)
I finally got around running ktrace. On the iMac everything runs very smoothly, I get an "OK" for every command ncidd sends to the modem. On the G4 however, I get nothing, e.g.

----
"AT Z S0=0 E1 V1 Q0\r"
6536 ncidd RET write 19/0x13
6536 ncidd CALL read(0x3,0xbffff540,0x3ff)
6536 ncidd GIO fd 3 read 0 bytes
""
----

When I type the very same init string from above in minicom I get the usual "OK". Interestingly enough, when I run minicom and then start ncidd, the init string from above is launched 9 times in minicom whereupon I get 9 OK's, but ncidd still fails to recognize the modem...

In short, ncidd sends the init string to the modem, the modem receives the string and executes it, the modem sends back an OK signal, but ncidd somehow never receives that signal. Strange.

Are you using the same ncidd binary on each machine or did you compile it on each specific machine? Maybe the modem driver updates rumored in 10.3.9 will help--I'm hoping they do for me.

Otherwise, I'm stumped. I'm afraid I sent you down the wrong path and wasted your time.

Hi kahuna,

I compiled each binary on each machine respectively. As for the modem drivers, I guess I'll try again once 10.3.9 or even 10.4 is out. And don't worry about wasting my time, it was mine to waste to begin with and I'm sure that an update to ncidd will provide a solution and then I'm sure it's exactly what I've been looking for. I mean, I got it working on one Mac, admittedly not the one I was hoping it would be, but nonetheless. So, thanks for the help for the time being and I'll get back to you as soon as some solution presents itself :-)

I have been following this thread with interest because what I would like to do is:

1. Split the line to my phone to the modem in my old G4
2. Get the G4 modem to recognize the caller ID but not pick up the phone
3. Take the Caller ID number from the G4 modem and plug it into a Spotlight search
4. Get Spotlight to display the Address Book card that matches the Caller ID and flash the card up on screen.

It seems like such a useful procedure that I would have guessed there would be an application like Phone Valet that could this. But apparently not?

Any takers on the chances of doing this in 10.4?

I realize I'm hitting this thread late, but I think you can probably apply Hayes AT commands to the modem directly from the terminal using "echo" just like on the PC. It would look something like this:

"echo ATZ > /dev/cu.modem"

Obviously, you can use any AT command you need, but I used the reset command as an example.

Greg