On Wed, Nov 28, 2001 at 04:52:59PM -0800, Crist J. Clark wrote:
> On Wed, Nov 28, 2001 at 12:31:09PM -0500, Garrett Wollman wrote:
> > <
>said:
> >
> > > Where inet_pton(3) will fail (return a 1). That is, inet_pton(3) only
> > > understands dotted quads. The comments in src/lib/libc/net/inet_pt
On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> Thanks...I know where my problem is now...It's indeed a duplicate SYN.
>
> By the way, the tcp_input function is so long and large and there are
> several goto statements which make reading the code even more difficult. Is
> this intened
> For TCP, that is what is always used by default when creating an
> outbound connection. For incoming connections, the machine will of
> course reply using the IP address the connection came in on. And a
> program can always request to use a specific address if it wants to.
>
> I am not sure wher
as recognised in the ports bug report, the isakmpd port for freebsd soaks
up 99% CPU even when no connections have been established - even when in
completely passive-connection mode.
i'm not an expert coder but i think the select() in the main loop (isakmpd.c
main()) is doing this.
is there a
* Tariq Rashid <[EMAIL PROTECTED]> [011129 08:04] wrote:
>
> as recognised in the ports bug report, the isakmpd port for freebsd soaks
> up 99% CPU even when no connections have been established - even when in
> completely passive-connection mode.
>
> i'm not an expert coder but i think the sel
What's our current best recommended solution for channel-bonding ethernet
cards? Netgraph?
-
Kris Kirby, KE4AHR | TGIFreeBSD... 'Nuff said.
<[EMAIL PROTECTED]> | IM: KrisBSD
---
"Fate, it seems, is not without a sense of irony."
On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> Thanks...I know where my problem is now...It's indeed a duplicate SYN.
>
> By the way, the tcp_input function is so long and large and there are
> several goto statements which make reading the code even more difficult. Is
> this intened
On Thu, Nov 29, 2001 at 10:05:34AM -0600, Jonathan Lemon wrote:
> On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> > Thanks...I know where my problem is now...It's indeed a duplicate SYN.
> >
> > By the way, the tcp_input function is so long and large and there are
> > several goto sta
On Thu, Nov 29, 2001 at 08:30:06AM -0800, Luigi Rizzo wrote:
> On Thu, Nov 29, 2001 at 10:05:34AM -0600, Jonathan Lemon wrote:
> > On Thu, Nov 29, 2001 at 03:03:04PM +0800, ¼B¾JÂ× wrote:
> > > Thanks...I know where my problem is now...It's indeed a duplicate SYN.
> > >
> > > By the way, the tcp
On Thu, Nov 29, 2001 at 11:27:50AM -0600, Jonathan Lemon wrote:
>
> All the various #ifdefs scattererd over the code are absolutely sick;
> they fairly scream out for a sensible rewrite. However, from my point
> of view, if I'm going to rewrite things, there should be functional
> improvements a
On Thu, Nov 29, 2001 at 03:38:19PM +, Kris Kirby wrote:
>
> What's our current best recommended solution for channel-bonding ethernet
> cards? Netgraph?
http://people.freebsd.org/~wpaul/FEC/
/Jesper
--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
Work:Network manager @ AS
On Thu, Nov 29, 2001 at 06:01:04PM +0500, Ahsan Ali wrote:
> > For TCP, that is what is always used by default when creating an
> > outbound connection. For incoming connections, the machine will of
> > course reply using the IP address the connection came in on. And a
> > program can always reque
On Thursday, November 29, 2001, at 05:01 , Ahsan Ali wrote:
>> For TCP, that is what is always used by default when creating an
>> outbound connection. For incoming connections, the machine will of
>> course reply using the IP address the connection came in on. And a
>> program can always reques
> On Mon, 26 Nov 2001, Luigi Rizzo wrote:
>
> > [Bcc to -stable in case someone is interested there]
> >
> > Attached you can find the latest version of the polling code
> > for STABLE (which is useful to make boxes much more robust
> > to attacks and have much better responsiveness under [over]lo
Bruce, thanks for the feedback.
Re. the second issue:
the code was placed in kern_clock.c just as a placeholder (and
because i needed to touch a couple of places in that file, i tried
to minimize the number of files affected by the patch). But surely,
the core of the code can go somewhere else,
If memory serves me right, Garrett Wollman wrote:
> Each trace shows a single large file transfer from a 4.4-stable
> machine to my -current desktop over a local-area network.
I'm pretty rusty at debugging TCP implementations, but I'll try to
contribute something...
Your 4.4-STABLE machine,
OK, I think this time around I have fixed the duplex issues and the problem
with the D-link not being initialized properly (reset PCI config data in
the BIOS fixed a the problems).
Using netperf I ran the basic snapshot script to see what affect the
polling code had on network performance. I
> > Matthew Emmerton wrote:
> > >
> > > Hi all,
> > >
> > > In the continuing saga of IPSec over PPPoE for a retail POS
environment that
> > > I'm maintaing, the problems seem to become more complex as time goes
on.
> > >
> > > The network is quite simple:
> > > [ LAN #1 ] - [ FreeBSD Gateway #1 ]
In article
[EMAIL PROTECTED]> you
write:
>-=-=-=-=-=-
>test4 was the only trace I looked at. One thing that caught my eye is
>that the receiver seems to be sending a bunch of dupacks (in some cases,
>many more than needed to trigger fast retransmit) but no retransmit
>happens. In *most* cases,
On Thu, 29 Nov 2001, Luigi Rizzo wrote:
> The call to update_poll_threshold() however needs to be done by
> either hardclock() or statclock() (i am experimenting with that
> right now) because the purpose is to sample what the CPU is doing
> when we get that particular interrupt.
Why in that par
20 matches
Mail list logo
