I've been running the attached patch for a month on routers in production.
To summarize:
* Routing daemons listen to routing messages.
* Without the patch routing messages all FIBs are sent to
all listeners.
* Routing daemons get confused.
This patch makes routing daemons listening to routi
The following reply was made to PR kern/137164; it has been noted by GNATS.
From: Stef Walter
To: bug-follo...@freebsd.org, jha...@pangolin-systems.com,
Bruce Simpson
Cc:
Subject: Re: kern/137164: [netinet] [patch] assert panic imo_match_source()
Date: Tue, 06 Oct 2009 10:37:31 -0500
This
Denis Shaposhnikov wrote:
> Hello,
>
> On Thu, 24 Sep 2009 19:46:41 -0700
> Sam Leffler wrote:
>
>>> May be do you know why I'm getting normal speed (2Mb/s) for some
>>> time after using "ifconfig bssid ..." command only?
>> When you set the bssid you reset the state of the tx rate control code
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: Stef Walter
To: bug-follo...@freebsd.org, co...@211.ru, m.dyadche...@sibset-team.ru
Cc:
Subject: Re: kern/134931: [route] [fib] Route messages sent to all socket
listeners regardless of setfib
Date: Tue, 22 Sep
Denis Shaposhnikov wrote:
> I see also it periodically changes "media:" between OFDM/54Mbps and
> OFDM/48Mbps.
That's normal behavior. ath_rate_sample is finding the OFDM speed at
which traffic flows best.
Cheers,
Stef
___
freebsd-net@freebsd.org mail
Randy Bush wrote:
> say i run routed and receive rip default from two routers, on the same
> local ether. what is the forwarding? i presume it's not smart enough
> to balance flows. i hope not alternating packets. clue, please?
Unless you have RADIX_MPATH in your kernel (with a recent FreeBSD,
When removing multicast membership from a socket (ie:
IP_DROP_MEMBERSHIP) that has multiple multicast memberships, the
internal list of memberships and filters are not kept in sync.
This results in dropped packets that are not delivered to the socket
that has the multicast membership. This was exp
Stef Walter wrote:
> The packets from 172.27.2.2 are not being delivered to the ospfd process
> socket (verified via userland debugging and logging). Even though, as
> you can see above the em0 interface is part of the group.
I've done more research on this.
Each time a packet is
Bruce Simpson wrote:
> I think this can probably go right in as-is. I'm supposed to be looking
> at other stuff now, so hopefully syrinx@ can check this in if I don't
> get around to it.
Great news. Should I just make a PR for this? Or is there somewhere I
should put it for the 8.0 BETA?
After th
If a multicast caller does an IP_DROP_MEMBERSHIP followed by a
IP_ADD_MEMBERSHIP, often an uninitialized filter is used for the
in_mfilter passed to in_joingroup_locked() in netinet/in_mcast.c.
The IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP have simple in_mreq input,
and are not using SSM or any of
After an interface goes down and its addresses go away, if a caller
calls setsockopt/IP_DROP_MEMBERSHIP with a simple in_mreq input
containing the address that no longer exists, the kernel should return
EADDRNOTAVAIL.
However the current behavior in 8.0-BETA3 is to remove a membership to
the same
Shteryana Shopova wrote:
> I actually managed to get the same kernel dump using the following
> sample code - http://people.freebsd.org/~syrinx/mcast/mcast_crash.c
> and the crash is 100% reproducable. A temporary fix is here -
> http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff
>
Bruce Simpson wrote:
> [Brief reply as I'm meant to be doing a zillion other things...]
>
> Bruce Simpson wrote:
>>
>> Full OS version, dmesg, panic and backtrace please, when reporting
>> this kind of issue... otherwise folk can't help. Are you using SSM
>> multicast features?
>
> P.S. You might
Bruce Simpson wrote:
> Full OS version, dmesg, panic and backtrace please, when reporting this
> kind of issue... otherwise folk can't help.
Thanks for taking a look. It was linked in the parent post:
> This is the stack trace:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/137164&cat=
> Are
Stef Walter wrote:
> On a new VPN server, running OSPF, I'm experiencing regular panics at:
>
> imo_match_source: !AF_INET
BTW, src->sa_family is 0
Moved back to FreeBSD 7.1 i386 and the problem goes away.
Cheers,
Stef
___
freebs
Boris Kochergin wrote:
>> ___
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
> More information: I upgraded it to a 7.2-STABLE with
On a new VPN server, running OSPF, I'm experiencing regular panics at:
imo_match_source: !AF_INET
System is: 8.0-BETA3 i386
This is the stack trace:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/137164&cat=
I noticed this code was changed as part of an IGMPv3 update in March:
http://www.fre
Stef Walter wrote:
> A short while ago (perhaps due to a change in traffic), every few hours,
> the wireless interface becomes unresponsive, and I started seeing
> thousands of lines like this in:
>
> ath0: ath_rx_proc: no mbuf!
> ath0: ath_rx_proc: no mbuf!
> ath0: ath_rx_
Li, Qing wrote:
> There are other commands through the routing socket that
> can trigger routing messages. For example, issuing "ifconfig"
> to add and remove interface addresses.
Thanks for taking a look at this and catching that problem. Here's a new
patch which does the following:
* Both rt_d
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: Stef Walter
To: "Li, Qing"
Cc: "freebsd-net@FreeBSD.org" ,
bug-follo...@freebsd.org, jul...@elischer.org
Subject: Re: kern/134931 [patch] Unbreak setfib + routing daemons
Date: Mon, 31 Aug 09
Julian Elischer wrote:
> there are two ways to go with this one being what you have done teh
> other to add fib info to the messages, Apparently
> OpenBSD has implemented the second by re-using a disused field.
> (I'm ve only been told this second hand)
It seems like they've taken apart the rtm_fl
The following reply was made to PR kern/134931; it has been noted by GNATS.
From: Stef Walter
To: bug-follo...@freebsd.org, co...@211.ru
Cc:
Subject: Re: kern/134931:[route] [fib] Route messages sent to all socket
listeners
regardless of setfib
Date: Mon, 31 Aug 09 17:20:06 UTC
This is a
Currently route messages are sent to all listeners of PF_ROUTE,
regardless or which FIB the listener socket was started on.
The upshot of this is that one can't really use routing daemons together
with multiple FIBs. The routing daemon sees the messages from the
alternate FIBs and rapidly gets con
Lev Serebryakov wrote:
> Hello, Stef.
>
>> ath0: ath_rx_proc: no mbuf!
>
>> The mbufs are in fact all used up. I allocate more via
>> kern.ipc.nmbclusters, and see the same behavior.
> Same problem here on 7.2-STABLE, but incresaing kern.ipc.nmbclusters
> to 65536 helps. It seems, that when traf
I'm having a problem on an old FreeBSD 6.0 box, that's a wireless
router, been running steadily for years.
A short while ago (perhaps due to a change in traffic), every few hours,
the wireless interface becomes unresponsive, and I started seeing
thousands of lines like this in:
ath0: ath_rx_proc:
I've started running 64-bit FreeBSD (version 7.2) in production. I have
a lot of old 6.3 32-bit jails I need to run as is for now.
One problem I ran into is 32-bit getifaddrs() would crash accessing a
64-bit kernel via the sysctl NET_RT_IFLIST method.
Attached is a patch that adds 32-bit compatib
was
in development (blush) and it's deployed as such on a couple dozen
production servers I've been running bsnmp-jails and bsnmp-pcap on.
If not, then any other two numbers are fine. Once I hear officially,
I'll roll new releases.
Cheers,
Stef Walter
__
27 matches
Mail list logo
