On Fri, 18 Oct 2002, Me, Myself, and I blathered:
> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
> packet will get rejected when it reaches the other IPSEC node.
I still stand by my original statement. However, it won't be true for
much longer. There is now a draft docume
Hi,
I've succesfully configured mpd as PPTP server for
VPNs. But I have one stumbling block: when I connect
to the server from a Windows XP client, the new
connection gets assigned the same IP address as the
default gateway. For instance:
Client IP address: 192.168.250.240
Client netmask:255.
On Fri, 18 Oct 2002, Feng Li wrote:
>
> Hi, Friends
>
> Could anyone advise me how to configure the Ethernet
> Card on my PC with speed=100Mbps, duplex=Full parameters ?
>
> My PC is running FreeBSD 3.1-Relase, the interface name
> is fxp0.
>
> The config example will be appreciated greatly !
>
> T
Hi, Friends
Could anyone advise me how to configure the Ethernet
Card on my PC with speed=100Mbps, duplex=Full parameters ?
My PC is running FreeBSD 3.1-Relase, the interface name
is fxp0.
The config example will be appreciated greatly !
Thanks a lot in advnace !
Feng
To Unsubscribe: sen
> In special cases, the error induced by having interrupts blocked
> causes errors which are much larger than polling alone.
Which conditions block interrupts for longer than, say, a millisecond?
Disk errors / wakeups? Anything occurring in "normal" conditions?
Pete
To Unsubscribe: send mail
On Fri, 18 Oct 2002, Kelly Yancey wrote:
> > You should definitely clarify how fast the smartbits unit is pushing
> > out traffic, and whether its speed depends on the measured RTT.
> >
>
> It doesn't sound like the box is that smart. As it was explained to me, the
> test setup includes a desir
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> Oh, I *thought* the numbers you reported were pps but now i see that
> nowhere you mentioned that.
>
Sorry. I just checked with our tester. Those are the total number of
packets sent during the test. Each test lasted 10 seconds, so divde by 10 to
get
On Fri, 18 Oct 2002, Prafulla Deuskar wrote:
> FYI. 82543 doesn't support PCI-X protocol.
> For PCI-X support use 82544, 82545 or 82546 based cards.
>
> -Prafulla
>
That is alright, we aren't expecting PCI-X speeds. It is just that our only
PCI slot on the motherboard (1U rack-mount system) is
As I think about it, it isn't IPSEC that needs to process twice once
before and once after ipfw. Its the other way around.
IPFW should first allow the ESP packets into the machine, then IPSEC
extracted the secured packet, and then IPFW will process the normal
packet again, thus allowing the dive
Oh, I *thought* the numbers you reported were pps but now i see that
nowhere you mentioned that.
But if things are as you say, i am seriously puzzled on what you
are trying to measure -- the output interface (fxp) is a 100Mbit/s
card which cannot possibly support the load you are trying to offer
t
On Fri, Oct 18, 2002 at 06:39:51AM -0700, Matthew Zahorik wrote:
> On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
>
> > You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
> > packet will get rejected when it reaches the other IPSEC node.
>
> Not exactly true. I use a Windows
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> How is the measurement done, does the box under test act as a router
> with the smartbit pushing traffic in and expecting it back ?
>
The box has 2 interfaces, a fxp and a em (or bge). The GigE interface is
configured with 7 VLANs. THe SmartBit produce
FYI. 82543 doesn't support PCI-X protocol.
For PCI-X support use 82544, 82545 or 82546 based cards.
-Prafulla
Kelly Yancey [[EMAIL PROTECTED]] wrote:
> On Fri, 18 Oct 2002, Luigi Rizzo wrote:
>
> > On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> > ...
> > > Hmm. Might that ex
How is the measurement done, does the box under test act as a router
with the smartbit pushing traffic in and expecting it back ?
The numbers are strange, anyways.
A frame of N bytes takes (N*8+160) nanoseconds on the wire, which
for 330-byte frames should amount to 100/(330*8+160) ~= 357kpps
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
> ...
> > Hmm. Might that explain the abysmal performance of the em driver with
> > packets smaller than 333 bytes?
>
> what do you mean ? it works great for me. even on -current i
> can push
On Fri, Oct 18, 2002 at 06:21:37PM +0300, Petri Helenius wrote:
...
> Luigi´s polling work would be useful here. That would lead to incorrect
> timestamps
> on the packets, though?
polling introduce an extra uncertainty which might be as large as
an entire clock tick, yes.
But even with interrupt
On Fri, 18 Oct 2002, Luigi Rizzo wrote:
> On Fri, Oct 18, 2002 at 12:59:27PM -0400, David Miller wrote:
> > On Wed, 9 Oct 2002, Attila Nagy wrote:
> >
> > With a dc ethernet card and ~45K packets per second, an XP1700 system went
> > from > 50% interrupt to < 1%. I was astounded at the change!
On Fri, Oct 18, 2002 at 10:27:04AM -0700, Kelly Yancey wrote:
...
> Hmm. Might that explain the abysmal performance of the em driver with
> packets smaller than 333 bytes?
what do you mean ? it works great for me. even on -current i
can push out over 400kpps (64byte frames) on a 2.4GHz box.
On Fri, 18 Oct 2002, Petri Helenius wrote:
> >
> > just reading the source code, yes, it appears that the card has
> > support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> > and usage in sys/dev/em/* . I don't know in what units are the values
> > (28 and 128, respectively), but
Transmit/Receive Interrupt Delay values are in units of 1.024 microseconds.
The em driver currently uses these to enable interrupt coalescing on the cards.
Thanks,
Prafulla
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On Fri, Oct 18, 2002 at 12:59:27PM -0400, David Miller wrote:
> On Wed, 9 Oct 2002, Attila Nagy wrote:
>
> With a dc ethernet card and ~45K packets per second, an XP1700 system went
> from > 50% interrupt to < 1%. I was astounded at the change!
that is partly cheating, because with polling, some
This has got me stumped. I must be missing something obvious. I am
trying to download some files via FTP. There are four files. Three
download just fine, one just won't go. Since the three work fine, I
assume it's not PORT vs. PASV, NAT, or other firewall issues, that is,
the usual suspects have be
On Wed, 9 Oct 2002, Attila Nagy wrote:
With a dc ethernet card and ~45K packets per second, an XP1700 system went
from > 50% interrupt to < 1%. I was astounded at the change!
If all it takes to get Gb interfaces polling is to send Luigi a card then
he needs to send me his shipping address:)
---
In reply to "Jim McGrath" <[EMAIL PROTECTED]> :
>
> > Where could I get the errata sheet?
>
> Product Specification Updates i.e. errata, and the Product Specification
> itself are available from Intel under a Non Disclosure Agreement. Unless
> you work for a company that is doing business with
> The chips I have are 82546. Is your recommendation to steer away
> from Intel
> Gigabit Ethernet chips? What would be more optimal alternative?
>
The 82543/82544 chips worked well in vanilla configurations. I never played
with an 82546. The em driver is supported by Intel, so any chip features
(I´ll throw in the address found in the README of the driver, maybe somebody
there has access to appropriate documentation / is willing to work on
documenting
tunables and optimizing the performance)
> I have to tread carefully here because I was under NDA at my previous
> company. My work was
Matthew Zahorik wrote:
On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
packet will get rejected when it reaches the other IPSEC node.
Not exactly true. I use a Windows Nortel Contivity client behind NAT just
fine.
Reading
Hi. Sorry for off-topic, but maybe authors of pppd reads this mail-list..
When porting latest pppd (2.4.1) to RTEMS OS I noticed that
auth_withpeer_success() does not check current operation phase thus if
we enable CHAP rechallenge , each
rechallenge will bring us to network phase (by calling
au
Hello Matthew,
Friday, October 18, 2002, 9:39:51 PM, you wrote:
MZ> On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
>> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
>> packet will get rejected when it reaches the other IPSEC node.
MZ> Not exactly true. I use a Windows N
On Fri, 18 Oct 2002, Andrew P. Lentvorski wrote:
> You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
> packet will get rejected when it reaches the other IPSEC node.
Not exactly true. I use a Windows Nortel Contivity client behind NAT just
fine.
If you're using an AH associat
IMHO, there is a combination of two bugs.
1) MPD (3.9, at least) calculates and sets mtu (bund.c/BundUpdateParams())
at wrong time -- when one of MIN() args is still zero. ioctl with bizzare mtu
value rejected, thus leaving the default (1500), which in turn is above
MRU requested from win client (
> Where could I get the errata sheet?
Product Specification Updates i.e. errata, and the Product Specification
itself are available from Intel under a Non Disclosure Agreement. Unless
you work for a company that is doing business with Intel, they are probably
not obtainable.
>
> Could the number
+ Archie Cobbs wrote:
| Are you intending to have this hook into the normal FreeBSD TCP/IP
| stack or be truly standalone? I read your question as the latter but
| others seem to read it as the former.
I am very much a babe in the woods at this point. I have no plan aside
from reading as much
I have to tread carefully here because I was under NDA at my previous
company. My work was with the wx driver, but hardware problems are hardware
problems. There are a lot of performance enhancing features in the 82544.
You will notice that the em driver does not use them. This may be for a
reas
On Thu, 17 Oct 2002, Jonathan Feally wrote:
>
> I think a solution to the problem would be to have ipsec processing take
> place both before and after ipfw(or ipf).
> Somebody else though will have to figure out how to make a custom kernel
> to do double ipsec processing because I'm not a C progra
I was just looking at the latest postings from the net list and was
reading yours when I found this e-mail you sent directly to me.
I've had some success with IPSEC/IPFW and NATD.
The problem lies in the kernel, ipsec and ipfw ordering of where the
packets flow.
What you are trying to do - makes
On a side note:
For whoever tackles this project - a sysctl variable would be nice to
turn the second ipsec processing(pre ipfw/ipf) on or off.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
>
> just reading the source code, yes, it appears that the card has
> support for delayed rx/tx interrupts -- see RIDV and TIDV definitions
> and usage in sys/dev/em/* . I don't know in what units are the values
> (28 and 128, respectively), but it does appear that tx interrupts are
> delayed a bit
Where could I get the errata sheet?
Could the numbers be packet thresholds? 28 and 128 packets respectively?
Anything else that can be done? Does PCI width/speed affect the amount of
time spent in the kernel interrupt or are the PCI transfers asynchronous?
Pete
- Original Message -
Fro
You cannot NAT an IPSEC packet. NAT rewrites the IP headers and the
packet will get rejected when it reaches the other IPSEC node.
You can create forwarding rules which NAT packets destined for other hosts
and leave the IPSEC packets alone. You'll have to create an ipfw ruleset.
You also probab
Francisco J. Medina Jimenez writes:
> I'm testing mpd 3.9 with FreeBSD 4.6.2. The performance of transfers
> using W2k clients is much better than using XP or Win9x (in same
> conditions). Are there any parameters to adjust or it's problem of pptp
> client implementation?
The different Windows
41 matches
Mail list logo
