- Original Message -
From: "Bikrant Neupane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, March 08, 2005 11:01 PM
Subject: Session Timeout issue in pppoed
> Hi,
> I have a pppoe server on FreeBSD 4.10.
> I have configured my Radius Server ( radiator) to set Session
On 2005-03-06 13:05, Andreas Bachmann <[EMAIL PROTECTED]> wrote:
> > AFAIK, this can only be done if the original process calls execve() on a
> > setuid binary and has not marked the socket descriptor as close-on-exec.
>
> i'm developing a gtk+ based equivalent to 'sockstat'.
> when a user is propo
On my NPE-G1 running just IOS 12.3(12a) cpu utilization was something
like 70-90% but with IOS 12.3(11)T3 it is 20% since this one has NAT
inside CEF and yes using small portions of address for NAT pool will
reduce CPU utilization and will improve NAT on 7206. However if you
compare prices of P
Goran Gajic wrote:
Actually I was interested if Dual Opteron with FBSD5.3
can compare with Cisco7206 with NPE-G1 running only for NAT
You'll need good motherboard, NICs, 1-2GB of RAM and quite capable
CPU. Two won't help much, but sometimes the motherboards for two
CPUs provide higher standard (sep
Hi,
I have used succesfuly FBSD 5.2.1 as BGP router and it is rock stable with
quagga (check out www.quagga.net) - more stable then 30k $ Cisco 7206 :))
Problem is if you have AS and LIR and if you don't there are other
solutions. Of course much depends is your uplink ISP willing to cooperate.
> In this particular case, the server is increasing the window size with
> subsequent ACKs. What does this mean? The receive buffer became less
> full so quickly? The receive buffer was enlarged?
The last ACKs that you mention are window update notifications that the client
application removed
Actually I was interested if Dual Opteron with FBSD5.3
can compare with Cisco7206 with NPE-G1 running only for NAT
purpose of some 7000 hosts (and sadly more then ~80k pps can easly bring it
down and no one can comfirm that 7206 with NPE-G1 can actually process 1M
pps:). Ipfilter that is include
On Tue, Mar 08, 2005 at 08:11:00AM -0600, Mark Tinguely wrote:
> The server is not telling the client that a packet has been lost.
> The first two ACKs are correct duplicate ACKs, but the remaining
> ACKs coming from he server have window adjustments, so the
> client does not treat them as duplica
Hi,
I have recently cvsuped to a new snapshot of -current, the existing system
was about 1-2 months old. I am now seeing a lot of link state messages in
dmesg.
em0: link state changed to DOWN
em0: link state changed to UP
em0: link state changed to DOWN
em0: link state changed to UP
em0: link sta
Hi all,
If I have the following on hand...
- 2 FastEthernet uplinks from ISP
- 1 GigabitEthernet port on my switch
- a subset of a /24 allocated by ISP
The gigabit ethernet link should be connecting to my internal network.
Problem: My internal network has been maxing out its 100Mbps limit, but my
I
Here is diff that makes ipfilter 4.1.6 able to compile on amd64
as kernel option IPFILTER:
--- ip_frag.c Tue Mar 8 13:51:04 2005
+++ ip_frag.c Tue Mar 8 14:53:46 2005
@@ -391,7 +398,7 @@
WRITE_ENTER(&ipf_ipidfrag);
fra = ipfr_newfrag(fin, 0, ipfr_ipidtab);
if (fra !=
Hi,
I have a pppoe server on FreeBSD 4.10.
I have configured my Radius Server ( radiator) to set Session-Timeout
parameter so that the clients who are using prepaid hour based service get
disconnected when their time is over. In the ppp.log file I see the the
Sessio-Timeout being accepted by th
Basing from what I see in Daniel Hartmeier analysis of tcpdump
(I honestly did not look at the original, when is has been summerized
so conveniently):
The server is not telling the client that a packet has been lost.
The first two ACKs are correct duplicate ACKs, but the remaining
ACKs coming fro
According to RFC 793 (the original TCP specification), the client may
(even should) wait at least one second before retransmitting any
segment.
However, RFC 2001 describes Fast Retransmission, where the third
acknowledgment for the same segment should be interpreted as an
indication of packet loss
On Tue, Mar 08, 2005 at 02:04:20AM -0500, Charles Sprickman wrote:
> http://home.manymonkeys.com/tcpdump/
> Observing this showed that the os-x to fbsd transfer went at about 200KB/s
> and the os-x to obsd transfer went at about 2.6MB/s.
In the osx-fbsd case we see the same problem again. This
15 matches
Mail list logo
