No Response from accessory after restart

[ewilken]

No Response from accessory after restart

[Roba1993]

@ewilken I have looked at your implementation and have not detected anything wrong.
So I tried to just serialize and deserialize the KeyPair with the following code

let mut csprng = OsRng {};
    let key = Ed25519Keypair::generate(&mut csprng);

    println!("KEY: {:?}", key);    
    let bytes = serde_json::to_vec(&key).unwrap();
    let new_key : Ed25519Keypair = serde_json::from_slice(&bytes).unwrap();
    println!("NEW KEY: {:?}", new_key);

The the following failure appears

KEY: Keypair { secret: SecretKey: [188, 223, 177, 97, 175, 196, 28, 195, 116, 104, 241, 76, 219, 172, 196, 45, 176, 250, 66, 110, 77, 147, 78, 107, 199, 66, 182, 251, 71, 30, 10, 222], public: PublicKey(CompressedEdwardsY: [64, 201, 56, 196, 42, 232, 143, 225, 121, 18, 202, 17, 73, 190, 127, 101, 173, 95, 238, 178, 145, 122, 91, 127, 50, 33, 169, 241, 225, 9, 81, 188]), EdwardsPoint{
	X: FieldElement51([687946466869619, 107360584677275, 298199894910233, 1211619723616352, 651182423837054]),
	Y: FieldElement51([1508208775280693, 158435790617717, 1644081860630336, 1874423471707253, 122428325338618]),
	Z: FieldElement51([261165033366735, 1451298753928703, 1804282745001967, 391348286045173, 1385537188942500]),
	T: FieldElement51([702606775487581, 471739482787318, 1120642760984846, 1234200999468521, 610789072190272])
}) }
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("invalid type: sequence, expected An ed25519 keypair, 64 bytes in total where the secret key is the first 32 bytes and is in unexpanded form, and the second 32 bytes is a compressed point for a public key.", line: 1, column: 1)', src/main.rs:21:36
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This seems like, the ed25519_dalekcrate has a bug here.
I will try to deep dive on that next.

[voider1]

Same issue here, I think it's because the mac address gets randomly generated on each start. I tried assigning my own PIN and mac address using the Config struct, but the PIN I set doesn't matter, it's always the default. So I guess it also doesn't really set your mac address.

[voider1]

So I've been debugging over the last couple of days and I've made sure the MAC address doesn't get randomly generated. I haven't been able to figure out why this happens.

[nusairat]

yeah i was going to create the Pin is another defect, I think i may try to debug that if i ever get half a chance.

[Roba1993]

Hi guys,

I have exactly the same problem:

[2020-07-13T14:55:54Z INFO  hap::transport::http::server] binding TCP listener on 192.168.178.22:32000
[2020-07-13T14:55:57Z INFO  hap::transport::http::handler::pair_verify] pair verify M1: received verify start request
[2020-07-13T14:55:57Z INFO  hap::transport::http::handler::pair_verify] pair verify M2: sending verify start response
[2020-07-13T14:56:02Z INFO  hap::transport::http::handler::pair_verify] pair verify M1: received verify start request
[2020-07-13T14:56:02Z INFO  hap::transport::http::handler::pair_verify] pair verify M2: sending verify start response

After some more debugging, I got this:

[2020-07-13T17:39:48Z DEBUG hap::transport::mdns] announcing mDNS: ["md=Acme Lightbulb", "id=0a:14:1e:28:32:3c", "c#=2", "s#=1", "ci=5", "pv=1.0", "sf=1", "ff=0"]
[2020-07-13T17:39:48Z DEBUG hap::transport::http::server] incoming TCP stream from 192.168.178.47:57859
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] polling incoming TCP stream receiver
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] received 168 Bytes on incoming TCP stream receiver
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] polling incoming TCP stream receiver
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] incoing TCP stream error: receiver channel is empty
[2020-07-13T17:39:48Z DEBUG hap::transport::http::handler::pair_verify] received body: [6, 1, 1, 3, 32, 242, 178, 179, 143, 238, 232, 152, 75, 146, 118, 230, 73, 27, 133, 93, 169, 124, 235, 88, 97, 134, 133, 159, 116, 226, 235, 61, 208, 201, 87, 53, 114]
[2020-07-13T17:39:48Z INFO  hap::transport::http::handler::pair_verify] pair verify M1: received verify start request
[2020-07-13T17:39:48Z INFO  hap::transport::http::handler::pair_verify] pair verify M2: sending verify start response
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] writing 117 Bytes to outgoing TCP stream sender
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] wrote 117 Bytes to outgoing TCP stream sender
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] writing 140 Bytes to outgoing TCP stream sender
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] wrote 140 Bytes to outgoing TCP stream sender
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] writing 117 Bytes to outgoing TCP stream
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] wrote 117 Bytes to outgoing TCP stream
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] writing 140 Bytes to outgoing TCP stream
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] wrote 140 Bytes to outgoing TCP stream
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] polling incoming TCP stream receiver
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] incoing TCP stream error: receiver channel is empty
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] polling incoming TCP stream receiver
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] incoing TCP stream error: receiver channel is empty
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] polling incoming TCP stream receiver
[2020-07-13T17:39:48Z DEBUG hap::transport::tcp] received 0 Bytes on incoing TCP stream receiver
[2020-07-13T17:39:49Z DEBUG hap::transport::mdns] announcing mDNS: ["md=Acme Lightbulb", "id=0a:14:1e:28:32:3c", "c#=2", "s#=1", "ci=5", "pv=1.0", "sf=1", "ff=0"]

Which means 2 polls which are failing and the last poll don't have a response.
Unfortunately I don't know the protocol. But I assume, it is an error code.
This means the M2 pairing answer was not right....

[ewilken]

Hey! Thanks a lot for sharing and sorry for the unresponsiveness here lately. The issue is most likely due to the Ed25519 keypair of the server not being correctly persisted over program restarts. With the redesigned API, the keypair is stored inside the Config struct that gets passed to the server. So the Config needs to be explicitly saved to and restored from the Storage (as shown in the new examples). The default() behavior of Config is to just generate a new keypair, which the iOS controller obviously doesn't accept.

Unfortunately, the deserialization of the Config is currently still broken. That's one of the quirks I need to iron out before we're ready for an 0.1 beta release. I'm hoping to get it ready in the next few days.

[Roba1993]

With the pre-release 4 of the ´ed25519_dalek´crate the bug seems to be fixed.
I will try to update to that version, which seems not to work without change on the hap-rs side.
Let me try this today....