[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] Re: [Help-gnunet] Re: udp traffic on port 65535

From: Christian Grothoff
Subject: [GNUnet-developers] Re: [Help-gnunet] Re: udp traffic on port 65535
Date: Tue, 20 Aug 2002 13:33:39 -0500
User-agent: KMail/1.4.1

Hash: SHA1

On Tuesday 20 August 2002 01:14 pm, David Hansen wrote:
> On Mon, Aug 19 at 17:55 Christian Grothoff wrote:
> > Port 65535 is also used for fragmented packets. I kind of doubt that
> > you've really got a kernel bug. What's the MTU of your network? How did
> > you get the portnumber?
> >
> > On Monday 19 August 2002 06:49 am, Peter Presslein wrote:
> > > Am Dienstag, 6. August 2002 04:23 schrieb Christian Grothoff:
> > >
> > > Hello again :-)
> > >
> > > > > since i installed gnunet 0.4.4 i have a lot of udp traffic
> > > > > on port 65535 going outside to other nodes.
> I just realized that i've the same problem...
> $IPCHAINS -A input -f -i $EXTDEV -l -j ACCEPT
> seems to help. But i dont know if this might be a security risk.

Well, that's what I figured, too. From the ipchains man-page:

      Fragments are handled differently.  All fragments after the first used 
to be let through (which is usually safe); they can now be filtered.   This  
       that you should probably add an explicit rule to accept fragments if 
you are converting over.  Also, look for old accounting rules which check for 
       and destination ports of 0xFFFF (0xFF for ICMP packets) which was the 
old way of doing accounting on fragments.

- ------

since an MTU of 1492 will mean that GNUnet traffic would be fragmented, that 
explains the problem very well. While I don't see a particular security risk 
with letting through fragments, there are solutions:

a) a stateful firewall (iptables, 2.4 kernel) should handle the case much
b) advertise MTU in the GNUnet handshake and automagically reduce to
    that size. This would increase the efficiency of the system and solve the
    problem at the same time. The code can not handle this at the moment,
    though. Maybe something to keep in mind for the future.

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


reply via email to

[Prev in Thread] Current Thread [Next in Thread]