Re: connect(): Operation not permitted
Kian Mohageri wrote: > On Sun, May 18, 2008 at 3:33 AM, Johan Ström <[EMAIL PROTECTED]> wrote: >> On May 18, 2008, at 9:19 AM, Matthew Seaman wrote: >> >>> Johan Ström wrote: >>> >>>> drop all traffic)? A check with pfctl -vsr reveals that the actual rule >>>> inserted is "pass on lo0 inet from 123.123.123.123 to 123.123.123.123 flags >>>> S/SA keep state". Where did that "keep state" come from? >>> 'flags S/SA keep state' is the default now for tcp filter rules -- that >>> was new in 7.0 reflecting the upstream changes made between the 4.0 and >>> 4.1 >>> releases of OpenBSD. If you want a stateless rule, append 'no state'. >>> >>> http://www.openbsd.org/faq/pf/filter.html#state >> Thanks! I was actually looking around in the pf.conf manpage but failed to >> find it yesterday, but looking closer today I now saw it. >> Applied the no state (and quick) to the rule, and now no state is created. >> And the problem I had in the first place seems to have been resolved too >> now, even though it didn't look like a state problem.. (started to deny new >> connections much earlier than the states was full, altough maybee i wasnt >> looking for updates fast enough or something). >> > > I'd be willing to bet it's because you're reusing the source port on a > new connection before the old state expires. > > You'll know if you check the state-mismatch counter. > > Anyway, glad you found a resolution. I've been experiencing this "Operation not permitted" too. I've been trying to track down the problem for many months, but due to the complexity of my firewalls (scores of jails each with scores of rules), I wasn't brave enough to ask for help :) As a work around we started creating rules without state, whenever we would run into the problem. Thanks for the pointer about state-mismatch. The state-mismatch counter does is in fact high in my case (see below). How would I go about getting the pf state timeout and the reuse of ports for outbound connections to match? Or is this an intractable problem, that just needs to be worked around? Cheers, Stef Walter Status: Enabled for 13 days 23:55:25 Debug: Urgent Hostid: 0x38ae6776 State Table Total Rate current entries 65 searches 819507771 677.7/s inserts 11366700.9/s removals 11366050.9/s Counters match 787482855 651.2/s bad-offset 00.0/s fragment 00.0/s short 00.0/s normalize 00.0/s memory 00.0/s bad-timestamp 00.0/s congestion 00.0/s ip-option 00.0/s proto-cksum00.0/s state-mismatch 7480.0/s state-insert 00.0/s state-limit00.0/s src-limit 00.0/s synproxy 00.0/s ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
bsnmp module for monitoring network flows: bsnmp-pcap
Figured this may be interesting for folks... I've released a bsnmp module which can monitor arbitrary traffic flows and expose them as SNMP counters. FreeBSD port attached, more info here: http://memberwebs.com/stef/software/bsnmp-pcap/ Cheers, Stef Walter ___ 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"
Re: bsnmp module for monitoring network flows: bsnmp-pcap
Harti Brandt wrote: > I probably missed something here. Any other conflicts? Can we move bsnmp-pcap > to 207? And does bsnmp-jails conflict with something? Like Shteryana said, it seems like it does conflict... Would it work to have and 1112? I used those while the software 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 ___ 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"
[patch] Unbreak setfib + routing daemons
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 confused.
In the future, someone might decide to expose FIB numbers in the route
messages themselves. This could allow routing daemons to filter them
out. Such a solution might be appropriate for FreeBSD 9.x and later, as
it would likely break API and ABI. In any case, I'm not really qualified
to argue the merits/problems of such an approach, and coding it is
beyond my abilities...
Attached is a patch which fixes this problem in a simple way. It limits
route messages to listening PF_ROUTE sockets on the same FIB that the
route message was for. It compiles and works on 7.1+ and 8.0 and CURRENT.
FreeBSD PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931
How can I help this get into FreeBSD? It would be awesome if this fix or
one like it made it in before the 8.0 release.
Cheers,
Stef
--- sys/net/rtsock.c.orig 2009-08-31 15:26:03.0 +
+++ sys/net/rtsock.c 2009-08-31 16:07:06.0 +
@@ -777,4 +777,5 @@
}
if (m) {
+ M_SETFIB(m, so->so_fibnum);
if (rp) {
/*
--- sys/net/raw_usrreq.c.orig 2009-08-31 16:04:58.0 +
+++ sys/net/raw_usrreq.c 2009-08-31 16:05:11.0 +
@@ -84,4 +84,7 @@
rp->rcb_proto.sp_protocol != proto->sp_protocol)
continue;
+ if (proto->sp_family == PF_ROUTE && rp->rcb_socket &&
+ M_GETFIB (m) != rp->rcb_socket->so_fibnum)
+ continue;
if (last) {
struct mbuf *n;
___
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"
Re: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib
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 multi-part message in MIME format.
--030509050508050401080102
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
As it currently stands, using routing daemons + multiple fibs in FreeBSD
7.x and 8.x is pretty much broken. Here's a patch which fixes the problem.
I agree in principle with Mark that having future route messages might
be able to let routing daemons differentiate between various fibs and
manage them, and that this might be a feature However any
implementation of that would likely break API and ABI, and very probably
exist purely in FreeBSD 9.x.
All the best,
Stef
--030509050508050401080102
Content-Type: text/x-diff;
name="freebsd-route-messages-respect-fib.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="freebsd-route-messages-respect-fib.patch"
--- sys/net/rtsock.c.orig 2009-08-31 15:26:03.0 +
+++ sys/net/rtsock.c 2009-08-31 16:07:06.0 +
@@ -777,4 +777,5 @@
}
if (m) {
+ M_SETFIB(m, so->so_fibnum);
if (rp) {
/*
--- sys/net/raw_usrreq.c.orig 2009-08-31 16:04:58.0 +
+++ sys/net/raw_usrreq.c 2009-08-31 16:05:11.0 +
@@ -84,4 +84,7 @@
rp->rcb_proto.sp_protocol != proto->sp_protocol)
continue;
+ if (proto->sp_family == PF_ROUTE && rp->rcb_socket &&
+ M_GETFIB (m) != rp->rcb_socket->so_fibnum)
+ continue;
if (last) {
struct mbuf *n;
--030509050508050401080102--
___
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"
Re: [patch] Unbreak setfib + routing daemons
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_flags field (int), and repurposed it as rtm_tableid (u_short), rtm_priority (u_char) and padding. Obviously such a change would require patches to the various routing daemons as well. But if you think this is the only way forward (ie: filtering the messages in userland), I'd be happy to contribute. > I"ll look a tyour change and see what we can do. > it might just make it to 8.1 at this stage but we can > see what it looks like. I've posted a new patch which should handle all the various senders of route messages better. Qing Li pointed out some naive assumptions I made in my initial patch. It's more complex because we can no longer use M_GETFIB and M_SETFIB to relay FIB information into the netisr routine. > how much have you tested this? I need this for some client systems that we're upgrading. I'll be putting it into production this week. If there's any problems with it, I'll let you and the mailing list know. Cheers, Stef ___ 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"
Re: kern/134931 [patch] Unbreak setfib + routing daemons
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 20:00:13 UTC
This is a multi-part message in MIME format.
--000601070001040803040904
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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_dispatch and raw_input accept an fib, or -1 (for any fib).
* Pases the fib along in the context to the netisr routine
that actually dispatches route messages.
* As you noted, some senders of route messages don't have the
context necessary to know what fib a message would belong to.
Where possible we pass in the appropriate fib to the routines
that send off route messages.
Cheers,
Stef
--000601070001040803040904
Content-Type: text/x-diff;
name="freebsd-route-messages-respect-fib-2.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="freebsd-route-messages-respect-fib-2.patch"
--- ./sys/net/rtsock.c.orig2009-08-31 15:26:03.0 +
+++ ./sys/net/rtsock.c 2009-08-31 19:06:53.0 +
@@ -93,4 +93,9 @@
SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, "");
+struct rt_dispatch_ctx {
+ unsigned short family; /* Socket family */
+ intfibnum; /* FIB for message or -1 for all */
+};
+
struct walkarg {
int w_tmemsize;
@@ -114,5 +119,5 @@
static void rt_getmetrics(const struct rt_metrics_lite *in,
struct rt_metrics *out);
-static void rt_dispatch(struct mbuf *, const struct sockaddr *);
+static void rt_dispatch(struct mbuf *, const struct sockaddr *, int);
static struct netisr_handler rtsock_nh = {
@@ -155,17 +160,19 @@
{
struct sockproto route_proto;
- unsigned short *family;
+ struct rt_dispatch_ctx *ctx;
struct m_tag *tag;
+ int fibnum = -1;
route_proto.sp_family = PF_ROUTE;
- tag = m_tag_find(m, PACKET_TAG_RTSOCKFAM, NULL);
+ tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL);
if (tag != NULL) {
- family = (unsigned short *)(tag + 1);
- route_proto.sp_protocol = *family;
+ ctx = (struct rt_dispatch_ctx*)(tag + 1);
+ route_proto.sp_protocol = ctx->family;
+ fibnum = ctx->fibnum;
m_tag_delete(m, tag);
} else
route_proto.sp_protocol = 0;
- raw_input(m, &route_proto, &route_src);
+ raw_input(m, &route_proto, &route_src, fibnum);
}
@@ -784,8 +791,8 @@
unsigned short family = rp->rcb_proto.sp_family;
rp->rcb_proto.sp_family = 0;
- rt_dispatch(m, info.rti_info[RTAX_DST]);
+ rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum);
rp->rcb_proto.sp_family = family;
} else
- rt_dispatch(m, info.rti_info[RTAX_DST]);
+ rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum);
}
}
@@ -1010,5 +1017,5 @@
*/
void
-rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error)
+rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error, int
fibnum)
{
struct rt_msghdr *rtm;
@@ -1025,5 +1032,5 @@
rtm->rtm_errno = error;
rtm->rtm_addrs = rtinfo->rti_addrs;
- rt_dispatch(m, sa);
+ rt_dispatch(m, sa, fibnum);
}
@@ -1050,5 +1057,5 @@
ifm->ifm_data = ifp->if_data;
ifm->ifm_addrs = 0;
- rt_dispatch(m, NULL);
+ rt_dispatch(m, NULL, -1);
}
@@ -1062,5 +1069,5 @@
*/
void
-rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt)
+rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt, int
fibnum)
{
struct rt_addrinfo info;
@@ -1120,5 +1127,5 @@
rtm->rtm_addrs = info.rti_addrs;
}
- rt_dispatch(m, sa);
+ rt_dispatch(m, sa, fibnum);
}
}
@@ -1156,5 +1163,5 @@
ifmam->ifmam_index = ifp->if_index;
ifmam->ifmam_addrs = info.rti_addrs;
- rt_dispatch(m, ifma->ifma_addr);
+ rt_dispatch(m, ifma->ifma_addr, -1);
}
@@ -1216,5 +1223,5 @@
m->m_pkthdr.len += data_len;
mtod(m, struc
Re: kern/134931 [patch] Unbreak setfib + routing daemons
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_dispatch and raw_input accept an fib, or -1 (for any fib).
* Pases the fib along in the context to the netisr routine
that actually dispatches route messages.
* As you noted, some senders of route messages don't have the
context necessary to know what fib a message would belong to.
Where possible we pass in the appropriate fib to the routines
that send off route messages.
Cheers,
Stef
--- ./sys/net/rtsock.c.orig 2009-08-31 15:26:03.0 +
+++ ./sys/net/rtsock.c 2009-08-31 19:06:53.0 +
@@ -93,4 +93,9 @@
SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, "");
+struct rt_dispatch_ctx {
+ unsigned short family; /* Socket family */
+ intfibnum; /* FIB for message or -1 for all */
+};
+
struct walkarg {
int w_tmemsize;
@@ -114,5 +119,5 @@
static void rt_getmetrics(const struct rt_metrics_lite *in,
struct rt_metrics *out);
-static void rt_dispatch(struct mbuf *, const struct sockaddr *);
+static void rt_dispatch(struct mbuf *, const struct sockaddr *, int);
static struct netisr_handler rtsock_nh = {
@@ -155,17 +160,19 @@
{
struct sockproto route_proto;
- unsigned short *family;
+ struct rt_dispatch_ctx *ctx;
struct m_tag *tag;
+ int fibnum = -1;
route_proto.sp_family = PF_ROUTE;
- tag = m_tag_find(m, PACKET_TAG_RTSOCKFAM, NULL);
+ tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL);
if (tag != NULL) {
- family = (unsigned short *)(tag + 1);
- route_proto.sp_protocol = *family;
+ ctx = (struct rt_dispatch_ctx*)(tag + 1);
+ route_proto.sp_protocol = ctx->family;
+ fibnum = ctx->fibnum;
m_tag_delete(m, tag);
} else
route_proto.sp_protocol = 0;
- raw_input(m, &route_proto, &route_src);
+ raw_input(m, &route_proto, &route_src, fibnum);
}
@@ -784,8 +791,8 @@
unsigned short family = rp->rcb_proto.sp_family;
rp->rcb_proto.sp_family = 0;
- rt_dispatch(m, info.rti_info[RTAX_DST]);
+ rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum);
rp->rcb_proto.sp_family = family;
} else
- rt_dispatch(m, info.rti_info[RTAX_DST]);
+ rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum);
}
}
@@ -1010,5 +1017,5 @@
*/
void
-rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error)
+rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error, int fibnum)
{
struct rt_msghdr *rtm;
@@ -1025,5 +1032,5 @@
rtm->rtm_errno = error;
rtm->rtm_addrs = rtinfo->rti_addrs;
- rt_dispatch(m, sa);
+ rt_dispatch(m, sa, fibnum);
}
@@ -1050,5 +1057,5 @@
ifm->ifm_data = ifp->if_data;
ifm->ifm_addrs = 0;
- rt_dispatch(m, NULL);
+ rt_dispatch(m, NULL, -1);
}
@@ -1062,5 +1069,5 @@
*/
void
-rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt)
+rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt, int fibnum)
{
struct rt_addrinfo info;
@@ -1120,5 +1127,5 @@
rtm->rtm_addrs = info.rti_addrs;
}
- rt_dispatch(m, sa);
+ rt_dispatch(m, sa, fibnum);
}
}
@@ -1156,5 +1163,5 @@
ifmam->ifmam_index = ifp->if_index;
ifmam->ifmam_addrs = info.rti_addrs;
- rt_dispatch(m, ifma->ifma_addr);
+ rt_dispatch(m, ifma->ifma_addr, -1);
}
@@ -1216,5 +1223,5 @@
m->m_pkthdr.len += data_len;
mtod(m, struct if_announcemsghdr *)->ifan_msglen += data_len;
- rt_dispatch(m, NULL);
+ rt_dispatch(m, NULL, -1);
}
}
@@ -1232,10 +1239,11 @@
m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, &info);
if (m != NULL)
- rt_dispatch(m, NULL);
+ rt_dispatch(m, NULL, -1);
}
static void
-rt_dispatch(struct mbuf *m, const struct sockaddr *sa)
+rt_dispatch(struct mbuf *m, const struct sockaddr *sa, int fibnum)
{
+ struct rt_dispatch_ctx *ctx;
struct m_tag *tag;
@@ -1243,14 +1251,16 @@
* Preserve the family from the sockaddr, if any, in an m_tag for
* use when injecting the mbuf into the routing socket buffer from
- * the netisr.
+ * the netisr. Additionally save the fibnum if needed.
*/
- if (sa != NULL) {
- tag = m_tag_get(PACKET_TAG_RTSOCKFAM, sizeof(unsigned short),
- M_NOWAIT);
+ if (sa != NULL || fibnum >= 0) {
+ tag = m_tag_get(PACKET_TAG_RTSOCK,
+ sizeof(struct rt_dispatch_ctx*), M_NOWAIT);
if (tag == NULL) {
m_freem(m);
return;
}
- *(unsigned short *)(tag + 1) = sa->sa_family;
+ ctx = (struct rt_dispatch_ctx*)(tag + 1);
+ ctx->family = sa->sa_family;
+ ctx->fibnum = fibnum;
m_tag_prepend(m, tag);
}
--- ./sys/net/raw_usrreq.c.orig 2009-08-31 16:04:58.0 +
+++ ./sys/net/raw_usrreq.c 2009-08-31 18:34:38.0 +
@@ -70,5 +70,5 @@
*/
void
-raw_input(
Re: ath0: ath_rx_proc: no mbuf!
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_proc: no mbuf! > ath0: ath_rx_proc: no mbuf! > ath0: ath_rx_proc: no mbuf! For the record. It was a hardware problem. Cheers, Stef ___ 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"
Panic in imo_match_source (netinet/in_mcast.c)
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.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in_mcast.c#rev1.15 Anyone heard of this before, or knows of a commit/patch that might fix the problem? Cheers, Stef ___ 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"
Re: kmem_map too small panics with Soekris/Atheros access point
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 August 20th sources > and increased kern.ipc.nmbclusters to 65536 in hopes of getting the > panic less often. I managed to catch it in a state where there were a > bunch of "ath0: ath_rx_proc: no mbuf!" messages in the kernel buffer. > One line of "vmstat -m" stood out as the leak: > > 80211node 12677 101401K - 120901 16,512 > > "ifconfig ath0 down" freed the memory. Is there any other useful > information I can provide if I catch it again? Someone suggested the > output of "vmstat -z" off list, and I will have that next time. This might be a long shot: Back when I deployed some similar devices on FreeBSD 6.0 there was a leak when using oddball ath_rate driver. I believe it went away when I used ath_rate_sample. But according to 'man 4 ath' nothing else besides ath_rate_sample exists anymore. Cheers, Stef ___ 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"
Re: Panic in imo_match_source (netinet/in_mcast.c)
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 ___ 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"
Re: Panic in imo_match_source (netinet/in_mcast.c)
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 you using SSM multicast > features? Not that I know of. This is IPv4 OSPF which as far as I know sends simple multicast to 224.0.0.5. I'm using quagga 0.99.15 to run OSPF. Cheers, Stef ___ 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"
Re: Panic in imo_match_source (netinet/in_mcast.c)
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 > but I actually prefer that we go over the logic in inp_join_group() > again before proposing a patch for head as this is the second assert > panic I am seeing it causes in the last few days. I can try making up > a proper fix if Bruce is busy, but it will take a day or two until I'm > able to fully test it. H, EADDRINUSE ... This sounds very familiar. Here's an old quagga bug that I don't think got patched properly. It does an unexpected double IP_ADD_MEMBERSHIP: http://bugzilla.quagga.net/show_bug.cgi?id=212 I'll test the patch here. Thanks! Cheers, Stef ___ 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"
Re: Panic in imo_match_source (netinet/in_mcast.c)
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 want to try demoting the KASSERT to a conditional error > return (return no match if src is NULL or src->sa_family != AF_INET), > and see if that fix 'just works' for you. Sometimes the asserts I > sprinkle into code are too paranoid for what's going on, and syrinx@ > recently caught one of those. Yes, I patched that out and have been testing. However in this case OSPF (quagga) stops running. Maybe quagga is doing something unexpected. I've been slowly trying to corner this issue. Cheers, Stef ___ 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"
[patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address
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 multicast group from the 'first' interface instead. You can see
the results below in the ifmcstat output below.
Before northstar1 (tunnel) interface goes away, both bge0 and northstar1
are on the 224.0.0.5 (ie: OSPF-ALL.MCAST.NET) group.
> bge0:
> inet 172.27.5.18
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.5 mode exclude
> mcast-macaddr 01:00:5e:00:00:05
> group 224.0.0.1 mode exclude
> mcast-macaddr 01:00:5e:00:00:01
> rl0:
> inet 192.168.1.70
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.1 mode exclude
> mcast-macaddr 01:00:5e:00:00:01
> lo0:
> inet 127.0.0.1
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.1 mode exclude
> inet6 fe80::1%lo0
> mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3
> group ff01::1%lo0 mode exclude
> group ff02::2:e78c:f513%lo0 mode exclude
> group ff02::1%lo0 mode exclude
> group ff02::1:ff00:1%lo0 mode exclude
> northstar1:
> inet 172.28.1.66
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.5 mode exclude
> group 224.0.0.1 mode exclude
After northstar1 goes down, and setsockopt(..., IP_DROP_MEMBERSHIP, ...)
is called for the 172.28.1.66 address, we see that the group has been
dropped from bge0 instead. No error was returned from setsockopt.
> bge0:
> inet 172.27.5.18
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.1 mode exclude
> mcast-macaddr 01:00:5e:00:00:01
> rl0:
> inet 192.168.1.70
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.1 mode exclude
> mcast-macaddr 01:00:5e:00:00:01
> lo0:
> inet 127.0.0.1
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.1 mode exclude
> inet6 fe80::1%lo0
> mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3
> group ff01::1%lo0 mode exclude
> group ff02::2:e78c:f513%lo0 mode exclude
> group ff02::1%lo0 mode exclude
> group ff02::1:ff00:1%lo0 mode exclude
> northstar1:
UNAME: FreeBSD portillo-gate.ws.local 8.0-BETA3 FreeBSD 8.0-BETA3 #19:
Wed Sep 9 01:27:39 UTC 2009
r...@portillo-gate.ws.local:/usr/src/sys/i386/compile/PORTILLO i386
Patch is attached which fixes the problem. Is this the right approach?
BTW, the behavior of FreeBSD has always been that after northstar1 comes
back up with the same address, it is a member of 224.0.0.5 group.
Memberships are retained across interfaces and addresses going away. Not
sure if this is the best behavior, but it has been the historical
behavior. One can see people coding against this in routing software [2].
Besides fixing the problem of dropping membership on the first
interface, the effect of this patch is to restore the previous freebsd
behavior.
Cheers,
Stef
PS: BTW, I've been using the patch [1] for the imo_match_source panic,
that Shteryana posted. That fixes problems calling IP_ADD_MEMBERSHIP
twice with the same info.
[1] http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff
[2]
http://code.quagga.net/cgi-bin/gitweb.cgi?p=quagga.git;a=blob;f=lib/sockopt.c;h=55c6226b711e6386ef0378eb6def992af281082e;hb=HEAD#l196
--- sys/netinet/in_mcast.c.orig 2009-08-03 08:13:06.0 +
+++ sys/netinet/in_mcast.c 2009-09-09 01:35:06.0 +
@@ -2139,6 +2143,9 @@
}
- if (!in_nullhost(gsa->sin.sin_addr))
+ if (!in_nullhost(gsa->sin.sin_addr)) {
INADDR_TO_IFP(mreqs.imr_interface, ifp);
+ if (ifp == NULL)
+return (EADDRNOTAVAIL);
+ }
CTR3(KTR_IGMPV3, "%s: imr_interface = %s, ifp = %p",
___
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"
[patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP
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 the new IGMPv3 features.
This results in the following behavior shown by ifmcstat. Before the
drop + add you can see the following groups for the northstar1
interface. Note that 224.0.0.5 (ie: OSPF-ALL.MCAST.NET) is subscribed
with an empty exclude filter as you would expect from simple ASM mode:
> # ifmcstat -i northstar1
> northstar1:
> inet 172.28.1.66
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.5 mode exclude
> group 224.0.0.1 mode exclude
After the drop + add, it looks like the following. Note that now
224.0.0.5 is subscribed with an empty *include* filter which results in
no packets received.
> # ifmcstat -i northstar1
> northstar1:
> inet 172.28.1.66
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.1 mode exclude
> group 224.0.0.5 mode include
uname: FreeBSD portillo-gate.ws.local 8.0-BETA3 FreeBSD 8.0-BETA3 #24:
Wed Sep 9 15:01:39 UTC 2009
r...@portillo-gate.ws.local:/usr/src/sys/i386/compile/PORTILLO i386
Patch is attached which fixes the problem. Is this the right approach?
If not, I hope it helps highlight the problem area.
Cheers,
Stef
--- sys/netinet/in_mcast.c.orig 2009-08-03 08:13:06.0 +
+++ sys/netinet/in_mcast.c 2009-09-09 15:01:24.0 +
@@ -2024,6 +2050,9 @@
error = ENOMEM;
goto out_imo_free;
}
+ } else if (is_new) {
+ /* Old style ASM filter mode is always exclude */
+ imf_init(imf, MCAST_UNDEFINED, MCAST_EXCLUDE);
}
/*
___
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"
Re: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP
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 these various (posted) multicast patches OSPF (with quagga) is now far more stable on 8.0-BETA4. However I'm still seeing intermittent problems. I need help in knowing how to debug the following. Once it's figured out, I'd like to make a patch. Specifically: Quagga has a sockets open on em0, portillo1, and northstar1 below on the 224.0.0.5 group. ifmcstat output: > em0: > inet 172.27.2.1 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > mcast-macaddr 01:00:5e:00:00:05 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > em1: > inet 189.162.25.187 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > lo0: > inet 127.0.0.1 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > inet6 fe80::1%lo0 > mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3 > group ff01::1%lo0 mode exclude > group ff02::2:10c2:bd48%lo0 mode exclude > group ff02::1%lo0 mode exclude > group ff02::1:ff00:1%lo0 mode exclude > leaseweb0: > inet 10.94.75.3 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > portillo1: > inet 172.28.1.65 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > group 224.0.0.1 mode exclude > eaglecrest1: > inet 172.28.1.70 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > group 224.0.0.1 mode exclude After a while and a few interface ups and downs, quagga stops getting OSPF packets on one of the interfaces. I can verify with tcpdump that these packets are seen by the machine. For example, on em0: > # tcpdump -pnti em0 proto ospf > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 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. Where and how could I see what's preventing these packets from being delivered to the ospfd process socket? Which code is involved in the dispatch? Thanks for your help and time. Much appreciated. Cheers, Stef ___ 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"
Re: Multicast SSM bug?
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 not delivered, I can see this counter being
incremented:
> # netstat -s -p ip | grep multicast
> 885 packets received for unknown multicast group
That counter originates from this block of code in raw_ip.c:
> 354 blocked = imo_multi_filter(inp->inp_moptions, ifp,
> 355 (struct sockaddr *)&group,
> 356 (struct sockaddr *)&ripsrc);
> 357 if (blocked != MCAST_PASS) {
> 358 IPSTAT_INC(ips_notmember);
> 359 continue;
> 360 }
After instrumenting it with this printf:
> printf("not member: group = %s, ", inet_ntoa (group.sin_addr));
> printf("src = %s, why = %d\n", inet_ntoa (ripsrc.sin_addr), (int)blocked);
Then wait, then up down some interfaces, etc quagga adds/drops
memberships, eventually I see the following output:
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
The why = 2 is MCAST_NOTSMEMBER. 172.28.1.66 is the tunnel peer sending
OSPF multicast packets. Somehow imo_multi_filter is limiting via packet
source for this membership. However, this is what the interface looks
like via ifmcstat (ie: no SSM memberships):
> portillo1:
> inet 172.28.1.65
> igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> group 224.0.0.5 mode exclude
> group 224.0.0.1 mode exclude
Any of the above ring a bell? If not, I'll keep poking around and see
what I find.
Cheers,
Stef
___
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"
[patch] Multicast: Keep membership and filters in sync
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 experienced with OSPF
(running quagga).
Besides the obvious non-functional multicast, the following command is
another way to see an indication of the problem:
> # netstat -s -p ip | grep multicast
> 7 packets received for unknown multicast group
Patch attached which fixes the problem.
Cheers,
Stef
--- sys/netinet/in_mcast.c.orig 2009-09-09 19:33:22.0 +
+++ sys/netinet/in_mcast.c 2009-09-10 05:28:20.0 +
@@ -2280,7 +2292,9 @@
if (is_final) {
- /* Remove the gap in the membership array. */
- for (++idx; idx < imo->imo_num_memberships; ++idx)
+ /* Remove the gap in the membership and filter array. */
+ for (++idx; idx < imo->imo_num_memberships; ++idx) {
imo->imo_membership[idx-1] = imo->imo_membership[idx];
+ imo->imo_mfilters[idx-1] = imo->imo_mfilters[idx];
+ }
imo->imo_num_memberships--;
}
___
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"
Re: forwarding when two rip defaults
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, ie: 8.0) it'll choose one at random. Unless one route has a better metric. Cheers, Stef ___ 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"
Re: low ath speed on 8.0-RC1
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 mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/134931: [route] [fib] Route messages sent to all socket listeners regardless of setfib
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 2009 11:42:02 -0500
This is a multi-part message in MIME format.
--010409020702060203010308
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
I'm having a bit of a hard time building FreeBSD current (LOR
diagnostics spew out on the console while building).
But here are the patches I've deployed into production, on a whole bunch
of network routers. They've behaved solidly, and have been running for a
couple weeks.
I've used one patch with 7.2-RELEASE-p3 (and should work against 7
stable), the other I've used with 8.0-BETA4 (and should work against
8.0-RC1 as well).
Cheers,
Stef
--010409020702060203010308
Content-Type: text/x-diff;
name="freebsd-80-route-messages-respect-fib-2.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="freebsd-80-route-messages-respect-fib-2.patch"
--- ./sys/net/rtsock.c.orig2009-08-31 15:26:03.0 +
+++ ./sys/net/rtsock.c 2009-08-31 19:06:53.0 +
@@ -93,4 +93,9 @@
SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, "");
+struct rt_dispatch_ctx {
+ unsigned short family; /* Socket family */
+ intfibnum; /* FIB for message or -1 for all */
+};
+
struct walkarg {
int w_tmemsize;
@@ -114,5 +119,5 @@
static void rt_getmetrics(const struct rt_metrics_lite *in,
struct rt_metrics *out);
-static void rt_dispatch(struct mbuf *, const struct sockaddr *);
+static void rt_dispatch(struct mbuf *, const struct sockaddr *, int);
static struct netisr_handler rtsock_nh = {
@@ -155,17 +160,19 @@
{
struct sockproto route_proto;
- unsigned short *family;
+ struct rt_dispatch_ctx *ctx;
struct m_tag *tag;
+ int fibnum = -1;
route_proto.sp_family = PF_ROUTE;
- tag = m_tag_find(m, PACKET_TAG_RTSOCKFAM, NULL);
+ tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL);
if (tag != NULL) {
- family = (unsigned short *)(tag + 1);
- route_proto.sp_protocol = *family;
+ ctx = (struct rt_dispatch_ctx*)(tag + 1);
+ route_proto.sp_protocol = ctx->family;
+ fibnum = ctx->fibnum;
m_tag_delete(m, tag);
} else
route_proto.sp_protocol = 0;
- raw_input(m, &route_proto, &route_src);
+ raw_input(m, &route_proto, &route_src, fibnum);
}
@@ -784,8 +791,8 @@
unsigned short family = rp->rcb_proto.sp_family;
rp->rcb_proto.sp_family = 0;
- rt_dispatch(m, info.rti_info[RTAX_DST]);
+ rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum);
rp->rcb_proto.sp_family = family;
} else
- rt_dispatch(m, info.rti_info[RTAX_DST]);
+ rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum);
}
}
@@ -1010,5 +1017,5 @@
*/
void
-rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error)
+rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error, int
fibnum)
{
struct rt_msghdr *rtm;
@@ -1025,5 +1032,5 @@
rtm->rtm_errno = error;
rtm->rtm_addrs = rtinfo->rti_addrs;
- rt_dispatch(m, sa);
+ rt_dispatch(m, sa, fibnum);
}
@@ -1050,5 +1057,5 @@
ifm->ifm_data = ifp->if_data;
ifm->ifm_addrs = 0;
- rt_dispatch(m, NULL);
+ rt_dispatch(m, NULL, -1);
}
@@ -1062,5 +1069,5 @@
*/
void
-rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt)
+rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt, int
fibnum)
{
struct rt_addrinfo info;
@@ -1120,5 +1127,5 @@
rtm->rtm_addrs = info.rti_addrs;
}
- rt_dispatch(m, sa);
+ rt_dispatch(m, sa, fibnum);
}
}
@@ -1156,5 +1163,5 @@
ifmam->ifmam_index = ifp->if_index;
ifmam->ifmam_addrs = info.rti_addrs;
- rt_dispatch(m, ifma->ifma_addr);
+ rt_dispatch(m, ifma->ifma_addr, -1);
}
@@ -1216,5 +1223,5 @@
m->m_pkthdr.len += data_len;
mtod(m, struct if_announcemsghdr *)->ifan_msglen += data_len;
- rt_dispatch(m, NULL);
+ rt_dispatch(m, NULL, -1);
}
}
@@ -1232,10 +1239,11 @@
m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, &info);
if (m
Re: low ath speed on 8.0-RC1
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 >> and that probably resets the tx rate to 24M. > > Does it possible to disable tx rate control and lock wlan0 on > OFDM/54Mbps? Think it isn't right tha I have only 900K of transfer speed > without using of bssid command. Off the top of my head: ifconfig ath0 media OFDM/54Mbps Cheers, Stef ___ 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"
Re: kern/137164: [netinet] [patch] assert panic imo_match_source()
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 is a multi-part message in MIME format. --090401010308070005060707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for working on getting all these multicast fixes in. Much appreciated! Just one more thing, previous to 7.x FreeBSD would return EADDRINUSE in the case of a double IP_ADD_MEMBERSHIP. Software like quagga uses this error code to detect this condition. As patched (and MFC'd in 7.x and 8.x) EINVAL is returned instead and this confuses such software. Currently the multicast code does not remove memberships from its internal structures when an interface goes down. It's hard for userland to reliably track the condition of a multicast membership that didn't go away due to an interface going down. So software like quagga uses EADDRINUSE to track the condition. Obviously, as you Bruce mentioned, an better solution needs to be found eventually WRT to 'dynamic' interfaces and the multicast code. But for now would the attached patch be acceptable? It would prevent regressions from FreeBSD 6.x. Thanks for considering, Stef --090401010308070005060707 Content-Type: text/x-diff; name="freebsd-mcast-eaddrinuse.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-mcast-eaddrinuse.patch" --- sys/netinet/in_mcast.c.orig2009-09-30 16:43:35.0 + +++ sys/netinet/in_mcast.c 2009-09-30 17:04:59.0 + @@ -2010,5 +2010,5 @@ * is atomic with allocation of a membership. */ - error = EINVAL; + error = EADDRINUSE; goto out_inp_locked; } --090401010308070005060707-- ___ 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"
Unbreak setfib + routing daemon [patch roundup]
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 routing messages only
receive those that affect their FIB. Some routing messages (such as
interface address announcements etc..) are still sent to all listeners.
Patches attached for CURRENT, latest 8.0, and 7.2.
Previous discussion:
http://www.mail-archive.com/freebsd-net@freebsd.org/msg30815.html
PR:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931
Cheers,
Stef
--- ./sys/net/rtsock.c.orig 2009-08-31 15:26:03.0 +
+++ ./sys/net/rtsock.c 2009-08-31 19:06:53.0 +
@@ -93,4 +93,9 @@
SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, "");
+struct rt_dispatch_ctx {
+ unsigned short family; /* Socket family */
+ intfibnum; /* FIB for message or -1 for all */
+};
+
struct walkarg {
int w_tmemsize;
@@ -114,5 +119,5 @@
static void rt_getmetrics(const struct rt_metrics_lite *in,
struct rt_metrics *out);
-static void rt_dispatch(struct mbuf *, const struct sockaddr *);
+static void rt_dispatch(struct mbuf *, const struct sockaddr *, int);
static struct netisr_handler rtsock_nh = {
@@ -155,17 +160,19 @@
{
struct sockproto route_proto;
- unsigned short *family;
+ struct rt_dispatch_ctx *ctx;
struct m_tag *tag;
+ int fibnum = -1;
route_proto.sp_family = PF_ROUTE;
- tag = m_tag_find(m, PACKET_TAG_RTSOCKFAM, NULL);
+ tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL);
if (tag != NULL) {
- family = (unsigned short *)(tag + 1);
- route_proto.sp_protocol = *family;
+ ctx = (struct rt_dispatch_ctx*)(tag + 1);
+ route_proto.sp_protocol = ctx->family;
+ fibnum = ctx->fibnum;
m_tag_delete(m, tag);
} else
route_proto.sp_protocol = 0;
- raw_input(m, &route_proto, &route_src);
+ raw_input(m, &route_proto, &route_src, fibnum);
}
@@ -784,8 +791,8 @@
unsigned short family = rp->rcb_proto.sp_family;
rp->rcb_proto.sp_family = 0;
- rt_dispatch(m, info.rti_info[RTAX_DST]);
+ rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum);
rp->rcb_proto.sp_family = family;
} else
- rt_dispatch(m, info.rti_info[RTAX_DST]);
+ rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum);
}
}
@@ -1010,5 +1017,5 @@
*/
void
-rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error)
+rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error, int fibnum)
{
struct rt_msghdr *rtm;
@@ -1025,5 +1032,5 @@
rtm->rtm_errno = error;
rtm->rtm_addrs = rtinfo->rti_addrs;
- rt_dispatch(m, sa);
+ rt_dispatch(m, sa, fibnum);
}
@@ -1050,5 +1057,5 @@
ifm->ifm_data = ifp->if_data;
ifm->ifm_addrs = 0;
- rt_dispatch(m, NULL);
+ rt_dispatch(m, NULL, -1);
}
@@ -1062,5 +1069,5 @@
*/
void
-rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt)
+rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt, int fibnum)
{
struct rt_addrinfo info;
@@ -1120,5 +1127,5 @@
rtm->rtm_addrs = info.rti_addrs;
}
- rt_dispatch(m, sa);
+ rt_dispatch(m, sa, fibnum);
}
}
@@ -1156,5 +1163,5 @@
ifmam->ifmam_index = ifp->if_index;
ifmam->ifmam_addrs = info.rti_addrs;
- rt_dispatch(m, ifma->ifma_addr);
+ rt_dispatch(m, ifma->ifma_addr, -1);
}
@@ -1216,5 +1223,5 @@
m->m_pkthdr.len += data_len;
mtod(m, struct if_announcemsghdr *)->ifan_msglen += data_len;
- rt_dispatch(m, NULL);
+ rt_dispatch(m, NULL, -1);
}
}
@@ -1232,10 +1239,11 @@
m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, &info);
if (m != NULL)
- rt_dispatch(m, NULL);
+ rt_dispatch(m, NULL, -1);
}
static void
-rt_dispatch(struct mbuf *m, const struct sockaddr *sa)
+rt_dispatch(struct mbuf *m, const struct sockaddr *sa, int fibnum)
{
+ struct rt_dispatch_ctx *ctx;
struct m_tag *tag;
@@ -1243,14 +1251,16 @@
* Preserve the family from the sockaddr, if any, in an m_tag for
* use when injecting the mbuf into the routing socket buffer from
- * the netisr.
+ * the netisr. Additionally save the fibnum if needed.
*/
- if (sa != NULL) {
- tag = m_tag_get(PACKET_TAG_RTSOCKFAM, sizeof(unsigned short),
- M_NOWAIT);
+ if (sa != NULL || fibnum >= 0) {
+ tag = m_tag_get(PACKET_TAG_RTSOCK,
+ sizeof(struct rt_dispatch_ctx*), M_NOWAIT);
if (tag == NULL) {
m_freem(m);
return;
}
- *(unsigned short *)(tag + 1) = sa->sa_family;
+ ctx = (struct rt_dispatch_ctx*)(tag + 1);
+ ctx->family = sa->sa_family;
+ ctx->fibnum = fibnum;
m_tag_prepend(m, tag);
}
--- ./sys/net/raw_usrreq.c.orig 2009-08-31 16:04:58.0 +
+++ ./sys/net/raw_usrreq.c 2009-08-31 18:34:38.0 +
@@ -70,5 +70,5 @@
*/
void
-raw_input(struct mbuf *m0, struct sockproto *proto, struct sockad
Re: bsnmp module for monitoring network flows: bsnmp-pcap
Harti Brandt wrote: > I probably missed something here. Any other conflicts? Can we move bsnmp-pcap > to 207? And does bsnmp-jails conflict with something? Like Shteryana said, it seems like it does conflict... Would it work to have and 1112? I used those while the software 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 ___ 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"
32 bit compatibility for getifaddrs()
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 compatibility to the rtsock.c route
messages.
Who would I work with to get this (or something like it) committed?
Cheers,
Stef
--- sys/net/rtsock.c.orig 2009-06-13 19:51:29.0 +
+++ sys/net/rtsock.c 2009-06-13 20:44:35.0 +
@@ -1199,6 +1199,251 @@
netisr_queue(NETISR_ROUTE, m); /* mbuf is free'd on failure. */
}
+#ifdef SCTL_MASK32
+
+/* 32-bit structure definitions */
+struct timeval32 {
+ int32_t tv_sec;
+ int32_t tv_usec;
+};
+
+struct if_data32 {
+ u_int8_t ifi_type;
+ u_int8_t ifi_physical;
+ u_int8_t ifi_addrlen;
+ u_int8_t ifi_hdrlen;
+ u_int8_t ifi_link_state;
+ u_int8_t ifi_recvquota;
+ u_int8_t ifi_xmitquota;
+ u_int8_t ifi_datalen;
+ u_int32_t ifi_mtu;
+ u_int32_t ifi_metric;
+ u_int32_t ifi_baudrate;
+ u_int32_t ifi_ipackets;
+ u_int32_t ifi_ierrors;
+ u_int32_t ifi_opackets;
+ u_int32_t ifi_oerrors;
+ u_int32_t ifi_collisions;
+ u_int32_t ifi_ibytes;
+ u_int32_t ifi_obytes;
+ u_int32_t ifi_imcasts;
+ u_int32_t ifi_omcasts;
+ u_int32_t ifi_iqdrops;
+ u_int32_t ifi_noproto;
+ u_int32_t ifi_hwassist;
+ int32_tifi_epoch;
+ struct timeval32 ifi_lastchange;
+};
+
+struct rt_metrics32 {
+ u_int32_t rmx_locks;
+ u_int32_t rmx_mtu;
+ u_int32_t rmx_hopcount;
+ u_int32_t rmx_expire;
+ u_int32_t rmx_recvpipe;
+ u_int32_t rmx_sendpipe;
+ u_int32_t rmx_ssthresh;
+ u_int32_t rmx_rtt;
+ u_int32_t rmx_rttvar;
+ u_int32_t rmx_pksent;
+ u_int32_t rmx_filler[4];
+};
+
+struct rt_msghdr32 {
+ u_int16_t rtm_msglen;
+ u_int8_t rtm_version;
+ u_int8_t rtm_type;
+ u_int16_t rtm_index;
+ int32_t rtm_flags;
+ int32_t rtm_addrs;
+ int32_t rtm_pid;
+ int32_t rtm_seq;
+ int32_t rtm_errno;
+ int32_t rtm_fmask;
+ u_int32_t rtm_inits;
+ struct rt_metrics32 rtm_rmx;
+};
+
+struct if_msghdr32 {
+ u_int16_t ifm_msglen;
+ u_int8_t ifm_version;
+ u_int8_t ifm_type;
+ int32_t ifm_addrs;
+ int32_t ifm_flags;
+ u_int16_t ifm_index;
+ struct if_data32 ifm_data;
+};
+
+struct ifa_msghdr32 {
+ u_int16_t ifam_msglen;
+ u_int8_t ifam_version;
+ u_int8_t ifam_type;
+ int32_t ifam_addrs;
+ int32_t ifam_flags;
+ u_int16_t ifam_index;
+ int32_t ifam_metric;
+};
+
+struct ifma_msghdr32 {
+ u_int16_t ifmam_msglen;
+ u_int8_t ifmam_version;
+ u_int8_t ifmam_type;
+ int32_t ifmam_addrs;
+ int32_t ifmam_flags;
+ u_int16_t ifmam_index;
+};
+
+struct if_announcemsghdr32 {
+ u_int16_t ifan_msglen;
+ u_int8_t ifan_version;
+ u_int8_t ifan_type;
+ u_int16_t ifan_index;
+ char ifan_name[IFNAMSIZ];
+ u_int16_t ifan_what;
+};
+
+#endif
+
+/*
+ * Output route message to sysctl for 64 or 32-bit
+ */
+static int
+rt_sysctl_out(struct sysctl_req *req, const void *data, size_t len)
+{
+ const struct rt_msghdr *rtm = data;
+ int error;
+
+#ifdef SCTL_MASK32
+ if (req->flags & SCTL_MASK32) {
+ switch (rtm->rtm_type) {
+ case RTM_IFINFO:
+ {
+ const struct if_msghdr *ifm = data;
+ struct if_msghdr32 ifm32;
+ data = ((const u_char*)data) + sizeof (*ifm);
+ len -= sizeof (*ifm);
+ ifm32.ifm_msglen = sizeof (ifm32) + len;
+ ifm32.ifm_version = ifm->ifm_version;
+ ifm32.ifm_type = ifm->ifm_type;
+ ifm32.ifm_addrs = ifm->ifm_addrs;
+ ifm32.ifm_flags = ifm->ifm_flags;
+ ifm32.ifm_index = ifm->ifm_index;
+ ifm32.ifm_data.ifi_type = ifm->ifm_data.ifi_type;
+ ifm32.ifm_data.ifi_physical = ifm->ifm_data.ifi_physical;
+ ifm32.ifm_data.ifi_addrlen = ifm->ifm_data.ifi_addrlen;
+ ifm32.ifm_data.ifi_hdrlen = ifm->ifm_data.ifi_hdrlen;
+ ifm32.ifm_data.ifi_link_state = ifm->ifm_data.ifi_link_state;
+ ifm32.ifm_data.ifi_recvquota = 0;
+ ifm32.ifm_data.ifi_xmitquota = 0;
+ ifm32.ifm_data.ifi_datalen = ifm->ifm_data.ifi_datalen;
+ ifm32.ifm_data.ifi_mtu = ifm->ifm_data.ifi_mtu;
+ ifm32.ifm_data.ifi_metric = ifm->ifm_data.ifi_metric;
+ ifm32.ifm_data.ifi_baudrate = ifm->ifm_data.ifi_baudrate;
+ ifm32.ifm_data.ifi_ipackets = ifm->ifm_data.ifi_ipackets;
+ ifm32.ifm_data.ifi_ierrors = ifm->ifm_data.ifi_ierrors;
+ ifm32.ifm_data.ifi_opackets = ifm->ifm_data.ifi_opackets;
+ ifm32.ifm_data.ifi_oerrors = ifm->ifm_data.ifi_oerrors;
+ ifm32.ifm_data.ifi_collisions = ifm->ifm_data.ifi_collisions;
+ ifm32.ifm_data.ifi_ibytes = ifm->ifm_data.ifi_ibytes;
+ ifm32.ifm_data.ifi_obytes = ifm->ifm_data.ifi_obytes;
+ ifm32.ifm_data.ifi_imcasts = ifm->ifm_data.ifi_imcasts;
+ ifm32.ifm_data.ifi_omcasts = ifm->ifm_data.ifi_omcasts;
+ ifm32.ifm_data.ifi_iqdrops = ifm->ifm_data.ifi_iqdrops;
+ ifm32.ifm_data.ifi_noproto = ifm->ifm_data.ifi_noproto;
+ ifm32.ifm_data.ifi_hwassist = ifm->ifm_data.ifi_hwassist;
+
ath0: ath_rx_proc: no mbuf!
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: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! ath0: ath_rx_proc: no mbuf! Has anyone seen this problem? An mbuf leak? Or perhaps fixed something like it in a later version of FreeBSD? Would upgrading the FreeBSD version fix this? It's in a really remote location, high on a tower, and tough to upgrade :( netstat -m shows: # netstat -m 104/19096/19200 mbufs in use (current/cache/total) 101/2971/3072/3072 mbuf clusters in use (current/cache/total/max) 0/3/1024 sfbufs in use (current/peak/max) 228K/10716K/10944K bytes allocated to network (current/cache/total) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines The mbufs are in fact all used up. I allocate more via kern.ipc.nmbclusters, and see the same behavior. 6.0-RELEASE-p5 FreeBSD 6.0-RELEASE-p5 #6: Thu May 18 18:02:20 UTC 2006 Thanks in advance, Stef ___ 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"
Re: ath0: ath_rx_proc: no mbuf!
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 traffic is reauuly huge, system > with ath need a lot of mbufs. At night, when traffic is almost zero, > netstat -m shows a lot of free mbufs and clusters, so it seems, that > there is no mbuf leaks. Thanks for responding. I'll try tweaking some more. Sadly this is an 'embedded' style box that has 64 MB of RAM. According to tuning(7) Having 65536 mbuf clusters would use up 128 MB of RAM :( Cheers, Stef ___ 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"
atmel drivers
Hello there, First of all, apologies if this is the wrong mailing list (did think that maybe mobile or perhaps hardware was the 'right' one). If this is horribly out of the mailing list topic let me know. Anyway, guess the topic really says it all. I can find linux atmel drivers (http://atmelwlandriver.sourceforge.net/) so, is it not possible to take a snapshot from there and perhaps code up even alpha drivers ? There are more and more 'legacy' or old 11mbp's wireless 802.11b cards that are using this and even new versions of some prism based cards are 'becoming' atmel cards (the one i have that causes me the most 'irk' is the SMC 2632W v2. v1 was prism2, v2 is atmel. way to go SMC) and also 3com's (as someone on irc pointed out). It really would be great to buy another card and ditch this 'atmel' card, however, my poor funds dont normally allow that, and others are probably in the same boat. help me get away from 'lesser os's :) regards Stef Telford <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
