# Can't connect to EVISTR Digital Voice Recorder



## borffis (Jan 20, 2022)

My trouble begins when I plug it in and observe that its MBR is aberrant.

dmesg:

```
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
da0: <EVISTR L157 2.00> Removable Direct Access SCSI device
da0: 40.000MB/s transfers
da0: 16122MB (16508928 1024 byte sectors)
da0: quirks=0x2<NO_6_BYTE>
GEOM_PART: integrity check failed (da0, MBR)
```

`ls -l /dev/da0`:

```
crw-rw----  1 root  operator  0xb1 Jan 15 18:27 /dev/da0
```

`diskinfo -v /dev/da0`:

```
/dev/da0
    1024            # sectorsize
    16905142272     # mediasize in bytes (16G)
    16508928        # mediasize in sectors
    0               # stripesize
    0               # stripeoffset
    1027            # Cylinders according to firmware.
    255             # Heads according to firmware.
    63              # Sectors according to firmware.
    EVISTR L157     # Disk descr.
                    # Disk ident.
    No              # TRIM/UNMAP support
    Unknown         # Rotation rate in RPM
    Not_Zoned       # Zone Mode
```

`file -s /dev/da0`

```
/dev/da0: DOS/MBR boot sector; partition 1 : ID=0xb, start-CHS (0x0,1,1), end-CHS (0x3ff,254,63), startsector 128, 16508928 sectors, extended partition table (last)
```

`gpart show da0`:

```
gpart: No such geom: da0.
```

`mount -o ro -t ntfs /dev/da0 /mnt/2`:

```
mount: /dev/da0: Operation not supported by device
```
`mount -o ro -t ntfs /dev/da0s1 /mnt/2`:

```
mount: /dev/da0s1: Operation not supported by device
```

Is this is a familiar problem?


----------



## jbo (Jan 20, 2022)

It's always useful if you could provide some information regarding functionality with a different OS. i.e. can you mount it on a Windows, MacOS or Linux machine?

I am a bit surprised that it would contain a boot sector. This should just be a simple mass storage device, right?

Can you provide the output of `usbconfig -d x.y dump_device_desc` where x.y is the USB device (check `dmesg`).


----------



## ralphbsz (Jan 20, 2022)

borffis said:


> My trouble begins when I plug it in and observe that its MBR is aberrant.


It's actually worse than that.



> ...
> diskinfo -v /dev/da0: ...
> `1024            # sectorsize
> ...`



So this device claims to be disk-like, meaning a block device (also known as a random access device). Great. But it has an extremely odd sector size, namely 1024 bytes. Sector sizes for common block devices are 512 bytes (traditional disks), 4096 bytes (modern disks), and 2048 bytes (CD-ROMs). A sector size of 1024 bytes is nearly unheard of. I think the last time I saw such things was the CD-ROM drives used for Digital Equipment's MicroVAX line of computers ... in the 80s and early 90s.

I very much doubt that any modern Unix file system can operate with 1024-byte sectors.



> file -s /dev/da0
> `/dev/da0: DOS/MBR boot sector; partition 1 : ID=0xb, start-CHS (0x0,1,1), end-CHS (0x3ff,254,63), startsector 128, 16508928 sectors, extended partition table (last)`
> 
> gpart show da0:
> `gpart: No such geom: da0.`


OK, so it looks like the first 512 bytes of the first sector on the disk are in the correct format for a MBR boot sector. That's what the file command says. But has anyone ever seen a MBR that expresses its sizes in 1024-byte sectors?

The gpart command tells us that the disk does not have a GPT header.

Question: Does FreeBSD even recognize partitions on this disk? Is there a set of /dev/da0s* files?



> mount -o ro -t ntfs /dev/da0 /mnt/2:


What makes you think that the file system stored on the whole disk (not the first partition) is NTFS? I would actually suspect FAT more.



> `mount: /dev/da0: Operation not supported by device`


That tells you that the mount code attempted to perform an operation on the disk (probably a read), which the disk said it could not perform. Most likely the file system code attempted to do a 512-byte read, and that may be impossible: block devices typically can only be accessed by reading/writing full blocks, in our case 1024-byte sectors.


----------



## covacat (Jan 20, 2022)

try 

sysctl kern.geom.part.check_integrity=0 and re-plug it


----------



## borffis (Jan 21, 2022)

jbodenmann said:


> It's always useful if you could provide some information regarding functionality with a different OS. i.e. can you mount it on a Windows, MacOS or Linux machine?


Alas, no: I no longer run Debian on any of my machines, and the recorder's owner only has some frivolous tablet that can read (but never transfer data from or to) storage devices....though not this one.


jbodenmann said:


> I am a bit surprised that it would contain a boot sector. This should just be a simple mass storage device, right?


Yes, but....!


jbodenmann said:


> Can you provide the output of `usbconfig -d x.y dump_device_desc` where x.y is the USB device (check `dmesg`).


Sure:
`ugen1.5: <EVISTR USB FlashDisk> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0200 
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000 
  bDeviceProtocol = 0x0000 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x20d6 
  idProduct = 0x1101 
  bcdDevice = 0x0100 
  iManufacturer = 0x0001  <EVISTR>
  iProduct = 0x0002  <USB FlashDisk>
  iSerialNumber = 0x0003  <>
  bNumConfigurations = 0x0001`


----------



## jbo (Jan 21, 2022)

I've just checked with my friend who used to operate devices like these (although different brands) and he confirmed that the ones which provide a USB interface with mass storage mode usually have an option (in the device menu) to format the storage. That would setup a clean slate by formatting the storage the way that the device is intended to. This might fix an issue in case somebody (or something) messed with the formatting. You might want to consider giving that a try (your existing recordings/data will be inaccessible afterwards tho).



borffis said:


> Yes, but....!


Just to avoid any miscommunication: Do you have any reason to believe that it should contain a boot sector?


----------



## borffis (Jan 21, 2022)

ralphbsz said:


> I very much doubt that any modern Unix file system can operate with 1024-byte sectors.


From gpart's output, I assumed that some such factor was my obstacle. I appreciate your explanation.


ralphbsz said:


> What makes you think that the file system stored on the whole disk (not the first partition) is NTFS? I would actually suspect FAT more.


That's a good point, but....
mount -o ro -t msdosfs /dev/da0 /mnt/2:
`mount_msdosfs: /dev/da0: Invalid argument`
mount -o ro -t msdosfs /dev/da0s1 /mnt/2:
`mount_msdosfs: /dev/da0s1: No such file or directory`
mount -o ro -t msdosfs /dev/da0s2 /mnt/2:
`mount_msdosfs: /dev/da0s2: No such file or directory`



ralphbsz said:


> That tells you that the mount code attempted to perform an operation on the disk (probably a read), which the disk said it could not perform. Most likely the file system code attempted to do a 512-byte read, and that may be impossible: block devices typically can only be accessed by reading/writing full blocks, in our case 1024-byte sectors.


Can you imagine why this device is so designed? Might the manufacturers have intended it to be accessed only by Win/Mac....?


----------



## borffis (Jan 21, 2022)

jbodenmann said:


> I've just checked with my friend who used to operate devices like these (although different brands) and he confirmed that the ones which provide a USB interface with mass storage mode usually have an option (in the device menu) to format the storage. That would setup a clean slate by formatting the storage the way that the device is intended to. This might fix an issue in case somebody (or something) messed with the formatting. You might want to consider giving that a try (your existing recordings/data will be inaccessible afterwards tho).


This option is certainly available, but the probability that anybody tinkered with this is nil. Its owner wouldn't have done so, and he purchased it new. I will consider this, though.


jbodenmann said:


> Just to avoid any miscommunication: Do you have any reason to believe that it should contain a boot sector?


No, none whatsoever. It strikes me as oddly as anyone else.


----------



## borffis (Jan 21, 2022)

covacat said:


> try
> 
> sysctl kern.geom.part.check_integrity=0 and re-plug it


I'll essay this. Thanks!


----------



## ralphbsz (Jan 21, 2022)

borffis said:


> mount -o ro -t msdosfs /dev/da0s1 /mnt/2:
> `mount_msdosfs: /dev/da0s1: No such file or directory`


That tells you that there is no BSD slice /dev/da0s1 on the device. That's to be expected: unlikely that this thing would be formatted with BSD-style slices. You might have instead tried /dev/da0p1, in case it has a (MSDOS-style) partition on it. Even better: Do a ls on /dev/da0*, and see what partitions/slices are even found.
EDIT: Never mind, see Covecat's post below. But do do an ls to see /dev/da0*, if there is anything there.



> Can you imagine why this device is so designed? Might the manufacturers have intended it to be accessed only by Win/Mac....?


That seems plausible: The people who built this thing only intended it to be used with custom software. They may have used a software stack for a USB mass-storage device (fake disk) just for convenience, with no intent of supporting generic file system access. They may have picked the 1024-byte sector size for their own reasons.

If you had a lot of spare time, you could buy a USB protocol analyzer, and connect this device to its own software, and see what operations it performs. Reverse engineer that, and come up with some compatible software. That is probably a lot of work.


----------



## covacat (Jan 21, 2022)

da0s1 is expected in any mbr setup, you don't need bsd slices (p1 is gpt setup)


----------

