Re: reading routing table
> Why don't you just use XORP's FEA code? > It already does all this under a BSD-type license. Nice stuff. However, it looks like a full blown routing platform. In that case it would be easier to re-write those portions using the relevant set of APIs. Happy hacking, Debarshi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: docs/120945: [PATCH] ip6(4) man page lacks documentation for TCLASS option.
Synopsis: [PATCH] ip6(4) man page lacks documentation for TCLASS option. Responsible-Changed-From-To: bms->net Responsible-Changed-By: bms Responsible-Changed-When: Mon 1 Sep 2008 13:37:24 UTC Responsible-Changed-Why: Someone else best grab this until I learn how to MFC in Subversion. http://www.freebsd.org/cgi/query-pr.cgi?pr=120945 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reading routing table
Debarshi Ray wrote: Why don't you just use XORP's FEA code? It already does all this under a BSD-type license. I was not aware of it. What does it do? Is it portable across other OSes or is it *BSD specific? XORP's FEA process is responsible for talking to the underlying forwarding plane. It supports *BSD, Linux, MacOS X, and Microsoft Windows. Over the last year there was a refactoring where the forwarding table management got split into plugin-like modules. It is written in C++ although it's likely this split might make integration into other projects easier. Normally that support all goes into a single process, rather than being linked into many. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reading routing table
> Why don't you just use XORP's FEA code? > It already does all this under a BSD-type license. I was not aware of it. What does it do? Is it portable across other OSes or is it *BSD specific? Thanks, Debarshi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reading routing table
> You want 'netstat -rn' to dump them, this is a very common command which > should be present in a number of online resources on using and administering > FreeBSD so I am somewhat surprised that you didn't find it. I know about netstat. I did mention having gone through its implementation. :-) What I am asking about is related to the implementation of the 'netstat -rn' functionality, which on some non-FreeBSD systems is also provided by 'route [show] -n'. > P.S. Look in the sysctl tree if you need to snapshot the kernel IP > forwarding tables. You can use kmem, but it is generally frowned upon unless > you're working from core dumps -- kernels can be built without kmem support, > or kmem locked down, etc. Ok, I will have a look. Thanks. Happy hacking, Debarshi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reading routing table
Debarshi Ray wrote: ... I was going through the FreeBSD and NetBSD documentation and the FreeBSD sources of netstat and route. I was suprised to see that while NetBSD's route implementation has a 'show' command, FreeBSD does not offer any such thing. Moreover it seems that one can not read the entire routing table using the PF_ROUTE sockets and RTM_GET returns information pertaining to only one destination. This suprised me because one can do such a thing with the Linux kernel's RTNETLINK. Is there a reason why this is so? Or is reading from /dev/kmem the only way to get a dump of the routing tables? You want 'netstat -rn' to dump them, this is a very common command which should be present in a number of online resources on using and administering FreeBSD so I am somewhat surprised that you didn't find it. P.S. Look in the sysctl tree if you need to snapshot the kernel IP forwarding tables. You can use kmem, but it is generally frowned upon unless you're working from core dumps -- kernels can be built without kmem support, or kmem locked down, etc. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: reading routing table
Debarshi Ray wrote: I am implementing a library/utility which basically encompasses the features of the traditional route utilities and those of newer tools (like ip from iproute2), which are mostly specific to a particular kernel. The overpowering objective is to make the library/utility work uniformly across all different kernels, so that programs like NetworkManager have a portable library/utility to use instead of the Linux-kernel specific ip which is now being used. Why don't you just use XORP's FEA code? It already does all this under a BSD-type license. cheers BMS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
reading routing table
I am implementing a library/utility which basically encompasses the features of the traditional route utilities and those of newer tools (like ip from iproute2), which are mostly specific to a particular kernel. The overpowering objective is to make the library/utility work uniformly across all different kernels, so that programs like NetworkManager have a portable library/utility to use instead of the Linux-kernel specific ip which is now being used. I was going through the FreeBSD and NetBSD documentation and the FreeBSD sources of netstat and route. I was suprised to see that while NetBSD's route implementation has a 'show' command, FreeBSD does not offer any such thing. Moreover it seems that one can not read the entire routing table using the PF_ROUTE sockets and RTM_GET returns information pertaining to only one destination. This suprised me because one can do such a thing with the Linux kernel's RTNETLINK. Is there a reason why this is so? Or is reading from /dev/kmem the only way to get a dump of the routing tables? Thanks, Debarshi ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: bug in unix sockets garbage collector
On Fri, 22 Aug 2008, Anton Yuzhaninov wrote: On servers where used unix sockets, sometimes thread taskq start to eat 100% CPU: http://docs.FreeBSD.org/cgi/mid.cgi?474EFC5C.9060508 Addition info about this problem - when this occurs sysctl net.local.inflight show negative number. % sysctl net.local.inflight net.local.inflight: -3 And this condition become always true: if (local_unp_rights) taskqueue_enqueue(taskqueue_thread, &unp_gc_task); It seems, that unp_rights decremented more often than incremented, or some race exist. Hi Anton: On reviewing this code, I've identified at least one race condition that could lead to the behavior that you've spotted. It will probably take me a couple of days to produce a patch for you to try. However, could I ask you to file a PR for this problem, with the above and any related diagnostics, and when you receive the e-mail PR receipt, could you forward it to me so that I can take ownership of it? Thanks, Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/126984: [carp][patch] add carp userland notifications via devctl(4)
Synopsis: [carp][patch] add carp userland notifications via devctl(4) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Mon Sep 1 11:42:22 UTC 2008 Responsible-Changed-Why: Carp is something networking related, bring it over. http://www.freebsd.org/cgi/query-pr.cgi?pr=126984 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW_TABLES_MAX in src/sbin/ipfw/ipfw2.c
Andrey V. Elsukov wrote:
Ganbold wrote:
Hi,
Sorry for sending this third time (2 to freebsd-ipfw, 1 to freebsd-net).
I'm trying to make small changes in ipfw2.c code (RELENG_7), but make
fails with following error:
v02# make
cc -O2 -fno-strict-aliasing -pipe -Wno-pointer-sign -c
/usr/src/sbin/ipfw/ipfw2.c
/usr/src/sbin/ipfw/ipfw2.c: In function 'table_handler':
/usr/src/sbin/ipfw/ipfw2.c:5941: error: 'IPFW_TABLES_MAX' undeclared
(first use in this function)
/usr/src/sbin/ipfw/ipfw2.c:5941: error: (Each undeclared identifier is
reported only once
/usr/src/sbin/ipfw/ipfw2.c:5941: error: for each function it appears
in.)
*** Error code 1
IPFW_TABLES_MAX seems like defined in netinet/ip_fw.h, which is included
in ipfw2.c:
IPFW_TABLES_MAX protected by _KERNEL macro. This is why you get
an error.
Yeah, my fault, I was looking around IPFW_INTERNAL and missed _KERNEL macro.
I defined new sysctl variable in netinet/ip_fw2.c and now I'm able to
get IPFW_TABLES_MAX via sysctl from /sbin/ipfw.
Is it the way I should get constant protected by _KERNEL?
Also should I PR my patch?
Anyway here is the diff against RELENG_7. Please let me know if I'm
doing something wrong here.
---
--- ip_fw2.c.orig2008-09-01 17:31:57.0 +0800
+++ ip_fw2.c2008-09-01 16:54:30.0 +0800
@@ -255,6 +255,8 @@
static u_int32_t dyn_count;/* # of dynamic rules */
static u_int32_t dyn_max = 4096;/* max # of dynamic rules */
+static u_int32_t tables_count = IPFW_TABLES_MAX;/* # of tables */
+
SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_buckets, CTLFLAG_RW,
&dyn_buckets, 0, "Number of dyn. buckets");
SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLFLAG_RD,
@@ -265,6 +267,8 @@
&dyn_max, 0, "Max number of dyn. rules");
SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, static_count, CTLFLAG_RD,
&static_count, 0, "Number of static rules");
+SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, tables_count, CTLFLAG_RD,
+&tables_count, 0, "Number of tables");
SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_ack_lifetime, CTLFLAG_RW,
&dyn_ack_lifetime, 0, "Lifetime of dyn. rules for acks");
SYSCTL_INT(_net_inet_ip_fw, OID_AUTO, dyn_syn_lifetime, CTLFLAG_RW,
---
--- /usr/src/sbin/ipfw/ipfw2.c2008-07-31 09:39:59.0 +0800
+++ ipfw2.c2008-09-01 16:46:08.0 +0800
@@ -5860,24 +5860,30 @@
* ipfw table N add addr[/masklen] [value]
* ipfw table N delete addr[/masklen]
* ipfw table N flush
- * ipfw table N list
+ * ipfw table N|all list
*/
static void
table_handler(int ac, char *av[])
{
ipfw_table_entry ent;
ipfw_table *tbl;
-int do_add;
+int do_add, is_all = 0;
char *p;
socklen_t l;
-uint32_t a;
+uint32_t a, b, c;
+size_t len;
ac--; av++;
if (ac && isdigit(**av)) {
ent.tbl = atoi(*av);
ac--; av++;
+} else if (_substrcmp(*av, "all") == 0) {
+ent.tbl = 0;
+is_all = 1;
+ac--; av++;
} else
errx(EX_USAGE, "table number required");
+
NEED1("table needs command");
if (_substrcmp(*av, "add") == 0 ||
_substrcmp(*av, "delete") == 0) {
@@ -5931,33 +5937,55 @@
if (do_cmd(IP_FW_TABLE_FLUSH, &ent.tbl, sizeof(ent.tbl)) < 0)
err(EX_OSERR, "setsockopt(IP_FW_TABLE_FLUSH)");
} else if (_substrcmp(*av, "list") == 0) {
-a = ent.tbl;
-l = sizeof(a);
-if (do_cmd(IP_FW_TABLE_GETSIZE, &a, (uintptr_t)&l) < 0)
-err(EX_OSERR, "getsockopt(IP_FW_TABLE_GETSIZE)");
-l = sizeof(*tbl) + a * sizeof(ipfw_table_entry);
-tbl = malloc(l);
-if (tbl == NULL)
-err(EX_OSERR, "malloc");
-tbl->tbl = ent.tbl;
-if (do_cmd(IP_FW_TABLE_LIST, tbl, (uintptr_t)&l) < 0)
-err(EX_OSERR, "getsockopt(IP_FW_TABLE_LIST)");
-for (a = 0; a < tbl->cnt; a++) {
-unsigned int tval;
-tval = tbl->ent[a].value;
-if (do_value_as_ip) {
-char tbuf[128];
-strncpy(tbuf, inet_ntoa(*(struct in_addr *)
-&tbl->ent[a].addr), 127);
-/* inet_ntoa expects network order */
-tval = htonl(tval);
-printf("%s/%u %s\n", tbuf, tbl->ent[a].masklen,
-inet_ntoa(*(struct in_addr *)&tval));
-} else {
-printf("%s/%u %u\n",
-inet_ntoa(*(struct in_addr *)&tbl->ent[a].addr),
-tbl->ent[a].masklen, tval);
+c = ent.tbl;
+
+if (is_all) {
+len = sizeof(uint32_t);
+
+/* get IPFW_TABLES_MAX */
+if (sysctlbyname("net.inet.ip.fw.tables_count",
+&c, &len, NULL, 0) == -1)
+errx(1, "sysctlbyname(\"%s\")",
+"net.inet.ip.fw.tables_count");
+
+
Re: IPFW_TABLES_MAX in src/sbin/ipfw/ipfw2.c
Ganbold wrote: Hi, Sorry for sending this third time (2 to freebsd-ipfw, 1 to freebsd-net). I'm trying to make small changes in ipfw2.c code (RELENG_7), but make fails with following error: v02# make cc -O2 -fno-strict-aliasing -pipe -Wno-pointer-sign -c /usr/src/sbin/ipfw/ipfw2.c /usr/src/sbin/ipfw/ipfw2.c: In function 'table_handler': /usr/src/sbin/ipfw/ipfw2.c:5941: error: 'IPFW_TABLES_MAX' undeclared (first use in this function) /usr/src/sbin/ipfw/ipfw2.c:5941: error: (Each undeclared identifier is reported only once /usr/src/sbin/ipfw/ipfw2.c:5941: error: for each function it appears in.) *** Error code 1 IPFW_TABLES_MAX seems like defined in netinet/ip_fw.h, which is included in ipfw2.c: IPFW_TABLES_MAX protected by _KERNEL macro. This is why you get an error. -- WBR, Andrey V. Elsukov ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics
The following reply was made to PR kern/125181; it has been noted by GNATS. From: "Paul B. Mahol" <[EMAIL PROTECTED]> To: "Andrew Thompson" <[EMAIL PROTECTED]> Cc: "Coleman Kane" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Re: kern/125181: [ndis] [patch] with wep enters kdb.enter.unknown, panics Date: Mon, 1 Sep 2008 09:57:42 +0200 On 7/17/08, Andrew Thompson <[EMAIL PROTECTED]> wrote: > On Thu, Jul 17, 2008 at 12:09:52PM -0400, Coleman Kane wrote: >> Andrew, >> >> I got directed to this PR by [EMAIL PROTECTED] (Paul D. Mahol), who's >> been helping me track down some edge cases in the if_ndis locking >> rewrite. I am not 100% familiar with the locking semantics in play here >> (IEEE80211 and VAPs), so I wanted to run it by you before I determine >> that it seems to be working well for me. > > I dont think ndis should be reaching into the net80211 lock. Now that > ndis uses a regular mutex its a good chance to add mtx_asserts in the > right places and get the locking up to speed. I will try to post a patch > soon unless someone beats be to it. > > Andrew > I got hit by this bug again, my only option is to switch to UP kernel until patch for this bug is finally committed. Subject of bug report is no more relevant, becuase this bug has nothing directly related with WEP. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
