Closed s-tikhomirov closed 4 years ago
m-schmoock
commented
4 years ago the very channel between src and dst is excluded, and maxhops = 1. I expect it to either return with "No route found", or return a parallel channel between src and dst if one exists.
Hmmm, ist your case assuming that there can be two or channels between two c-lightning instances?
For a lot of reasons, this is currently not supported (and likely never will), though the daemon should not crash in any case.
s-tikhomirov
commented
4 years ago assuming that there can be two or channels between two c-lightning instances
I'm assuming there can be two or more channels between two LN instances in general. I know c-lightning doesn't support this, but other implementations do (and the BOLTs allow it). Moreover, looking at network explorers, I see that this is not uncommon.
m-schmoock
commented
4 years ago im trying to build a dedicated testcase that triggers this, no luck yet...
m-schmoock
commented
4 years ago can you have a quick retry of your case on lastet master sources?
m-schmoock
commented
4 years ago Im trying something like this:
def test_find_parallel_route(node_factory, bitcoind):
# SETUP
# l1 --> l2 <--+
# | |
# +---> l3 ---+
l1, l2, l3 = node_factory.get_nodes(3)
l1.connect(l2)
l1.connect(l3)
l3.connect(l2)
nodes = [l1, l2, l3]
scid12 = l1.fund_channel(l2, 10**6)
scid13 = l1.fund_channel(l3, 10**6)
scid32 = l3.fund_channel(l2, 10**6)
scids = [scid12, scid13, scid32]
l1id = l1.rpc.getinfo()["id"]
l2id = l2.rpc.getinfo()["id"]
l3id = l3.rpc.getinfo()["id"]
# wait for each others gossip
bitcoind.generate_block(6)
for n in nodes:
for scid in scids:
n.wait_channel_active(scid)
# bring the channels to some balance, so routing has more options
l1.pay(l2, Millisatoshi(10**9) / 2)
l1.pay(l3, Millisatoshi(10**9) / 2)
l3.pay(l2, Millisatoshi(10**9) / 2)
amount = Millisatoshi(10**9) / 4
# now try to find a one-hop alternative route from
# l1 to l2 or vice versa on both nodes.
with pytest.raises(RpcError, match=r'Could not find a route'):
r = l1.rpc.getroute(
l2id,
amount,
riskfactor=1,
fromid=l1id,
maxhops=1,
exclude=[scid12 + '/0', scid12 + '/1'])
with pytest.raises(RpcError, match=r'Could not find a route'):
r = l1.rpc.getroute(
l1id,
amount,
riskfactor=1,
fromid=l2id,
maxhops=1,
exclude=[scid12 + '/0', scid12 + '/1'])
with pytest.raises(RpcError, match=r'Could not find a route'):
r = l2.rpc.getroute(
l2id,
amount,
riskfactor=1,
fromid=l1id,
maxhops=1,
exclude=[scid12 + '/0', scid12 + '/1'])
with pytest.raises(RpcError, match=r'Could not find a route'):
r = l2.rpc.getroute(
l1id,
amount,
riskfactor=1,
fromid=l2id,
maxhops=1,
exclude=[scid12 + '/0', scid12 + '/1'])Maybe related to the channels capacity, as you pointed out using an amount near to the total capacity 4294840000msat causes it for testnet 1451585x82x0 which has 5MegaSat capacity
m-schmoock
commented
4 years ago Nah, I cant reproduce this with clnd with such a testcase for the very reason it does not support multiple channels between peers. I need to construct the test in a way, that gossip sees parallel channels somewhere else.
s-tikhomirov
commented
4 years ago Adding a log with log-level=DEBUG:
a quick retry of your case on lastet master sources
I'm a bit reluctant as I worry to break my current setup... Would I be able to roll back easily?
s-tikhomirov
commented
4 years ago for the very reason it does not support multiple channels between peers
But as far as I see on 1ML, this is the only channel between those peers...
Maybe related to the channels capacity
But it's not that close to the limit, 700+k sats left to total capacity. It's close to the max HTLC amount of 4294967295msat, that's true.
m-schmoock
commented
4 years ago yup its just one between those particular nodes. The assertion that raises is:
gossipd/routing.c +1223
SUPERVERBOSE("Running shortest path from %s -> %s",
type_to_string(tmpctx, struct node_id, &dst->id),
type_to_string(tmpctx, struct node_id, &src->id));
dijkstra(rstate, dst, NULL, riskfactor, 1, fuzz, base_seed,
unvisited, shortest_cost_function);
dijkstra_cleanup(unvisited);
/* This must succeed, since we found a route before */
short_route = build_route(ctx, rstate, dst, src, me, riskfactor, 1,
fuzz, base_seed, fee);
assert(short_route);
rustyrussell
commented
4 years ago Reproduced here:
$ lightning-cli getroute id=0277622bf4c497475960bf91bd3c673a4cb4e9b589cebfde9700c197b3989cc1b8 fromid=03367c6e59a9924d2eb188ce43413dd6c76db102c3c0516d51ccea324b490e3bfa exclude='[1451585x82x0/0, 1451585x82x0/1]' msatoshi=4294840000 maxhops=1 riskfactor=1
lightning-cli: reading response: socket closedFound another case: 1665803x253x1/0 with amount 988781200msat (988781100 is OK):
logTest.txt.
Issue and Steps to Reproduce
I understand that this quite an edge case, still I'd like my lightningd not to crash.
I'm calling
getroutefrom a plugin to find a route betweensrcanddst. For my purposes, I put many restrictions ongetroutefor it to return the specific channel between the two nodes. Among other calls, I callgetroutewhere the very channel betweensrcanddstis excluded, andmaxhops = 1. I expect it to either return with "No route found", or return a parallel channel betweensrcanddstif one exists.For one particular channel on Bitcoin testnet, I run into problems:
I isolated the problem, this is the function which when called from a plugin produces the above effect (with smaller amount it's OK):
Note that my node is connected to 1451585x82x0's source (
0277622bf4c497475960bf91bd3c673a4cb4e9b589cebfde9700c197b3989cc1b8) but not to destination (03367c6e59a9924d2eb188ce43413dd6c76db102c3c0516d51ccea324b490e3bfa). I'm also connected to0303ba0fed62039df562a77bfcec887a9aa0767ff6519f6e2baa1309210544cd3d(its ID also appears in the crash trace).getinfooutput