search for: protocol_auth

...0 1D8F4C5319953417CA04771401B07EC683E6802AD3C29B024AB14AB24E783EA9BD3DF125A71347 C258DB235BE0152D9040AF039403DDB1ED76A908C5C19893A180723AE8623B1716DA9B7DCB280D 443FB2B787A2C2647249D43C07ACE0A7F4FA0288DEE53EABFE9360A008E03416084F2AA4E38D21 Got fatal signal 11 (Segmentation fault) Checkpoint trace: protocol_auth.c:215 <- protocol.c:135 <- meta.c:103 <- net.c:266 <- net.c:119 <- event.c:93 <- meta.c:44 <- protocol.c:74 <- protocol_auth.c:142 <- protocol_auth.c:131 <- conf.c:146 <- conf.c:106 <- conf.c:146 <- conf.c:106 <- conf.c:183 <- conf.c:106... dows anyo...

...,10 @@ int reachable:1; /* 1 if this node is reachable in the graph */ int indirect:1; /* 1 if this node is not directly reachable by us */ int unused:26; - }; +}; + +typedef union node_status_t { + struct node_st_bits st; uint32_t value; } node_status_t; diff -ubr tinc-1.0.8/src/protocol_auth.c tinc-1.0.8.my/src/protocol_auth.c --- tinc-1.0.8/src/protocol_auth.c Wed May 16 16:42:14 2007 +++ tinc-1.0.8.my/src/protocol_auth.c Thu Sep 25 11:19:53 2008 @@ -196,7 +196,7 @@ return false; } - c->status.encryptout = true; + c->status.st.encryptout = true; } return x; @@ -...

...sk ... What _exactly_ are the consequences and risks of using --bypass-security ? My network sniffs as well as an earlier posting here seem to show that the packets are still not sent in clear text, but what does the --bypass-security turn off if not encryption? As far as I think to understand protocol_auth.c, it - switches of the check of RSA keys - suppresses the checking of IndirectData and TCPOnly settings (therefore forcing UDP usage?) The "only" security leak seems to be that a foreign system might join the VPN, if it has the same tinc configuration as the real partner _and_ "s...

I'm using Tinc 1.1pre14 and I'm trying to connect a node that is behind a firewall that blocks all non-standard ports. I set up a rule in the server to redirect port 25 (that is not used in the server right now) to port 655, both in tcp and udp protocols, and set up the port 25 in the server host configuration file. The client can reach the server, but after the initial sync and key

...e it attempt to send the packet directly to C. Question: does A also attempt to open a meta connection to C? If not how can it check that the packets to C arrive to destination? More generally I am interested in understanding how 'indirect' connections work in tinc. For instance I see in `protocol_auth.c` that TCPOnly implies 'OPTION_INDIRECT' (as documented in the doc), but it seems (according to the docs) like tinc can still try to send data via the TCP meta connection? Thanks in advance! Damien Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: &lt...

...reason why you're experiencing this problem is because tinc does not use the connection TCP port to determine which port to send UDP packets to. Instead, it uses the port that is *advertised* by the other node. https://github.com/gsliepen/tinc/blob/06b820133285f83f7e1a839cccbed13358b84081/src/protocol_auth.c#L886 That means that if node A is configured with UDP port 655, that's the UDP port it will advertise to node B when it connects and that's what node B will use, even if node B used a different TCP port to establish the metaconnection. I'm not sure why you didn't encounter this...

...Cipher = aes-128-cbc Digest = sha512 I am a bit surprised that the router's tinc manages to talk to Debian's tinc, when I set a cipher suite that the router's SSL library does not recognise. I looked at the log, it triggers this line: https://github.com/gsliepen/tinc/blob/master/src/protocol_auth.c#L297 I am just wondering, what happens after metakey_h() returns false? Does tinc simply fall bacck to a more common cipher? Do the two clients neogiate what to fallback to? FF

...-O2 -DCONFDIR=\"/usr/local/etc\" -DLOCALEDIR=\"/usr/local/share/locale\" -DLOCALSTATEDIR=\"/usr/local/var\" -g -O2 -o tincd conf.o connection.o edge.o event.o graph.o logger.o meta.o net.o net_packet.o net_setup.o net_socket.o netutl.o node.o process.o protocol.o protocol_auth.o protocol_edge.o protocol_misc.o protocol_key.o protocol_subnet.o route.o subnet.o tincd.o ../lib/libvpn.a -lcrypto -lz -llzo graph.o: In function `sssp_bfs':/usr/src/tinc/src/graph.c:278: undefined reference to `device' ... tincd.o: In function `main':/usr/src/tinc/src/tincd.c:50...

...e -L/opt/local/lib -o tincd avl_tree.o conf.o connection.o dropin.o dummy_device.o edge.o event.o fake-getaddrinfo.o fake-getnameinfo.o getopt.o getopt1.o graph.o list.o logger.o meta.o multicast_device.o net.o net_packet.o net_setup.o net_socket.o netutl.o node.o pidfile.o process.o protocol.o protocol_auth.o protocol_edge.o protocol_misc.o protocol_key.o protocol_subnet.o raw_socket_device.o route.o subnet.o tincd.o utils.o xmalloc.o bsd/device.o -lcrypto -lz -llzo2 clang: warning: argument unused during compilation: '-pie' Undefined symbols for architecture x86_64: "_res_9...

...a.c U tinc/src/meta.h U tinc/src/net.c U tinc/src/net.h U tinc/src/net_packet.c U tinc/src/net_setup.c U tinc/src/net_socket.c U tinc/src/netutl.c U tinc/src/netutl.h U tinc/src/node.c U tinc/src/node.h U tinc/src/process.c U tinc/src/process.h U tinc/src/protocol.c U tinc/src/protocol.h U tinc/src/protocol_auth.c U tinc/src/protocol_edge.c U tinc/src/protocol_key.c U tinc/src/protocol_misc.c U tinc/src/protocol_subnet.c U tinc/src/route.c U tinc/src/route.h U tinc/src/subnet.c U tinc/src/subnet.h U tinc/src/tincd.c cvs server: Updating tinc/src/cygwin U tinc/src/cygwin/device.c cvs server: Updating tinc/s...