Is there a way to zero out the packet/byte counters on pipes and queues
like you can to the rules? The command "ipfw pipe|queue zero" display a
message that accounting was cleared, but rather than clear out pipe or
queue counters it clears the rules counters only. Am I missing
something or is
I have a machine running 4.7. I can panic it by sending a reasonably
high load of tcp open/close from/to it. The trace below is from
a socket from localhost to localhost (sendmail). The max number
of open file descriptors I would have had would be ~4500.
The rx buffer says it has 43008 bytes, but t
I'm developing an application to set the interface to use for different
IP addresses, e.g. if I want to use a modem to talk to certain
"protected" nets while using the ordinary ethernet port for web access
a.s.o.
I've wracked my head for two days now, trying different ways of making
"route" do
On Fri, 25 Oct 2002, Romain Kang wrote:
> On Fri, Oct 25, 2002 at 10:03:21PM +0300, Petri Helenius wrote:
> > Are you sure that this is not caused by spanning tree delay on the ethernet
> > switch you are probably connected to?
>
> Time for me to read up on STP bridging. However, I'd be a little
Funny, this was the exact topic of my e-mail just 2 days ago (tcp_input's
header prediction and a collapsing send window). But you may have done a
better job of explaining.
My symptom was slightly different. When the send window drops below a
segment size, tcp_output() stops sending. It only s
On Fri, Oct 25, 2002 at 10:03:21PM +0300, Petri Helenius wrote:
> Are you sure that this is not caused by spanning tree delay on the ethernet
> switch you are probably connected to?
Time for me to read up on STP bridging. However, I'd be a little
surprised that the delay would occur when both hos
Lars Eggert wrote:
Attached is a rough patch to if_ethersubr.c that fixes the problem. It
should probably further be tweaked (there's a chance for duplicates),
but I wanted some comments first :-)
Here's a revised version of the patch (against bridge.c, which is a
better place for it) that onl
> Whatever the cause, is there some method better than the ping loop
> to determine if IP is actually getting out?
>
Look at the lights on the switch or the card.
Or put an analyzer on the wire.
We use fxp´s extensively and have never seen this.
Pete
To Unsubscribe: send mail to [EMAIL PROTECT
Um.. Seems like its the switch port Spanning tree bringing the port
active after 15 seconds of learning and 15 seconds of listening?
Romain Kang wrote:
I spent some time trying to figure out why the my ntpdate doesn't
seem to work. It appears to me that the fxp0 isn't transmitting
for a relat
Are you sure that this is not caused by spanning tree delay on the ethernet
switch you are probably connected to?
Pete
- Original Message -
From: "Romain Kang" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 25, 2002 10:00 PM
Subject: post-ifconfig delay causes ntpdate
I spent some time trying to figure out why the my ntpdate doesn't
seem to work. It appears to me that the fxp0 isn't transmitting
for a relatively long period of time following the ifconfig. The
saga follows.
On the client (10.10.1.101), I gave ntpdate the -d flag and saved
its output. ntpdate
Marko,
Marko Zec wrote:
This problem was also solved in the giant patch for network stack
virtualization.
I had looked at that patch briefly, and it looked like VERY interesting
work. If it fixes the bridging code, too, it's even better - I'll
definitly look forward to using it, once it has
- Original Message -
From: "Markko Merzin" <[EMAIL PROTECTED]>
To: "Charlie Root" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, October 24, 2002 4:16 PM
Subject: Re: VLAN problems with replies to broadcast
> On Wed, 23 Oct 2002, Charlie Root wrote:
>
> > The fxp is plugged
Julian Elischer wrote:
> On Thu, 24 Oct 2002, Marko Zec wrote:
>
> > Julian Elischer wrote:
> >
> >
> > > 11/ why was ng_bridge unsuitable for your use?
> >
> > Both the native and netgraph bridging code, I believe, were designed with
> > the presumption that only one "upper" hook is really needed
Lars Eggert wrote:
> The ISC dhcpd uses a bpf to "listen" on an interface. When a broadcast
> packet (e.g. DHCP request) comes in on one interface, the bridging code
> will correctly forward it out all the other interfaces in the cluster,
> and also deliver it locally. However, it will not send co
15 matches
Mail list logo
