I'm developing a USB device driver for an embedded system, and the host is a Linux system (Ubuntu 21.04 for now). The device is based on an FPGA, a SmartFusion2. I'm using pyusb to test my device, and I check performance with Wireshark + usbmon.
The device is running in high speed mode, have several endpoints, and an interrupt IN endpoint in particular.
On this endpoint:
with an interval setting in the descriptor of 32, my device get tokens every 32 ms (stdev ~50us). That's what is expected for low speed / full speed devices, so there is already something broken here, but otherwise the situation is acceptable.
with an interval setting of 16 (or less), I get a whopping 4096 ms (stdev ~100 us). Very broken.
Those timing are independent of the device, I can reset the device and reconnect, the alignment with the previous 4096ms cycles is nearly perfect. They are also independent of pyusb start time, and timeout settings, so I'm thinking it's due to the linux USB host driver.
Is that normal?
How do I debug that?
I can post some Wireshark captures if needed.
My descriptors looks otherwise ok to me, but maybe I missed something:
sudo lsusb -v
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 3
bMaxPacketSize0 9
idVendor 0x1d6b Linux Foundation
idProduct 0x0003 3.0 root hub
bcdDevice 5.11
iManufacturer 3 Linux 5.11.0-22-generic xhci-hcd
iProduct 2 xHCI Host Controller
iSerial 1 0000:00:15.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x001f
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
bMaxBurst 0
Hub Descriptor:
bLength 12
bDescriptorType 42
nNbrPorts 7
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
bHubDecLat 0.0 micro seconds
wHubDelay 0 nano seconds
DeviceRemovable 0x00
Hub Port Status:
Port 1: 0000.02a0 5Gbps power Rx.Detect
Port 2: 0000.02a0 5Gbps power Rx.Detect
Port 3: 0000.02a0 5Gbps power Rx.Detect
Port 4: 0000.02a0 5Gbps power Rx.Detect
Port 5: 0000.02a0 5Gbps power Rx.Detect
Port 6: 0000.02a0 5Gbps power Rx.Detect
Port 7: 0000.02a0 5Gbps power Rx.Detect
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x000f
bNumDeviceCaps 1
SuperSpeed USB Device Capability:
bLength 10
bDescriptorType 16
bDevCapabilityType 3
bmAttributes 0x02
Latency Tolerance Messages (LTM) Supported
wSpeedsSupported 0x0008
Device can operate at SuperSpeed (5Gbps)
bFunctionalitySupport 3
Lowest fully-functional device speed is SuperSpeed (5Gbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat 512 micro seconds
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
-- Other device --
-- Other device --
-- Other device --
Bus 001 Device 083: ID 1514:fff0 Actel CLICK USB bridge
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
idVendor 0x1514 Actel
idProduct 0xfff0
bcdDevice 0.01
iManufacturer 1 MIT STARLab
iProduct 2 CLICK USB bridge
iSerial 3 V0.1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x002e
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 255
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 64
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
-- Other device --
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 5.11
iManufacturer 3 Linux 5.11.0-22-generic xhci-hcd
iProduct 2 xHCI Host Controller
iSerial 1 0000:00:15.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0019
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 11
bDescriptorType 41
nNbrPorts 9
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00 0x03
PortPwrCtrlMask 0xff 0xff
Hub Port Status:
Port 1: 0000.0503 highspeed power enable connect
Port 2: 0000.0503 highspeed power enable connect <- *** My device ***
Port 3: 0000.0503 highspeed power enable connect
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0503 highspeed power enable connect
Port 7: 0000.0103 power enable connect
Port 8: 0000.0100 power
Port 9: 0000.0100 power
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered
It turns out that I cannot read the spec properly. The bInterval setting in the descriptor is a power of 2 of the actual time interval. For high speed mode:
time interval = 2 ** (bInterval - 1) * 0.125.
So for bInterval = 16, 4096 ms, as measured.
Also the maximum value for bInterval is 16, if higher linux sets it to 9 instead, and outputs something in dmesg:
[ 693.295727] usb 1-1.1: config 1 interface 0 altsetting 0 endpoint 0x81 has an invalid bInterval 32, changing to 9
So bInterval = 9 is 32 ms... as measured.
Related
I'm looking at the _ykusb_write() function from the Yubikey-Personalization package and the first line of code executed is
int rc = usb_claim_interface((usb_dev_handle *)dev, 0);
Why is the zeroth USB interface claimed? From what I can tell from the lsusb output (see below) that interface is an HID and not the smartcard itself. I would had expected the 2nd interface to be claimed instead, but I do not understand this part of Yubikey very well. Where is it documented? Thank you for your help.
bNumInterfaces 3
Interface Descriptor:
bInterfaceNumber 0
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 1 Keyboard
iInterface 0
Interface Descriptor:
bInterfaceNumber 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Interface Descriptor:
bInterfaceNumber 2
bInterfaceClass 11 Chip/SmartCard
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
ChipCard Interface Descriptor:
The YubiKey Personalization package referenced dates back to the YubiKey 1/2 models, which did not have CCID/Smart card support. The YubiKey 1/2 devices could only be communicated to via the HID keyboard interface, and identified to host devices as a USB keyboard. As such, the package attempts to connect to a YubiKey as if it was a keyboard.
The YubiKey Personalization package does not communicate over CCID/Smart card, but instead uses the HID keyboard interface. Yubico maintains this project as modern devices which support the touch-triggered OTP functions also can be programmed over the HID keyboard interface, and as such it remains useful for specific cases.
I have been trying out the bluez btmon tool to monitor the bluetooth discovery result on my raspberry pi 4.
The btmon tool returns stdout which is the following:
# MGMT Event: Device Found (0x0012) plen 42 {0x0001} [hci0] 0.207973
LE Address: 61:E1:E1:49:C8:DC (Resolvable)
RSSI: -51 dBm (0xcd)
Flags: 0x00000004
Not Connectable
Data length: 28
16-bit Service UUIDs (complete): 1 entry
Google (0xfe9f)
Service Data (UUID 0xfe9f): 0000000000000000000000000000000000000000
# MGMT Event: Device Found (0x0012) plen 33 {0x0001} [hci0] 0.224956
LE Address: 48:82:8F:DB:5C:65 (Resolvable)
RSSI: -76 dBm (0xb4)
Flags: 0x00000000
Data length: 19
Flags: 0x1a
LE General Discoverable Mode
Simultaneous LE and BR/EDR (Controller)
Simultaneous LE and BR/EDR (Host)
TX power: 5 dBm
Company: Apple, Inc. (76)
Type: Unknown (16)
Data: 491faeca8c8638
# MGMT Event: Device Found (0x0012) plen 43 {0x0001} [hci0] 0.298194
LE Address: 0E:AF:D9:F0:D8:F1 (Non-Resolvable)
RSSI: -68 dBm (0xbc)
Flags: 0x00000004
Not Connectable
Data length: 29
Company: Microsoft (6)
Data: 0109210a065124d7b5c04445534b544f502d44484845413434
# MGMT Event: Device Found (0x0012) plen 43 {0x0001} [hci0] 0.940219
LE Address: 86:2A:FD:9E:57:0D (OUI 86-2A-FD)
RSSI: -77 dBm (0xb3)
Flags: 0x00000000
Data length: 29
Flags: 0x06
LE General Discoverable Mode
BR/EDR Not Supported
Service Data (UUID 0xfdf7): 01384a3dd6381b593c74d9369eefaa9b720000000003
Been looking for some official docs on explaining the field "Flags" in each discovered device info (those flag codes: 0x00000004, 0x00000000, 0x1a, 0x06), but I couldn't seem to find one that makes sense.
Would really appreciate if anyone could explain what does the Flags tell, and how to make sense of these codes?
Thanks in advance.
I don't know what you call "official docs", but the Bluetooth Core Specification and the Supplement to the Bluetooth Core Specification certainly explains it. Have a look at chapter 1.3 FLAGS of CSS
In the log you showed, you can see the advertising data of several Bluetooth LE devices. Each of this advertising data contains one ore more fields called AD Types. One of the AD Types is the "Flags" field. It may be zero or more octets long, with the first octet containing the following information:
Octet
Bit
Description
0
0
LE Limited Discoverable Mode
0
1
LE General Discoverable Mode
0
2
BR/EDR Not Supported. Bit 37 of LMP Feature Mask Definitions (Page 0)
0
3
Simultaneous LE and BR/EDR to Same Device Capable (Controller). Bit 49 of LMP Feature Mask Definitions (Page 0)
0
4
Previously Used
0
5..7
Reserved for future use
The given information tells you something about the used Bluetooth radio and about the advertising itself. If you are interested in a deeper understanding of this topic, I recommend reading this Bluetooth blog article: Advertising Works, Part 1
In prior kernels and releases of Ubuntu, it was possible to use the hci socket interface to send an arbitrary set of 31 bytes as an advertising beacon, but in ubuntu 20.04 the hci bluetooth tools were deprecated, as were some elements of the socket API they were using.
The goal is to have some N number of devices broadcast 31 bytes of sensor data to each other at a rate of 5 Hz, and have all N read the packets from the other devices.
With the hci socket API being deprecated, the replacements are the DBus BlueZ API and the Management BlueZ API. The DBus API is limited and seems to only allow a max of 25 bytes. The Management API seems more capable, and it seems to work on Ubuntu 18.04/4.15 kernel (though even there the scan seemed to only pick up the advertisements sporadically when switching between scan and advertise every 100ms while with the hci api it was rock solid), but on Ubuntu 20.04/5.4 kernel, various issues crop up.
Using the hci socket API seems like it could still be possible, but even running something like hcitool lescan results in btmon saying Command Disallowed. I believe this might be due to LE Extended Advertising being enabled, but I have not figured out how to disable it yet.
Using the DBus API (or bluetoothctl) is still limited and doesn't allow the full use of the 31 bytes (or even 30 bytes + length)
Using the Management API leads to a Advertising Timeout shortly after setting the advertising data, which I think might be from LE Extended Advertising being enabled. This problem persists even if I explicitly set the timeout in the packet.
For example, running
btmgmt add-adv -c -d 1E000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D 1
to send an advertising packet at a fixed MAC with the advertising data being length:31 payload: 0-30 results in a btmon output of:
< HCI Command:... (0x08|0x0036) plen 25 #631 [hci0] 5676.358401
Handle: 0x01
Properties: 0x0013
Connectable
Scannable
Use legacy advertising PDUs: ADV_IND
Min advertising interval: 1280.000 msec (0x0800)
Max advertising interval: 1280.000 msec (0x0800)
Channel map: 37, 38, 39 (0x07)
Own address type: Public (0x00)
Peer address type: Public (0x00)
Peer address: 00:00:00:00:00:00 (OUI 00-00-00)
Filter policy: Allow Scan Request from Any, Allow Connect Request from Any (0x00)
TX power: 127 dbm (0x7f)
Primary PHY: LE 1M (0x01)
Secondary max skip: 0x00
Secondary PHY: LE 1M (0x01)
SID: 0x00
Scan request notifications: Disabled (0x00)
> HCI Event: Command Co.. (0x0e) plen 5 #632 [hci0] 5676.359321
LE Set Extended Advertising Parameters (0x08|0x0036) ncmd 1
Status: Success (0x00)
TX power (selected): 7 dbm (0x07)
< HCI Command: L.. (0x08|0x0039) plen 6 #633 [hci0] 5676.359410
Extended advertising: Enabled (0x01)
Number of sets: 1 (0x01)
Entry 0
Handle: 0x01
Duration: 2000 ms (0xc8)
Max ext adv events: 0
> HCI Event: Command Co.. (0x0e) plen 4 #634 [hci0] 5676.361330
LE Set Extended Advertising Enable (0x08|0x0039) ncmd 2
Status: Success (0x00)
# MGMT Event: Com.. (0x0001) plen 4 {0x0003} [hci0] 5676.361372
Add Advertising (0x003e) plen 1
Status: Success (0x00)
Instance: 1
> HCI Event: LE Meta Ev.. (0x3e) plen 6 #635 [hci0] 5676.362333
LE Advertising Set Terminated (0x12)
Status: Advertising Timeout (0x3c)
Handle: 1
Connection handle: 65535
Number of completed extended advertising events: 0
Is there a good way to recreate the functionality that was available using the hci socket, or a way to disable extended advertising so that the hci socket works again?
This image from Jos Ryke might help explain what is going on. Of those 31 bytes, 3 were always used for setting the advertising flags.
Looking at the source code for btmgmt those flags are now set with the -g, and -l command line switches. Use general discoverable mode to advertise indefinitely.
static void add_adv_usage(void)
{
bt_shell_usage();
print("Options:\n"
"\t -u, --uuid <uuid> Service UUID\n"
"\t -d, --adv-data <data> Advertising Data bytes\n"
"\t -s, --scan-rsp <data> Scan Response Data bytes\n"
"\t -t, --timeout <timeout> Timeout in seconds\n"
"\t -D, --duration <duration> Duration in seconds\n"
"\t -P, --phy <phy> Phy type, Specify 1M/2M/CODED\n"
"\t -c, --connectable \"connectable\" flag\n"
"\t -g, --general-discov \"general-discoverable\" flag\n"
"\t -l, --limited-discov \"limited-discoverable\" flag\n"
"\t -n, --scan-rsp-local-name \"local-name\" flag\n"
"\t -a, --scan-rsp-appearance \"appearance\" flag\n"
"\t -m, --managed-flags \"managed-flags\" flag\n"
"\t -p, --tx-power \"tx-power\" flag\n"
"e.g.:\n"
"\tadd-adv -u 180d -u 180f -d 080954657374204C45 1");
}
The other 28 bytes must start with a byte declaring the length and a byte declaring what data type the rest of the bytes in the declared length are describing.
It is those 28 bytes that is being set with the -d option of btmgmt.
If 28 bytes are not enough, then common workarounds people use is to split the data over multiple adverts or use scan response packet.
There is more detail on the Advertising Data Format in the Core Specification where it defines an Advertising Packet as:
A packet containing an advertising PDU. See [Vol 6]
Part B, Section 2.3.1
More data is section:
BLUETOOTH CORE SPECIFICATION Version 5.2 | Vol 3, Part C | 11 ADVERTISING AND SCAN RESPONSE DATA FORMAT
It has an example for ADV_NONCONN_IND packet type:
PDU Type: 2
ChSel: RFU
TxAdd: 1 (random)
RxAdd: RFU
AdvA: 0xC1A2A3A4A5A6 (a static device address)
AdvData: (3 octets) 0x01 0x02 0x03
Which starts with the flags data type.
I am trying to connect a Wahoo Scale 1.3 to read the live weight of a person via bluetooth notifications.
The live weight can be read via the following characteristic:
handle: 0x0025, char properties: 0x10, char value handle: 0x0026, uuid: 00002b01-0000-1000-8000-00805f9b34fb.
This is working with LightBlue app on my iPhone.
When I try to receive notifications via gatttool I get the following error:
Command line gatttool: (tried also lots of different notations from different stack overflow topics)
[XX:XX:XX:XX:XX:XX][LE]> char-write-req 0x0026 0100
Error: Characteristic Write Request failed: Attribute can't be written
btmon bluetooth log
< ACL Data TX: Handle 0 flags 0x00 dlen 9 [hci0] 4.291021
ATT: Write Request (0x12) len 4
Handle: 0x0026
Data: 0100
> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 4.327199
Num handles: 1
Handle: 0
Count: 1
> ACL Data RX: Handle 0 flags 0x02 dlen 9 [hci0] 4.383580
ATT: Error Response (0x01) len 4
Write Request (0x12)
Handle: 0x0026
Error: Write Not Permitted (0x03)
One thing I noticed is that under UUID 1901 (weight service) there are 3 properties: 1: write/indicate, 2: notify, 3: notify.
Bluetooth characteristics on LightBlue App
I am able to write with gatttool to the first property, but not to the 2 and 3 property. But how does LightBlue starts listening for notifications?
I tried this one two different systems:
Beaglebone Black with QN9021 BLE controller (Bluez 5.38, OpenWrt Linux 4.4)
Beaglebone Black WiFi/Bluetooth (Bluez 5.23, Debian Linux 4.4)
Do I get this error because of incompatiblities of the Bluez stack and the Wahoo Scale? How do I fix this?
Thank you!
0x0026 is the handle for the value, not for the descriptor. I would guess the descriptor's handle is 0x0027.
I've written a program in Linux bash using udev and bash scripting.
when a usb is attached, udev rule executes which calls a script. that script read /var/log/messages file and get info about attached usb hard drive from log file and send info in email.
Program is working fine but I've encountered a problem. when I try to remove usb, I have to shake it (as it is firmly injected inside), so what happens is that in removal process, it removes, attaches, removes attach and then finally remove. due to this my email format gets disturb and i dont get proper information.also it generates multiple useless emails and i get following logs:
May 04 13:06:13 coil sendEmail[12467]: Email was sent successfully!
May 4 13:06:13 coil vmbackup[12450]: USB Removed: Email sent to backupjobs#domain.com
May 4 13:06:16 coil kernel: [8474935.215393] usb 2-6: USB disconnect, address 126
May 4 13:06:16 coil kernel: [8474935.601292] usb 2-6: new high speed USB device using ehci_hcd and address 127
May 4 13:06:17 coil kernel: [8474935.868637] usb 2-6: configuration #1 chosen from 1 choice
May 4 13:06:17 coil kernel: [8474935.915429] scsi85 : SCSI emulation for USB Mass Storage devices
May 4 13:06:17 coil kernel: [8474935.982734] input: Western Digital My Book as /devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.1/input/input82
May 4 13:06:17 coil kernel: [8474935.982808] generic-usb 0003:1058:1102.0050: input,hidraw0: USB HID v1.11 Device [Western Digital My Book] on usb-0000:00:1d.7-6/input1
May 4 13:06:17 coil kernel: [8474935.982808] generic-usb 0003:1058:1102.0050: input,hidraw0: USB HID v1.11 Device [Western Digital My Book] on usb-0000:00:1d.7-6/input1
May 4 13:06:17 coil kernel: [8474936.084957] usb 2-6: USB disconnect, address 127
May 4 13:06:17 coil kernel: [8474936.500051] usb 2-6: new high speed USB device using ehci_hcd and address 2
May 4 13:06:17 coil kernel: [8474936.769487] usb 2-6: configuration #1 chosen from 1 choice
May 4 13:06:17 coil kernel: [8474936.815499] scsi86 : SCSI emulation for USB Mass Storage devices
May 4 13:06:18 coil kernel: [8474936.882954] input: Western Digital My Book as /devices/pci0000:00/0000:00:1d.7/usb2/2-6/2-6:1.1/input/input83
May 4 13:06:18 coil kernel: [8474936.883044] generic-usb 0003:1058:1102.0051: input,hidraw0: USB HID v1.11 Device [Western Digital My Book] on usb-0000:00:1d.7-6/input1
May 4 13:06:22 coil kernel: [8474941.837814] scsi 86:0:0:0: Direct-Access WD My Book 1028 PQ: 0 ANSI: 4
May 4 13:06:22 coil kernel: [8474941.838208] sd 86:0:0:0: Attached scsi generic sg3 type 0
May 4 13:06:22 coil kernel: [8474941.838208] sd 86:0:0:0: Attached scsi generic sg3 type 0
May 4 13:06:23 coil kernel: [8474941.860051] sd 86:0:0:0: [sdc] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
May 4 13:06:23 coil kernel: [8474941.873798] sd 86:0:0:0: [sdc] Write Protect is off
May 4 13:06:23 coil kernel: [8474941.955971] sdc: sdc1
May 4 13:06:23 coil kernel: [8474942.014853] sd 86:0:0:0: [sdc] Attached SCSI disk
May 04 13:06:23 coil sendEmail[12495]: Email was sent successfully!
May 4 13:06:23 coil vmbackup[12478]: USB Added: Email sent to backupjobs#domain.com
May 04 13:06:26 coil sendEmail[12527]: Email was sent successfully!
May 4 13:06:26 coil vmbackup[12510]: USB Removed: Email sent to backupjobs#domain.com
May 04 13:06:35 coil sendEmail[12546]: Email was sent successfully!
May 4 13:06:35 coil vmbackup[12535]: USB Added: Email sent to backupjobs#domain.com
May 04 13:06:37 coil sendEmail[12576]: Email was sent successfully!
May 4 13:06:37 coil vmbackup[12559]: USB Removed: Email sent to backupjobs#domain.com
May 04 13:06:48 coil sendEmail[12596]: Email was sent successfully!
May 4 13:06:48 coil vmbackup[12585]: USB Added: Email sent to backupjobs#domain.com
Now I know that this is not coding problem. But I want to know if somehow i can fix this issue? and care this scenario.
You have to do some sort of de-bouncing in your script. Whenever it's called check if it's been called recently (< 1 or 2 seconds), and if so, don't do anything. You can use a file as a timestamp in /tmp as your time marker.
Something like this might work:
delta=2 # 2 seconds of debounce
stampfile=/tmp/stamp
now=$(date +%s)
then=$(< $stampfile)
[[ -z $then ]] && then=$now
diff=$((now-then))
if [[ $((diff < delta)) ]]; then
exit
else
echo $now > $stampfile
fi