cinfo->mtx_ MUST be locked before socketsMutex, so it SHOULD never
be locked in a callback. Retrigger the lock in its own thread avoid
a deadlock there.

GitLab: #20
Change-Id: If17af7db81d8ca2b990629446b5d78dc11a785b1

Change-Id: Ib9466e7b7a8f093620949ad4557817c26e52566e

Each tool must create its own iceFactory.

Change-Id: I9a6ba240a06dd1c344097a99ebebc6464cafd018

Change-Id: I6c252a9f9d6de1c4f6d85043d3ed238eec747244

Change-Id: I4c0d5cd67ea41f3285ccc1e203942222c1cf15fd

Amna Snene authored 1 year ago and Sébastien Blin committed 1 year ago

dvpn tool is a VPN based on the DHTNET stack. The tool creates a TUN interface to efficiently route traffic to the destination.

For the client side, upon establishing a connection, the tool creates a TUN interface and sets it as the default route in the routing table, excluding traffic destined for the peer. On the server side, a TUN interface is created, and NAT configuration is used to respond to client requests.

Change-Id: I43ff43982930d97502a64d15aeb2c8df283bdda9
GitLab: #13

Amna Snene authored 1 year ago and Sébastien Blin committed 1 year ago

Change-Id: If1dbbe6ae8a7a9b6abc740507645a04da1adba7e

If we're joining and already shutdown, no need to perform complex
code.

GitLab: #19
Change-Id: Ie8bc24361c9e1ab71b26f19711cce928a2b64077

Andreas Traczyk authored 1 year ago and Adrien Béraud committed 1 year ago

https://review.jami.net/c/dhtnet/+/26809 revisited

Change-Id: Ib8e20e6322fd06ca0a2acb25823549e3271ca593

Sébastien Blin authored 1 year ago and Adrien Béraud committed 1 year ago

Else, a deadlock may occurs

jami-daemon#936
Change-Id: Ib4a02845bd0b7e5d482f3fc5f5c8b8a01a50a80f

Change-Id: Icf73d406d749168ff22652b0b27fa241fb2ed047

Amna Snene authored 1 year ago and Sébastien Blin committed 1 year ago

Change-Id: Id200b73da4c35e001b69749bc32ca3dcc5eb989a
GitLab: #14

issue: when clicking on this link from local, it redirects to the github file.
solution: redirect to local file.
pros: it will also helps when clicking the link on gitlab to not be redirected to github.
Change-Id: I2b8cdc83837b003b067d04eb7f42c3fdedc5cb42

Change-Id: Ic2397eee6ea67fc5d0b76ce77bbd8e000f90177c

Change-Id: Ic9bd9a2b570b334cd84652cae97c9a1ffe3350b5

It seems there are scenarios in which the ConnectionInfo is disposed during the on-ready callback, resulting in the TlsSocketEndpoint's callback mutex being locked twice on the same thread.

Change-Id: I401b3c70ba81708e4a3d4ecf3f099f0292c2ff04

Change-Id: Ib7f3ae5a49ee73e4c3c9c97b7ca1e2788d241bf3

Change-Id: Ic24123e329b221f5f1e24d3df6f3cc93649c4591

To check if we're connected with a device

Change-Id: I9d0659c3d6d5e305baabd5c4156a820754bae377

In the else branch, `s` is always an invalid iterator.
Use `us` instead.

Change-Id: Ib517dce22f3bde103f753b325e919f86db299623

Change-Id: I8732dfaab77bc147763b7591d88e8ca476566627

Change-Id: Ia0c3c975961bf96c6db80ed8f5c7b45bdee7e9cb

Amna Snene authored 1 year ago and Adrien Béraud committed 1 year ago

Change-Id: I1f32ffe43a51535ec64355186a1c7cc13e6be281

Amna Snene authored 1 year ago and Adrien Béraud committed 1 year ago

Change-Id: I30ca8601fa2e221158b28a260bb7893d1ff8aac3

Amna Snene authored 1 year ago and Adrien Béraud committed 1 year ago

Change-Id: I18622e6064494c19952ddafc21d81a40da841cc7

Amna Snene authored 1 year ago and Adrien Béraud committed 1 year ago

Change-Id: Iaaee0ed079c8f5d181776a08b8865c9e637d3f29

Change-Id: I03cf7bead8bcf5760d035e32a82ec3412ef6fea9

Change-Id: I4030534348074592b6f2a3ff8c1f8f2cb4438ca3

Change-Id: Ie1338675efb16783a68a344da2a164632c0e088a

Change-Id: I869fcb8903654558c39afa4f9d4aaefecd7cb40a

Change-Id: Idbd2d136cf6725bf198afeb4ebe3284f9a817744

Change-Id: Ifdb26180460343fab1cf39a770d90d924f8ef263

Adrien Béraud authored 1 year ago and Sébastien Blin committed 1 year ago

Change-Id: I4c29a9117414da46bc57af6649763cecea6e6918

Adrien Béraud authored 1 year ago and Sébastien Blin committed 1 year ago

Change-Id: Ie5fe090494e30f99587d048dad709b8ac50a3cef

Change-Id: I46a4563e24f3a427931be886b726a585fe823eff

Change-Id: I8ef7ed0336a02692fb3ec0959f2f7f8891c52808

If a TLS handshake was failing, the device information was not
correctly removed, causing a connection to be detected and further
communications to fail.
So, while monitoring, some connections were stuck in "Connecting TLS".

Moreover, remove waitForReady because it's unused

Change-Id: I8350d7f8731311ab46db78fb26328edc0dcb31dc

Avoids blocking on socket write sequentially,
and prevents locking while blocked on a write.

Change-Id: Ia9e6e0f3e0d73e070f90d988f351d782932a1a07

Change-Id: I93782be5cd93c824d14e7c9871be47ed6527d836

Change-Id: I768da190ea9dc891aba059ab9b44664897a9fffe