-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathHACKING
100 lines (84 loc) · 3.92 KB
/
HACKING
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
HOW to do multiple networks???
- currently creating an adapter for each network
k, addresses weren't tracking true addresses, they were being overwritten by relay stuff. 3 options:
1) keep separate list of relays. seems like a lot of extra checks
*->2) keep peer.address as the relay address, and add a new field for DC addresses
3) keep peer.address unchanged unless we have a DC
we need to know the DC addresses to try and establish a DC on a relay peer.
for new handhsake version: 3 options
1) include a relay (TTL) field for each packet (most work, most overhead)
2) send relay count with handshake packet (most like original version, know relays at connection)
3) initiate connection with unknown relay count, then update with a 'tracert' packet: easiest, but may have difficulties selecting "best" path for a relay
TODO:
connection/peer history? persistant?
separate log lvl for file and console: requires changing interface's log level setter
periodically try to DC relay peers?
should we try hole punching NATs?
tun not currently worked on/working
TAP:
iperf from dev to naz: 17.8
iperf from naz to dev: 33.7
TUN:
iperf from dev to naz: 18.0
iperf from naz to dev: 28.8
after adding weakrefs:
TAP: iperf -t 30
iperf from naz to dev: 22.7 (second try: 32.7)
iperf from dev to naz: 22.5-9
bi: 8.51
revno: 62
naz > dev 30.4
dev > naz 19.6
with AESCrypterPP (revno 62):
naz > dev 30.5
dev > naz 21.7
with AESCrypter (revno 62):
naz > dev 30
dev > naz 21
revno: 68+edits
naz > XP: 9.2
XP > naz: 11.2
#naz > dev: 20 cpu busy
#dev > naz: 16.5
... new benchmark, iperf to lxc (pretty much the same both ways)
revno: 89 (old version)
naz > eye: 67.6 Mb/s
revno: 97/hsrelayz
naz > eye: 71.4 Mb/s
revno: 101/hsrelayz
naz > eye: 69.7
revno: 102/hsrelayz
naz > eye: 70.6
... new benchmark, iperf between 2 arkose containers on new i5 system (arkose v 1.4)
revno: 103
183 Mb/s
restructure: (w/SSL) revno 119
165 Mbs
restructure: (w/oSSL) revno 120
205 Mbs
revno 121: 210 Mbs
revno 123: 197 Mbs
revno 124: 208 Mbs
revno 130: 194 Mbs
revno 150: 191 Mbs
revno 175: 185 Mbs
revno 190: 185 Mbs
revno 191: 153 Mbs (read size changed from 5120B to 1024*1024B)
revno 200: 163 Mbs
revno 220: 158 Mbs
revno 250: 150 Mbs
revno 262: 150 Mbs
revno 263: 177 Mbs (read size back to 5120B)
revno 266: 197 Mbs (introduce lazy log evals)
revno 269: 203 Mbs
revno 272: 202 Mbs
announces are kinda numerous when a new peer gets added. there is an announce when a new peer is added as a relay from an announce and then a second announce if we can direct-connect to them. This could end up causing a lot of unnecessary announces.
Instead, I could make an incoming announce cause a direct connect attempt, and only add the peer as a relay if that fails (via deferred). The downside of this is that it could take longer for a peer's presence to propagate through the net.
The first method would propagate the peer as relays through the network really fast and then each relay would be updated when a direct connection is made, causing extra announces. If there were a lot of peers this could cause a lot of traffic...?
Crytpo:
I use a larger, 'network' key that is used for HMAC on the per-session generated keys.
Packet Format:
Currently, if it is a 'data' packet, or a packet that goes over the TUN wire, the packet is just [type-2B][data]. Since data is an IP packet, src and destination virtual IPs are included.
For non-data packets, the format is [type-2B][id-2B][dest-4B][src-4B][data]. The id field is there so we can send an ack packet with the same value to ensure delivery. The src and dsg fields are used for routing.
Routing relay packets:
Reg/Announce/Peer exchange packets contain .relay field, which are used to assign a 'relay' address to peers that don't have direct connections. Whenever packet comes in with info about a peer containing a better relay field, the source of that packet is used as the new relay address. There is probably a better way to do this.