Re: umodem0, Cisco USB serial console, and quirks

[Mike Andrews]

On Tue, 19 Sep 2017, Hans Petter Selasky wrote:


On 09/19/17 18:15, Mike Andrews wrote:
 
12:03:37.726830 usbus4.3 SUBM-BULK-EP=0082,SPD=FULL,NFR=1,SLEN=0,IVAL=0

  frame[0] READ 1024 bytes
  flags 0xa 
  status 0xcf023


Hi,

Look for:

-BULK-EP=0082

This is the USB read transfer. The other side is not returning any data, so 
neither is "cu" printing anything. Maybe you can try to get a similar trace 
from the system where it works?


Looks to me like some kind of protocol error, that the Cisco USB serial 
console needs some kind of activation.


Took me a few days to get around to getting usbmon going on Linux.  The 
verbose dump is too large for the list, so:


   https://www.bit0.com/tmp/usbmon-ciscoasa-verbose.txt
   https://www.bit0.com/tmp/usbmon-ciscoasa.txt
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

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

[Tomasz CEDRO]

Its all commented out, just an example on how to configure "this kind
of device".. not really mandatory but nice to have I thought :-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

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

[Ian Lepore]

On Wed, 2017-09-27 at 00:30 +0200, Hans Petter Selasky wrote:
> On 09/27/17 00:11, Tomasz CEDRO wrote:
> > 
> > https://github.com/freebsd/freebsd/pull/115
> > 
> > :-)
> > 
> The devd.conf rule should match more than just vendor and product:
> 
> 
> +# Load GOBI 2000/3000 U3G QDL modem firmware on attach / boot.
> +# Note: This requires additional "gobi_loader" utility to be
> installed,
> +#   as well as valid QDL driver firmware files placed in 
> /boot/firmware/gobi.
> +#   If modem does not accept valid firmware try gobi_loader -2000
> switch.
> +#   Please adjust modem VID/PID to match your device supported by
> u3g 
> module.
> +#attach 100 {
> +#match "vendor" "0x04da";
> +#match "product" "0x250e";
> +#action "/usr/local/sbin/gobi_loader /dev/cuaU0
> /boot/firmware/gobi/";
> +#};
> 
> Else patch looks good.
> 
> --HPS

Hard-coding /dev/cuaU0 cannot possibly be right.

-- Ian
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

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

[Hans Petter Selasky]

On 09/27/17 00:11, Tomasz CEDRO wrote:

https://github.com/freebsd/freebsd/pull/115

:-)



The devd.conf rule should match more than just vendor and product:


+# Load GOBI 2000/3000 U3G QDL modem firmware on attach / boot.
+# Note: This requires additional "gobi_loader" utility to be installed,
+#   as well as valid QDL driver firmware files placed in 
/boot/firmware/gobi.

+#   If modem does not accept valid firmware try gobi_loader -2000 switch.
+#   Please adjust modem VID/PID to match your device supported by u3g 
module.

+#attach 100 {
+#  match "vendor" "0x04da";
+#  match "product" "0x250e";
+#  action "/usr/local/sbin/gobi_loader /dev/cuaU0 /boot/firmware/gobi/";
+#};

Else patch looks good.

--HPS
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

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

[Tomasz CEDRO]

https://github.com/freebsd/freebsd/pull/115

:-)

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB Device self-umount

[Polytropon]

On Tue, 26 Sep 2017 22:52:28 +0200, Tomasz CEDRO wrote:
> I will have to see how Windoze handles ATAPI EJECT, maybe that could
> bring some insight on how to umount ejectable media triggered by the
> device-eject-button-press..

Hmmm... I don't think this is what happens. ATAPI EJECT is issued
by the OS (ATAPI device driver) and the device simply ejects. If
this action is "prefixed" with an unmount() call and a certain
delay, everything is well. This is how a typical GUI file manager
on Linux or FreeBSD works. But pressing the device's eject button
will simply eject the media. Subsequent TUR inquiries by the OS
will result in "device not ready", and that may cause the umount()
call, but _after_ the device has been removed.



> As for now the device reports CHECK-CONDITION to mark media missing,
> then reboots and re-appeares, but that causes "device not cleanly
> unmounted" warnings on macOS for instance..

Of course it does. :-)

With filesystems mounted read-only, this typically isn't a problem,
but those with read-write access might be left in an inconsistent
state, and depending on the OS, cannot be mounted again (or require
a run of fsck, or in case of "Windows", a kind of "repair" that
often leads to data loss and corrupted files).

Examining the USB traffic and checking for the CAM packets exchanged
between the device and the OS could help you find a way to implement
the impossible. ;-)




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB Device self-umount

[Tomasz CEDRO]

Hey Polytropon! :-)

Thanks for ideas! I am at the moment at point where I sniff out the
USB traffic and analyze SCSI packets.. and also I got into SCSI
specification to search for some possibilities.. :-)

I will have to see how Windoze handles ATAPI EJECT, maybe that could
bring some insight on how to umount ejectable media triggered by the
device-eject-button-press..

As for now the device reports CHECK-CONDITION to mark media missing,
then reboots and re-appeares, but that causes "device not cleanly
unmounted" warnings on macOS for instance..

Will report back when I find anything interesting :-)

Best regards! :-)
Tomek

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

Re: USB Device self-umount

[Polytropon]

On Tue, 26 Sep 2017 16:30:48 +0200, Tomasz CEDRO wrote:
> The question is how to gracefully self-umount from a device point of
> view in a way not to confuse automounter and/or usb / mass storage
> drivers? Is there any way of doing that in SCSI+USB? Something like
> CD-ROM eject, then device removal..

This is a _very_ good question of high relevance which hasn't been
solved across many operating systems. :-)

Basically, a normal (clean) unmount can only be initiated by the OS.
You can program the controller (on the USB device) to disconnect on
its own, but that doesn't cause the OS to call unmount(), it just
makes the device disappear.

One thing I could imagine is the use of SCSI status messages and
a modified (!) storage access driver in the OS which could act upon
a specific status code with a call to unmount(), but that is, as far
as I know, not implemented yet anywhere.

The primary problem with disconnecting is that it happens _before_
the unmount() call, and keep in mind that unmounting also requires
some time. The OS can issue a certain direct access action, but it's
up to the device to perform that action. Until it has successfully
been performed, the device may not be deconnected.

Timing is hard. :-)

For CD-ROM, or optical media in general, it's not a problem because
it's read-only. The CAM EJECT command - again issued by the OS, not
by the device -, when performed _before_ unmount, leaves the OS in
a problematic state: Something is still mounted, but it doesn't
exist anymore. Okay, umount -f, no damage done. But with read-write
media such as USB direct access storage... well... that looks much
more complicated.

That's why you alway unmount first, then wait, then disconnect.
Sorry I couldn't provide more helpful suggestions... ;-)





-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"

USB Device self-umount

[Tomasz CEDRO]

Hello world! :-)

I am working on a device that implements USB MSC mass storage for
firmware programming [1]. After receiving file, it flashes the
firmware image to the target MCU, then reboots and starts the program
or waits debug session..

The question is how to gracefully self-umount from a device point of
view in a way not to confuse automounter and/or usb / mass storage
drivers? Is there any way of doing that in SCSI+USB? Something like
CD-ROM eject, then device removal..

Any hints appreciated :-)
Tomek

[1] https://github.com/mbedmicro/DAPLink

-- 
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
___
freebsd-usb@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"