How to log USB modem data for a specific device?

[Jeffrey Walton]

On Tue, Nov 12, 2019 at 1:20 AM Jeffrey Walton <noloader at gmail.com> wrote:
>
> On Tue, Nov 12, 2019 at 12:37 AM Greg KH <greg at kroah.com> wrote:
> > ...
> >
> > > Here's why I want to specify a device number:
> > >
> > >     $ cat /sys/kernel/debug/usb/devices | grep -i -c 'Bus=01'
> > >     13
> > >
> > > It is too much information for me to sift through. I'll do it if I
> > > have to, but I prefer the tools do the work for me (rather than me do
> > > the work of the tools).
> >
> > That explains why you only want one device's data, but does not answer
> > why you want that data at all :)
>
> I have a pet project like NoMoRobo. It is essentially a call blocking
> service that depends on Caller ID. My pet project takes things a step
> further by initiating a call trace on suspicious numbers, and also
> files FCC and FTC complaints.
>
> The program works well with Conexant, Accura/Hayes and MultiTech
> modems. The program chokes on USR modems. For USR I get the RING
> message, but not the Caller ID information. From my program's
> perspective, it looks like the Caller ID information is never sent.
>
> So I want to perform some low level traces to understand why I am
> mishandling things.
>
> The GNU screen program receives the information as expected. The
> problem is, GNU screen does not show me individual messages. I don't
> know where one message ends and another begins. (One of my theories is
> the USR modem is batching RING and Caller ID into a single message).

I think I tracked down the problem.

The Caller ID information was not sent from the USR modem to my
program. It seems reading the ring count from the S1 register after a
RING is destructive for USR modems. My program fetches the ring count
for each RING message.

GNU's screen did not witness the problem because screen did not fetch
ring count when it encountered a RING message.

Getting the ring count is as simple as 'write(fd, "ATS1?\r", 6);' and
then parsing the result of 'read(fd, buff, size);'. The ASCII result
will be 001, 002, 003, etc. There's not much to it.

Fetching the ring count from the modem was a simple way to track
state. I guess I have to rethink the way I track state and perform
state transitions.

Jeff