similar to: No subject

Dear Guus, I've attached my first git commit to your repository. It does not contain any new functionalities, but it is a first try to interact with your git copy. Could you please verify, if you can push this commit to your repository? If it works, I'll send you the rest of my work, which contains: 1) some small improvements in logging (using flags instead of counters) 2) the

Hello. I found that anonymous structures does not work on gcc-2.95. If you guys want to support a bit older platforms I suggest fixing it. You can check out patch I created to fix this issue. I just added 2 extra structures to remove anonymous structs inside connection_status_t and node_status_t. Patch is here: ftp://borg.uu3.net/pub/unix/tinc/tinc.patch Attaching it as well. Regards, Borg

--- 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

We''re using tc to classify all packets currently - it avoids conflicting with other packages that want to play with the ipfilters, and up to this point has done everything we need. However now I''d like to map the four htb flows I''ve set up (and are working great on their own) to the four wireless hardware driver queues when the driver currently only has support for

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

Howdy: I'm new to this samba stuff, but I've run across a problem that doesn't seem to be documented anywhere. It seems that OSR/2 clients (with all the M$ system updates; I already added the EnableClearTextPassword key) that have had their TCP/IP settings tweaked in the registry (eg, MaxMTU=576, TTL=32, RWIN added, etc) for DUN connections have mucho problems with a samba

When the world was young, Ole Holm Nielsen carved some runes like this: > Date: Fri, 20 Nov 1998 12:03:59 +0100 > From: Ole Holm Nielsen <Ole.H.Nielsen@fysik.dtu.dk> > Subject: Re: Dial in accounts > Regarding remote network browsing: > We have had mixed success browsing Network Neighborhood from > PPP-connected Win95 PCs. Our servers are all SAMBA, no NT here :-)

Hi all. We have a performance problem over a 2 Mbits radio link. The configuration is as follows: we have a RH Linux 6.1 (double PIII processor, 100 mbit ethernet, raid 5), acting as a server for a network of Windows 95, 98 and NT. On the local network I can achieve up to 40 mbits transferring large files from the server to a windows 98 machine. This network is connected through a 2 mbits radio

When the world was young, Adam Snodgrass carved some runes like this: > Date: Mon, 10 Aug 1998 19:06:07 -0400 > Subject: Failure to execute programs from a mapped drive letter on a samba > I have a strange situation. I have a Linux machine running samba > 1.9.18p8, serving a mix of NT Workstation 4.0 and Windows 95 clients. In > general, things have worked flawlessly, with one

Hello, Guus Sliepen, on Wed 02 Dec 2015 13:53:37 +0100, wrote: > That's great! It would be good though to split > handle_incoming_vpn_data() into a function that does the actual > recvfrom/mmsg() and one that processes each individual packet, to reduce > the level of indentation and make the functions a bit more readable. > Then I'll merge it :) Here it is. Samuel

10.12.2015 03:35, Samuel Thibault wrote: [] I suggest reducing ifdeffery in handle_incoming_vpn_data(), especially the error checking code. The function isn't that large now, it might be much better to have two different implementations. Like this (untested, patch attached): void handle_incoming_vpn_data(int sock) { #ifdef HAVE_RECVMMSG #define MAX_MSG 256 vpn_packet_t

Oh, goodie! I'd made a start on the send direction here: https://github.com/dtaht/tinc/commits/master Perhaps that will help. I would not just pull that as it was just some late night hacking... and it turns out the posix time calls I upgraded to to get better than second resolution are not supported on OSX. My ultimate intent was to move to not bottlenecking or dropping packets on the

Hi there, I run tinc with not ConnectTo, (and it can't tcp-connect to the relevant other tincd, because that tincd is behind a firewall --> that tincd usualy connects to my tincd). If I start that tincd alone (not connected at all) and do a ping some_other_ip, it gets a SIGBUS in route.c:207 in the function route_ipv4_unreachable at the line: hdr->ip_v = 4; This seems to be an

10.12.2015 09:20, Michael Tokarev wrote: > 10.12.2015 03:35, Samuel Thibault wrote: > [] > > I suggest reducing ifdeffery in handle_incoming_vpn_data(), especially > the error checking code. > > The function isn't that large now, it might be much better to have > two different implementations. Like this (untested, patch attached): > > void

I am currently investigating using samba on a Linux box to provide file server services on our NT LAN (I'm a bit sick of NT doing dummy spits on me). I'm running RH5.1, and have just upgraded samba to samba-1.9.18p8-51.3 (using the rpm from http://samba.anu.edu.au/samba/ftp/Binary_Packages/redhat/RPMS/5.1/samba- 1.9.18p8-51.3.i386.rpm) The setup includes several NT servers, one set up as

(Second try to send this. I wonder if the first one gotten eaten by a spam filter; I'll link to patches instead of attaching them.) Here are the tincctl patches I've been working on. They apply to http://www.tinc-vpn.org/svn/tinc/branches/1.1@1545. I intend to commit them once the crypto stuff's fixed. Since they're basically done, I'm emailing them now for review and in case

Hello, Linux has a recvmmsg() system call which allows to achieve several recvfrom() at a time. The patch below makes tinc use it (patch against 1.1-pre11). Basically the patch turns the handle_incoming_vpn_data variables into arrays (of size 1 when recvmmsg is not available, and thus compiled the same as before), and makes the code index into the arrays. You may want to use interdiff -w