| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
Network.Socket.ByteString is in network since before 2.4, so no need to
adjust bounds.
|
|
|
|
| |
It's a code smell, can lead to hard to diagnose error messages.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pairing process separately.
I was able to reproduce something very like this bug by starting
pairing separately on both computers under poor network conditions (ie,
weak wifi on my front porch). Neither computer showed an alert for the
PairReq messages it was seeing (intermittently) from the other.
So, I've made a new PairReq message that has not been seen before
always make the alert pop up, even if the assistant thinks it is
in the middle of its own pairing process (or even another pairing
process with a different box on the LAN).
(This shouldn't cause a rogue PairAck to disrupt a pairing process part
way through.)
|
|
|
|
|
|
|
|
|
| |
The msg contains a haskell-escaped string, so control characters in it can
also be escaped. So this didn't work before, really.
Got rid of the \n check, because current pairing messages actually do
contain a \n, after the ssh public key. Don't want to break
back-compatability.
|
| |
|
|
|
|
|
| |
Retying every second is a bit much, especially given the current leak
https://github.com/audreyt/network-multicast/issues/4
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This includes keeping track of which buddies we're pairing with, to know
which PairAck are legitimate.
|
| |
|
| |
|
| |
|
|
|
|
| |
All temporary and old functions are removed.
|
|
|
|
|
|
| |
Currently have three old versions of functions that more reworking is
needed to remove: getDaemonStatusOld, modifyDaemonStatusOld_, and
modifyDaemonStatusOld
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
All toplevel named threads are converted to the Assistant monad.
Some utility functions still need to be converted.
|
|
|
|
|
|
|
|
|
|
| |
Converted several threads to run in the monad.
Added a lot of useful combinators for working with the monad.
Now the monad includes the name of the thread.
Some debugging messages are disabled pending converting other threads.
|
|
|
|
|
|
|
|
|
|
|
| |
I noticed this while offline (so that lack of solar power is good for something).
Apparently it tries to bind multicast to lo, and that fails.
If this happens, catch it, and retry until a real network interface becomes
available.
It may be that this should tie into the NetWatcher, and rebind whenever
an interface comes up. Needs testing..
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Finally.
Last bug fixes here: Send PairResp with same UUID in the PairReq.
Fix off-by-one in code that filters out our own pairing messages.
Also reworked the pairing alerts, which are still slightly buggy.
|
|
|
|
|
| |
This avoids us responding to our own pairing messages, as well
as ignoring any out of order messages that might be received somehow.
|
| |
|
|
|
|
|
|
|
| |
Pair requests the the same UUID are part of the same pairing session,
which allows us to detect attempts to brute force the shared secret,
as that will result in pair requests with the same UUID that are
not verified with the right secret.
|
| |
|
|
|
|
|
| |
Including rollback of adding the key when a pairing response
gets canceled by the user.
|
| |
|
| |
|
|
|
|
| |
Has a button to cancel the request.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
They work fine. But I had to go to a lot of trouble to get Yesod to render
routes in a pure function. It may instead make more sense to have each
alert have an assocated IO action, and a single route that runs the IO
action of a given alert id. I just wish I'd realized that before the past
several hours of struggling with something Yesod really doesn't want to
allow.
|
| |
|
|
|
|
|
| |
Due to being multicast, requests sent by one thread are received by the
listener in another thread.
|
| |
|
|
|