USB/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module

[Ian Lepore]

On Sun, 2017-10-01 at 22:20 +0200, Tomasz CEDRO wrote:
> On Sun, Oct 1, 2017 at 9:38 PM, Ian Lepore <ian at freebsd.org> wrote:
> > 
> > On Sun, 2017-10-01 at 20:59 +0200, Tomasz CEDRO wrote:
> > > 
> > > On Sun, Oct 1, 2017 at 8:23 PM, Ian Lepore <ian at freebsd.org>
> > > wrote:
> > > > 
> > > > 
> > > > On Sun, 2017-10-01 at 20:17 +0200, Tomasz CEDRO wrote:
> > > > > 
> > > > > 
> > > > > [...old stuff...]
> > > I have verified on uath device (more on that below) and it turns
> > > out
> > > $cdev works fine.. but it returns /dev/usb/X.Y.Z not the
> > > /dev/cuaU0
> > > which does not work with this "gobi_loader" utility which
> > > requires
> > > /dev/cuaU0 (CDC / serial port device)... any clues how to replace
> > > $cdev with cuaUX? :-)
> > > 
> > > Regarding the UATH, I have TP-LINK TL-WN822N Ver2.0 based on
> > > Atheros
> > > 9002[1] and it seems to work with modified /dev/devd/uath.conf
> > > but
> > > the
> > > uathload returns "Operation not permitted" when executed as root
> > > and
> > > during boot..
> > > 
> > > [1] https://wikidevi.com/wiki/TP-LINK_TL-WN822N_v2
> > > 
> > Hmmm.  I think we need to key off the tty 'attach' event instead of
> > the
> > devfs 'create' event.  The tty attach for a usb device is the one
> > event
> > that has all the info we need in one message.  This is assuming the
> > device name in dmesg on attach is u3g0 or u3g1 or whatever.
> > 
> > attach 100 {
> >         device-name             "(u3g)[0-9]+";
> >         match "vendor"          "0x04da";
> >         match "product"         "0x250e";
> >         action "/usr/local/bin/gobi_loader /dev/cua$ttyname
> > /boot/firmware/gobi/";
> > };
> > 
> > The way I arrived at this conclusion was to first look in the devd
> > source to figure out/remind myself that devd creates variables from
> > all
> > the tag=value tuples it finds in the events coming from the kernel.
> >  Then I connected to devd using netcat so I could watch the events
> > as
> > they happen:
> > 
> >   nc -U /var/run/devd.pipe
> > 
> > then I plugged in a usb-serial adapter (I have no u3g stuff), which
> > creates a whole lot of events.  The last one was the tty attach:
> > 
> > +uplcom0 at bus=1 hubaddr=1 port=1 devaddr=2 interface=0
> > ugen=ugen1.2
> > vendor=0x067b product=0x2303 devclass=0x00 devsubclass=0x00
> > devproto=0x00 sernum="" release=0x0300 mode=host intclass=0xff
> > intsubclass=0x00 intprotocol=0x00 ttyname=U0 ttyports=1 on uhub1
> > 
> > The '+' means it's an attach, the "device-name" variable is set
> > from
> > the space-delimited word after the +, and then vars are created
> > from
> > all the tag=value tuples between 'at' and 'on'.  So that gives us
> > the
> > info to match product and vendor, and ttyname is the suffix to
> > append
> > to /dev/cua to make the cdev name.
> > 
> > -- Ian
> Awsome! That works!! Thank you Ian!! Thank you for pointing out how
> that was achieved! :-)
> 
> Is there any way to echo something out to the console to notify user
> that firmware is being updated? This takes some time and it would be
> nice to see something happens in the background.. I cannot see
> anything with action "logging blah"; maybe no need for that?
> 

I think you can use logger(1) in the action, like:

  action "logger -p kern.crit Loading firmware to cua$ttyname ;
    /usr/local/bin/gobi_loader etc etc"

The 'kern.crit' should be a high enough priority to ensure it comes out
on the console, but it depends on syslog.conf of course.  If
gobi_loader outputs a nice message it could be piped to logger(1)
instead of putting the message in the command.

-- Ian