Hi,
I use freebsd 4.5, and find a really unexplainable behavior of TCP.
If there is no loss, TCP grows its cwnd and finally reaches the maximum window
size advertised by the receiver, for example 12 packets, after a while a packet is
lost. When the loss is recovered, TCP will begin its another
On Tuesday 18 June 2002 05:54, you wrote:
In article 001f01c21493$b0612620$010110ac@SPEWIN,
Sebastien Petit [EMAIL PROTECTED] wrote:
Apparently, my kernel contains the fix already:
[spe@artik /usr/src/sys/netgraph]$ grep if_hwassist ng_ether.c
priv-hwassist = ifp-if_hwassist;
Hi,
Could someone tell me if there is a way to build a VPN(like) tunnel from
a FreeBSD machine acting as a VPN gateway to another machine acting as
another VPN gateway using normal IP packets that have only their data
payload encrypted. Of course there would have to be a way to setup the
tunnel
Hi,
Could someone tell me if there is a way to build a VPN(like) tunnel from
a FreeBSD machine acting as a VPN gateway to another machine acting as
another VPN gateway using normal IP packets that have only their data
payload encrypted. Of course there would have to be a way to setup the
In article [EMAIL PROTECTED],
Sebastien Petit [EMAIL PROTECTED] wrote:
Ok, I think that I've found the problem, this patch was not applied in
RELENG_4_5 branch and is just available on RELENG_4 (so FreeBSD-4.6)
Effectlivly, my running kernel was not actually built from those sources. So
I can use AH/ESP however since I am using a satellite link
thru a modem/hub(NOC) that fiddles around with packets in order
to optimize them , I can't encrypt the headers otherwise the
optimizer can't see inside the packets and therefore can't see the
headers , so no optimization is done ,and I
Christophe Prevotaux wrote:
I can use AH/ESP however since I am using a satellite link
thru a modem/hub(NOC) that fiddles around with packets in order
to optimize them , I can't encrypt the headers otherwise the
optimizer can't see inside the packets and therefore can't see the
headers , so
I have a dell poweredge 2550 with which I am having all sorts of
nasty network problems.
The network interface will just stop responding.
I get an error message like this:
Jun 18 08:19:38 shekondar /kernel: bge0: watchdog timeout -- resetting
This is using the broadcom 10/100/1000 NIC on the
The DSL whole supplier we use (Bell Canada) has been turfing their Redback
SMSes and moving to an ERX from unisphere networks.
With the Redback, all was great... I had a FreeBSD box acting as a NAT
gateway for a number of Windows boxes and all was great. Then, the
customer got moved over to
On Tue, 18 Jun 2002, Mike Tancsa wrote:
The DSL whole supplier we use (Bell Canada) has been turfing their
Redback SMSes and moving to an ERX from unisphere networks.
There was, at one time, MTU problems with PPPoE. See the tcpmssd
port or other online documentation. I
Hi,
the mss fixup is enabled by default and is part of the stock PPP from what
I understand. Also, this was all working just great when the other end was
a redback. The problems only started when the telco moved the termination
to the ERX.
---Mike
At 04:34 PM 18/06/2002 -0500,
We have a Dell poweredge 2650 (successor to 2550).
We also saw the same problem with 4.5. I tried the current bge driver from 4.6
without success. The problem seems to be a size problem. When we ftp a small
file, things work fine. However, when we try a 18 Megabyte file, the ftp
hands and we see
Well, if you need to find the MTU, the ppp logs should tell you what the
remote end is telling you to use.
Usually, if you are having a MTU problem, it relates to fragmentation,
MTU detection and ICMP filters. FreeBSD uses MTU detection by default.
However, MTU detection requires that ICMP
Section 6.3 of the following document describes this issue in detail and may
help you solve it.
http://renaud.waldura.com/doc/freebsd/pppoe/
- Original Message -
From: Tom Samplonius [EMAIL PROTECTED]
To: Mike Tancsa [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, June 18,
Perhaps adding
set mtu max 1452
will help ?
On Tue, 18 Jun 2002 16:54:49 -0400, Mike Tancsa [EMAIL PROTECTED] wrote:
The DSL whole supplier we use (Bell Canada) has been turfing their Redback
SMSes and moving to an ERX from unisphere networks.
With the Redback, all was great... I had
Hi,
In terms of the MTU, I can set that in my router as I am the ISP
:-) Not sure how it works with Telus on the west coast, but with Bell,
PPPoE is done between the client and the DSL concentrator. Then the session
is handed off to the ISP via an L2TP tunnel. I can control that
Yes, that did it! Thanks very much! What is different about that, and me
setting it on the other end as part of the virt-template ?
---Mike
At 12:33 AM 6/19/2002 +0100, Brian Somers wrote:
Perhaps adding
set mtu max 1452
will help ?
On Tue, 18 Jun 2002 16:54:49 -0400, Mike
Possibly. There is a PPPoE session to the Redback (or ERX), then
usually a L2TP session to the ISP. A PPPoE client connecting to the
Redback (or ERX) should be told a valid MTU. PPP tunel to L2TP tunnel
raises some interesting possiblities. I wonder how much mucking about the
SMS does to
At 05:16 PM 6/18/2002 -0700, Tom Samplonius wrote:
Possibly. There is a PPPoE session to the Redback (or ERX), then
usually a L2TP session to the ISP. A PPPoE client connecting to the
Redback (or ERX) should be told a valid MTU. PPP tunel to L2TP tunnel
raises some interesting
Actually, in your documentation you mention that its broken for the
situation where the FreeBSD box acts as a gateway. In my case, its broken
right from the FreeBSD box. But the same machine connected with Windows 98
does not have the problem.
---Mike
At 04:18 PM 6/18/2002 -0700,
Looking at the TCPDump, to a host that works, I see
iscar# tcpdump -n -i tun0 'tcp[13] 2 != 0'
tcpdump: listening on tun0
23:21:37.506516 64.7.134.131.1029 199.212.134.1.80: S
3285534554:3285534554(0) win 57344 mss 1452,nop,wscale 0,nop,nop,timestamp
59058 0 (DF)
23:21:37.528294
I've released a new zero copy sockets snapshot, against -current from June
18th, 2002.
http://people.FreeBSD.org/~ken/zero_copy
The fixes that went into this snapshot:
- Take mutex locking out of ti_attach(), it isn't really needed.
As long as we can assume that probes of successive ti(4)
On Tue, Jun 18, 2002 at 10:36:36PM -0600, Kenneth D. Merry wrote:
I've released a new zero copy sockets snapshot, against -current from June
18th, 2002.
http://people.FreeBSD.org/~ken/zero_copy
The fixes that went into this snapshot:
- Take mutex locking out of ti_attach(), it
On Wed, Jun 19, 2002 at 00:43:13 -0400, Bosko Milekic wrote:
On Tue, Jun 18, 2002 at 10:36:36PM -0600, Kenneth D. Merry wrote:
I've released a new zero copy sockets snapshot, against -current from June
18th, 2002.
http://people.FreeBSD.org/~ken/zero_copy
The fixes that went into
There's something odd here - MSS does not include headers, and is 1460
on a straight ethernet connection. So your MSS of 1452 equates to an
MTU of 1492.
I'd try setting MTU (or MSS) way down, to 1024. If that works, you can
do a binary search to find the max working value.
You haven't shown
Brooks Davis stated the following on Tue, Jun 18, 2002 at 10:37:23AM -0700 :
On Tue, Jun 18, 2002 at 06:33:06PM +0100, Colin Whittaker wrote:
I have a dell poweredge 2550 with which I am having all sorts of
nasty network problems.
The network interface will just stop responding.
I get an
26 matches
Mail list logo
