| 75 | } |
| 76 | |
| 77 | static bool get_data_details_onionreply(struct payment_result *result, |
| 78 | const char *buffer, |
| 79 | const jsmntok_t *datatok, |
| 80 | struct secret *shared_secrets) |
| 81 | { |
| 82 | const tal_t *this_ctx = tal(result, tal_t); |
| 83 | const jsmntok_t *onionreplytok; |
| 84 | struct onionreply *onionreply, *wonionreply; |
| 85 | const u8 *replymsg; |
| 86 | int index; |
| 87 | |
| 88 | onionreplytok = json_get_member(buffer, datatok, "onionreply"); |
| 89 | if (!onionreplytok || !shared_secrets) |
| 90 | goto fail; |
| 91 | onionreply = new_onionreply( |
| 92 | this_ctx, |
| 93 | take(json_tok_bin_from_hex(this_ctx, buffer, onionreplytok))); |
| 94 | assert(onionreply); |
| 95 | /* FIXME: It seems that lightningd will unwrap top portion of the |
| 96 | * onionreply for us before serializing it, while unwrap_onionreply will |
| 97 | * try to do the entire unwraping. It would be a better API if either |
| 98 | * lightningd unwraps the entire thing or it doesn't do any unwraping. |
| 99 | * Also it wouldn't hurt if injectpaymentonion accepted the shared |
| 100 | * secrets to allow lightningd do the decoding for us. */ |
| 101 | wonionreply = wrap_onionreply(this_ctx, &shared_secrets[0], onionreply); |
| 102 | replymsg = unwrap_onionreply(this_ctx, shared_secrets, |
| 103 | tal_count(shared_secrets), |
| 104 | wonionreply, &index); |
| 105 | if (replymsg) { |
| 106 | result->failcode = tal(result, enum onion_wire); |
| 107 | *result->failcode = fromwire_peektype(replymsg); |
| 108 | |
| 109 | result->erring_index = tal(result, u32); |
| 110 | *result->erring_index = index; |
| 111 | } |
| 112 | tal_free(this_ctx); |
| 113 | return true; |
| 114 | fail: |
| 115 | tal_free(this_ctx); |
| 116 | return false; |
| 117 | } |
| 118 | |
| 119 | static bool get_data_details(struct payment_result *result, |
| 120 | const char *buffer, |
no test coverage detected