search for: receive_udppacket

...ve got more changes on my to-do list, but I want to ensure I'm making my changes against the right branch. * I'm working with trunk now. I don't think its TCP tunneling is as secure as the UDP tunneling. It looks like its IVs and HMACs are added and verified in send_udppacket and receive_udppacket. The TCP connection encrypts but doesn't have these anti-modification features. (Right?) * The 1.0-gnutls branch lets gnutls take care of encryption for the TCP connection. I'm confident this is secure. * The 2.0 branch appears to be all reorganized but not functional yet. A coupl...

...%s (%s) with unknown source and/or destination ID", n->name, n->hostname); - return; } - if(to != myself) { - send_sptps_data_priv(to, n, 0, DATA(&pkt), pkt.len - 2 * sizeof(node_id_t)); - return; - } - } else { - direct = true; - from = n; + pkt[i].offset = 0; + if(!receive_udppacket(from, &pkt[i])) + continue; + + n->sock = ls - listen_socket; + if(direct && sockaddrcmp(&addr[i], &n->address)) + update_node_udp(n, &addr[i]); } - - pkt.offset = 0; - if(!receive_udppacket(from, &pkt)) - return; - - n->sock = ls - listen_socket; - if(...

--- doc/tinc.conf.5.in | 3 +++ src/linux/device.c | 7 +++++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/doc/tinc.conf.5.in b/doc/tinc.conf.5.in index 2bfd5fe..01f7f81 100644 --- a/doc/tinc.conf.5.in +++ b/doc/tinc.conf.5.in @@ -255,6 +255,9 @@ a lookup if your DNS server is not responding. This does not affect resolving hostnames to IP addresses from the host

...{ - hostname = sockaddr2hostname(&from); + hostname = sockaddr2hostname(from); logger(LOG_WARNING, "Received UDP packet from unknown source %s", hostname); free(hostname); return; @@ -730,5 +725,55 @@ void handle_incoming_vpn_data(int sock) { n->sock = sock; - receive_udppacket(n, &pkt); + receive_udppacket(n, pkt); +} + +void handle_incoming_vpn_data(int sock) { + vpn_packet_t pkt[MAX_MSG]; + sockaddr_t from[MAX_MSG]; +#ifdef HAVE_RECVMMSG + struct mmsghdr msg[MAX_MSG]; + struct iovec iov[MAX_MSG]; +#else + socklen_t fromlen = sizeof(from[0]); +#endif + int num = 1,...

...send_sptps_data_priv(to, n, 0, DATA(&pkt), pkt.len - 2 * sizeof(node_id_t)); > - return; > - } > - } else { > - direct = true; > - from = n; > + pkt[i].offset = 0; > + if(!receive_udppacket(from, &pkt[i])) > + continue; > + > + n->sock = ls - listen_socket; > + if(direct && sockaddrcmp(&addr[i], &n->address)) > + update_node_udp(n, &addr[i]); > } > - >...

Hi all I try to use tinc within my network, but I find almost all mtu probe take 30 times to fix, it's never really fix at all. after read code, i think the problem case by function receive_udppacket(); and line : origin -= MTU / 64 + 20; here , MTU / 64 + 20 =43, this means, every time we send a mtu probe packet, we get a reply smaller then what we send. review the commit log, the line added for keep saft to compress. for capable with current version, I can't remove this line, so I add...

Hi Guus, while checking the source code, I stumbled upon PMTU Discovery. I've got a question regarding the process of sending/receiving PMTU packets. As I understand, the packet flow is like this: 1 .Tinc creates a packet with a specific payload length to send it as an PMTU probe. (The data part is just some random bytes.) 2. This packet gets compressed and sent

...gth, (unsigned char *)hmac, NULL); - return !memcmp(hmac, (char *) &inpkt->seqno + inpkt->len - n->inmaclength, n->inmaclength); + return !memcmp(hmac, (char *) &inpkt->seqno + inpkt->len - sizeof inpkt->flags - n->inmaclength, n->inmaclength); } static void receive_udppacket(node_t *n, vpn_packet_t *inpkt) { @@ -260,6 +261,10 @@ n->name, n->hostname); return; } + + /* Remove flags */ + + inpkt->len -= sizeof(inpkt->flags); /* Check packet length */ @@ -367,6 +372,7 @@ void receive_tcppacket(connection_t *c, char *buffer, int len) { vpn...