r3673 - in trunk/n2n: . win32

Author: deri
Date: 2009-02-01 14:04:41 +0100 (Sun, 01 Feb 2009)
New Revision: 3673

Modified:
   trunk/n2n/edge.c
   trunk/n2n/supernode.c
   trunk/n2n/win32/getopt.c
Log:
Win32 fixes
- Supernode fix when binding to the requested port
- Removed warnings while parsing CLI options

r3674 - trunk/n2n

Author: deri
Date: 2009-02-01 14:10:16 +0100 (Sun, 01 Feb 2009)
New Revision: 3674

Modified:
   trunk/n2n/n2n.c
Log:
Restored lzo1x_decompress_safe as it works on Win32/.NET too

Subject: Re: Just reporting some n2n problems...

Hi all

On Jan 31, 2009, at 12:22 PM, Richard Andrews wrote:

>> I would like to report some problems:
>>
>> 1.
>> New patch in n2n.c
>> (lzo1x_decompress --> lzo1x_decompress_safe) breaks windows version
>> of n2n, no data goes over tunnel.
>>
>> after removing _safe from n2n.c n2n works well
>> again.
>
> OK. I'll make this platform dependent. We should find out why it  
> causes a problem for WIN32, but I have no Windows installs to test  
> with.

1. i have reverted your fix as I have tested on Win32 and it works for  
me. it's now in a #if #endif block just in case we need it again
>
>
>> 2.
>> Supernode newer than svn revision 3505 doesn't work
>> under windows, it reports following error:
>>
>> C:\n2n>supernode -l 80
>> 31/Jan/2009 10:59:47
>> [    .\n2n.c: 224] ERROR: Bind error [No error]
>

Subject: Re: Just reporting some n2n problems...

Jaromír
the bug is fixed in SVN (.NET 2008 Express)

Luca

On Jan 31, 2009, at 12:54 PM, Jaromír Kuba wrote:

> unprivilegied port doesn't help. Tested on 4 computers with windows  
> xp sp3.
> c:\n2n>supernode -l 1234
> 31/Jan/2009 12:41:47 [    .\n2n.c: 224] ERROR: Bind error [No error]
>
> supernode svn <= 3505 - works well,
> supernode svn 3530, 3531 - doesn't compile on windows using visual  
> studio
> supernode svn >= 3533 compiles, but doesn't bind
>
> I use Visual studio 2008 sp1 on windows xp sp3 32bit, i'll try another
> compiler (mingw, digital mars, openwatcom,...?).
>
> Have a nice day.
>
> JK
>
> ----- Original Message -----
> From: "Richard Andrews" <bbmaj7 <at> yahoo.com.au>
> To: <ntop-dev <at> unipi.it>
> Sent: Saturday, January 31, 2009 12:22 PM
> Subject: Re: [Ntop-dev] Just reporting some n2n problems... 
>

r3675 - trunk/n2n

Author: deri
Date: 2009-02-01 14:33:59 +0100 (Sun, 01 Feb 2009)
New Revision: 3675

Modified:
   trunk/n2n/edge.c
   trunk/n2n/n2n.c
   trunk/n2n/n2n.h
   trunk/n2n/supernode.c
   trunk/n2n/tuntap_freebsd.c
   trunk/n2n/tuntap_linux.c
   trunk/n2n/tuntap_osx.c
Log:
Updated copyright

Subject: Re: Just reporting some n2n problems...

> 1. i have reverted your fix as I have tested on Win32 and it works for  
> me. it's now in a #if #endif block just in case we need it again

It doesn't work for me. Using lzo1x_decompress_safe breaks edge under linux.
I'd like to understand why it doesn't work but I have not had time yet.
Can we make it #ifdef WIN32 (uses _safe) for now.

I have created a ticket to track the problem.

http://www.ntop.org/trac/ticket/73

--
  Rich

      Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox

Subject: just in case anybody cares ...

...

Jonkman was nice enough to host a CentoOS5 rpm repo for me. I have
created a set of i686 kernel rpms that have been patched to include
PF_RING and ipset. I did not backport libpcap to the version included
with CentOS5 so you will have to recompile your libpcap based tools if
you decide to use the pf_ring/libpcap based stuff for the 0.9.7
version in the repo. I also have included rpms for the latest apache
etc so I suggest if you use a file to throw into /etc/yum.repos.d/ you
use the include/exclude stuff options so that you only pull the items
that you need/want. There are quite a few other useful tools that have
been recomipled to use libpfring.

To use ipset you will have to remove your existing iptables version
and replace it with the one in the repo.

link to the repo..

http://www.emergingthreats.net/emergingrepo/

I have also modified the script created by Joshua Gimer for updating
the fw rules using ipset which you can download here.

http://doc.emergingthreats.net/pub/Main/EmergingFirewallRules/emerging-ipset-update.pl.txt

link to blog post which doesn't contain anymore info than what is listed here.

http://node5.blogspot.com/2009/02/pfringipset-rpms-for-centos5.html

Regards,

Will

r3676 - trunk/n2n

Author: andrews
Date: 2009-02-02 12:30:53 +0100 (Mon, 02 Feb 2009)
New Revision: 3676

Modified:
   trunk/n2n/n2n.c
Log:
Fix reliability of lzo1x_decompress_safe. It needs the output buffer length passed in.

Subject: Re: Just reporting some n2n problems...

> I would like to report some problems:
>  
> 1.
> New patch in n2n.c 
> (lzo1x_decompress --> lzo1x_decompress_safe) breaks windows version 
> of n2n, no data goes over tunnel.
>  
> after removing _safe from n2n.c n2n works well 
> again.

Jaromir - I have made a change in r3676 which fixes this for me under Linux. Can you please check if this works
for you under Windows to.

Luca - I suspect your Windows build may have worked by a fluke of uninitialised data. If your compiler does
not set uninitialised variables to zero (and some do not) then the input length to
lzo1x_decompress_safe() would be a random positive 32-bit integer; almost always larger than your
typic IP packet of a few hundred bytes.

Luca if you get a chance can you verify this under your Windows compiler too.

--
  Rich

      Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox

Subject: Re: Just reporting some n2n problems...

Richard
great work. Everything works on Windows

Luca

On Feb 2, 2009, at 12:41 PM, Richard Andrews wrote:

>> I would like to report some problems:
>>
>> 1.
>> New patch in n2n.c
>> (lzo1x_decompress --> lzo1x_decompress_safe) breaks windows version
>> of n2n, no data goes over tunnel.
>>
>> after removing _safe from n2n.c n2n works well
>> again.
>
> Jaromir - I have made a change in r3676 which fixes this for me  
> under Linux. Can you please check if this works for you under  
> Windows to.
>
> Luca - I suspect your Windows build may have worked by a fluke of  
> uninitialised data. If your compiler does not set uninitialised  
> variables to zero (and some do not) then the input length to  
> lzo1x_decompress_safe() would be a random positive 32-bit integer;  
> almost always larger than your typic IP packet of a few hundred bytes.
>
> Luca if you get a chance can you verify this under your Windows  
> compiler too.
>