>How does the kernel handle pccard and USB devices disappearing?  Would
>having some sort of intelligent ugensa_methods.ucom_close() help?  I've
>not examined the source enough, but I'd guess ucom_close() would be
>called to clean up when the device is disconnected.  Perhaps I should
>look at umass(4) for an example of something that needs orderly cleanup
>when the device vanishes.
>
>Would such glue even be necessary?  The current driver presents the
>serial interface via ttyU<#>, which IMHO is quite clean.  It appears the
>USB code is a series of interface definitions, with ugensa conforming to
>the ucom(4) interface.
>
>Again, someone please correct me if I'm wrong or confused.
>  
>
When the card locks up, I can't even use tip to access it directly. It's my
impression that the USB endpoints are still functioning, just the internal
virtual pppd mechanism on the card has gone out to lunch and trying to
use the basic serial modem endpoints to re-establish communication is not
possible.

The 5220 and 580 cards actually have 5 endpoints: An Interrupt IN, 2 
Bulk INs
and 2 Bulk OUTs. The ugensa driver is only concerned with the first Bulk IN
and first Bulk OUT. These two endpoints give you access to the basic modem
command set and the data once connected. I'm not certain as yet what the
Interrupt IN could do for you, but the second pair of Bulk IN/OUT endpoints
are for the control functions. Data passed across these endpoints use a 
proprietary
protocol that I believe could be diciphered from the SDK. I've watched the
data transmission across these ports with a serial sniffer when using 
the 5220
card under Windows with Verizon's included software. It's a binary format
for sure, but could be of use with an appropiate userland application. 
talking
to the endpoints. I also think the API has the ability to power off the 
card or
at least reset the card from these second ports--not to mention do 
activation
and get real-time signal strength while connected.

>Hmmmm.  I've noticed IP pauses when the card [presumably] goes into
>"dormant mode", but the only system hang I've had is when I ejected the
>card while active.  See above ucom_close() questions.
>
>
>MW> has a SDK for their 580 card which is very similar to the Audiovox
>MW> (AirPrime) 5220 card.  My thought in all this is that is should be
>
>Cool!
>
>
>MW> possible to write a more specific (better overall functionality)
>MW> interface to the 5220 and 580 cards--something that can easily
>MW> monitor the signal quality, activate the card and reset the card
>MW> when it locks up.  With NetBSD used in many embedded environments,
>
>I honestly didn't know about the SDK.  AFAI knew, the management
>functions were secret and unavailable.  If I understand correctly, one
>would add ugensa_methods.ucom_ioctl() and a userland program to send the
>proper ioctls.
>  
>
Userland program yes; ugensa as is, no. Ugensa doesn't even bother with
the second pair of endpoints. It could be made to, but my point as mentioned
by Lennart, is that the ugensa would no longer be generic. If we were to
build on top of the generic ugen driver with a userland program that drives
pppd and talks to ugen, I would view this is much more suitable. It would
also be very valuable code of others that want to write userland code for
talking to vendor specific ugen enabled devices.

>Does anyone know what Venturi's compression is?  (Maybe I should RTFSDK
>before asking...)  AFAICT, pppstats indicates there's no compression;
>I'd have to brush up on ppp before looking at any negotiation dumps.
>
>
>MW> the possibility for using one of these wireless cards in a NetBSD
>MW> powered office router seems more likely.  And with Verizon
>
>s/router/firewall/ -- VZW prohibits sharing Internet connections IIRC
>  
>
You may want to make mention of that to Bob Kim at:
http://www.evdo-coverage.com/

He sells a device as an Authorized Verizon Wireless Agent that does just
what I'm talking about.

>MW> Wireless' plan to have EVDO implemented across their entire
>MW> network by the end of the year, it might be a good time to get
>MW> the ball rolling.
>
>Indeed.  I've not made it to EVDO territory on NetBSD, yet; simply
>having RTT when I'm between { client sites | home | cities } has been
>nice.  On Windows, EVDO was notably faster than RTT, so I'd think many
>a fellow roaming geek would love a solid, stable EVDO-on-NetBSD setup.
>  
>
For sure. Verizon Wireless is the only Internet connection that I can get
at my location without going full bore with a T-1 line.

Matt Watts
Systems Integrator
WattsComputers, LLC