python / pyusb / libusb
Hello world :-) Was there any substantial change in LibUSB / USB implementation in FreeBSD stacks? I mean somewhere around 12.1 -> 12.2 upgrade? I have this nice pyOCD hardware debug utility that I use for embedded systems debug for my everyday work. It started to segfault Python. All of its versions even those older ones that worked fine before. So far I could flash firmwares using other channel (UMS mass storage function of the debug probe and it works fine), but I am getting to a point where I need to debug target and it seems blocked for now. I also reported this issue to the application tracker, but it may as well look as problem on the OS side. This is strange because for instance Yubikey that uses the same Python environment works fine. I have used hardfault module to backtrack Python crash :-) (venv37zephyr) pyocd list Fatal Python error: Segmentation fault Current thread 0x000800a3a000 (most recent call first): File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/usb/backend/libusb1.py", line 611 in __init__ File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/usb/backend/libusb1.py", line 644 in __iter__ File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/usb/core.py", line 1280 in device_iter File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.28.1.dev97+dirty-py3.7.egg/pyocd/probe/pydapaccess/interface/pyusb_v2_backend.py", line 184 in get_all_connected_interfaces File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.28.1.dev97+dirty-py3.7.egg/pyocd/probe/pydapaccess/dap_access_cmsis_dap.py", line 68 in _get_interfaces File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.28.1.dev97+dirty-py3.7.egg/pyocd/probe/pydapaccess/dap_access_cmsis_dap.py", line 471 in get_connected_devices File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.28.1.dev97+dirty-py3.7.egg/pyocd/probe/cmsis_dap_probe.py", line 73 in get_all_connected_probes File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.28.1.dev97+dirty-py3.7.egg/pyocd/probe/aggregator.py", line 64 in get_all_connected_probes File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.28.1.dev97+dirty-py3.7.egg/pyocd/core/helpers.py", line 82 in get_all_connected_probes File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.28.1.dev97+dirty-py3.7.egg/pyocd/core/helpers.py", line 109 in list_connected_probes File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.28.1.dev97+dirty-py3.7.egg/pyocd/__main__.py", line 462 in do_list File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.28.1.dev97+dirty-py3.7.egg/pyocd/__main__.py", line 402 in run File "/home/cd/usr/local/venv37zephyr/lib/python3.7/site-packages/pyocd-0.28.1.dev97+dirty-py3.7.egg/pyocd/__main__.py", line 931 in main File "/home/cd/usr/local/venv37zephyr/bin/pyocd", line 11 in Segmentation fault Any hints welcome :-) 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 reset fails when using a LimeSDR Mini on FreeBSD
Thank you guys for trust and hints, I will be able to get into this around August, sorry, I am a bit overworked at the moment, I have some backlog waiting for FreeBSD already :-) -- 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 reset fails when using a LimeSDR Mini on FreeBSD
pt., 3 lip 2020, 11:15 użytkownik Hans Petter Selasky napisał: > > Second would allow user for example to unload ucom driver that is > attached > > to a device which does not seem possible right now and causes problem > with > > i.e. pyOCD / some debug probes. > > Currently we use PRIV_DRIVER in the USB stack. Not sure how a user gets > PRIV_DRIVER rights. > > Tomasz: Feel free to suggest a patch for this after testing. > Thank You HPS :-) -- 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 reset fails when using a LimeSDR Mini on FreeBSD
pt., 3 lip 2020, 10:10 użytkownik Hans Petter Selasky napisał: > > I see three possible approaches currently: > > > > 1. Allowing a USB reset if the user has access to /dev/ugenX.Y (might > > allow users to mess with kernel's operation on a device, unless the > > problem exists anyway, see my questions above). > > > > 2. Allowing a USB reset if the user has access to /dev/ugenX.Y and > > there are other prerequirements fulfilled (e.g. a sysctl setting to > > enable it globally, which might not be fine-graded enough, or the > > requirement that there is currently no kernel driver attached, or a > > combination thereof). > > > > 3. Providing a way to grant "reset permissions" on a per-device basis > > (might be overkill, and not really needed). > > > > Maybe you're right we should allow this for non-root aswell. I need to > think about it! > +1 for user enabled actions like usb reset and kernel driver detach :-) maybe based on a sysctl like usermount, i.e. usb_allow_user_device_reset and usb_allow_user_kernel_driver_detach..? One would allow user to reset a usb device. This is sometimes required to restore device or change its configration. Second would allow user for example to unload ucom driver that is attached to a device which does not seem possible right now and causes problem with i.e. pyOCD / some debug probes. 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 reset fails when using a LimeSDR Mini on FreeBSD
Another idea: are you sure you are using valid usb cable and capable usb port? Please try with another short length certified cable and use direct usb 3.0 port with no usb hub. Cables and HUBs (even those built-in) are the most common problem :-) -- 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 reset fails when using a LimeSDR Mini on FreeBSD
On Sat, Jun 27, 2020 at 2:44 PM Jan Behrens wrote: > The question is: Is it correct or wise to return an error status of -99 > (LIBUSB_ERROR_OTHER) when the function is called as non-root? Maybe > it's possible to return a more fitting error code? Also note that the > debug level was set to 3, and there was still no hint written to stderr > about any privilege problem: > > #if LIBUSBX_API_VERSION < 0x01000106 > libusb_set_debug(ctx, 3); //set verbosity level to 3, as suggested in the > documentation > #else > libusb_set_option(ctx, LIBUSB_OPTION_LOG_LEVEL, 3); //set verbosity level > to 3, as suggested in the documentation > #endif > > Source: > https://github.com/myriadrf/LimeSuite/blob/1c1c202f9a6ae4bb34068b6f3f576f7f8e74c7f1/src/ConnectionFTDI/ConnectionFT601Entry.cpp#L40 I guess the FreeBSD's LibUSB implementation should be one-to-one compatible with the GNU LibUSB. I would try to test and compare it with Linux and MacOS implementation and see the difference: 1. If the problem exists on FreeBSD, Linux, MacOS. If so/no then if there are different error messages / codes. If there are more verbose codes / messages on systems other than BSD then FreeBSD's implementation may need an update. However, the difference here seems to be the USB stack itself. 2. If that function blocks normal operations on FreeBSD while without it everything works fine, then it may be wrapped around ifdef and simply removed for FreeBSD. 3. Make sure this is not a bug in the LimeSDR firmware that makes this non-standard behaviour. 4. According to `man usbconfig` reset will perform "Reset the device. This forces the USB stack to reenumerate the bus.". If LimeSDR uses some dynamic USB interfaces configuration and re-organizes itself at runtime then I would observe how the FreeBSD USB stack reacts to that changes. Such reset may not be even necessary by hand (or from libusb) if the OS re-enumerates the bus for you. Maybe on other OS it is important to call that libusb reset to make sure the bus is re-enumerated. @HPS is the author of the USB stack so he could provide some hints.. but without actually seeing the device it can be hard to achieve :-) > > When in trouble always try to test at root especially when working with > > hardware. That may pinpoint the permissions issuses (not only /dev/usb* > > permissions). > > You are right, of course. As "chown user /dev/usb/2.2.*" made a > difference (and there wasn't any hint about a privilege problem), I > wrongly assumed that it was not a privilege problem. I'll know better > next time. > > Another question that I still have no clear answer to is: Is it > semantically correct to use libusb_reset_device() in the Lime Suite > driver for SoapySDR. The driver runs in the context of user > applications which likely have no root privileges (for a good reason). > I also don't know yet why this library call is made in the driver, and > which purpose it has. See also my most recent post on the myriadrf.org > discussion forum: > > https://discourse.myriadrf.org/t/limesdr-mini-with-freebsd/6230/8 > > I wrote: > > "I wonder if FreeBSD’s libusb should (and/or could) be fixed to ensure > libusb_reset_device() can be run as non-root user, or if the Lime Suite > should be fixed to not call libusb_reset_device() at all because it > might be an administrative call that should never be used by a user of > a USB device. I’m not sure what’s right to do. Particularly, I don’t > know why the Lime Suite developers included that call, and I don’t even > fully understand (yet) what it does." /dev/usb* are userland "access points" to the USB devices. They may be accessed by the user according to the filesystem permissions. Some stack level operations on the USB bus/port/hub may only be accessible to the root user. Are you sure this is the problem? When run as root does the program works fine? If so, there may be a systctl setting for the stack that may allow user to reset / power-on-off the port (@HPS?)? You may want to take a look at `sysctl -a | grep usb` to search for such sysctl option. Maybe also `man usbconfig` and `man usb`. > > > What I don't understand is that the Lime Suite SoapySDR module seems to > > > work fine on Linux and other operating systems but makes trouble with > > > FreeBSD. Is it a FreeBSD specific thing that libusb_reset_device() > > > fails if called as non-root? Again, if you are sure that this is the problem, there may be a sysctl that could set USB stack to allow non-root users to reset / power-off-on the ports - @HPS can you give a hint please? :-) > > Linux as well as other operating systems usually uses dirty and quick > > hacks. FreeBSD treats standards seriously and usually does not have these > > kind of dirty hacks. This is the first difference. Second difference is > > that FreeBSD has its own implementation of LibUSB. There may be a problem > > here bu that would require detailed investigation and proofs. Very nice > > exercise to perform :- > > I
Re: USB reset fails when using a LimeSDR Mini on FreeBSD
pt., 26 cze 2020, 17:28 użytkownik Jan Behrens napisał: > Does this mean that depending on the device, it will either be a > no-operation or a re-enumeration, and in the latter case, root > privileges are required, otherwise not? > > Or did you mean that if you are non-root, it will/should always be a > no-operation? > I guess that root is required for some administrative operations like port reset etc that are not really possible to achieve even through /dev/usb* permissions. When in trouble always try to test at root especially when working with hardware. That may pinpoint the permissions issuses (not only /dev/usb* permissions). What I don't understand is that the Lime Suite SoapySDR module seems to > work fine on Linux and other operating systems but makes trouble with > FreeBSD. Is it a FreeBSD specific thing that libusb_reset_device() > fails if called as non-root? > Linux as well as other operating systems usually uses dirty and quick hacks. FreeBSD treats standards seriously and usually does not have these kind of dirty hacks. This is the first difference. Second difference is that FreeBSD has its own implementation of LibUSB. There may be a problem here bu that would require detailed investigation and proofs. Very nice exercise to perform :- I could give recommendation to the Lime Suite developers to remove the > libusb_reset_device() call on FreeBSD systems if it is not neccessary. > However, I would like to understand why it is called and what's its > usual purpose, and if there are side effects when removing the call, or > whether the call should/could be replaced by a different call that > "only" requires device privileges. Also: Why does this work on Linux > but fails on FreeBSD? Is the API differently defined? Very good approach to understand what is the problem and fix it rarher than using dirty hacks just to make things work :-) What particular LimeSDR device do you have? Is it expensive? Can you share a spare one for testing? Can you acquire access to hardware USB sniffer? 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 System hangs after removing Yubikey
On Sat, Jun 20, 2020 at 7:22 PM Hans Petter Selasky wrote: > On 2020-06-20 19:03, Joseph Ward wrote: > > Can anyone propose any other troubleshooting steps I should take? > Try doing "procstat -akk", maybe some process is simply not exiting > properly freeing the handle it has got for the USB device. > --HPS I am using Yubikey with gpg-agent and sometimes I have to kill -9 that guy because it hangs but not the whole system :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info -- 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: arduino usb/com port issue
On Mon, Jun 1, 2020 at 5:28 PM Ian Lepore wrote: > There should be no need to unload ucom to access the low-level usb > device via libusb. I typically have anywhere from 5-8 usb-serial > adapters connected at once, it would be crazy to unload ucom and lose > access to all of them just to use one of them with libusb. > > It is important, however, to avoid accessing /dev/cuaU# or /dev/ttyU# > at the same time that some application is using libusb (or libftdi) to > access that same device. That would cause ucom and the work being done > via libusb to conflict with each other. Exactly the problem here. Either application tries to unload kernel driver just to make sure terminal can connect to a dongle (linux quickfix), or the modem port is already opened with u3g module (more probable scenario). Anyway CMSIS-DAP has its own endpoint that is separate from VCP so it should work without unloading the module. Will verify and send patches to the upstream no worries, thanks for the hints, but that could be another source of problem described by Gary that I found in a similar application :-) -- 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: arduino usb/com port issue
On Sun, May 31, 2020 at 11:45 PM Gary Aitken wrote: > >>> I installed the arduino package on an 11.3-RELEASE system. Message from arduino-1.0.6_3,1: "-- Notes on using the Arduino IDE: To allow serial port locking, add your user to the dialer group: pw groupmod dialer -m myuser (..)" Did you add your user to the dialer group? That would allow to you to access modem/vcom devices which seems exactly what you need. The modem device is /dev/cuaU* for USB-Virtual-COM-Ports :-) > >> Did you check the permissions on /dev/usb/XXX ? > > These are all set to crw--- > I tried changing all to crw-rw-rw- but still no arduino success How about /dev/cuaU* ? > > ***/etc/devfs.rules: [localrules=10] add path 'ugen*' mode 0660 group > > operator add path 'usb/*' mode 0660 group operator add path 'usb' > > mode 0770 group operator > > > > ***/etc/rc.conf: devfs_system_ruleset="localrules" > > $ cat /etc/rc.conf | grep devfs > # allow local rules as specified in /etc/devfs.rules (5) > devfs_system_ruleset="localrules" > > $ cat /etc/devfs.rules > # Allow operator group to mount USB devices > [localrules=5] > add path 'da*' mode 0660 group operator > # for arduino hotplug USB > add path 'ugen*' mode 0660 group operator > add path 'usb/*' mode 0660 group operator > add path 'usb' mode 0770 group operator Either try adding your user to the dialer group as instructed by the post-install package message (this is the preferred method, note you need to logout and login after that), or add `add path 'cuaU*' mode 0660 group operator` as another rule in /etc/devfs.rules so you will gain access to the /dev/cuaU* files as needed if that method works for you with other devices :-) You can restart devfs with `service devfs restart` as root no need to reboot :-) > I don't understand the need for MINICOM. I currently use xterm. > Will that work for the print output? MINICOM can talk to the /dev/cuaU0 and other serial ports like this so you can test if communication works with your device if other software fails :-) Good luck and have fun! :-) 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: arduino usb/com port issue
On Sun, May 31, 2020 at 7:54 PM Hans Petter Selasky wrote: > > On 2020-05-31 18:55, Gary Aitken wrote: > > It's not clear to me if this is the right place for this or not; please > > let me know if not. I originally posted on questions and got no response. > > > > I installed the arduino package on an 11.3-RELEASE system. When > > it comes up, the Tools/Serial Port menu item is greyed out, > > apparently because it doesn't know USB ports serve as com ports, > > or for some reason it can't find them. Is this something I need to > > configure somehow? Is this something that should be filed as a > > bug? > > > > Thanks for any clues, > > > > Did you check the permissions on /dev/usb/XXX ? > > And output from usbconfig > > --HPS Hey Gary, Hey HPS :-) I am using /dev/cuaU0 USB VCOM Port with success for years on FreeBSD, even today it works fine with ARM DAPLink debug probe :-) As HPS noted in the first place check if you have valid permissions that allow you to read/write from/to usb device. I did a hint at the OpenOCD port: /usr/ports/devel/openocd/pkg-message To allow an ordinary user to acces any of the the hotplug USB interface add him/her to the operator group (pw groupmod operator -m username), then setup the devfs subsystem by adding these lines to the following files: ***/etc/devfs.rules: [localrules=10] add path 'ugen*' mode 0660 group operator add path 'usb/*' mode 0660 group operator add path 'usb' mode 0770 group operator ***/etc/rc.conf: devfs_system_ruleset="localrules" I use MINICOM as the Terminal emulator. Type Ctrl+A then Z for command menu. Note that you will have to create a configuration for a given port in the first place (as root type `minicom -s /dev/cuaU0` set valid port name and parameters then save as the default configuration for that port). I did not use that particular Arduino utility, but there may be a chance that it was written for Linux and it may suggest port name like /dev/ttyUSB0 instead /dev/cuaU0 as it is used in FreeBSD. In general on FreeBSD COM port over USB (aka Virtual-COM-Port) is handled by `ucom` kernel module (type `kldstat` to list loaded kernel modules), also it may use `umodem` or even `u3g` module. Those modules are loaded by `devd` system daemon based on USB descriptors when you plug a device. I just found a bug in pyOCD (Python module for ARM CPU debug) that prevents running GDB Server when `ucom` module is loaded for the VCP port on that board. pyOCD tries to unload the kernel module by default to gain access to the VCP using LibUSB but it lacks permissions to do so and the whole program stops with an exception. In that case simply unload selected modules and `service devd stop` for the time of testing. This may be also the case for you: 1. You lack permissions to access a resource so temporary try run as root and see if that works. 2. You may require some component that is already taken by other service/application. Note: It is not wise to run as root networked enabled applications even though are "only meant" for electronics development, so try to configure your system so it runs such applications without root :-) Have fun! :-) 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: pendrive clone impossible ?
As my previous message got moderated, just a quick summary - looks like a GEOM_PART silently discards writes to MBR with a DD when it considers MBR broken (writing to the rest of the disk is possible). I have reported this as error: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242341 -- 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: pendrive clone impossible ?
On Sun, Dec 1, 2019 at 8:28 AM Scott Bennett wrote: > >Does GEOM in any way prevents me from using disk that has corrupt MBR? > Yes, most likely. > > >Why I cannot write a MBR from a file but I can from a md0? > >Any hints welcome :-) > See the last line of your messages below. > (..) > >ugen0.8: at usbus0 > >umass1 on uhub0 > >umass1: on > >usbus0 > >umass1: SCSI over Bulk-Only; quirks = 0x8100 > >umass1:3:1: Attached to scbus3 > >da1 at umass-sim1 bus 1 scbus3 target 0 lun 0 > >da1: Removable Direct Access SPC-4 SCSI > >device > >da1: Serial Number BLAHBLAH > >da1: 400.000MB/s transfers > >da1: 118272MB (242221056 512 byte sectors) > >da1: quirks=0x2 > >GEOM_PART: integrity check failed (da1, MBR) > There is your hint, courtesy of > | || FreeBSD's GEOM_PART kernel > class. Hello Scott and thank you for your valuable input. If you are sure that this is NOT a problem of a pendrive or anything USB related with that particular pendrive (i.e. some quirk required for valid operations), and you ARE sure that this is a matter of GEOM, then: 1. OS / GEOM is hiding things from operator. It does not write bytes as instructed to fix the disk, instead, it considers disk invalid and silently discards _only_some_of_the_data_ with no clear error/warning indication. Unacceptable!!! 2. OS / GEOM lies to operator. It does return a SUCCESS code while _some_ data goes to /dev/null. Unacceptale!!! 3. If disk is _considered_ broken then access should be _fully_ blocked. But how am I supposed to fix it when OS silently blocks essential part of the fix? Who allows writing over a corrupted disk anyway? 4. OS / GEOM is broken and incoherent in this area and proves system unreliable / not trustworthy. This needs to be fixed please. Will report a bug. That "irrelevant blather" just proves above. OS cannot silently interfere with operator actions and do whatever it likes. Other people also noticed this problem. This is not the FreeBSD way, looks more like Linux way. Now it looks like the factory pre-format pendrive was considered invalid by GEOM, this is why the initial `dd if=/dev/da0 of=/dev/da1` copied _almost_ whole data but without MBR. Then the situation escalated - MBR dumped to a file could not be written to a target drive, but it could be written from a md0 device, and all sorts of black magic. It THIS IS UNACCEPTABLE!!! When I DD something from IF then it must get untouched into OF, unless missing privilege or hardware failure error is clearly reported preventing further actions. Damn, the DD is the simplest thing in Unix. Either I get the command executed exactly as instructed, or not executed at all. The return code is here to say what happened. Error is here to show me something is wrong. As simple as that. Now it looks like the disk is okay, just GEOM did some interpretation, knew better what I want to, and did, without telling me that. Imagine there were some really sensitive backups on the drive and system decided only to copy selected parts of them with no error. Not a problem for you? 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: pendrive clone impossible ?
On Sun, Dec 1, 2019 at 3:03 AM Anatoly wrote: > I've had a problem in the past with one of the first 32GB pendrives. > Not quite similar problem, but may it be buggy RAM cache > implementation too? What if: > - Write sector(s) > - usbconfig -d . power_off > - usbconfig -d . power_on > - Read and compare. > > As you saying some writes was succeful, some not. May it > depend not on source of that bytes or their content, but on time passed > between write and read? > > It turns out that Transcend pendrive I've got in 2010 had RAM cache > (didn't remember exact cache size I measured out, as I remember > something around 128K-512K), and all writes was cached. This amazingly > speeds up random R/W fs operations in comparation with similar > pendrives of those years, but I constantly losing the data and getting > fs corrupted when used it with OSes that do not "power_off" or > "suspend" that drive before I pull of it out of the socket. The first pendrive is physically smaller Kingston slower and more expensive. The second Kingston (the one with write problems) is physically bigger 30% cheaper and a bit faster (50% read, 10% write, but not as advertised 2x read, 4x write). If its cheaper and faster then Kingston is bullshitting their clients. Also one of their workers admitted that they have various vendors of flash controllers and different firmware among them. so their products looks more like a lottery. Not cool. Thank you Anatoly! It looks then like a pendrive faulty tricky design to fool users with exaggerated read/w/rite speeds. -- 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: pendrive clone impossible ?
On Sat, Nov 30, 2019 at 11:49 PM Polytropon wrote: > > On Sat, 30 Nov 2019 23:28:04 +0100, Tomasz CEDRO wrote: > > It looks like either GEOM is hiding something from application/me, or > > pendrive itself is preventing MBR to be modified, or some sort of > > mix..? > > That is possible (but unlikely), and there's another (equally > unlikely) possibility that your computer has some "boot sector > virus protection" activated in the BIOS which prevents writes > to block 0 of a device... Nope, I also though about that, buy would have noticed that, and the problem did not show up with any other device, while I am really cloning lots of drives for servicing/backup purposes :-) > > I guess the first is more probable because DD'ing from /dev/md0, > > /dev/zero, /dev/random devices always works, while DD'ing from da0.mbr > > file never works. If pendrive was defending itself none of them would > > be possible, right? > > Yes, that's at least my impression. Can you provide an error > message of dd, or does it say "blocks copied", but no MBR data > actually arrived on the USB stick? no error at all. just blah bytes transferred in blah seconds (blah bytes / second). > > The Source pendrive was MBR. This is why I did /dev/zero -> /dev/da1 > > just to make sure there is no GPT of any sort on the Target pendrive, > > nor MBR, also I could see where write was skipped. > > Okay, so you can _confirm_ that there is MBR (partition table > with "DOS primary partitions") in it - good. In that case, > using gpart or fdisk to read the MBR should work definitely > for the source stick - and should also work for the target stick > after the MBR has been written correctly. Yes. Source pendrive works and worked fine for several months on dozens of machines connected with no problem. Target pendrive was advertised to be faster so I just wanted to clone the data to a faster device ;-) > If you use something like > # dd if=/dev/da0 of=/dev/da1 bs=1M > i. e., a block size typical for such media, does it make any > difference? Not copying 512 bytes is one thing, but not copying > a much larger block - 1 MB - with the 512 bytes at its beginning, > that would be _really_ strange. I usually use "bs=1000m" or "bs=500m" with "status=progress" for a large drives because that allows optimal performance and progress tracking.. so I guess the bigger block size has already been tested :-) > If you dd the 1st 512 bytes out of the source and the target and > compare them, are they identical? They _should_, according to what > dd reports. > > # dd if=/dev/da0 of=/dev/da1 bs=512 count=1 That did not copy the DA0 MBR to DA1. > # dd if=/dev/da0 of=da0.mbr bs=512 count=1 That did copy DA0 MBR to a file. > # dd if=/dev/da1 of=da1.mbr bs=512 count=1 That did copy DA1 MBR to a file. > # diff da0.mbr da1.mbr Looking with `less -f` when the copy was done the contents was the same, when copy was not done I could see the difference because of writing zeros prior. > You can then repeat this test with a bigger block: I did a copy whole disk data from one to another using much more bigger blocks like 100M 500M and 1000M.. no change. > In any case, there should be _no_ difference (no matter if the > partitions themselves are incomplete and unreadable on the target > stick). Yes, I think so too. > > Because I need to finish quickly, I have used GPART to create and add > > partitions by hand and I am DD'ing partition by partition. So far so > > good. > > In case they are UFS partitions, you could newfs the target > partition, and then use dump | restore - I don't know if this > is faster, but it would work as well. I just have one big FAT32 storage partition for files, one bootable FreeBSD LiveCD/Installed copied from a memstick image, and one Kali Linux bootable image just in case ;-) > Next idea is for them to put some "AI/ML anti virus malware" into > the firmware of the USB stick that accepts data, returns "written" > to the writer, but doesn't actually write anything to its storage, > because... we need to protect the users! :-) Well, I need to stop at assumption that this particular Kingston line of pendrives are messy and should be avoided, maybe some quirk could do the job, but I have no more time to play, so I leave a trace if someone meets similar issues in future :-) > Rule: > If it stops you to do stupid things, it also stops you to do clever > things, and most things we do in UNIX world are usually not invented > elsewhere. :-) This is why I do not respect these modern UX "researchers" that removed menu from a GIMP toolbar "because no other program works that way"
Re: pendrive clone impossible ?
It looks like either GEOM is hiding something from application/me, or pendrive itself is preventing MBR to be modified, or some sort of mix..? I guess the first is more probable because DD'ing from /dev/md0, /dev/zero, /dev/random devices always works, while DD'ing from da0.mbr file never works. If pendrive was defending itself none of them would be possible, right? The Source pendrive was MBR. This is why I did /dev/zero -> /dev/da1 just to make sure there is no GPT of any sort on the Target pendrive, nor MBR, also I could see where write was skipped. This is the first time ever dd if=/dev/da0 of=/dev/da1 did NOT copy the entire drive (the da1 attached GEOM noted inegrity checked MBR was left blank the rest seems to be there). DD reported NO ERROR.. in fact I got a standard summary on transferred bytes as operation was completed successfully. I did not count all bytes transferred because I never had to before. Is the OS hiding something from me? And from DD? Is Penrdive messing with the GEOM / OS? Because I need to finish quickly, I have used GPART to create and add partitions by hand and I am DD'ing partition by partition. So far so good. The Target pendrive is Kingston 128GB DTSE9 G2 USB3.0. Be careful with that fellow! Below is a Kingston's response cut-and-paste found on a forum where another folk tried to install bootable system on a 32GB DTSE9 G2 ;-) " The first thing to point out is that a USB drive needs to be set as a fixed drive which requires a tweak in the firmware, commonly refereed to as "flipping the RMB". Not every firmware is suitable for such an operation and since we use different flash controller providers to meet the supply and demand for our products, we cannot check the suitability of every firmware to be altered to accomodate booting from USB. Furthermore a standard USB drive is designed for sequential read and writes, rather than random read and write speeds. Booting from the USB will be very slow and will be a detriment to the product, affectively its longevity. Therefore we cannot guarantee the longevity and reliability of the drive within the warranty period, and could offer no further support in case of a drive failure. This is the reason why we at Kingston do not support the bootability of our commodity USB products. If you purchased the DTSE9G2/32GB to be used specifically for this purpose, we can only recommend that you return it to your supplier for a refund and we apologise for any inconvenience this may cause. " WELL, KINGSTON LOOKS LIKE A LOTTERY AND I FEEL LIKE A WINNER! ;-) -- 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"
pendrive clone impossible ?
Hello world :-) I have to clone a pendrive, the same one to another almost the same (number of sectors differs a bit). The problem is that DD does not seem to do the job. It always worked for me. Also I am not really able to clone the MBR: 1. dd if=/dev/da0 of=/dev/da1 bs=512 count=1 does not copy anything. 2. dd if=/dev/zero of=/dev/da1 bs=512 count=1 zeroes the mbr. 3. dd if=/dev/random of=/dev/da1 bs=512 count=1 randoms the mbr. 4. dd if=/dev/da0 of=da0.mbt bs=512 count1; dd if=da0.mbr bc=512 count=1 does NOT copy the mbr. 5. mdconfig -a -tvnode da0.mbr; dd if=/dev/md0 of=/dev/da1 bc=512 count=1 does put the data into mbr, but still da1 seems to have no partitions!!! In such Black Magic situations I usually put /dev/zero on a target disk, just to make sure MBR and GPT are not messed/mixed up, then re-tried and things worked. Not this time. While size of the drives differs a bit, the last partition contains FreeBSD LiveCD image and is much smaller than the partition so it can be truncated with no problem because there are zeros after. Does GEOM in any way prevents me from using disk that has corrupt MBR? Why I cannot write a MBR from a file but I can from a md0? Any hints welcome :-) Tomek # gpart backup da0 | gpart restore -F da1 gpart: size '17575936': Invalid argument ugen0.7: at usbus0 umass0 on uhub0 umass0: on usbus0 umass0: SCSI over Bulk-Only; quirks = 0x8100 umass0:2:0: Attached to scbus2 da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: Removable Direct Access SPC-4 SCSI device da0: Serial Number BLAHBLAH da0: 400.000MB/s transfers da0: 118368MB (242417664 512 byte sectors) da0: quirks=0x2 ugen0.8: at usbus0 umass1 on uhub0 umass1: on usbus0 umass1: SCSI over Bulk-Only; quirks = 0x8100 umass1:3:1: Attached to scbus3 da1 at umass-sim1 bus 1 scbus3 target 0 lun 0 da1: Removable Direct Access SPC-4 SCSI device da1: Serial Number BLAHBLAH da1: 400.000MB/s transfers da1: 118272MB (242221056 512 byte sectors) da1: quirks=0x2 GEOM_PART: integrity check failed (da1, MBR) FreeBSD 0xCFMX4 12.1-RELEASE-p1 FreeBSD 12.1-RELEASE-p1 GENERIC amd64 -- 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: Installing FreeBSD 12.1 on XPS 8930
On Thu, Nov 14, 2019 at 6:34 PM Jerry wrote: > I am trying to install FreeBSD 12.1 onto a Dell XPS 8930 PC. I had to > shut off secure boot in order to get the PC to use the CD I created. > This was a “Boot Only” CD. I intended to install via the net, like I > always do. > > Shortly after the CD boots up, this message is displayed, ad infinitum: > > uhub_reattach_port: giving up port reset - device vanished > > It is impossible for me to install FreeBSD because of this. Since I > have never had this happen before, I assume it is something local to > this PC. > > I Googled and came up with nothing. Can anyone assist me? If not, I am > going to end up with a semi-expensive paper weight. Hey Jerry, looks like something wrong with USB, maybe someone at the freebsd-usb or HPS (CC) will know the issue / solution :-) In the meantime I would try with USB/MemStick image instead of ISO/CD just to make sure the problem is not with USB-CD device. -- 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: VirtualBox Extensions Pack (for USB and Video)
On Tue, May 7, 2019 at 5:23 PM Johannes Lundberg wrote: > > Out of curiosity I googled and it seems you might be able to > pass-through the entire USB controller using PCI pass-through. Not sure > it's so practical if you end up loosing input capability on the host > (and also the guest since it's VNC)... Would be nice though if bhyve had > all the required functionality so we'd have a more "native" and open > source solution for all VM needs. In VirtualBox, when you select a given USB device, it is then lost to the Host and re-connected into Guest. Then you can "unselect" the device from a list the disconnect it from Guest and re-connect to the Host. This is for the "on-the-fly" attachments. But some devices needs to be enumerated directly and would not work that way, so you can create a "filter" that would directly attach given USB device into the Guest. Loosing all of the USB Host for the Guest may not be desirable because then I would loose touchscreen, LTE modem, touchpad, etc.. but I am sure @HPS can invent a solution for that problem :-) Another thing would be 2D/3D graphics acceleration in bhyve Guest under Xorg. But if nVidia driver could implement 3D acceleration into Linux Emulation, that could be also implemented into bhyve..? That bhyve stuff sounds really nice! Once again thanks for that great hint! I have to finish some hardware+firmware project and then I would get into bhyve :-) Best regards! :-) Tomek ps/2: I have to check if bhyve can emulate ARM on x86 that would be fun!! -- 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: VirtualBox Extensions Pack (for USB and Video)
On Tue, May 7, 2019 at 4:40 PM Johannes Lundberg wrote: > On 5/7/19 7:26 AM, Tomasz CEDRO wrote: > > On Tue, May 7, 2019 at 4:11 PM Johannes Lundberg wrote: > >> On 5/6/19 12:42 PM, Hans Petter Selasky wrote: > >>> On 2019-05-06 20:49, Tomasz CEDRO wrote: > >>>> @HPS have you ever considered such operation? If the FreeBSD's USB can > >>>> be shared to the userland, maybe that could be also shared to the > >>>> Virtual Machine? > >>> Hi, > >>> The problem is inside VBOX, that the USB APIs only support USB 1.x and > >>> not in FreeBSD from what I understand last time I checked. > >>> --HPS > >> Maybe bhyve is an option? I have completely replaced virtualbox with > >> bhyve for my vms and loving it but I haven't tested it with usb yet. > > Hmm, thanks Johannes for that hint.. can you run Windoze (yuck), Linux > > and other stuff as full hypervisor or does this work more like > > separated dedicated FreeBSD Jail? > > I haven't tried Windows but it's supposed to work. I'm running Ubuntu > successfully with graphical desktop in bhyve. It uses VNC for the > graphical interface so it's not the best experience but it's usable if > you don't have too high requirements. Mostly my VMs are headless. > > Check https://www.freebsd.org/doc/handbook/virtualization-host-bhyve.html > > For managing my VMs I like this one https://github.com/churchers/vm-bhyve Sounds really nice and what I need! More than that we would develop true Open-Source solution :-) Thank you Johannes !! :-) 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: VirtualBox Extensions Pack (for USB and Video)
On Tue, May 7, 2019 at 4:11 PM Johannes Lundberg wrote: > On 5/6/19 12:42 PM, Hans Petter Selasky wrote: > > On 2019-05-06 20:49, Tomasz CEDRO wrote: > >> @HPS have you ever considered such operation? If the FreeBSD's USB can > >> be shared to the userland, maybe that could be also shared to the > >> Virtual Machine? > > Hi, > > The problem is inside VBOX, that the USB APIs only support USB 1.x and > > not in FreeBSD from what I understand last time I checked. > > --HPS > Maybe bhyve is an option? I have completely replaced virtualbox with > bhyve for my vms and loving it but I haven't tested it with usb yet. Hmm, thanks Johannes for that hint.. can you run Windoze (yuck), Linux and other stuff as full hypervisor or does this work more like separated dedicated FreeBSD Jail? My main problem is with people that write software for Windoze (yuck) only. Both hardware and software utilities that needs USB2.0 connectivity. Recently the e-government got into closed-source PKI with Windoze (yuck) only applications. So the problem with lack of USB 2.0/3.0 in FreeBSD's VirtualBox is getting bigger and bigger.. not everything works in USB 1.0 mode. I am working usually on my macOS, but 10.14 + VirtualBox performance got that terrible, I had to move to FreeBSD where things work smoothly on a really slower underlying hardware.. except that USB2.0 support which is missing because of missing VirtualBox ExtensionPack. 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: VirtualBox Extensions Pack (for USB and Video)
On Thu, May 2, 2019 at 8:25 PM Jung-uk Kim wrote: > On 19. 5. 2., Tomasz CEDRO wrote: > > Hello world! > > Are there any plans to implement VirtualBox Extension Pack on FreeBSD? > > That would allow USB 2.0 + 3.0 support and better screen acceleration > > + integration, etc. USB support seems most desirable and important, > > especially for hardware hacking which is quite limited at the moment > > to USB 1.0. With great USB stack that FreeBSD already has it should be > > possible to implement those Extensions for VirtualBox right? :-) > > Unfortunately, there is no way to port VirtualBox Extension Pack because > it is NOT open sourced. In fact, it is governed by a different license. > https://www.virtualbox.org/wiki/VirtualBox_PUEL > Jung-uk Kim Thank you Kim! Did not realize that ugly licensing of the Extension Pack (except its buggy as hell and allows hijacking the hypervisor host machine). But, if the Core VirtualBox is GPL2 then API should be open too and maybe its time for some Open-Source alternative? :-) @HPS have you ever considered such operation? If the FreeBSD's USB can be shared to the userland, maybe that could be also shared to the Virtual Machine? 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"
VirtualBox Extensions Pack (for USB and Video)
Hello world! Are there any plans to implement VirtualBox Extension Pack on FreeBSD? That would allow USB 2.0 + 3.0 support and better screen acceleration + integration, etc. USB support seems most desirable and important, especially for hardware hacking which is quite limited at the moment to USB 1.0. With great USB stack that FreeBSD already has it should be possible to implement those Extensions for VirtualBox right? :-) 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-C smartphone does not detect correctly as UMS
Thanks Polytropon :-) I know more or less how USB-C works, I am using USB-A - USB-C cable that works fine on the same machine under Windoze.. it looks like Device/Phone detects Host by connect/disconnect itself somehow in a loop.. maybe because its USB descriptors/interfaces configuration can change on the fly.. -- 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"
USB-C smartphone does not detect correctly as UMS
Hello world, I have problems detecting a smartphone over USB-C - at first it only changes over the USB, then I switch it to be a USB Mass Storage, but I see no disk.. the same with different modes (i.e. Media Transfer, Picture Transfer, etc).. DMESG shows only device connected and disconnected in a loop.. What is the problem here? VID/PID is unknown to the system or it does not present itself correctly as known USB endpoint? Any hints appreciated :-) 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: usbdump on macOS
On Fri, Oct 6, 2017 at 6:39 PM, Julian H. Stacey <j...@berklix.com> wrote: > Tomasz CEDRO wrote: >> Hello world! >> Is there any chance to have USBDUMP working on current macOS? I can >> see there is a manual page for usbdump in XCode taken directly from >> the FreeBSD.. but I could not find the binary.. >> Is anyone aware or can make usbdump work on macOS? I may be able to >> find some funding to make it work.. :-) >> Best regards, >> Tomek CEDRO > > I'd guess you'd stand best chance asking on a MacOS list. But if you > do find funding & want a geographic indexed global BSD contractors index: > http://www.berklix.com/consultants/ > Cheers, > Julian Hello Julian, thanks for response! I thought there may be an effort already to port usbdump to macOS as I found the man page there.. no clue why it landed there without the binary... this is why I ask here :-) Do you know any sensible macOS list of this kind where I could ask? I did not get ANY sensible support from Apple Developer Forum nor Support.. 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"
usbdump on macOS
Hello world! Is there any chance to have USBDUMP working on current macOS? I can see there is a manual page for usbdump in XCode taken directly from the FreeBSD.. but I could not find the binary.. Is anyone aware or can make usbdump work on macOS? I may be able to find some funding to make it work.. :-) Best regards, Tomek CEDRO -- 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
On Mon, Oct 2, 2017 at 1:40 AM, Ian Lepore <i...@freebsd.org> wrote:
> On Mon, 2017-10-02 at 00:05 +0200, Tomasz CEDRO wrote:
>> On Sun, Oct 1, 2017 at 10:59 PM, Ian Lepore <i...@freebsd.org> wrote:
>> > On Sun, 2017-10-01 at 22:20 +0200, Tomasz CEDRO wrote:
>> > > On Sun, Oct 1, 2017 at 9:38 PM, Ian Lepore <i...@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 <i...@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.
>> > > >
>> > > >
Re: USB/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module
On Sun, Oct 1, 2017 at 10:59 PM, Ian Lepore <i...@freebsd.org> wrote:
> On Sun, 2017-10-01 at 22:20 +0200, Tomasz CEDRO wrote:
>> On Sun, Oct 1, 2017 at 9:38 PM, Ian Lepore <i...@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 <i...@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
Logger works with syslog which is loaded after modules and firmware,
this is why I could not see the message.. but additional action with
/bin/echo seems to do the job :-)
Thank you guys! You are the best! FreeBSD ROX!!! =)
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/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module
On Sun, Oct 1, 2017 at 9:38 PM, Ian Lepore <i...@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 <i...@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?
--
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
On Sun, Oct 1, 2017 at 8:23 PM, Ian Lepore <i...@freebsd.org> wrote:
> On Sun, 2017-10-01 at 20:17 +0200, Tomasz CEDRO wrote:
>> On Sun, Oct 1, 2017 at 7:21 PM, Hans Petter Selasky <h...@selasky.org>
>> wrote:
>> >
>> > On 10/01/17 19:09, Tomasz CEDRO wrote:
>> > >
>> > >
>> > > On Sun, Oct 1, 2017 at 6:40 PM, Ian Lepore <i...@freebsd.org>
>> > > wrote:
>> > > >
>> > > >
>> > > > On Sun, 2017-10-01 at 18:33 +0200, Tomasz CEDRO wrote:
>> > > > >
>> > > > >
>> > > > > On Wed, Sep 27, 2017 at 8:32 AM, Hans Petter Selasky <hps@sel
>> > > > > asky.org
>> > > > > >
>> > > > > >
>> > > > > > wrote:
>> > > > > >
>> > > > > > On 09/27/17 00:37, Ian Lepore wrote:
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > 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
>> > > > > > >
>> > > > > > These three lines are missing:
>> > > > > >
>> > > > > > match "system" "DEVFS";
>> > > > > > match "subsystem" "CDEV";
>> > > > > > match "type""CREATE";
>> > > > > >
>> > > > > >
>> > > > > > --HPS
>> > > > > Thanks! Updated! :-)
>> > > > >
>> > > > > https://github
Re: USB/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module
On Sun, Oct 1, 2017 at 7:21 PM, Hans Petter Selasky <h...@selasky.org> wrote:
> On 10/01/17 19:09, Tomasz CEDRO wrote:
>>
>> On Sun, Oct 1, 2017 at 6:40 PM, Ian Lepore <i...@freebsd.org> wrote:
>>>
>>> On Sun, 2017-10-01 at 18:33 +0200, Tomasz CEDRO wrote:
>>>>
>>>> On Wed, Sep 27, 2017 at 8:32 AM, Hans Petter Selasky <h...@selasky.org
>>>>>
>>>>> wrote:
>>>>>
>>>>> On 09/27/17 00:37, Ian Lepore wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>> These three lines are missing:
>>>>>
>>>>> match "system" "DEVFS";
>>>>> match "subsystem" "CDEV";
>>>>> match "type""CREATE";
>>>>>
>>>>>
>>>>> --HPS
>>>>
>>>> Thanks! Updated! :-)
>>>>
>>>> https://github.com/freebsd/freebsd/pull/115
>>>>
>>>
>>> If this is to be an example, it should be correct. Please replace the
>>> "cuaU0" with "$cdev". (See /etc/devd/uath.conf for an example).
>>>
>>> -- Ian
>>
>>
>> Thanks Ian! Is it okay now? I have moved this example to dedicated
>> /etc/devd/u3g.conf file, and added u3g load to /etc/devd/usb.conf.. if
>> syntax is okay I will verify on my laptop..
>>
>> https://github.com/freebsd/freebsd/pull/115
>>
>
> Looks good to me. Don't forget to MFC!
>
> --HPS
/etc/devd/u3g.conf:
notify 100 {
match "system" "USB";
match "subsystem" "DEVICE";
match "type" "ATTACH";
match "vendor" "0x04da";
match "product" "0x250e";
action "/usr/local/bin/gobi_loader /dev/$cdev /boot/firmware/gobi/";
};
This does not work when /dev/$cdev is used.. but it works when
/dev/cuaU0 is used. Ian, could you please advise? :-)
--
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
On Sun, Oct 1, 2017 at 6:40 PM, Ian Lepore <i...@freebsd.org> wrote:
> On Sun, 2017-10-01 at 18:33 +0200, Tomasz CEDRO wrote:
>> On Wed, Sep 27, 2017 at 8:32 AM, Hans Petter Selasky <h...@selasky.org
>> > wrote:
>> >
>> > On 09/27/17 00:37, Ian Lepore wrote:
>> > >
>> > >
>> > > 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
>> > >
>> > These three lines are missing:
>> >
>> > match "system" "DEVFS";
>> > match "subsystem" "CDEV";
>> > match "type""CREATE";
>> >
>> >
>> > --HPS
>> Thanks! Updated! :-)
>>
>> https://github.com/freebsd/freebsd/pull/115
>>
>
> If this is to be an example, it should be correct. Please replace the
> "cuaU0" with "$cdev". (See /etc/devd/uath.conf for an example).
>
> -- Ian
Thanks Ian! Is it okay now? I have moved this example to dedicated
/etc/devd/u3g.conf file, and added u3g load to /etc/devd/usb.conf.. if
syntax is okay I will verify on my laptop..
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/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module
On Wed, Sep 27, 2017 at 8:32 AM, Hans Petter Selasky <h...@selasky.org> wrote:
> On 09/27/17 00:37, Ian Lepore wrote:
>>
>> 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
>>
>
> These three lines are missing:
>
> match "system" "DEVFS";
> match "subsystem" "CDEV";
> match "type""CREATE";
>
>
> --HPS
Thanks! Updated! :-)
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/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module
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"
USB/U3G: Added support for Panasonic CF-F9 GOBI 3G modem to U3G module
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
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"
USB Device self-umount
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"
FreeBSD's USBDUMP on macOS to dump USB traffic
Hello! It looks that I need to dump USB traffic on macOS.. and it looks its not that easy.. there is no usbmon module and the old Mac tools got obsolete long ago. Searching for anything USB related I have found USBDUMP manual page as part of the XCode CommandLineTools.. but there is no binary.. So my question is did anyone make it to dump USB traffic on macOS or knows how to do it without hardware analyzer? Where did the usbdump man page come from on macOS without a binary? Any hints appreciated :-) 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"
