John, good day.
Tue, Mar 20, 2007 at 09:31:50AM +0200, John Hay wrote:
> > >
> > splx() and friends have been no-ops since FreeBSD 5.x was branched.
> > Synchronization is now done using other mechanisms such as mutexes and
> > spin locks. See the new man page locking(9) in -CURRENT.
>
> It d
On Mon, Mar 19, 2007 at 10:14:33PM +, Bruce M. Simpson wrote:
> Ignacio Rey wrote:
> >...
> >The question is: Have calls to these functions been wrapped? or are they
> >simply not used in this context?
> >
> splx() and friends have been no-ops since FreeBSD 5.x was branched.
> Synchronizatio
Hi list,
First, excuse-me by the off-topic message, I asked this on -questions
but I don't have any answer.
I'm trying to setup ifstated to check two links and if some go down,
do some actions like change pf rules and machine's route.
My doubt is about the execution order/repetition of t
Andre Oppermann wrote:
http://people.freebsd.org/~bms/dump/multi_refcounting.diff
Patch looks good. :-)
Committed, with some changes.
Regards,
BMS
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To un
Kevin Lahey wrote:
The boxes were running FreeBSD-6.1, but I can't really vouch for the
particular kernel configuration. It could well be that the problem is
with the loose nut behind the wheel, rather than with FreeBSD. :-)
I believe PMTU measurements may only be relied upon for active TC
On Mon, 19 Mar 2007 14:54:22 -0700
Kevin Lahey <[EMAIL PROTECTED]> wrote:
> Of course, the real test is to set up a few hosts and see what
> happens, rather than speculating based on a quick perusal of the
> code. :-)
After my slap-dash read of the current FreeBSD code, I was a little
concerned t
On Tue, 6 Mar 2007 10:35:42 +0530
"aditya kiran" <[EMAIL PROTECTED]> wrote:
> RFC 1191 says to increase the PMTU at some itnerval (15 minutes default)
10 minutes.
> next time a packet is sent, this will be used... and if PMTU is really
> increased,
> no ICMP error will be recieved. that shows an
Ignacio Rey wrote:
...
The question is: Have calls to these functions been wrapped? or are they
simply not used in this context?
splx() and friends have been no-ops since FreeBSD 5.x was branched.
Synchronization is now done using other mechanisms such as mutexes and
spin locks. See the new
Ignacio Rey wrote:
Hello everyone,
I'm studying a bit the FreeBSD networking code.
I've read "TCP/IP illustrated vol 2" by G. R. Wright and W. R. Stevens,
which describes code in 4.4BSD-lite.
Now I'm taking a look at FreeBSD 6.2 release. Some things are different,
many others kept the same. Wh
> "Doug" == Doug Barton <[EMAIL PROTECTED]> writes:
Doug> Kian Mohageri wrote:
>> I agree VERY MUCH with this sort of approach. It would be a much
>> cleaner solution than completely separate handling of all of these
>> different problems. I'm trying to get an idea of what all of the
>> majo
Hello everyone,
I'm studying a bit the FreeBSD networking code.
I've read "TCP/IP illustrated vol 2" by G. R. Wright and W. R. Stevens,
which describes code in 4.4BSD-lite.
Now I'm taking a look at FreeBSD 6.2 release. Some things are different,
many others kept the same. What I'm confused about
On 3/11/07, Robert Watson <[EMAIL PROTECTED]> wrote:
There are several ways we could start to reduce contention on that lock:
(3) Move towards greater granularity of locking for the tcbinfo: instead
of
a single mutex, move to more than one locks, so that different
connections
process
Bruce M Simpson wrote:
Hi,
A patch against -CURRENT is now available:
http://people.freebsd.org/~bms/dump/multi_refcounting.diff
This is a fairly sweeping architectural change which should resolve
memory leaks and potential panics with the network stack as a whole, to
better support interf
Hi,
A patch against -CURRENT is now available:
http://people.freebsd.org/~bms/dump/multi_refcounting.diff
This is a fairly sweeping architectural change which should resolve
memory leaks and potential panics with the network stack as a whole, to
better support interface detach at runtime.
> Mine applied cleanly to sources from last Friday.
O.K., that works (now I have the correct date in my supfile). Will
give it a shot...
-pete.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe
At 12:28 PM 3/19/2007, Pete French wrote:
> I have made bge(4) patch for -STABLE (sorry, not suitable for
> RELENG_6_2):
What dates stable is this relative to ? I am trying to apply your
patch to a cvsup of stable pulled on the day/time you sent your email,
but parts of it are failing for me unf
Shteryana Shopova wrote:
On 3/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Max, correct me if I'm wrong but tcpdump will only give you the
headers, is that correct? This is fine most of the time but sometimes
I need to capture full frames.
Nope - that's not correct -
#tcpdump -s 0
wi
Kian Mohageri wrote:
After re-reading your original idea, I think I understand a little
better what you mean to do. For clarification, are you proposing that
the [early] firewall scripts do nothing if firewall_late_enable=YES, and
then have all firewalling taken care of later in the boot proces
Eugene Grosbein wrote:
I recall that routed and ripd used to utilize something similar
long time ago. I'm not sure if they have switched to another API.
You're right -- this would break routed on point-to-point interfaces.
They didn't, unless it was updated at the upstream, i.e. rhyolite.co
> I have made bge(4) patch for -STABLE (sorry, not suitable for
> RELENG_6_2):
What dates stable is this relative to ? I am trying to apply your
patch to a cvsup of stable pulled on the day/time you sent your email,
but parts of it are failing for me unfortunately. I would like to test this
as I
On Mon, Mar 19, 2007 at 02:28:52PM +, Bruce M Simpson wrote:
> I plan to get rid of the ugly little ip_multicast_if() hack in the IP
> stack.=
> Before I do, is anyone actually using this?
>
> RFC 3678 specifies a protocol independent API for socket group
> memberships which allow joins on
Hi,
I plan to get rid of the ugly little ip_multicast_if() hack in the IP
stack.=
Before I do, is anyone actually using this?
RFC 3678 specifies a protocol independent API for socket group
memberships which allow joins on interfaces referenced by index. This is
intended to support IGMPv3 and
On 3/19/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Max, correct me if I'm wrong but tcpdump will only give you the headers, is
that correct? This is fine most of the time but sometimes I need to capture
full frames.
Nope - that's not correct -
#tcpdump -s 0
will capture full frames.
Max, correct me if I'm wrong but tcpdump will only give you the headers, is
that correct? This is fine most of the time but sometimes I need to capture
full frames.
Thanks
Manuel Ochoa CCNP MCSA MCSE MCDBA
- Original Message
From: Max Laier <[EMAIL PROTECTED]>
To: freebsd-net@fre
Current FreeBSD problem reports
Critical problems
Serious problems
S Tracker Resp. Description
a kern/38554 netchanging interface ipaddress doesn't seem to work
s kern/39937 netipstealth
> Therefore I believe strongly that the default behavior should be
> changed to load all firewalls (and rules) before netif, and that those
> who want to do firewall-related things that require netif or routing
> to be up should be the ones who have to opt in to the new script. That
> said, I
26 matches
Mail list logo
