Re: Applying NAT-T patch

[VANHULLEBUS Yvan]

On Thu, May 31, 2007 at 03:19:15AM +, [EMAIL PROTECTED] wrote:

Hi.

> According to the following thread, one must do more then just apply the NAT-T
> patch and rebuild the kernel:
> http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011855.html
> 
> What other steps are necessary to apply the patch to a 6.x system? Can I get
> away without re-building/re-installing world?

rebuilding/reinstalling  world may be very interesting as some system
programs uses some structs which size are changed by the patch.
But you can skip this part if you are *absolutely* sure to NEVER use
such programs (system's setkey and a few other ones I don't remember).

reinstalling /usr/include headers is necessary to export the correct
versions of some headers (net/pfkeyv2.h, some stuff in udp headers,
etc...).

rebuilding ipsec-tools port is necessary when your headers have been
exported, to let the port's configure detect that your system now have
NAT-T support.


Yvan.

-- 
NETASQ
http://www.netasq.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Applying NAT-T patch

[Eric Masson]

VANHULLEBUS Yvan <[EMAIL PROTECTED]> writes:

Hi Yvan,

> rebuilding/reinstalling  world may be very interesting as some system
> programs uses some structs which size are changed by the patch.

Is there any hope to see NATT support, based on your patches, included
in -current before 7.0-RELEASE engineering process begins ?

-- 
 Un groupe spécifique aux débutants permettrai aux gens qui sont
 "middle-class" de pouvoir continuer à se former et à aller plus
 profond dans Linux.
 -+-EF In :  - Fais moi tout -+-
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: driver packet coalesce

[Andre Oppermann]

Julian Elischer wrote:

Andrew Thompson wrote:

On Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote:

Does any driver do this now? And if a driver were to coalesce
packets and send something up the stack that violates mss
will it barf?


It would barf for things like bridging where the packet gets spit out a
different interface. The bridge driver already has code to disable
txcsum so it could be made to handle that too.


Andrew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


This is part od TOE right?


No, LRO (Large Receive Offload).

I presume that it wouldn't coalesce packets that are not destined for 
the local
machine?  would it coalesce in promiscuous mode?   I guess it would only 
be able to coalesce TCP packets that are adjacent in the same session. 
Whether it also can coalesce adjacent packets that are destined for another
machine (for which it is not running the session) is not known... I 
would guess it

wouldn't do it.


These are all nasty problems that should be handled in one central
place for various protocols (primarily TCP right now).  For TCP there
are a number of obvious and non-obvious interaction issues with LRO
to be handled.  For example LRO may have a drastic effect on stacks
that don't (yet) make use of ABC and increase the CWND by one for
every ACK received.  With LRO up to some 44 segments may be aggregated.
On back to back connections with microsecond RTT this isn't much a
problem.  However once you have even 1ms performance goes way down.
The LRO implementation (in the driver) has to be aware of all these
issues and how the TCP stack treats them.  That's why I want to have
only one LRO implementation in the base system that is used by all
drivers.

--
Andre

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: em0 failed to work at 1000baseTX. WAS [Re: em0 - bge0 failed to work at 1000baseTX]

[Stefan Lambrev]

Jack Vogel wrote:

On 5/29/07, Jack Vogel <[EMAIL PROTECTED]> wrote:

On 5/27/07, Jack Vogel <[EMAIL PROTECTED]> wrote:
> On 5/27/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote:
> > Hi Jack,
> >
> > Jack Vogel wrote:
> > > Stefan,
> > >
> > > I am having a long weekend and am supposed to be doing
> > > something other than this :) However, when I get back in the 
office
> > > on Tuesday I will see if I can repro this, so just to make 
sure, tell

> > > me what the PCI ID of the two cards are when it fails with Intel
> > > on both sides, that should be easy.
> > >
> > > Jack
> > this is the card that works in my tests:
> >
> > [EMAIL PROTECTED]:0:1:   class=0x02 card=0x34768086 chip=0x10968086 
rev=0x01

> > hdr=0x00
> > vendor = 'Intel Corporation'
> > device = 'PRO/1000 EB Network Connection'
> > class  = network
> > subclass   = ethernet
> >
> > and this is the one that do not work at gigabit speed:
> >
> > [EMAIL PROTECTED]:25:0:  class=0x02 card=0x2800103c chip=0x104a8086 
rev=0x02

> > hdr=0x00
> > vendor = 'Intel Corporation'
> > device = '82566DM Gigabit Network Connection'
> > class  = network
> > subclass   = ethernet
>
> OK, I will attempt to repro this on Tuesday, thanks Stefan.

Good News, I have repro'd this on hardware here, so I'm actively
debugging things now, hope its an easy fix... stay tuned.


I have fixed the problem, I will be checking in that together with
a couple other minor bugs this afternoon sometime.

Cheers,

Jack

Thank you very much for the help Jack :))
Unfortunately I'm off next four days and probably will not be able to 
test it before Monday.
Btw any chances to have patch for releng_6 or the difference in the 
drivers is too big ? :)


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Applying NAT-T patch

[VANHULLEBUS Yvan]

On Thu, May 31, 2007 at 09:38:26AM +0200, Eric Masson wrote:
> VANHULLEBUS Yvan <[EMAIL PROTECTED]> writes:
> 
> Hi Yvan,

Hi Eric,

> > rebuilding/reinstalling  world may be very interesting as some system
> > programs uses some structs which size are changed by the patch.
> 
> Is there any hope to see NATT support, based on your patches, included
> in -current before 7.0-RELEASE engineering process begins ?

There is always some hope :-)

As far as I know, the patch is ready to be applied, and I provided
both patches for FreeBSD6 and FreeBSD's HEAD.

But as I don't have a commit bit on FreeBSD's sources, I can't do the
remaining part of the work: commiting

I know that some FreeBSD developpers have expressed some interest in
this patch, I had some discussions with some of them since some months
ago, but actually, I can just wait for a commit or for some
feedback/questions/bug reports/other things


Yvan.

-- 
NETASQ
http://www.netasq.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Applying NAT-T patch

[Eric Masson]

VANHULLEBUS Yvan <[EMAIL PROTECTED]> writes:

Hi,

> There is always some hope :-)

:)

> I know that some FreeBSD developpers have expressed some interest in
> this patch, I had some discussions with some of them since some months
> ago, but actually, I can just wait for a commit or for some
> feedback/questions/bug reports/other things

Ok, so just wait & see. It would be really convenient to see it in
7.0-RELEASE.

Thanks

Éric

-- 
 [Attention : « vote OUI [resp. NON] pour fr.comp.os.linux » signifie
 pour [resp. contre] la _suppression_ de fr.comp.os.linux.] 
 [...] Ceci est une réponse automatique à votre vote. 
 -+- CM in: Guide du linuxien pervers - Roby le robot rame et radote -+-
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Applying NAT-T patch

[Bjoern A. Zeeb]

On Thu, 31 May 2007, VANHULLEBUS Yvan wrote:


On Thu, May 31, 2007 at 09:38:26AM +0200, Eric Masson wrote:

VANHULLEBUS Yvan <[EMAIL PROTECTED]> writes:

Hi Yvan,


Hi Eric,


rebuilding/reinstalling  world may be very interesting as some system
programs uses some structs which size are changed by the patch.


Is there any hope to see NATT support, based on your patches, included
in -current before 7.0-RELEASE engineering process begins ?


There is always some hope :-)

As far as I know, the patch is ready to be applied, and I provided
both patches for FreeBSD6 and FreeBSD's HEAD.

But as I don't have a commit bit on FreeBSD's sources, I can't do the
remaining part of the work: commiting

I know that some FreeBSD developpers have expressed some interest in
this patch, I had some discussions with some of them since some months
ago, but actually, I can just wait for a commit or for some
feedback/questions/bug reports/other things


Maybe you could start addressing the things I posted last September?
http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011807.html

Also lately someone in my digital neighborhood had problems compiling
the patch for kernels with and without NAT-T support, for KAME and
fast_ipsec. Seems some #ifdef and #includes were not worked out
properly. I do not know which verion of the patch was used because
they, unfortunately, always had the same name and no versioning.

/bz

--
Bjoern A. Zeeb  bzeeb at Zabbadoz dot NeT
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Applying NAT-T patch

[VANHULLEBUS Yvan]

On Thu, May 31, 2007 at 08:52:03AM +, Bjoern A. Zeeb wrote:
> On Thu, 31 May 2007, VANHULLEBUS Yvan wrote:
[...]
> 
> Maybe you could start addressing the things I posted last September?
> http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011807.html

You're right: I was sure that this patch had been reported to
"official" NAT-T patch, but it hasn't been yet, I appologize for
that.


While re-reading it, I remember now that I wanted to check again the
minlen computation.

The rest of the patch is ok and will be included today.


> Also lately someone in my digital neighborhood had problems compiling
> the patch for kernels with and without NAT-T support, for KAME and
> fast_ipsec. Seems some #ifdef and #includes were not worked out
> properly. I do not know which verion of the patch was used because
> they, unfortunately, always had the same name and no versioning.

Well, the file is versionned as it's in a CVS, but I'm not sure this
specific CVS is available to public (this is the CVS used to update
sourceforge's projects web sites).

Now I know that the patch stayed there for a long time, I know that I
should have putted it somewhere else, with better versionning
informations available..


Yvan.

-- 
NETASQ
http://www.netasq.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

RE: Applying NAT-T patch

[Peter Blok]

I wish this would happen too. I'm using NAT-T in combination with a cisco
client I use for work and home. It works great!

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Eric Masson
Sent: Thursday, May 31, 2007 9:38 AM
To: VANHULLEBUS Yvan
Cc: freebsd-net@freebsd.org
Subject: Re: Applying NAT-T patch

VANHULLEBUS Yvan <[EMAIL PROTECTED]> writes:

Hi Yvan,

> rebuilding/reinstalling  world may be very interesting as some system
> programs uses some structs which size are changed by the patch.

Is there any hope to see NATT support, based on your patches, included
in -current before 7.0-RELEASE engineering process begins ?

-- 
 Un groupe spécifique aux débutants permettrai aux gens qui sont
 "middle-class" de pouvoir continuer à se former et à aller plus
 profond dans Linux.
 -+-EF In :  - Fais moi tout -+-
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: udp fragmentation with pf/ipf

[Sten Daniel Soersdal]

Hugo Koji Kobayashi wrote:

Hello,

While making some tests with fragmented udp DNS responses (with
EDNS0), we discovered a possible problem with ipf and pf in FreeBSD
6.2 and 7.0 (200705 snapshot).

Our test is a DNS query to an DNSSEC enabled server which replies with
a ~4KB udp response. We do this with the following dig command:

 dig @192.36.144.107 se dnskey +dnssec +bufsize=4500 +retry=0

ipf and pf in FreeBSD 6.2 or 7.0 block the fragments and the DNS
queries timeout. Disabling the firewall, complete replies are received
with no problem.

We've made the same tests with FreeBSD 4.11 with ipf and OpenBSD 4.1
with pf with no problems. You can see a summary of the tests below.

  OS + fwdig result
fbsd4.11 + ipf  OK
obsd4.1 + pfOK
fbsd6.2 OK
fbsd6.2 + ipf timeout
fbsd6.2 + pf  timeout
fbsd7.0 OK
fbsd7.0 + ipf timeout
fbsd7.0 + pf  timeout

Complete test results (including tcpdump output and firewall rule
sets) are attached.

Can somebody tell us if he hit a bug or if there is something we are
missing?



By the looks of it, you hit a bug.

"scrub in all fragment reassemble" should reassemble good fragments 
before evaluating the rules.


--
Sten Daniel Soersdal
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: driver packet coalesce

[Wilkinson, Alex]

0n Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote: 

> Does any driver do this now? And if a driver were to coalesce
> packets and send something up the stack that violates mss
> will it barf?

erm, what is meant by "coalesce" ?

 -aW

IMPORTANT: This email remains the property of the Australian Defence 
Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 
1914.  If you have received this email in error, you are requested to contact 
the sender and delete the email.


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Download speed and TCPIP window sizing

[Pang]

Hello,
 Recently, I have leased a rack in Asianetcom and some bandwidth. 
However, the speed for my curcuit is substantially slower than my 
provider's company site. The provider said my circuit and their one are 
treated exactly the same way.

 Below is the URL for the download:
My circuit*: http://203.192.137.194/test.rar
ANC curcuit: 
http://www.asianetcom.com/pub/communications/AsiaNetcomNews_2006Q2.pdf
*This server is using FreeBSD 6.2 patch 4 with Apache in the port tree. 
The kernel is custom built but I haven't made any modification in sysctl


 I have asked many techs in Asianetcom and they blamed on TCPIP window 
sizing. I am not sure what it is, so I do a search in Google and find 
the following:

http://www.vad1.com/tcp-throughput-limit.html

 After reading the article above, I feel the situation is very similar. 
But, from my understanding, the download speed should be proportional to 
the ping speed. However, test done on Canada is much higher (about 3 
times higher) than in US while the ping is very similar.


 Could anyone tell me whether my understanding on Window sizing 
correct? Also, is there any way to alter the window sizing in freebsd or 
apache?


Thanks
Pang
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Download speed and TCPIP window sizing

[Nicolas Gieczewski]

On Thu, 31 May 2007 22:06:39 +0800, Pang <[EMAIL PROTECTED]> wrote:
>   Recently, I have leased a rack in Asianetcom and some bandwidth.
> However, the speed for my curcuit is substantially slower than my
> provider's company site.
> [...]
> *This server is using FreeBSD 6.2 patch 4 with Apache in the port tree.
> The kernel is custom built but I haven't made any modification in sysctl
> 
>   I have asked many techs in Asianetcom and they blamed on TCPIP window
> sizing.

I used to have the same problem with my FreeBSD dedicated servers in the U.S. 
when I was living in South America with a latency of ~200 ms. Given identical 
hardware and connectivity, I could max out my download speed when downloading 
from a server running Linux, but would get no more than 100-150 KB/s when 
downloading from an otherwise identical FreeBSD box.

The solution was to increase the size of the TCP send window on the FreeBSD 
server to about 128 KB--the default of 32 KB turned out to be way too small.

# sysctl net.inet.tcp.sendspace=131072

After modifying this value, you need to restart any processes (e.g. Apache) 
that you want to take advantage of the change.

Hope it helps.

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Applying NAT-T patch

[Matthew Grooms]

>On Thu, May 31, 2007 at 08:52:03AM +, Bjoern A. Zeeb wrote:
>> On Thu, 31 May 2007, VANHULLEBUS Yvan wrote:
>[...]
>>
>> Maybe you could start addressing the things I posted last September?
>> http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011807.html
>
>You're right: I was sure that this patch had been reported to
>"official" NAT-T patch, but it hasn't been yet, I appologize for
>that.
>
>
>While re-reading it, I remember now that I wanted to check again the
>minlen computation.
>
>The rest of the patch is ok and will be included today.
>

Does that mean that only a single issue mentioned by Bjoern has not been
addressed in the latest version of the patch set?

What about the setkey program? Does it need to be patched to read
security associations that use natt extensions? Perhaps the ipsec tools
version can be imported to replace the stock freebsd version?

I really hope this makes into head before the 7 branch.

Thanks,

-Matthew
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: em0 failed to work at 1000baseTX. WAS [Re: em0 - bge0 failed to work at 1000baseTX]

[Jack Vogel]

On 5/31/07, Stefan Lambrev <[EMAIL PROTECTED]> wrote:


Thank you very much for the help Jack :))
Unfortunately I'm off next four days and probably will not be able to
test it before Monday.
Btw any chances to have patch for releng_6 or the difference in the
drivers is too big ? :)


Welcome, turns out its just as well that you didnt test yet because
my test engineer came back to me this morning and it turns out there
was still a code path that caused the autoneg back down to 100, I
worked with him this morning and now I've simplified the code and
plugged that hole at the same time, so another delta will be coming
today.

As for 6.X, well, its definitely a fix that needs to go back, but the
question is how. What I would like to do is MFC the whole new
shared code driver, in fact the next release that gets published
by Intel which is a few months out should have that version anyway
so I'll work that and the MFC together.

However, if you have an urgent need for this fix on 6.2 I can make
up a special patch, I'm pretty sure the old shared code still has
what we need to do this.

Jack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: driver packet coalesce

[Jack Vogel]

On 5/31/07, Andre Oppermann <[EMAIL PROTECTED]> wrote:

Julian Elischer wrote:
> Andrew Thompson wrote:
>> On Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote:
>>> Does any driver do this now? And if a driver were to coalesce
>>> packets and send something up the stack that violates mss
>>> will it barf?
>>
>> It would barf for things like bridging where the packet gets spit out a
>> different interface. The bridge driver already has code to disable
>> txcsum so it could be made to handle that too.
>>
>>
>> Andrew
>> ___
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>
> This is part od TOE right?

No, LRO (Large Receive Offload).

> I presume that it wouldn't coalesce packets that are not destined for
> the local
> machine?  would it coalesce in promiscuous mode?   I guess it would only
> be able to coalesce TCP packets that are adjacent in the same session.
> Whether it also can coalesce adjacent packets that are destined for another
> machine (for which it is not running the session) is not known... I
> would guess it
> wouldn't do it.

These are all nasty problems that should be handled in one central
place for various protocols (primarily TCP right now).  For TCP there
are a number of obvious and non-obvious interaction issues with LRO
to be handled.  For example LRO may have a drastic effect on stacks
that don't (yet) make use of ABC and increase the CWND by one for
every ACK received.  With LRO up to some 44 segments may be aggregated.
On back to back connections with microsecond RTT this isn't much a
problem.  However once you have even 1ms performance goes way down.
The LRO implementation (in the driver) has to be aware of all these
issues and how the TCP stack treats them.  That's why I want to have
only one LRO implementation in the base system that is used by all
drivers.



From email I've seen it appears Linux is working thru this issue as well,

and I agree that it makes sense to have one implementation, so lets
get going on it :)

Jack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: driver packet coalesce

[Jack Vogel]

On 5/31/07, Wilkinson, Alex <[EMAIL PROTECTED]> wrote:

0n Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote:

> Does any driver do this now? And if a driver were to coalesce
> packets and send something up the stack that violates mss
> will it barf?

erm, what is meant by "coalesce" ?



combining packets before sending to the stack, aka LRO.

Jack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Download speed and TCPIP window sizing

[Pang]

Thanks for reply.

Nicolas Gieczewski wrote:

On Thu, 31 May 2007 22:06:39 +0800, Pang <[EMAIL PROTECTED]> wrote:
  

  Recently, I have leased a rack in Asianetcom and some bandwidth.
However, the speed for my curcuit is substantially slower than my
provider's company site.
[...]
*This server is using FreeBSD 6.2 patch 4 with Apache in the port tree.
The kernel is custom built but I haven't made any modification in sysctl

  I have asked many techs in Asianetcom and they blamed on TCPIP window
sizing.



I used to have the same problem with my FreeBSD dedicated servers in the U.S. 
when I was living in South America with a latency of ~200 ms. Given identical 
hardware and connectivity, I could max out my download speed when downloading 
from a server running Linux, but would get no more than 100-150 KB/s when 
downloading from an otherwise identical FreeBSD box.

The solution was to increase the size of the TCP send window on the FreeBSD 
server to about 128 KB--the default of 32 KB turned out to be way too small.

# sysctl net.inet.tcp.sendspace=131072

After modifying this value, you need to restart any processes (e.g. Apache) 
that you want to take advantage of the change.
  


It doesn't work. I am still getting ~10KB/s speed.



Hope it helps.

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
  


Thanks
Pang
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: driver packet coalesce

[Bruce M. Simpson]

Jack Vogel wrote:

On 5/31/07, Wilkinson, Alex <[EMAIL PROTECTED]> wrote:

0n Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote:

> Does any driver do this now? And if a driver were to coalesce
> packets and send something up the stack that violates mss
> will it barf?

erm, what is meant by "coalesce" ?


combining packets before sending to the stack, aka LRO.


Yup - the firmware for the card's LRO engine would have to know not to 
coalesce packets not destined for the local host. I speculate many cards 
are not smart enough to do this, and LRO is an all-or-nothing 
proposition, as it's a technology designed to optimize for hosts, not 
routers; see recent discussions/slanging matches on end2end.


At the moment there is no central place where we track all layer 2 
addresses for which traffic should be delivered locally. This would 
logically belong in struct ifnet, and clients e.g. CARP would have to be 
taught to add their layer 2 endpoint addresses there.


It seems acceptable to disable LRO if bridging is on and document this 
behaviour.


BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: New driver coming soon.

[Christian Brueffer]

On Wed, May 30, 2007 at 05:51:35PM -0700, Jack Vogel wrote:
> I wanted to let everyone know that I will soon have a
> new 10G driver to add to the tree. It is a PCI Express
> MSI/X adapter, I would like to call this driver 'ix' rather
> than follow Linux who are calling it 'ixgbe'. It is not
> backwardly compatible with ixgb.   Any objections
> to the name? It would be nice to get this in before
> 7 becomes a RELEASE, what time frame do I
> have for that?
> 

Hi Jack,

will the new driver support the hardware that ixgb(4) currently supports,
e.g. will it replace ixgb(4)?  If yes, I'd like the name ixgb to stay.

- Christian

-- 
Christian Brueffer  [EMAIL PROTECTED]   [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D


pgpnUA4Z8D1d6.pgp
Description: PGP signature

Re: driver packet coalesce

[Kip Macy]

Bruce -

All LRO implementations are currently on the host.

On 5/31/07, Bruce M. Simpson <[EMAIL PROTECTED]> wrote:

Jack Vogel wrote:
> On 5/31/07, Wilkinson, Alex <[EMAIL PROTECTED]> wrote:
>> 0n Wed, May 30, 2007 at 04:45:05PM -0700, Jack Vogel wrote:
>>
>> > Does any driver do this now? And if a driver were to coalesce
>> > packets and send something up the stack that violates mss
>> > will it barf?
>>
>> erm, what is meant by "coalesce" ?
>>
> combining packets before sending to the stack, aka LRO.

Yup - the firmware for the card's LRO engine would have to know not to
coalesce packets not destined for the local host. I speculate many cards
are not smart enough to do this, and LRO is an all-or-nothing
proposition, as it's a technology designed to optimize for hosts, not
routers; see recent discussions/slanging matches on end2end.

At the moment there is no central place where we track all layer 2
addresses for which traffic should be delivered locally. This would
logically belong in struct ifnet, and clients e.g. CARP would have to be
taught to add their layer 2 endpoint addresses there.

It seems acceptable to disable LRO if bridging is on and document this
behaviour.

BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: New driver coming soon.

[Kip Macy]

He stated previously that they are not compatible.

On 5/31/07, Christian Brueffer <[EMAIL PROTECTED]> wrote:

On Wed, May 30, 2007 at 05:51:35PM -0700, Jack Vogel wrote:
> I wanted to let everyone know that I will soon have a
> new 10G driver to add to the tree. It is a PCI Express
> MSI/X adapter, I would like to call this driver 'ix' rather
> than follow Linux who are calling it 'ixgbe'. It is not
> backwardly compatible with ixgb.   Any objections
> to the name? It would be nice to get this in before
> 7 becomes a RELEASE, what time frame do I
> have for that?
>

Hi Jack,

will the new driver support the hardware that ixgb(4) currently supports,
e.g. will it replace ixgb(4)?  If yes, I'd like the name ixgb to stay.

- Christian

--
Christian Brueffer  [EMAIL PROTECTED]   [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B  B29B 6C76 178C A0ED 982D


___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Applying NAT-T patch

[VANHULLEBUS Yvan]

On Thu, May 31, 2007 at 08:52:03AM +, Bjoern A. Zeeb wrote:
[]
>  Maybe you could start addressing the things I posted last September?
>  http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011807.html

I just integrated the patch.

To be able to identify future versions of the patchs, and to have a
fastest availability, new versions of the patch will be stored at
http://vanhu.free.fr/FreeBSD and files names will include the date.


>  Also lately someone in my digital neighborhood had problems compiling
>  the patch for kernels with and without NAT-T support, for KAME and
>  fast_ipsec. Seems some #ifdef and #includes were not worked out
>  properly. I do not know which verion of the patch was used because
>  they, unfortunately, always had the same name and no versioning.

I know we had such issues with early versions of the patch, afaik it
compiles cleanly for both KAME and FAST_IPSEC, with and without NAT-T
support.

But if some people still have issues with recent versions of the
patch, please tell me so !



Yvan.

-- 
NETASQ
http://www.netasq.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Applying NAT-T patch

[VANHULLEBUS Yvan]

On Thu, May 31, 2007 at 09:37:30AM +, Matthew Grooms wrote:
[]
> >The rest of the patch is ok and will be included today.
> >
> 
> Does that mean that only a single issue mentioned by Bjoern has not been
> addressed in the latest version of the patch set?

I integrated Bjoern's patch to my own compile when he sent it, but, I
don't understand how, I didn't report his patch to the official NAT-T
patch (where I was sure I did it).

I just sent another mail in this thread to confirm that the patch is
up to date now.


> What about the setkey program? Does it need to be patched to read
> security associations that use natt extensions? Perhaps the ipsec tools
> version can be imported to replace the stock freebsd version?

That is another quite old discussion.
ipsec-tools's setkey changed quite a lot from system's one, and
actually, using the NAT-T patch means "forget system's setkey for at
least some features".

system's setkey will work as it worked before as soon as it have been
recompiled (needed as some PFkey structs size changed), but won't dump
NAT-T related informations.

To have such informations, you'll have to use ipsec-tools's setkey.

> I really hope this makes into head before the 7 branch. 

Looks like we were all waiting for each others, but it should be
better now.




Yvan.

-- 
NETASQ
http://www.netasq.com
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [PATCH] ng_pf and l7 filtering possibility with PF

[Ermal Luçi]

On 5/30/07, Alexander Motin <[EMAIL PROTECTED]> wrote:

Ermal Luçi wrote:
> OK,  here it is with stats activated :).

One more: all binary netgraph messages are hidden from user-level in
ng_pf.h. They are all covered with #ifdef _KERNEL. Specially?


No special need just forgotten by me.
I fixed that too and another bug with max-packets-to-netgraph option
which i am surprised have not seen before.

Thanks for your help,
Ermali



--
Alexander Motin

___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: New driver coming soon.

[Jack Vogel]

On 5/31/07, Christian Brueffer <[EMAIL PROTECTED]> wrote:

On Wed, May 30, 2007 at 05:51:35PM -0700, Jack Vogel wrote:
> I wanted to let everyone know that I will soon have a
> new 10G driver to add to the tree. It is a PCI Express
> MSI/X adapter, I would like to call this driver 'ix' rather
> than follow Linux who are calling it 'ixgbe'. It is not
> backwardly compatible with ixgb.   Any objections
> to the name? It would be nice to get this in before
> 7 becomes a RELEASE, what time frame do I
> have for that?
>

Hi Jack,

will the new driver support the hardware that ixgb(4) currently supports,
e.g. will it replace ixgb(4)?  If yes, I'd like the name ixgb to stay.


No, new driver is exclusively for the new PCI-E family, I suppose it
would be possible to make a combined driver, but its such a different
beast that its cleaner to just have a new driver.

ixgb can stay as is, I own that driver inside Intel as well, but our
FreeBSD customer base has been miniscule so not much has
been done to the code, maybe someday in my spare time :)

Cheers,

Jack
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Download speed and TCPIP window sizing

[Norberto Meijome]

On Fri, 1 Jun 2007 12:34:11 +1000
Norberto Meijome <[EMAIL PROTECTED]> wrote:

> http://www.meijome.net/files/freebsd/test_hk_dl/fbsd_NL_test_from_au.cap
> the same file, which I uploaded to a FBSD in NL (as mentioned above). Ping 
> time
> is about 320 ms to this box from home. Probably as fast as I'd expect it to 
> be.

meaning, from home to this server. It can definitely push more than this.

> I know I can transfer about up of 8 Mbps between the USA and NL hosts, so
> that test is not going to prove anything more.

meaning : testing between US host and NL host isn't going to prove anything
more than it works as expected.

/me needs more coffee...

oopss :)
_
{Beto|Norberto|Numard} Meijome

"A problem cannot be solved with the same type of thinking that created it."
  Albert Einstein

I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Download speed and TCPIP window sizing

[Norberto Meijome]

On Fri, 01 Jun 2007 02:21:13 +0800
Pang <[EMAIL PROTECTED]> wrote:

> Thanks for reply.
> 
> Nicolas Gieczewski wrote:
> > On Thu, 31 May 2007 22:06:39 +0800, Pang <[EMAIL PROTECTED]> wrote:
> >   
> >>   Recently, I have leased a rack in Asianetcom and some bandwidth.
> >> However, the speed for my curcuit is substantially slower than my
> >> provider's company site.
> >> [...]
> >> *This server is using FreeBSD 6.2 patch 4 with Apache in the port tree.
> >> The kernel is custom built but I haven't made any modification in sysctl
> >>
> >>   I have asked many techs in Asianetcom and they blamed on TCPIP window
> >> sizing.
> >> 
> >
> > I used to have the same problem with my FreeBSD dedicated servers in the 
> > U.S. when I was living in South America with a latency of ~200 ms. Given 
> > identical hardware and connectivity, I could max out my download speed when 
> > downloading from a server running Linux, but would get no more than 100-150 
> > KB/s when downloading from an otherwise identical FreeBSD box.
> >
> > The solution was to increase the size of the TCP send window on the FreeBSD 
> > server to about 128 KB--the default of 32 KB turned out to be way too small.
> >
> > # sysctl net.inet.tcp.sendspace=131072
> >
> > After modifying this value, you need to restart any processes (e.g. Apache) 
> > that you want to take advantage of the change.
> >   
> 
> It doesn't work. I am still getting ~10KB/s speed.
> 

hmm in some FBSD (6.0-STABLE) that we have in NL i have that set to 64K . From
AU (where I live), 320 ms of ping away, i can almost saturate my meagre DSL
link (got up to 2mpbs). 

There can be several things involved in bad download speeds - from the TCP
stack of the OS , the software you use to serve (I'm assuming Apache is
configured out of the box - it's not great, but should be better than this.),
NIC in the server, the network segment where it's located (in the DC,
upstream,etc), bandwidth limiting upstream or in apache itself,etc...

.I tested that download of yours from different parts of the world, it was
pretty bad from everywhere - I've captured the traffic from each download:

http://www.meijome.net/files/freebsd/test_hk_dl/fbsd_hk_test_from_au.cap
From AU , between 204 and 206 ms ping.

http://www.meijome.net/files/freebsd/test_hk_dl/fbsd_hk_from_NL.cap
Your file in HK downloaded from NL - ping time to HK = 329 ms

http://www.meijome.net/files/freebsd/test_hk_dl/fbsd_hk_from_txusa.cap
Your file in HK, downloaded from a linux server (RHES 3) in TX, USA. ping time
avg 227.

http://www.meijome.net/files/freebsd/test_hk_dl/fbsd_NL_test_from_au.cap
the same file, which I uploaded to a FBSD in NL (as mentioned above). Ping time
is about 320 ms to this box from home. Probably as fast as I'd expect it to be.
I know I can transfer about up of 8 Mbps between the USA and NL hosts, so
that test is not going to prove anything more.

I haven't got time right now to review all the captures, but at first sight it
seems there's more packet loss than you'd expect, duped ACKs,etc. The IO , RTT
and throughpouts graphs (i'm using wireshark) definitely show very poor
performance, though.

I dont see any relation betwen ping times and download speed.

BTW, how fast can you download this file from the server you say it's in the
same network segment ? 

Have you got polling enabled?

what hardware / nic ? 

HIH,
Beto

_
{Beto|Norberto|Numard} Meijome

"It's not what you do, it's the love you put into it."
   Mother Theresa.

I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"