gsup_router.c: gsup_route_find(): support blob

Do not require the blob (addr, addr_len) passed to gsup_route_find()
to be nul-terminated. We already have the length, so the nul-termination
is redundant.

This is needed for the upcoming gsup message forwarding patch [1]: we
want to be able to directly pass non-nul-terminated source and
destination name blobs to gsup_route_find().

I have looked into fixing all code that calls gsup_route_find() to never
pass a nul-terminated blob combination. But this is a can of worms,
because it involves both gsup client and server code. Wireshark shows
that clients are sending the nul-terminated string in TLV IEs of IPA
messages. The server assumes that this is the case in various places.
So we would need to fix it in both (server and client), but then we
would lose backwards compatibility with old servers and clients.

[1]: change-id Ia4f345abc877baaf0a8f73b8988e6514d9589bf5

Related: OS#3793
Change-Id: I01a45900e14d41bcd338f50ad85d9fabf2c61405
This commit is contained in:
Oliver Smith 2019-02-26 10:59:13 +01:00 committed by Neels Hofmeyr
parent 9ac494f486
commit f1b9e0246e
1 changed files with 8 additions and 2 deletions

View File

@ -40,8 +40,14 @@ struct osmo_gsup_conn *gsup_route_find(struct osmo_gsup_server *gs,
struct gsup_route *gr;
llist_for_each_entry(gr, &gs->routes, list) {
if (talloc_total_size(gr->addr) == addrlen &&
!memcmp(gr->addr, addr, addrlen))
size_t gr_addrlen = talloc_total_size(gr->addr); /* gr->addr is a nul-terminated string */
/* FIXME: despite passing addrlen, a lot of code assumes that addr is also nul-terminated */
if (gr_addrlen == addrlen && !memcmp(gr->addr, addr, addrlen))
return gr->conn;
/* Compare addr as non-nul-terminated blob */
if (gr_addrlen - 1 == addrlen && !memcmp(gr->addr, addr, addrlen))
return gr->conn;
}
return NULL;