Michael Tokarev | 23 May 22:50 2009
Picon

several problems....

Hello.

Finally I discovered the mailinglists and subscribed.
Before, I were in #tinc, pinging guus all the time with
various stuff/problems/patches/etc.

So... the problems, in no particular order.

1)
Quite often, after re-starting a client (I run in tunnelserver
mode), no packets are flowing.  Tcpdump shows packets being
sent from client but nothing gets received, and on the server
both send and receive is happening.  Increasing debug level
on client discovers:

May 24 00:15:52 gnome tinc.vpn[2798]: Sending packet of 98 bytes to tls (81.13.33.158 port 655)
May 24 00:15:53 gnome tinc.vpn[2798]: Got unauthenticated packet from tls (81.13.33.158 port 655)

and so on.  That is, the client dislikes packets the server
sends out.

I wasn't able to find any solution to this, EXCEPT of *restarting*
the *server*.  Until it happens, there will be entries like that
in log and nothing received, no matter how much client restarting
takes place.

2)
upgrading client to latest git:

May 24 00:19:32 gnome tinc.vpn[2918]: No minimum MTU established yet for tls (81.13.33.158 port 655),
(Continue reading)

Florian Forster | 26 May 11:41 2009

[PATCH] configure.in: Fix a typo.


Signed-off-by: Florian Forster <octo@...>
---
 configure.in |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/configure.in b/configure.in
index 3cb6a4d..2ce5ce3 100644
--- a/configure.in
+++ b/configure.in
 <at>  <at>  -160,6 +160,6  <at>  <at>  AC_ARG_ENABLE(tracing,

 AC_SUBST(INCLUDES)

-AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/Makefile.in m4/Makefile])
+AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/POTFILES m4/Makefile])

 AC_OUTPUT
--

-- 
1.5.6.5

Guus Sliepen | 26 May 12:30 2009

Re: [PATCH] configure.in: Fix a typo.

On Tue, May 26, 2009 at 11:41:51AM +0200, Florian Forster wrote:

> -AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/Makefile.in m4/Makefile])
> +AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/POTFILES m4/Makefile])

This patch breaks the build system. Why do you think it is necessary?

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>
On Tue, May 26, 2009 at 11:41:51AM +0200, Florian Forster wrote:

> -AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/Makefile.in m4/Makefile])
> +AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/POTFILES m4/Makefile])

This patch breaks the build system. Why do you think it is necessary?

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>
Florian Forster | 26 May 18:06 2009

BindToAddress: TCP connections originate from random source address.

Hi,

I've stumbled upon a problem which I can't solve easily with the
available options in tinc - at least as far as I see. If enlightenment
is all I need, I'll happily accept pointers ;)

I try to establish a connection between two hosts. Each host has
multiple addresses assigned to it's internet interface. A stripped down
list would be:

  Host 1:
    2001:780:0:1e::1
    2001:780:0:1e::60

  Host 2:
    2001:780:106::1
    2001:780:106::f1

With the `BindToAddress' I have bound the daemon(s) to the addresses
2001:780:0:1e::1 and 2001:780:106::1. `netstat(8)' confirms this:

  tcp6 0 0 2001:780:0:1e::1:655 :::* LISTEN 5707/tincd          
  udp6 0 0 2001:780:0:1e::1:655 :::*        5707/tincd

The problem is that `BindToAddress' is only used for *listening* TCP
sockets, not for sending TCP sockets. This is a packet sent by tincd
while trying to establish a connection, captured with tcpdump:

  12:07:19.203429 IP6 2001:780:0:1e::60.42881 > 2001:780:106::1.655: S 2460575975:2460575975(0) win
5760 <mss 1440,sackOK,timestamp 1195871553 0,nop,wscale 7>
(Continue reading)

Guus Sliepen | 26 May 20:43 2009

Re: BindToAddress: TCP connections originate from random source address.

On Tue, May 26, 2009 at 06:06:37PM +0200, Florian Forster wrote:

> I've stumbled upon a problem which I can't solve easily with the
> available options in tinc - at least as far as I see. If enlightenment
> is all I need, I'll happily accept pointers ;)
[...]
> The problem is that `BindToAddress' is only used for *listening* TCP
> sockets, not for sending TCP sockets.
[...]
> On the other hand, the UDP sockets are
> bound and used for both, sending and receiving.
[...]
> The function `handle_incoming_vpn_data' then fails to look up the host
> entry belonging to this IP address and I get the error printed in
> lineĀ 559:
> 
>   Received UDP packet from unknown source 2001:780:0:1e::1
> 
> I propose to check the `BindToAddress' configuration in
> `do_outgoing_connection' and, if set, bind TCP sockets to that address,
> too.

Yes, that is a simple solution that should work. The same change should
probably also be made for BindToInterface then.

> Are there any comments, suggestions, or objections? Otherwise I'd write
> a quick patch..

A patch would be welcome! But I still wonder about the configure.in patch you
sent?
(Continue reading)

Florian Forster | 26 May 22:47 2009

Re: [PATCH] configure.in: Fix a typo.

Hi Guus,

On Tue, May 26, 2009 at 12:30:25PM +0200, Guus Sliepen wrote:
> > -AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/Makefile.in m4/Makefile])
> > +AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/POTFILES m4/Makefile])
> 
> This patch breaks the build system. Why do you think it is necessary?

sorry, I realized later this doesn't solve my problem at all: The
autotools complained about po/Makefile.in being missing and I suspected
a simple typo (`.in' is usually appended by autoconf itself). Looking in
po/, however, I found no `Makefile.in' (nor a `Makefile.am'), but a
`POTFILES.in'...

My guess is that the required `Makefile.am' exists in your working
directory but hasn't been checked into the Git repository..

Regards,
-octo
--

-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
Hi Guus,

On Tue, May 26, 2009 at 12:30:25PM +0200, Guus Sliepen wrote:
> > -AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/Makefile.in m4/Makefile])
(Continue reading)

Florian Forster | 26 May 23:04 2009

Re: [PATCH] configure.in: Fix a typo.

Hi again,

On Tue, May 26, 2009 at 10:47:26PM +0200, Florian Forster wrote:
> My guess is that the required `Makefile.am' exists in your working
> directory but hasn't been checked into the Git repository..

never mind me, I was too near-sighted to think of running
`intltoolize'.. I'm now getting a creative new error, but I'll assume my
own incompetence for now and try again tomorrow.. ;)

-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
Hi again,

On Tue, May 26, 2009 at 10:47:26PM +0200, Florian Forster wrote:
> My guess is that the required `Makefile.am' exists in your working
> directory but hasn't been checked into the Git repository..

never mind me, I was too near-sighted to think of running
`intltoolize'.. I'm now getting a creative new error, but I'll assume my
own incompetence for now and try again tomorrow.. ;)

-octo
--

-- 
(Continue reading)

Guus Sliepen | 26 May 23:05 2009

Re: [PATCH] configure.in: Fix a typo.

On Tue, May 26, 2009 at 10:47:26PM +0200, Florian Forster wrote:

> > > -AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/Makefile.in m4/Makefile])
> > > +AC_CONFIG_FILES([Makefile src/Makefile doc/Makefile lib/Makefile po/POTFILES m4/Makefile])
> > 
> > This patch breaks the build system. Why do you think it is necessary?
> 
> sorry, I realized later this doesn't solve my problem at all: The
> autotools complained about po/Makefile.in being missing and I suspected
> a simple typo (`.in' is usually appended by autoconf itself). Looking in
> po/, however, I found no `Makefile.in' (nor a `Makefile.am'), but a
> `POTFILES.in'...
> 
> My guess is that the required `Makefile.am' exists in your working
> directory but hasn't been checked into the Git repository..

The git repository should contain all the files necessary. You should run the
following command to create the rest of the files:

autoreconf -fsi

Afterwards, ./configure; make should work. If not, then please tell me which
OS and which version of autoconf you are using.

--

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus@...>
On Tue, May 26, 2009 at 10:47:26PM +0200, Florian Forster wrote:
(Continue reading)

Florian Forster | 27 May 09:27 2009

[PATCH] src/linux/device.c: Fix segfault when running without `--net'.

If running without `--net', the (global) variable `netname' is NULL. This
creates a segmentation fault because this NULL-pointer is passed to strdup:

 Program terminated with signal 11, Segmentation fault.
 #0  0xb7d30463 in strlen () from /lib/tls/i686/cmov/libc.so.6
 (gdb) bt
 #0  0xb7d30463 in strlen () from /lib/tls/i686/cmov/libc.so.6
 #1  0xb7d30175 in strdup () from /lib/tls/i686/cmov/libc.so.6
 #2  0x0805bf47 in xstrdup (s=0x0) at xmalloc.c:118  <---
 #3  0x0805be33 in setup_device () at device.c:66
 #4  0x0805072e in setup_myself () at net_setup.c:432
 #5  0x08050db2 in setup_network () at net_setup.c:536
 #6  0x0805b27f in main (argc=Cannot access memory at address 0x0) at tincd.c:580

This patch fixes this by checking `netname' in `setup_device'. An alternative
would be to check for NULL-pointers in `xstrdup' and return NULL in this case.

Signed-off-by: Florian Forster <octo@...>
---
 src/linux/device.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/linux/device.c b/src/linux/device.c
index 2e44755..4e9591c 100644
--- a/src/linux/device.c
+++ b/src/linux/device.c
 <at>  <at>  -63,7 +63,8  <at>  <at>  bool setup_device(void)

 	if(!get_config_string(lookup_config(config_tree, "Interface"), &iface))
 #ifdef HAVE_LINUX_IF_TUN_H
(Continue reading)

Florian Forster | 27 May 09:49 2009

[PATCH] src/net_socket.c: Bind outgoing TCP sockets to `BindToAddress'.

If a host has multiple addresses on an interface, the source address of the TCP
connection(s) was picked by the operating system while the UDP packets used a
bound socket, i. e. the source address was the address specified by the user.
This caused problems because the receiving code requires the TCP connection and
the UDP connection to originate from the same IP address.

This patch adds support for the `BindToInterface' and `BindToAddress' options
to the setup of outgoing TCP connections.

Tested with Debian Etch on x86 and Debian Lenny on x86_64.

Signed-off-by: Florian Forster <octo@...>
---
 src/net_socket.c |  121 ++++++++++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 104 insertions(+), 17 deletions(-)

diff --git a/src/net_socket.c b/src/net_socket.c
index dcdcc0b..758d36b 100644
--- a/src/net_socket.c
+++ b/src/net_socket.c
 <at>  <at>  -34,6 +34,8  <at>  <at> 
 #include "utils.h"
 #include "xalloc.h"

+#include <assert.h>
+
 #ifdef WSAEINPROGRESS
 #define EINPROGRESS WSAEINPROGRESS
 #endif
 <at>  <at>  -82,6 +84,101  <at>  <at>  static void configure_tcp(connection_t *c)
(Continue reading)


Gmane