Enhanced udev utility

[Ed Wildgoose-2]

Hi, I have a need for an enhanced udev utility which will get watch the
input from generic serial to usb adaptors and decide if they are a gps
or a modem.  If it's a GPS then we pass it to gpsd, if it's a modem then
pass it somewhere else.  This is hopefully quite useful because at
present gpsd snaffles any serial device

First up, would anyone be interested in working on this for a donation?

I think a solution could be done using a derivative of gpsctl, which
already scans the serial port to guess the type of device.  If the
scanning were enhanced to detect an AT compatible modem (ie send it an
AT and see if it says OK back again) then largely much of the code is
already done.

I have done a little investigation into this and having only looked at
the code for a few hours I have the following questions:

- I can see how driver_xyz.c works in big picture terms, but not really
how to get a driver_at_modem.c started... Anyone want to start it off?
- At present there doesn't appear to be active baud rate setting for
most of the drivers? This seems to lead to problems if the default baud
does not allow us to communicate with the device? Can anyone comment on
whether this is deliberate and the best way forward?
- What's the best way to have a driver which is there to be detected,
but detected as a non gps? ie once we discover it's not a GPS we drop it
and don't use it for input?

Grateful for any help

Thanks

Ed W
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Ed W <lists@...>:
> Hi, I have a need for an enhanced udev utility which will get watch the
> input from generic serial to usb adaptors and decide if they are a gps
> or a modem.  If it's a GPS then we pass it to gpsd, if it's a modem then
> pass it somewhere else. This is hopefully quite useful because at
> present gpsd snaffles any serial device

But releases it if it's not identifiably a GPS. I have trouble seeing how a
seperate utiliyy could do a beter job than the preent combination of udev
script and gpsd, which tosses USB devices at gpsd nd has it release then if it
can't achieve sync on the data stream.

What do you want the hypothetical utility to do that this combination is
not already doing?
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Bernd Zeimetz]

Eric S. Raymond wrote:

> Ed W <lists@...>:
>> Hi, I have a need for an enhanced udev utility which will get watch the
>> input from generic serial to usb adaptors and decide if they are a gps
>> or a modem.  If it's a GPS then we pass it to gpsd, if it's a modem then
>> pass it somewhere else. This is hopefully quite useful because at
>> present gpsd snaffles any serial device
>
> But releases it if it's not identifiably a GPS. I have trouble seeing how a
> seperate utiliyy could do a beter job than the preent combination of udev
> script and gpsd, which tosses USB devices at gpsd nd has it release then if it
> can't achieve sync on the data stream.
>
> What do you want the hypothetical utility to do that this combination is
> not already doing?

The only advantage I can see is that you'd be able to give gps devices different
permissions, while non-gps devices stay with the default setting.

--
 Bernd Zeimetz                             Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
                   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Ed Wildgoose-2]

Eric S. Raymond wrote:

> Ed W <lists@...>:
>  
>> Hi, I have a need for an enhanced udev utility which will get watch the
>> input from generic serial to usb adaptors and decide if they are a gps
>> or a modem.  If it's a GPS then we pass it to gpsd, if it's a modem then
>> pass it somewhere else. This is hopefully quite useful because at
>> present gpsd snaffles any serial device
>>    
>
> But releases it if it's not identifiably a GPS. I have trouble seeing how a
> seperate utiliyy could do a beter job than the preent combination of udev
> script and gpsd, which tosses USB devices at gpsd nd has it release then if it
> can't achieve sync on the data stream.
>
> What do you want the hypothetical utility to do that this combination is
> not already doing?
>  

Well, that would be some of the way there if gpsd actually worked the
way you describe, but at least on my installation it doesn't:

Here I plug in a generic serial to usb adaptor with nothing connected to it:

Sep  4 19:01:58 localhost user.info kernel: [ 1127.813801] usb 1-2.2:
new full speed USB device using ehci_hcd and address 6
Sep  4 19:01:58 localhost user.notice gpsd[4338]: gpsd: select waits
Sep  4 19:01:58 localhost user.info kernel: [ 1127.910955] usb 1-2.2:
configuration #1 chosen from 1 choice
Sep  4 19:01:58 localhost user.info kernel: [ 1127.911499] pl2303
1-2.2:1.0: pl2303 converter detected
Sep  4 19:01:58 localhost user.info kernel: [ 1127.913592] usb 1-2.2:
pl2303 converter now attached to ttyUSB1
Sep  4 19:01:59 localhost daemon.info gpsd.hotplug:
gpsd_control(action=add, arg=/dev/ttyUSB1)
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: control socket
connect on 7
Sep  4 19:01:59 localhost daemon.info gpsd.hotplug: reached a running gpsd
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: <= control(7):
+/dev/ttyUSB1\x0d
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: <= control(7):
adding /dev/ttyUSB1
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: opening GPS data
source at '/dev/ttyUSB1'
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: speed 9600, 8N1
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: => GPS:
2450415348512c5249442a32380d0a
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: Navcom: command
dump: 0299661c0800040200001203
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: => GPS:
0299661c0800040200001203
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: Navcom: sent
command 0x1c (Test Support Block)
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: Navcom: command
0x1c mode = 02, length = 0
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: Navcom: command
dump: 029966200e000001ae02000071000000f203
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: => GPS:
029966200e000001ae02000071000000f203
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: Navcom: sent
command 0x20 (Data Request) - data block id = ae at rate 00
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: Navcom: command
dump: 029966200e00000186020a0071000000d003
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: => GPS:
029966200e00000186020a0071000000d003
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: writing
superstar2 control type 2d len 6:012dd2000000
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: => GPS: 012dd2000000
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: garmin_gps Linux
USB module not active.
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: no probe matched...
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd:
gpsd_activate(1): opened GPS (8)
Sep  4 19:01:59 localhost user.notice gpsd[4338]: gpsd: select waits
Sep  4 19:02:00 localhost user.notice gpsd[4338]: gpsd: select waits


Then:
$ telnet localhost 2947
k
GPSD,K=1 /dev/ttyUSB1


So it hasn't "released it", or in fact given me a nice clear log message
that this is definitely not a gps?

I will reply about "why" in a second message

Ed W
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Ed Wildgoose-2]

Eric S. Raymond wrote:

Ed W lists@...:
  

Hi, I have a need for an enhanced udev utility which will get watch the 
input from generic serial to usb adaptors and decide if they are a gps 
or a modem.  If it's a GPS then we pass it to gpsd, if it's a modem then 
pass it somewhere else. This is hopefully quite useful because at 
present gpsd snaffles any serial device
    

But releases it if it's not identifiably a GPS. I have trouble seeing how a
seperate utiliyy could do a beter job than the preent combination of udev 
script and gpsd, which tosses USB devices at gpsd nd has it release then if it
can't achieve sync on the data stream.

What do you want the hypothetical utility to do that this combination is 
not already doing?
  

The reason "why" this is useful is that serial to usb adaptors are right now fairly generic devices and used in all kinds of odd places (especially the PL2303... sigh...)  So my situation is I have an embedded device (on a boat) which will be connected to lots of them and I expect anything up to all three of the following to be connected at various times (or all at once)

- generic pl2303 s2usb connected to some NMEA talker with a gps on it
- generic BU-353 gps (which just looks like a pl2303 to udev)
- generic pl2303 s2usb with a satellite telephone on the end of it (looks like a standard AT modem)

I have to assume that people will be foolish enough to swap these around from time to time, especially 1) and 3) above where you can even leave the s2usb connected and unplug the serial cables and swap them around (sigh...)

About the best I can reasonably do is simply scan any new serial devices and try to guess what kind of device we have got (sounds a lot like gpsd so far except it's slightly more generic in that I need to also spot AT modems).  Once I figure out the type of device I will need to either:

- Add it to my gpsd instance if it's a gps
- Configure it as a dialup device if it's a modem

Whilst gpsd has no reason to care about modems, there does seem to be a huge overlap with what it already does and the desired end goal. I had suggested making it a standalone utility because otherwise interfacing with whatever happens after it's identified as a modem becomes a case of log watching (not ideal on an embedded device).  However, most of the code to probe a serial port for interesting output seems already in gpsd and all I really need is a kind of "does it say "OK" when I say "AT" to it" test added

I hope the logic of what I am attempting is sensible even if it's not something you will be using yourself tomorrow...  Serial connected modems are still somewhat common in certain markets

Grateful for any thoughts

Ed W


_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Ed Wildgoose-2]

Bernd Zeimetz wrote:

Eric S. Raymond wrote:
  

Ed W lists@...:
    

Hi, I have a need for an enhanced udev utility which will get watch the 
input from generic serial to usb adaptors and decide if they are a gps 
or a modem.  If it's a GPS then we pass it to gpsd, if it's a modem then 
pass it somewhere else. This is hopefully quite useful because at 
present gpsd snaffles any serial device
      

But releases it if it's not identifiably a GPS. I have trouble seeing how a
seperate utiliyy could do a beter job than the preent combination of udev 
script and gpsd, which tosses USB devices at gpsd nd has it release then if it
can't achieve sync on the data stream.

What do you want the hypothetical utility to do that this combination is 
not already doing?
    

The only advantage I can see is that you'd be able to give gps devices different
permissions, while non-gps devices stay with the default setting.

  

The advantage I see is that you can trigger certain scripts/events to run when a non gps device is connected.  After all we want to run some script when a gps is connected, so it doesn't seem unreasonable to want some other script to run when a non gps is connected

Granted this isn't directly within the scope of a gps daemon application on the surface, but it does seem reasonable to want to play fair with other users of a serial port (there are lots of other uses for them from serial terminals to connecting modems)

The current utility is also not working well in my setup in conjunction with boot time identification of devices already plugged in.  POssibly it's my configuration and that udev is running earlier than expected, but its something that I will need to work on for this application

Thanks

Ed W

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Ed W <lists@...>:
> So it hasn't "released it", or in fact given me a nice clear log message  
> that this is definitely not a gps?

Right.  And I see from later email that this is a kernel-level problem,
no udev remove event is being emitted.  How would writing another
userspace program address this?
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Eric S. Raymond-2]

Ed W <lists@...>:
> I hope the logic of what I am attempting is sensible even if it's not  
> something you will be using yourself tomorrow...  Serial connected  
> modems are still somewhat common in certain markets
>
> Grateful for any thoughts

Write it.  If it looks clean,., I'll take it.

I xan't do it; I don't have the right kind of test equipment.
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev

[Ed Wildgoose-2]

Eric S. Raymond wrote:

> Ed W <lists@...>:
>  
>> So it hasn't "released it", or in fact given me a nice clear log message  
>> that this is definitely not a gps?
>>    
>
> Right.  And I see from later email that this is a kernel-level problem,
> no udev remove event is being emitted.  How would writing another
> userspace program address this?
>  

You are answering one question with the information about a different
question, please re-read up the thread?

To recap in this case I was saying that I didn't see gpsd "release" the
device once it failed to identify it as a gps. You were (I think?)
postulating an idea where I just check my modem device's into gpsd and
then when I spot them being "released" that I run some other scan on
them to see if they are really a modem?  I don't think this strategy
will work with gpsd in it's current state?

So my assertion is that really it would be useful to have a udev utility
which determines the type of many common serial devices (PnP for serial
ports...).  My chain of thought so far is that there is already a very
good detection routine in gpsd and hence perhaps that was a good
starting point for this utility, ie starting with a mature scanner for a
broad class of devices and just add in additional devices to the scanner.

Just an idea anyway...

I still have to somehow solve the problem that I have a whole bunch of
PL2303 devices being plugged in and some of them have a modem on the end
and others have a gps on them. Any other suggestions appreciated for
matching the correct device with the correct extra setup...?

Ed W

_______________________________________________
Gpsd-dev mailing list
Gpsd-dev@...
https://lists.berlios.de/mailman/listinfo/gpsd-dev