GitLab

random weirdness.

Fix race condition on disconnect

is being disconnected, and the buffers are leaked from the packet pool
forever.

Clean up if device intialization fails.

Add options for setting scanning and advertising parameters.

Make flow control work

the Bluetooth spec (Vol 2, Part E, Section 4.4), old version tended to
collect extra allowed commands over time and eventually lock up.

This can be useful when we need to use specific HCI device ID.

* Add ability to get RxMTU from a connection

* Fix race detector warning

* Fix compiler error

This prevents multiple evtPeripheralConnected events from causing a
deadlock.

* Simplify uuid.Reverse method

* Add uuid test

* Fix linting issues

* Fix cancel via context and respect context deadline

* Remove timeout overwrite and remove go1.7 from travis

* Bump up the number of command channels and changed not to exit

* Clean up

* revert smiple ' to fancy '

* Changed the error handling

* perhaps notify flag used to be set in yosemite? this blocks on sierra now

* few more xpcids for sierra

This is a hack which silences an extraneous log message.  The message
gets reported due to an apparent race condition involving the
`sktLoop()` function in `linux/hci/hci.go`.  This function implements a
socket-read loop that only returns on error.  It is called as a
Goroutine, and typically continues to run until the process terminates.

If client code closes the owning `Device` at an inopportune time
(presumably during the socket read), the `Read()` call returns an
`io.EOF` error, which causes `NewDevice()` to log the following message:

    can't accept: skt: EOF

Since the API permits the user to close the device at any time, this
error message is extraneous.

This commit simply inhibits the logging of the error message in case of
EOF.  This is not a long-term solution, but it does fix the visible
issue.

Add build status badge

This commit addresses a panic that occurs in older versions of MacOS
(tested with 10.11.5).  The problem occurs because, on this machine, the
DiscoverDescriptors response lacks a `kCBMsgArgResult` field.  This
missing field must have gotten fixed in a subsequent version of MacOS.
Here are the contents of the DiscoverDescriptors response:

```
map[kCBMsgArgCharacteristicHandle:17 kCBMsgArgDeviceUUID:3e8e65b72da94f70bbbe2d8f1a2524ee kCBMsgArgDescriptors:[]]
```

The fix is to treat a response that lacks the `kCBMsgArgResult` field as
indicating success.  That is, pretend `kCBMsgArgResult` is 0.

* XPC cleanup

* Go Meta Linter

* Update travis with linux

* Fix unintroduced interface

* Fix travis.yml

* Fix travis.yml

* Fix travis.yml

* Add GOOS to Travis

* Damn travis

* Finally?

* Goddamn travis

Premininary support for OS X High Sierra

Signed-off-by: deadprogram <ron@hybridgroup.com>

Signed-off-by: deadprogram <ron@hybridgroup.com>

Signed-off-by: deadprogram <ron@hybridgroup.com>

Signed-off-by: deadprogram <ron@hybridgroup.com>

Signed-off-by: deadprogram <ron@hybridgroup.com>