• C:\Windows\system32\fsquirt.exe

    From Bill Powell@21:1/5 to All on Mon Jan 15 00:08:58 2024
    After you run C:\Windows\system32\fsquirt.exe, what do you run on the other devices to copy a set of files from them (or to them)?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul@21:1/5 to Bill Powell on Sun Jan 14 18:54:49 2024
    On 1/14/2024 6:08 PM, Bill Powell wrote:
    After you run C:\Windows\system32\fsquirt.exe, what do you run on the other devices to copy a set of files from them (or to them)?

    You could run fsquirt on one end, in receive mode.

    You then run fsquirt on the other end, in transmit mode.

    Notice that fsquirt appears to have no command line help.
    It has a GUI with a receive-side button, as well
    as a transmit-side button.

    You need to set up a receiver first (or, you will be
    prompted at runtime, when you start a transfer, to
    authorize it on the receive side).

    And it also needs device discovery and pairing, as part
    of the recipe. Because, after all, the Bluetooth
    devices can reach a number of "mates" in air space, and
    the user needs a means to select them. Only I have
    control of the pairing digits, I can see the "number"
    one end puts up, and check the other end for the identical
    number. I can't make fsquirt work with the computer of
    the guy next door, because i can't see the digits on his
    screen while pairing.

    While you can enjoy sending files at 75KB/sec with little
    effort, note that I discovered while testing, that finally,
    piconet capability is there. And, you can set up *file sharing*
    across Bluetooth. So not only have I used the point-to-point
    fsquirt method, I also had general purpose networking set up
    at 75KB/sec. Imagine doing Windows Update over that... :-)
    This is similar in concept to ICS (Internet Connection Sharing).
    And the activity is not without its little challenges, but
    just having a working TCP/IP stack, is a major achievement.
    The other issues it's got, pop up all the time in other
    parts of networking, so the inconveniences are nothing new.
    It's possible you will need to widen the netmask from the
    normal /24 to /16, to make the BT piconet work with everything
    else. That might be a command or two, per session (the changes
    are not recorded between sessions).

    A few years back, I tried to set up a piconet on Bluetooth,
    and it managed to send two packets before dying. And repeated
    efforts to repeat the feat, failed entirely. Color me shocked,
    when finally it worked. I couldn't tell if they were really
    working on it, or were planning such a thing or not.

    And this really has nothing to do with Bluetooth 5 as an enabler.
    As near as I can tell, Bluetooth 4 and Bluetooth 5 are more or
    less functionally equivalent on Windows. The new capabilities
    for BT5, are really for IoT, not for Windows. Windows tries
    to run all the devices in the same "mode", so it is a
    backwards compatibility play.

    One other thing to note, while I was testing this and that,
    I noticed that *no* bandwidth indicator was accurate :-)
    Don't you love this stuff ? You really have to take the
    number of bytes transferred, divide by the number of
    seconds on your stopwatch, to figure out what speed
    the transfer occurred at.

    Summary: I'm hoping you find this discoverable, and no matter
    what you do first, the interface will tell you what to do.
    Sometimes, getting paired can be a chore.

    NOTE: DO NOT share a Bluetooth nano plug with two computers.
    When you retrofit a BT to a desktop computer, it stays paired
    with the computer. So BT with MAC 123456 stays on this computer
    and the other BT with 789123 stays on the other computer. In fact,
    all my networking boxes are marked this way, with a Wifi labeled
    Intel and a Wifi labeled AMD, so they stay on the correct side of
    the room.

    NOTE: A second warning. Do not send audio from a Windows computer
    to a Linux computer and its speakers. This is a different config
    than using BT speakers. What happens if you try that, is metadata
    is stored in two places in Windows, and you can't make the machine
    forget the details of the transaction. Bluetooth can get *confused*
    which is why you have to use restraint when experimenting. Like, by
    moving a BT, the computer will figure out something is wrong with
    the computer name and the BT MAC address, and it will get some details
    of association wrong. This will eventually drive you nuts, when you
    can't reliably run fsquirt and friends. So some things you do to the
    computer, have side effects, and deleting ENUM will never clean out
    the mess.

    A reliable way to sort a BT issue... is to reinstall Windows.

    Paul

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stan Brown@21:1/5 to Bill Powell on Tue Jan 16 11:12:26 2024
    On Mon, 15 Jan 2024 00:08:58 +0100, Bill Powell wrote:

    After you run C:\Windows\system32\fsquirt.exe, what do you run on the other devices to copy a set of files from them (or to them)?

    Paul has given you a lot of good information. I'll just add this link
    from Microsoft:

    <https://learn.microsoft.com/en-us/windows- hardware/drivers/bluetooth/bluetooth-user-interface.

    --
    Stan Brown, Tehachapi, California, USA https://BrownMath.com/
    Shikata ga nai...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)