4

We have a Nagios + check_mk setup on Ubuntu 12.04 LTS server with smstools for sending text message notifications. We are using an old Nokia 6230 phone connected by a USB cable, though I do not remember the vendor symbol of the cable. Occasionally the device becomes unresponsive - apparently the tty device address changes from /dev/ttyACM0 to /dev/ttyACM1 or the other way around.

According to the smstools log:

2013-05-28 16:51:16,3, GSM1: Could not send character A, cause: Input/output error
2013-05-28 16:51:18,3, GSM1: Could not send character A, cause: Input/output error

and nothing more in fact (I haven't used the full debug mode though).

After the restart of the smstools service it is:

2013-05-28 22:29:09,3, GSM1: Cannot open serial port /dev/ttyACM0, error: No such file or directory

It is possible that some of these occurrences were caused by one of our tech guys inadvertently and unknowingly disconnecting the phone for a few seconds while connecting some other device. I cannot be sure though.

The question is, how do I make the phone always use the same tty address? I suppose there is no problem with using udev rules for that, but I have little experience with those.

lsusb output for the phone is:

Bus 002 Device 004: ID 0421:040f Nokia Mobile Phones 6230 GSM Phone

It is a live production server monitoring some 250 hosts and I have not another phone at hand for experiments at the moment, so I cannot really test it by trial and error myself.

EDIT.

The output of udevadm info -q all -n /dev/ttyACM1 --attribute-walk:

  looking at device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.1/tty/ttyACM1':
    KERNEL=="ttyACM1"
    SUBSYSTEM=="tty"
    DRIVER==""

  looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6/2-1.6:1.1':
    KERNELS=="2-1.6:1.1"
    SUBSYSTEMS=="usb"
    DRIVERS=="cdc_acm"
    ATTRS{bInterfaceNumber}=="01"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bNumEndpoints}=="01"
    ATTRS{bInterfaceClass}=="02"
    ATTRS{bInterfaceSubClass}=="02"
    ATTRS{bInterfaceProtocol}=="01"
    ATTRS{supports_autosuspend}=="1"
    ATTRS{bmCapabilities}=="6"

  looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.6':
    KERNELS=="2-1.6"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}=="11"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bMaxPower}=="  8mA"
    ATTRS{urbnum}=="391970"
    ATTRS{idVendor}=="0421"
    ATTRS{idProduct}=="040f"
    ATTRS{bcdDevice}=="0550"
    ATTRS{bDeviceClass}=="02"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="12"
    ATTRS{busnum}=="2"
    ATTRS{devnum}=="4"
    ATTRS{devpath}=="1.6"
    ATTRS{version}==" 1.10"
    ATTRS{maxchild}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}=="Nokia"
    ATTRS{product}=="Nokia 6230"

  looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2/2-1':
    KERNELS=="2-1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bMaxPower}=="  0mA"
    ATTRS{urbnum}=="59"
    ATTRS{idVendor}=="8087"
    ATTRS{idProduct}=="0024"
    ATTRS{bcdDevice}=="0000"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="01"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="480"
    ATTRS{busnum}=="2"
    ATTRS{devnum}=="2"
    ATTRS{devpath}=="1"
    ATTRS{version}==" 2.00"
    ATTRS{maxchild}=="6"
    ATTRS{quirks}=="0x0"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{authorized}=="1"

  looking at parent device '/devices/pci0000:00/0000:00:1d.0/usb2':
    KERNELS=="usb2"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{configuration}==""
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bMaxPower}=="  0mA"
    ATTRS{urbnum}=="24"
    ATTRS{idVendor}=="1d6b"
    ATTRS{idProduct}=="0002"
    ATTRS{bcdDevice}=="0302"
    ATTRS{bDeviceClass}=="09"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{speed}=="480"
    ATTRS{busnum}=="2"
    ATTRS{devnum}=="1"
    ATTRS{devpath}=="0"
    ATTRS{version}==" 2.00"
    ATTRS{maxchild}=="2"
    ATTRS{quirks}=="0x0"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{authorized}=="1"
    ATTRS{manufacturer}=="Linux 3.2.0-38-generic ehci_hcd"
    ATTRS{product}=="EHCI Host Controller"
    ATTRS{serial}=="0000:00:1d.0"
    ATTRS{authorized_default}=="1"

  looking at parent device '/devices/pci0000:00/0000:00:1d.0':
    KERNELS=="0000:00:1d.0"
    SUBSYSTEMS=="pci"
    DRIVERS=="ehci_hcd"
    ATTRS{vendor}=="0x8086"
    ATTRS{device}=="0x1e26"
    ATTRS{subsystem_vendor}=="0x1043"
    ATTRS{subsystem_device}=="0x84ca"
    ATTRS{class}=="0x0c0320"
    ATTRS{irq}=="23"
    ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,0000000f"
    ATTRS{local_cpulist}=="0-3"
    ATTRS{numa_node}=="-1"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{enable}=="1"
    ATTRS{broken_parity_status}=="0"
    ATTRS{msi_bus}==""
    ATTRS{companion}==""
    ATTRS{uframe_periodic_max}=="100"

  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

I am not sure which attributes from which parent tree level I am to use.

I tried with SUBSYSTEM=="usb",ATTRS{product}=="Nokia 6320",NAME="ttyACM*",SYMLINK+="nokia" and variations (SYMLINK - without +; KERNEL=="2-1.6", without NAME and so on), all in /etc/udev/rules.d/10-local.rules file. I just get no symlink or no noticeable change at all.

Perhaps the problem is with the way the rules were applied - I cannot afford to reboot the machine and I hoped I won't have to send a tech to the server room only for plugging in and out a USB cable. I used /etc/init.d/udev restart, udevadm control --reload-rules and udevadm trigger with some combinations of --attr-match=vendor="Nokia", --attr-match=product="Nokia 6320" and so on, as described in this answer. Should I just send a tech to plug the thing in and out or buy another (cheap) phone for tests?

  • Which part of the canonical udev document are you having trouble with? – Ignacio Vazquez-Abrams May 29 '13 at 10:57
  • 1
    @IgnacioVazquez-Abrams I am not sure of the possibilities. For all I see I could use the KERNEL directive taken from the output of udevadm info -q all -n /dev/ttyACM1 --attribute-walk and add a symlink with SYMLINK and then use it in smstools config file as /dev/symlinked_name, am I right? If yes, I am not sure which level of the parent structure I should choose for the KERNEL parameter and then if I should use some more details in the rule. Will something along BUS=="usb",ATTRS{product}=="Nokia 6230",NAME="ttyACM0",SYMLINK="nokia_6230" work? – moon.musick May 29 '13 at 12:39
  • @IgnacioVazquez-Abrams I may post the output for udevadm info -q all -n /dev/ttyACM1 --attribute-walk if needed. – moon.musick May 29 '13 at 12:40
  • You've hardcoded the name. Try ttyACM* instead. – Ignacio Vazquez-Abrams May 29 '13 at 12:41
  • 1
    @IgnacioVazquez-Abrams Ok, I am using /dev/ttyACM0 directly in smsd.conf, but it seems once I use the SYMLINK option it should not matter whether it's ACM0 or ACM1 because I will have the symlinked name available to be used in the config file, like /dev/nokia_6230, is that right? – moon.musick May 29 '13 at 12:48
  • @IgnacioVazquez-Abrams didn't work unfortunately - I made an edit with more data. – moon.musick May 29 '13 at 14:24

2 Answers2

2

I can confirm that smstools will not start without the device name at all. So this wont work:

devices = GSM*

#device = /dev/ttyACM0

You could add both device, but that's not the right solution either. When you have ACM1 and ACM0 used by the smstools then what happen? Yes you wont have the phone available for calls/sms.

I could not find the right solution just yet, but the above will not work at all. Copied from this site actually: http://unix.findincity.net/view/635395087004115229136640/point-usb-phone-to-specific-devttyacm-using-udev

Laz Sz
  • 21
  • If by 'above' you mean adding both devices, then it does work in production for two years now and apart from it being kludgy it doesn't seem to cause us any problems. In my smsd.conf it's devices = GSM1, GSM2 though and two separate [GSMx] sections, each containing a different device entry. – moon.musick Jun 10 '15 at 18:48
1

Idea #1: Monitor & Restart

I would consider this a hack but you could setup a cron to monitor the smstools log for when this situation occurs, and restart smstools on whatever device it happens to be on at the moment.

You can watch the smstools log with this nagios script, check_log3.pl:

check_log3.pl -l /var/log/smstools -s /tmp/log_smstools.seek \
      -p 'Input/output error'

Once the error is detected you could restart smstools. To get around the issue with it moving you could keep 2 copies of smstool's config file one setup for /dev/ttyACM0 & the other for /dev/ttyACM1.

Use the appropriate one to start up.

Idea #2: Add both devices

Looking at the docs for smstools it seems like you could add both tty's to the file or leave the device line unspecified completely.

devices = GSM*
# device = /dev/ttyACM0
slm
  • 369,824
  • I considered monitoring the log restarting with another config, possibly with sed -i, but that seems to be somewhat hackish. I might try with both addresses though, even if it requires a cron job for restarting smstools. Will see if it helps, thanks ;) – moon.musick May 30 '13 at 07:31
  • It seems it is working - I couldn't find the time to test it on purpose myself, but an hour or so a tech called me to verify if the phone's connected properly, as he had to uplug for a minute it to put another server in the rack. The tty address changed, but the service is working fine, it seems. Had to set up a cron job, but restarting the service takes like 1.5 second, it seems. Thanks :) As the answer is a bit of a workaround, I am not sure if accepting it is ok according to the site rules - if it is, I will gladly accept it :) – moon.musick Jun 06 '13 at 13:13
  • Nope it's completely fine to accept. It solved your problem. Glad it fixed your issue. I've used this trick more times than I care to admit for other things, sometimes it's about fixing it, not necessarily solving it 8-). – slm Jun 06 '13 at 13:19