ames: add stun client for informal pings #509
Conversation
pkg/vere/io/ames.c
Outdated
|
|
||
| c3_y buf_y[20] = {0}; | ||
| buf_y[1] = 0x1; // message type "binding request" | ||
| memcpy(buf_y + 4, sam_u->sun_u.tid_y, 16); // TODO convert byte order? |
There was a problem hiding this comment.
I believe this needs to have the STUN "magic cookie", followed by 12 bytes of randomness. Something like:
c3_y buf_y[20] = {
0x0, 0x1, // binding req
0x0, 0x0, // len
0x21, 0x12, 0xA4, 0x42, // cookie
0x0
};
memcpy(buf_y + 8, sam_u->sun_u.tid_y, 12);
| } break; | ||
| default: assert("programmer error"); | ||
| } | ||
| } |
There was a problem hiding this comment.
This should either be called from _ames_recv_cb() (if we can always distinguish STUN responses preemptively), or from _ames_hear() (as a fallback if a packet is not a valid ames packet).
I believe the response will look like:
c3_y rep_y[20] = {
0x1, 0x1, // binding resp
0x??, 0x??, // len (including optional attributes)
0x21, 0x12, 0xA4, 0x42, // cookie
... original 12 bytes of randomness
... XOR-mapped address attribute
}
An ames header will never begin with { 0x1, 0x1 } (binding success response) or { 0x1, 0x11 } (binding error response), so that plus a sanity check of the constant "STUN cookie" should be enough to distinguish protocols.
There was a problem hiding this comment.
I'm going off the rfc (https://www.rfc-editor.org/rfc/rfc8489), and sanity checking that with packet captures (https://www.cloudshark.org/captures/4686b8430477).
|
Closed in favor of #545 |
Implements the client side of UIP-0112: Informal Ping.
Very much still a work in progress. Next step is to wire up a DNS lookup for the sponsoring galaxy into the STUN client so it knows where to send the packets. It does compile, though.