freebsd-net Digest, Vol 364, Issue 5
freebsd-n...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-net
or, via email, send a message with subject or body 'help' to
freebsd-n...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-net digest..."
Today's Topics:
1. Poor situation with snmp support in FreeBSD (Vasyl Samoilov)
2. Re: Poor situation with snmp support in FreeBSD (Harti Brandt)
3. Re: Poor situation with snmp support in FreeBSD (Ivan Voras)
4. Re: Poor situation with snmp support in FreeBSD
(Shteryana Shopova)
5. Re: kern/138427: [wpi] [panic] Kernel panic after trying set
monitor wlanmode on Intel 3945 ABG (wpi driver) (Henry Hu)
6. Re: kern/143595: [wpi] [panic] Creating virtual interface
over wpi0 in monitor mode causes crash (Henry Hu)
7. Re: kern/144917: Flowtable crashes system (Ilya Zhuravlev)
8. Re: kern/138427: [wpi] [panic] Kernel panic after trying set
monitor wlanmode on Intel 3945 ABG (wpi driver) (Henry Hu)
9. Re: CARP vs. if_bridge (Boris Kochergin)
10. Re: Poor situation with snmp support in FreeBSD (Vasyl Samoilov)
11. Re: kern/145036: [fxp] poor preformance with fxp driver &
intel 82550 chipset (lin...@FreeBSD.org)
12. Re: Choosing CPU for router (Jon Otterholm)
13. Re: kern/145036: [fxp] poor preformance with fxp driver &
intel 82550 chipset (yon...@FreeBSD.org)
14. Fwd: dummynet error in last stable version (Adailton Milhorini)
15. Re: kern/118238: commit references a PR (dfilter service)
16. Re: kern/118238: commit references a PR (dfilter service)
17. Re: Poor situation with snmp support in FreeBSD (Alexander Bubnov)
18. Re: Poor situation with snmp support in FreeBSD (Alexander Bubnov)
19. Re: Poor situation with snmp support in FreeBSD (Harti Brandt)
20. Re: Poor situation with snmp support in FreeBSD (Harti Brandt)
21. Re: Poor situation with snmp support in FreeBSD (Hartmut Brandt)
22. Re: Poor situation with snmp support in FreeBSD (Alexander Bubnov)
23. Re: Poor situation with snmp support in FreeBSD (Vasily Samoylov)
24. Re: Poor situation with snmp support in FreeBSD (Hartmut Brandt)
25. Re: Poor situation with snmp support in FreeBSD (Vasily Samoylov)
26. NFS lockd problem (Giulio Ferro)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Mar 2010 14:43:35 +0200
From: Vasyl Samoilov <v...@mts.com.ua>
Subject: Poor situation with snmp support in FreeBSD
To: freeb...@freebsd.org
Message-ID: <4BAB5A77...@mts.com.ua>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hello.
Lately I was desperatly trying to build a networking element based on
freebsd to fit into overall networking infrastructure. It's not a secret
that virtually anything now can do more or less snmp, thus I was trying
to monitor and query my boxes with snmp - it didn't end well. Any help
would be appreciated.
So far I found two options for snmp daemon - bsnmp and net-snmp.
net-snmo giving back invalid data, bsnmp lacks some data at all.
What do I expect to get from snmp? As for L3 device, I want to:
1) Get interfaces list with their properties (name, type, speed, mac,
subnets assigned)
2) Get ARP info (ipNetToPhysicalTable or ipNetToMedia)
3) Get routing table
4) Get neighboor data - LLDP is common protocol for devices now.
extra bonuses like mac address table or vlan info is out of the scope
for now.
setup:
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
ether 00:02:b3:c9:75:ef
inet 192.168.2.2 netmask 0xffffff00 broadcast 192.168.2.255
media: Ethernet autoselect (10baseT/UTP <full-duplex>)
status: active
rl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8<VLAN_MTU>
ether 00:02:b3:c9:75:df
inet 10.101.45.10 netmask 0xffffff80 broadcast 10.101.45.127
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:07:e9:0b:2d:96
inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=3<RXCSUM,TXCSUM>
inet 127.0.0.1 netmask 0xff000000
tun5: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
inet 192.168.150.5 --> 192.168.150.6 netmask 0xffffffff
Opened by PID 1508
vboxnet0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 0a:00:27:00:00:00
(vboxnet0 was up during snmp session)
IF-MIB::ifName.1 = STRING: re0
IF-MIB::ifName.2 = STRING: rl0
IF-MIB::ifName.3 = STRING: em0
IF-MIB::ifName.4 = STRING: lo0
IF-MIB::ifName.5 = STRING: vboxnet0
IF-MIB::ifName.6 = STRING: tun5
Results:
* net-snmp got ipRoute table, which is outdated. The information is
relatively correct, but all the types considered to be "local". bsnmp,
on the other hand, got ipCidrRoute group, but it prints out only routes
ipCidrRouteType=remote, and ipCidrRouteProto=netmgmt, which makes it
unuseable (not all routes are printed, only few that are non-local
destination).
* net-snmp can give out ipNetToMedia to get arp table (yes, it's old and
should not be used in 2010), bnsmp got no means to get arp table at all.
* out of link-layer advertisements daemons, ladvd seems to be most
bsd-compatible-feature-rich, but there is no way to export any kind on
link-layer info via snmp under freebsd at all. neither net-snmp or bsnmp
support this.
In all other cases, bsnmp was found superior to net-snmp under freebsd:
net-snmp don't handle connector information properly:
net-snmp:
IF-MIB::ifConnectorPresent.1 = INTEGER: true(1)
IF-MIB::ifConnectorPresent.2 = INTEGER: true(1)
IF-MIB::ifConnectorPresent.3 = INTEGER: true(1)
IF-MIB::ifConnectorPresent.4 = INTEGER: true(1)
IF-MIB::ifConnectorPresent.5 = INTEGER: true(1)
IF-MIB::ifConnectorPresent.6 = INTEGER: true(1)
bnsmp:
IF-MIB::ifConnectorPresent.1 = INTEGER: true(1)
IF-MIB::ifConnectorPresent.2 = INTEGER: true(1)
IF-MIB::ifConnectorPresent.3 = INTEGER: true(1)
IF-MIB::ifConnectorPresent.4 = INTEGER: false(2)
IF-MIB::ifConnectorPresent.5 = INTEGER: true(1)
IF-MIB::ifConnectorPresent.6 = INTEGER: false(2)
net-snmp doesn't handle interface ifHighSpeed and ifSpeed properly (An
estimate of the interface's current bandwidth):
net-snmp:
IF-MIB::ifHighSpeed.1 = Gauge32: 1000
IF-MIB::ifHighSpeed.2 = Gauge32: 100
IF-MIB::ifHighSpeed.3 = Gauge32: 1000
IF-MIB::ifHighSpeed.4 = Gauge32: 0
IF-MIB::ifHighSpeed.5 = Gauge32: 0
IF-MIB::ifHighSpeed.6 = Gauge32: 0
IF-MIB::ifSpeed.1 = Gauge32: 1000000000
IF-MIB::ifSpeed.2 = Gauge32: 100000000
IF-MIB::ifSpeed.3 = Gauge32: 1000000000
IF-MIB::ifSpeed.4 = Gauge32: 0
IF-MIB::ifSpeed.5 = Gauge32: 0
IF-MIB::ifSpeed.6 = Gauge32: 0
bsnmp:
IF-MIB::ifHighSpeed.1 = Gauge32: 10
IF-MIB::ifHighSpeed.2 = Gauge32: 100
IF-MIB::ifHighSpeed.3 = Gauge32: 1000
IF-MIB::ifHighSpeed.4 = Gauge32: 0
IF-MIB::ifHighSpeed.5 = Gauge32: 0
IF-MIB::ifHighSpeed.6 = Gauge32: 0
IF-MIB::ifSpeed.1 = Gauge32: 10000000
IF-MIB::ifSpeed.2 = Gauge32: 100000000
IF-MIB::ifSpeed.3 = Gauge32: 1000000000
IF-MIB::ifSpeed.4 = Gauge32: 0
IF-MIB::ifSpeed.5 = Gauge32: 0
IF-MIB::ifSpeed.6 = Gauge32: 0
net-snmp shows incorrect interface mac (a:0:27:0:0:0 is correct):
net-snmp:
IF-MIB::ifPhysAddress.1 = STRING: 0:2:b3:c9:75:ef
IF-MIB::ifPhysAddress.2 = STRING: 0:2:b3:c9:75:df
IF-MIB::ifPhysAddress.3 = STRING: 0:7:e9:b:2d:96
IF-MIB::ifPhysAddress.4 = STRING:
IF-MIB::ifPhysAddress.5 = STRING: 0:0:27:0:0:0
IF-MIB::ifPhysAddress.6 = STRING:
bsnmp:
IF-MIB::ifPhysAddress.1 = STRING: 0:2:b3:c9:75:ef
IF-MIB::ifPhysAddress.2 = STRING: 0:2:b3:c9:75:df
IF-MIB::ifPhysAddress.3 = STRING: 0:7:e9:b:2d:96
IF-MIB::ifPhysAddress.4 = STRING:
IF-MIB::ifPhysAddress.5 = STRING: a:0:27:0:0:0
IF-MIB::ifPhysAddress.6 = STRING:
------------------------------
Message: 2
Date: Thu, 25 Mar 2010 14:33:15 +0100 (CET)
From: Harti Brandt <hartmut...@dlr.de>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Vasyl Samoilov <v...@mts.com.ua>
Cc: freeb...@freebsd.org
Message-ID: <2010032514...@beagle.kn.op.dlr.de>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 25 Mar 2010, Vasyl Samoilov wrote:
VS>So far I found two options for snmp daemon - bsnmp and net-snmp. net-snmo
VS>giving back invalid data, bsnmp lacks some data at all.
Just two general remarks:
- net-snmp is probably developed on Linux so it doesn't know how to
access many of the informations that is available in FreeBSD.
- bsnmp is lacking developers (I'm the only one). I had a surgery in
november and took the 4 weeks after this to rewrite all the networking
stuff. It is in principle mostly up to date and supports also IPv6. The
problem is that I run out of time again and just cannot do the last steps
to release it (including testing). If there were people interested in it,
I would happily work with them.
harti
------------------------------
Message: 3
Date: Thu, 25 Mar 2010 14:42:14 +0100
From: Ivan Voras <ivo...@freebsd.org>
Subject: Re: Poor situation with snmp support in FreeBSD
To: freeb...@freebsd.org
Message-ID: <hofp7m$r06$1...@dough.gmane.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 03/25/10 13:43, Vasyl Samoilov wrote:
> Hello.
> Lately I was desperatly trying to build a networking element based on
> freebsd to fit into overall networking infrastructure. It's not a secret
> that virtually anything now can do more or less snmp, thus I was trying
> to monitor and query my boxes with snmp - it didn't end well. Any help
> would be appreciated.
This looks like a good suggestion for a student of Google Summer of
Code. Maybe you can find such a student or advertise the idea on mailing
lists (you'll need to exactly specify what is needed).
------------------------------
Message: 4
Date: Thu, 25 Mar 2010 13:59:30 +0000
From: Shteryana Shopova <shte...@gmail.com>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Ivan Voras <ivo...@freebsd.org>
Cc: freeb...@freebsd.org
Message-ID:
<61b573981003250659n107...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi all,
On Thu, Mar 25, 2010 at 1:33 PM, Harti Brandt <hartmut...@dlr.de> wrote:
> On Thu, 25 Mar 2010, Vasyl Samoilov wrote:
>
>
> - bsnmp is lacking developers (I'm the only one). I had a surgery in
+ 1 (count me in that is)
> november and took the 4 weeks after this to rewrite all the networking
> stuff. It is in principle mostly up to date and supports also IPv6. The
> problem is that I run out of time again and just cannot do the last steps
> to release it (including testing). If there were people interested in it,
> I would happily work with them.
>
> harti
>
sorry to hear about the surgery - I've recently resumed somewhat
active work on bsnmp and modules, so if you can upload your work to an
accessible repository, say svn.freebsd.org/user/harti I can take on
testing and preparing the code for import. btw, I was contacted some
time ago by Carlos Santos suggesting a set of patches adding IPV6
transport, unfortunatelly he hasn't replied to any of my last e-mails,
is this the same patchset we're talking about or a different one?
On Thu, Mar 25, 2010 at 1:42 PM, Ivan Voras <ivo...@freebsd.org> wrote:
> On 03/25/10 13:43, Vasyl Samoilov wrote:
>> to monitor and query my boxes with snmp - it didn't end well. Any help
>> would be appreciated.
>
> This looks like a good suggestion for a student of Google Summer of Code.
> Maybe you can find such a student or advertise the idea on mailing lists
> (you'll need to exactly specify what is needed).
>
We already have BSNMP listed on the SoC project ideas page :) The
problem is we still need a developer to review and test the code
before it can be imported. :)
cheers,
Shteryana
P.S. Back to the thread topic - so the only problem the author is
facing with bsnmp is that it lacks support for LLDP, do I understand
correctly?
------------------------------
Message: 5
Date: Thu, 25 Mar 2010 15:50:06 GMT
From: Henry Hu <henry...@gmail.com>
Subject: Re: kern/138427: [wpi] [panic] Kernel panic after trying set
monitor wlanmode on Intel 3945 ABG (wpi driver)
To: freeb...@FreeBSD.org
Message-ID: <201003251550....@freefall.freebsd.org>
The following reply was made to PR kern/138427; it has been noted by GNATS.
From: Henry Hu <henry...@gmail.com>
To: bug-fo...@FreeBSD.org, marcin...@simplusnet.pl
Cc:
Subject: Re: kern/138427: [wpi] [panic] Kernel panic after trying set monitor
wlanmode on Intel 3945 ABG (wpi driver)
Date: Thu, 25 Mar 2010 23:40:26 +0800
Me too. backtrace:
(kgdb) where
#0 doadump () at pcpu.h:246
#1 0xc0637af7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2 0xc0637e02 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:579
#3 0xc08bd983 in trap_fatal (frame=0xf09caaa8, eva=20) at
/usr/src/sys/i386/i386/trap.c:938
#4 0xc08be2b7 in trap (frame=0xf09caaa8) at /usr/src/sys/i386/i386/trap.c:328
#5 0xc08a0bbb in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#6 0xc06736bf in turnstile_broadcast (ts=0x0, queue=0) at
/usr/src/sys/kern/subr_turnstile.c:832
#7 0xc0628129 in _mtx_unlock_sleep (m=0xc6d2b008, opts=0, file=0x0,
line=0) at /usr/src/sys/kern/kern_mutex.c:677
#8 0xc06286c4 in unlock_mtx (lock=0xc6d2b008) at
/usr/src/sys/kern/kern_mutex.c:164
#9 0xc06409e7 in _sleep (ident=0xf0bd1b60, lock=0xc6d2b008,
priority=256, wmesg=0xc8c3a896 "wpicmd", timo=100) at
/usr/src/sys/kern/kern_synch.c:204
#10 0xc8c34369 in wpi_cmd (sc=0xc6d2b000, code=Variable "code" is not available.
) at /usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2210
#11 0xc8c3709b in wpi_config (sc=0xc6d2b000) at
/usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2771
#12 0xc8c374d7 in wpi_set_channel (ic=0xc8c3d000) at
/usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:3555
#13 0xc0729913 in update_channel (arg=0xc8c3d000, npending=1) at
/usr/src/sys/net80211/ieee80211_proto.c:1119
#14 0xc06711a2 in taskqueue_run (queue=0xc81dc100) at
/usr/src/sys/kern/subr_taskqueue.c:239
#15 0xc06713ad in taskqueue_thread_loop (arg=0xc8c3d074) at
/usr/src/sys/kern/subr_taskqueue.c:360
#16 0xc060c661 in fork_exit (callout=0xc06712f0
<taskqueue_thread_loop>, arg=0xc8c3d074, frame=0xf09cad38) at
/usr/src/sys/kern/kern_fork.c:843
#17 0xc08a0c30 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270
(kgdb) frame 7
#7 0xc0628129 in _mtx_unlock_sleep (m=0xc6d2b008, opts=0, file=0x0,
line=0) at /usr/src/sys/kern/kern_mutex.c:677
677 turnstile_broadcast(ts, TS_EXCLUSIVE_QUEUE);
(kgdb) l
672 turnstile_chain_lock(&m->lock_object);
673 ts = turnstile_lookup(&m->lock_object);
674 if (LOCK_LOG_TEST(&m->lock_object, opts))
675 CTR1(KTR_LOCK, "_mtx_unlock_sleep: %p contested", m);
676 MPASS(ts != NULL);
677 turnstile_broadcast(ts, TS_EXCLUSIVE_QUEUE);
678 _release_lock_quick(m);
679
680 /*
681 * This turnstile is now no longer associated with the
mutex. We can
(kgdb) p ts
$13 = (struct turnstile *) 0x0
(kgdb) frame 10
#10 0xc8c34369 in wpi_cmd (sc=0xc6d2b000, code=Variable "code" is not available.
) at /usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2210
2210 return msleep(cmd, &sc->sc_mtx, PCATCH, "wpicmd", hz);
(kgdb) l
2205 if (async) {
2206 sc->flags &= ~ WPI_FLAG_BUSY;
2207 return 0;
2208 }
2209
2210 return msleep(cmd, &sc->sc_mtx, PCATCH, "wpicmd", hz);
2211 }
2212
2213 static int
2214 wpi_wme_update(struct ieee80211com *ic)
(kgdb) frame 7
#7 0xc0628129 in _mtx_unlock_sleep (m=0xc6d2b008, opts=0, file=0x0,
line=0) at /usr/src/sys/kern/kern_mutex.c:677
677 turnstile_broadcast(ts, TS_EXCLUSIVE_QUEUE);
(kgdb) p *m
$14 = {lock_object = {lo_name = 0xc655f1a0 "wpi0", lo_flags =
16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3358744576}
(kgdb) frame 10
#10 0xc8c34369 in wpi_cmd (sc=0xc6d2b000, code=Variable "code" is not available.
) at /usr/src/sys/modules/wpi/../../dev/wpi/if_wpi.c:2210
2210 return msleep(cmd, &sc->sc_mtx, PCATCH, "wpicmd", hz);
(kgdb) p sc->sc_mtx
$15 = {lock_object = {lo_name = 0xc655f1a0 "wpi0", lo_flags =
16973824, lo_data = 0, lo_witness = 0x0}, mtx_lock = 3358744576}
it seems like turnstile_lookup failed.
The driver works well in normal mode.
--
Cheers,
Henry
------------------------------
Message: 6
Date: Thu, 25 Mar 2010 15:50:09 GMT
From: Henry Hu <henry...@gmail.com>
Subject: Re: kern/143595: [wpi] [panic] Creating virtual interface
over wpi0 in monitor mode causes crash
To: freeb...@FreeBSD.org
Message-ID: <201003251550....@freefall.freebsd.org>
The following reply was made to PR kern/143595; it has been noted by GNATS.
From: Henry Hu <henry...@gmail.com>
To: bug-fo...@FreeBSD.org, gau...@lisphacker.org
Cc:
Subject: Re: kern/143595: [wpi] [panic] Creating virtual interface over wpi0
in monitor mode causes crash
Date: Thu, 25 Mar 2010 23:42:09 +0800
It seems like that this is the same problem as kern/138427: [wpi]
[panic] Kernel panic after trying set monitor wlanmode on Intel 3945
ABG (wpi driver)
--
Cheers,
Henry
------------------------------
Message: 7
Date: Thu, 25 Mar 2010 23:32:45 +0800
From: Ilya Zhuravlev <il...@el-crane.net>
Subject: Re: kern/144917: Flowtable crashes system
To: Evgenii Davidov <da...@korolev-net.ru>
Cc: freeb...@freebsd.org
Message-ID: <4BAB821D...@el-crane.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 21.03.2010 17:04, Evgenii Davidov wrote:
> Здравствуйте,
>
> On Sat, Mar 20, 2010 at 11:06:35PM +0000, Doychin Dokov пишет:
>
>>> Description:
>> It seems like flowtable has been merged and enabled by default in 8.0.... which is a really really bad idea.
>> On a system which handles two full BGP tables it makes one of the CPU cores run at 100% right after most of the prefixes get installed in the routing table.
>
> i saw the same effect with ospf
>
8.0-p2, 2 full-view with openbgpd
"tuning":
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.icmp.icmplim_output=0
net.inet.icmp.drop_redirect=1
net.inet.flowtable.nmbflows=32768
1 week uptime.Now I think only about increasing tx/rx descriptors to
reduce interrupts (default values was not changed)
netstat -w1 -Iigb0
input (igb0) output
packets errs bytes packets errs bytes colls
49100 0 12290513 23693 0 27268884 0
48322 0 12688283 24332 0 28099404 0
50602 0 12759620 24437 0 27698341 0
47857 0 11354124 21410 0 23845155 0
netstat -w1 -Iigb1
input (igb1) output
packets errs bytes packets errs bytes colls
32428 0 35027019 24562 0 5624934 0
30621 0 33384339 23569 0 4456944 0
28419 0 31014269 21571 0 3638083 0
29409 0 32524760 22137 0 3503600 0
30965 0 33532742 23973 0 5089231 0
netstat -w1 -Iem0
input (em0) output
packets errs bytes packets errs bytes colls
17217 0 3929366 72741 0 46377762 0
17412 0 3745112 75522 0 49338883 0
18385 0 4014568 77444 0 50532101 0
17142 0 3875518 77125 0 47646681 0
16870 0 3528316 73188 0 47940959 0
17069 0 3682891 80268 0 52904747 0
17313 0 4101576 75586 0 51933330 0
------------------------------
Message: 8
Date: Thu, 25 Mar 2010 16:20:06 GMT
From: Henry Hu <henry...@gmail.com>
Subject: Re: kern/138427: [wpi] [panic] Kernel panic after trying set
monitor wlanmode on Intel 3945 ABG (wpi driver)
To: freeb...@FreeBSD.org
Message-ID: <201003251620....@freefall.freebsd.org>
The following reply was made to PR kern/138427; it has been noted by GNATS.
From: Henry Hu <henry...@gmail.com>
To: bug-fo...@FreeBSD.org, marcin...@simplusnet.pl
Cc:
Subject: Re: kern/138427: [wpi] [panic] Kernel panic after trying set monitor
wlanmode on Intel 3945 ABG (wpi driver)
Date: Fri, 26 Mar 2010 00:19:14 +0800
--00163628426c61e9260482a26872
Content-Type: text/plain; charset=ISO-8859-1
OK, maybe I've found the problem.
In wpi_set_channel, when in monitor mode, wpi_config is called without
locks. However, it thinks that the lock is held. So the problem
occurs.
See the attached patch. Now I'm capturing in monitor mode with wireshark.
--
Cheers,
Henry
--00163628426c61e9260482a26872
Content-Type: application/octet-stream; name="wpi.diff"
Content-Disposition: attachment; filename="wpi.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g77rnz290
LS0tIGlmX3dwaS5jLm9yaWcJMjAxMC0wMy0yNSAyMzo1NTo0MC4wMDAwMDAwMDAgKzA4MDAKKysr
IGlmX3dwaS5jCTIwMTAtMDMtMjUgMjM6NTU6NTcuMDAwMDAwMDAwICswODAwCkBAIC0zNTUyLDcg
KzM1NTIsOSBAQAogCSAqIGFyZSBhbHJlYWR5IHRha2VuIGNhcmUgb2YgYnkgdGhlaXIgcmVzcGVj
dGl2ZSBmaXJtd2FyZSBjb21tYW5kcy4KIAkgKi8KIAlpZiAoaWMtPmljX29wbW9kZSA9PSBJRUVF
ODAyMTFfTV9NT05JVE9SKSB7CisJCVdQSV9MT0NLKHNjKTsKIAkJZXJyb3IgPSB3cGlfY29uZmln
KHNjKTsKKwkJV1BJX1VOTE9DSyhzYyk7CiAJCWlmIChlcnJvciAhPSAwKQogCQkJZGV2aWNlX3By
aW50ZihzYy0+c2NfZGV2LAogCQkJICAgICJlcnJvciAlZCBzZXR0dGluZyBjaGFubmVsXG4iLCBl
cnJvcik7Cg==
--00163628426c61e9260482a26872--
------------------------------
Message: 9
Date: Thu, 25 Mar 2010 12:20:14 -0400
From: Boris Kochergin <sp...@acm.poly.edu>
Subject: Re: CARP vs. if_bridge
To: freeb...@freebsd.org
Message-ID: <4BAB8D3E...@acm.poly.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Boris Kochergin wrote:
> Max Laier wrote:
>> On Thursday 18 February 2010 18:02:55 Boris Kochergin wrote:
>>
>>> Ahoy. I'm seeing what appears to be erroneous interaction between CARP
>>> and if_bridge on multiple machines with a variety of Ethernet
>>> controllers and architectures. I've observed it on 7.2-R and 8.0-R. The
>>> test setup is simple enough:
>>>
>>> CARP master:
>>>
>>> FreeBSD t30 8.0-RELEASE-p1 FreeBSD 8.0-RELEASE-p1 #5: Sun Feb 14
>>> 20:22:41 EST 2010 root@t30:/usr/obj/usr/src/sys/T30 i386
>>>
>>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>>> options=3<RXCSUM,TXCSUM>
>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
>>> inet6 ::1 prefixlen 128
>>> inet 127.0.0.1 netmask 0xff000000
>>> dc0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>>> metric 0
>>> mtu 1500
>>> options=8<VLAN_MTU>
>>> ether 00:04:5a:a8:e0:bf
>>> inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
>>> media: Ethernet autoselect (100baseTX <full-duplex>)
>>> status: active
>>> carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
>>> inet 192.168.0.1 netmask 0xffffff00
>>> carp: MASTER vhid 1 advbase 1 advskew 0
>>>
>>> CARP backup:
>>>
>>> FreeBSD ultra5 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Thu Feb 18 15:19:39
>>> UTC 2010 boris@ultra5:/usr/obj/usr/src/sys/GENERIC.carp sparc64
>>>
>>> hme0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
>>> options=b<RXCSUM,TXCSUM,VLAN_MTU>
>>> ether 08:00:20:f5:65:d4
>>> media: Ethernet autoselect
>>> xl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>>> metric 0
>>> mtu 1500
>>> options=9<RXCSUM,VLAN_MTU>
>>> ether 00:01:03:2c:06:6d
>>> inet 192.168.0.3 netmask 0xffffff00 broadcast 192.168.0.255
>>> media: Ethernet autoselect (100baseTX <full-duplex>)
>>> status: active
>>> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>>> options=3<RXCSUM,TXCSUM>
>>> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
>>> inet6 ::1 prefixlen 128
>>> inet 127.0.0.1 netmask 0xff000000
>>> carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500
>>> inet 192.168.0.1 netmask 0xffffff00
>>> carp: MASTER vhid 1 advbase 1 advskew 100
>>> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0
>>> mtu
>>> 1500
>>> ether 3a:e6:09:2d:da:bc
>>> id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
>>> maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
>>> root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
>>> member: xl0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
>>> ifmaxaddr 0 port 2 priority 128 path cost 200000
>>> member: hme0 flags=8<SPAN>
>>> ifmaxaddr 0 port 1 priority 128 path cost 200000
>>>
>>> In summary, I have a basic CARP configuration and, on the backup CARP
>>> machine, a bridge with the CARP device's physical interface in it. The
>>> purpose of this setup is the ability to monitor traffic passing through
>>> that interface using another machine. If the master CARP machine is
>>> disconnected from the network, the CARP interface on the backup machine
>>> correctly changes to the MASTER state, but does not act on traffic
>>> bound
>>> for the shared IP address--192.168.0.1. tcpdump shows the traffic
>>> coming
>>> in on the correct physical interface, but it is never replied to,
>>> or, in
>>> the case of routing, forwarded. Removing xl0 from the bridge on the
>>> backup machine instantly fixes this, and the shared IP address behaves
>>> as expected. Adding xl0 back to the bridge while the backup CARP
>>> interface is in the MASTER state keeps things running correctly, so the
>>> problem is only observed when xl0 is part of the bridge during the CARP
>>> transition from BACKUP to MASTER. Thoughts?
>>>
>>
>> I assume the bridge filters out the traffic as it thinks the
>> destination is elsewhere (it has previously seen ARPs from the other
>> MASTER entering via xl0). It shouldn't do that, but that's a
>> different story. You can try to force edge or ptp status on xl0, not
>> sure if this does the trick, but it's worth a try.
>>
>> Regards,
>> Max
>>
> Sure. No go, though, I'm afraid. It's not an operational show-stopper
> for me, at least. In the worst case, I can always hack up a PCAP
> program to copy the frames around in user space.
>
> -Boris
For the archives, in the off chance that someone else encounters this:
http://acm.poly.edu/wiki/Userspace_SPAN_Port
-Boris
------------------------------
Message: 10
Date: Thu, 25 Mar 2010 18:07:18 +0200
From: Vasyl Samoilov <ma...@vas.org.ua>
Subject: Re: Poor situation with snmp support in FreeBSD
To: freeb...@freebsd.org
Message-ID: <4BAB8A36...@vas.org.ua>
Content-Type: text/plain; charset=UTF-8; format=flowed
25.03.2010 15:59, Shteryana Shopova написав(ла):
>
> We already have BSNMP listed on the SoC project ideas page :) The
> problem is we still need a developer to review and test the code
> before it can be imported. :)
>
> cheers,
> Shteryana
>
> P.S. Back to the thread topic - so the only problem the author is
> facing with bsnmp is that it lacks support for LLDP, do I understand
> correctly?
>
It's 3 problems:
1) No ARP support
2) Routing table not exported correctly (directly attached routes not
visible, maybe something else - at least it's nothing like netstat -rn
gives)
3) No LLDP support
for the future (I understand how hard it is to complete with limited
resources):
*Complete etherlike-mib for interface duplex information
* vlan information for interfaces / per-vlan mac address table for
bridge - freebsd as managed layer 2 device (I didn't dig deep into this
yet, considering the first 3 showstoppers)
------------------------------
Message: 11
Date: Thu, 25 Mar 2010 16:28:57 GMT
From: lin...@FreeBSD.org
Subject: Re: kern/145036: [fxp] poor preformance with fxp driver &
intel 82550 chipset
To: lin...@FreeBSD.org, freebs...@FreeBSD.org,
freeb...@FreeBSD.org
Message-ID: <201003251628....@freefall.freebsd.org>
Old Synopsis: poor preformance with fxp driver & intel 82550 chipset
New Synopsis: [fxp] poor preformance with fxp driver & intel 82550 chipset
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Thu Mar 25 16:28:46 UTC 2010
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=145036
------------------------------
Message: 12
Date: Thu, 25 Mar 2010 18:08:35 +0100
From: Jon Otterholm <jon.ot...@ide.resurscentrum.se>
Subject: Re: Choosing CPU for router
To: <freeb...@freebsd.org>
Message-ID: <C7D15723.24A90%jon.ot...@ide.resurscentrum.se>
Content-Type: text/plain; charset="US-ASCII"
Den 2010-03-23 19.36, skrev "Jon Otterholm"
<jon.ot...@ide.resurscentrum.se>:
>
>
>
> Den 2010-03-23 14.12, skrev "Ivan Voras" <ivo...@freebsd.org>:
>
>> On 03/18/10 01:32, Andrew Snow wrote:
>>>
>>> Jon Otterholm wrote:
>>>> This machine is going to act as access-router serving ~500
>>>> FTTH-customers.
>>>> About 500Mbit/s and 200kpps. The big issue is Dummynet, around 1000
>>>> pipes (2
>>>> pipes/customer).
>>>
>>> That doesn't sound right, 200kpps @ 500Mbps works out to an average
>>> packet size of 250 bytes? Am I missing something
>>
>> Maybe he's pushing VoIP...
>
> Today we are pushing ~0,4kpps/Mbit. At the same ratio 500Mbit/s sums up to
> ~200kpps.
>
> //JO
>
I ended up ordering a Supermicro SC513, X8SIE-LN4F and a i5-670 as suggested
by someone earlier. I have not tried the management interface earlier,
anyone with experience running it?
//JO
------------------------------
Message: 13
Date: Thu, 25 Mar 2010 18:26:42 GMT
From: yon...@FreeBSD.org
Subject: Re: kern/145036: [fxp] poor preformance with fxp driver &
intel 82550 chipset
To: mfa...@gmail.com, yon...@FreeBSD.org, freeb...@FreeBSD.org,
yon...@FreeBSD.org
Message-ID: <201003251826....@freefall.freebsd.org>
Synopsis: [fxp] poor preformance with fxp driver & intel 82550 chipset
State-Changed-From-To: open->feedback
State-Changed-By: yongari
State-Changed-When: Thu Mar 25 18:25:58 UTC 2010
State-Changed-Why:
What FreeBSD version do you use?
And show me the output of dmesg and "ifconfig fxp0".
Could you give me more details on
"high ping times and slow transder rates about 5k max"?
Would you let me know how did you measure network performance?
Responsible-Changed-From-To: freebsd-net->yongari
Responsible-Changed-By: yongari
Responsible-Changed-When: Thu Mar 25 18:25:58 UTC 2010
Responsible-Changed-Why:
Grab.
http://www.freebsd.org/cgi/query-pr.cgi?pr=145036
------------------------------
Message: 14
Date: Thu, 25 Mar 2010 16:12:53 -0300
From: Adailton Milhorini <milh...@hardonline.com.br>
Subject: Fwd: dummynet error in last stable version
To: freeb...@FreeBSD.org, ri...@iet.unipi.it
Message-ID: <4BABB5B5...@hardonline.com.br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
i use this rules for my bandwidth control, and after update my freebsd
in last days, show any error for me..
my rule
# ipfw pipe 10 config mask dst-ip 0xffffffff bw 900Kbit/s queue 90Kbit/s
errors in dmesg after rule
#Bump sched buckets to 64 (was 0)
and after traffic show
#dummynet_io dropped by enqueue
these rules were used up last week..
Adailton Milhorini
------------------------------
Message: 15
Date: Thu, 25 Mar 2010 23:40:05 GMT
From: dfi...@FreeBSD.ORG (dfilter service)
Subject: Re: kern/118238: commit references a PR
To: freeb...@FreeBSD.org
Message-ID: <201003252340....@freefall.freebsd.org>
The following reply was made to PR kern/118238; it has been noted by GNATS.
From: dfi...@FreeBSD.ORG (dfilter service)
To: bug-fo...@FreeBSD.org
Cc:
Subject: Re: kern/118238: commit references a PR
Date: Thu, 25 Mar 2010 23:38:29 +0000 (UTC)
Author: sobomax
Date: Thu Mar 25 23:38:10 2010
New Revision: 205657
URL: http://svn.freebsd.org/changeset/base/205657
Log:
MFC: workaround no-carrier issue on IBM HS21.
PR: 118238
Modified:
stable/8/sys/dev/mii/brgphy.c
Directory Properties:
stable/8/sys/dev/mii/ (props changed)
Modified: stable/8/sys/dev/mii/brgphy.c
==============================================================================
--- stable/8/sys/dev/mii/brgphy.c Thu Mar 25 22:41:01 2010 (r205656)
+++ stable/8/sys/dev/mii/brgphy.c Thu Mar 25 23:38:10 2010 (r205657)
@@ -72,8 +72,9 @@ struct brgphy_softc {
int mii_model;
int mii_rev;
int serdes_flags; /* Keeps track of the serdes type used */
-#define BRGPHY_5706S 0x0001
-#define BRGPHY_5708S 0x0002
+#define BRGPHY_5706S 0x0001
+#define BRGPHY_5708S 0x0002
+#define BRGPHY_NOANWAIT 0x0004
int bce_phy_flags; /* PHY flags transferred from the MAC driver */
};
@@ -142,6 +143,23 @@ static const struct mii_phydesc brgphys[
MII_PHY_END
};
+#define HS21_PRODUCT_ID "IBM eServer BladeCenter HS21"
+#define HS21_BCM_CHIPID 0x57081021
+
+static int
+detect_hs21(struct bce_softc *bce_sc)
+{
+ char *sysenv;
+
+ if (bce_sc->bce_chipid != HS21_BCM_CHIPID)
+ return (0);
+ sysenv = getenv("smbios.system.product");
+ if (sysenv == NULL)
+ return (0);
+ if (strncmp(sysenv, HS21_PRODUCT_ID, strlen(HS21_PRODUCT_ID)) != 0)
+ return (0);
+ return (1);
+}
/* Search for our PHY in the list of known PHYs */
static int
@@ -291,6 +309,19 @@ brgphy_attach(device_t dev)
if (bce_sc && (bce_sc->bce_phy_flags & BCE_PHY_2_5G_CAPABLE_FLAG)) {
ADD(IFM_MAKEWORD(IFM_ETHER, IFM_2500_SX, IFM_FDX, sc->mii_inst), 0);
printf("2500baseSX-FDX, ");
+ } else if ((bsc->serdes_flags & BRGPHY_5708S) && bce_sc &&
+ (detect_hs21(bce_sc) != 0)) {
+ /*
+ * There appears to be certain silicon revision
+ * in IBM HS21 blades that is having issues with
+ * this driver wating for the auto-negotiation to
+ * complete. This happens with a specific chip id
+ * only and when the 1000baseSX-FDX is the only
+ * mode. Workaround this issue since it's unlikely
+ * to be ever addressed.
+ */
+ printf("auto-neg workaround, ");
+ bsc->serdes_flags |= BRGPHY_NOANWAIT;
}
}
@@ -544,7 +575,8 @@ brgphy_status(struct mii_softc *sc)
/* Autoneg is still in progress. */
if ((bmcr & BRGPHY_BMCR_AUTOEN) &&
- (bmsr & BRGPHY_BMSR_ACOMP) == 0) {
+ (bmsr & BRGPHY_BMSR_ACOMP) == 0 &&
+ (bsc->serdes_flags & BRGPHY_NOANWAIT) == 0) {
/* Erg, still trying, I guess... */
mii->mii_media_active |= IFM_NONE;
goto brgphy_status_exit;
_______________________________________________
svn-s...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all...@freebsd.org"
------------------------------
Message: 16
Date: Fri, 26 Mar 2010 00:10:04 GMT
From: dfi...@FreeBSD.ORG (dfilter service)
Subject: Re: kern/118238: commit references a PR
To: freeb...@FreeBSD.org
Message-ID: <201003260010....@freefall.freebsd.org>
The following reply was made to PR kern/118238; it has been noted by GNATS.
From: dfi...@FreeBSD.ORG (dfilter service)
To: bug-fo...@FreeBSD.org
Cc:
Subject: Re: kern/118238: commit references a PR
Date: Fri, 26 Mar 2010 00:05:54 +0000 (UTC)
Author: sobomax
Date: Fri Mar 26 00:05:42 2010
New Revision: 205658
URL: http://svn.freebsd.org/changeset/base/205658
Log:
MFC: workaround no-carrier issue on IBM HS21.
PR: 118238
Modified:
stable/7/sys/dev/mii/brgphy.c
Directory Properties:
stable/7/sys/dev/mii/ (props changed)
Modified: stable/7/sys/dev/mii/brgphy.c
==============================================================================
--- stable/7/sys/dev/mii/brgphy.c Thu Mar 25 23:38:10 2010 (r205657)
+++ stable/7/sys/dev/mii/brgphy.c Fri Mar 26 00:05:42 2010 (r205658)
@@ -72,8 +72,9 @@ struct brgphy_softc {
int mii_model;
int mii_rev;
int serdes_flags; /* Keeps track of the serdes type used */
-#define BRGPHY_5706S 0x0001
-#define BRGPHY_5708S 0x0002
+#define BRGPHY_5706S 0x0001
+#define BRGPHY_5708S 0x0002
+#define BRGPHY_NOANWAIT 0x0004
int bce_phy_flags; /* PHY flags transferred from the MAC driver */
};
@@ -142,6 +143,23 @@ static const struct mii_phydesc brgphys[
MII_PHY_END
};
+#define HS21_PRODUCT_ID "IBM eServer BladeCenter HS21"
+#define HS21_BCM_CHIPID 0x57081021
+
+static int
+detect_hs21(struct bce_softc *bce_sc)
+{
+ char *sysenv;
+
+ if (bce_sc->bce_chipid != HS21_BCM_CHIPID)
+ return (0);
+ sysenv = getenv("smbios.system.product");
+ if (sysenv == NULL)
+ return (0);
+ if (strncmp(sysenv, HS21_PRODUCT_ID, strlen(HS21_PRODUCT_ID)) != 0)
+ return (0);
+ return (1);
+}
/* Search for our PHY in the list of known PHYs */
static int
@@ -291,6 +309,19 @@ brgphy_attach(device_t dev)
if (bce_sc && (bce_sc->bce_phy_flags & BCE_PHY_2_5G_CAPABLE_FLAG)) {
ADD(IFM_MAKEWORD(IFM_ETHER, IFM_2500_SX, IFM_FDX, sc->mii_inst), 0);
printf("2500baseSX-FDX, ");
+ } else if ((bsc->serdes_flags & BRGPHY_5708S) && bce_sc &&
+ (detect_hs21(bce_sc) != 0)) {
+ /*
+ * There appears to be certain silicon revision
+ * in IBM HS21 blades that is having issues with
+ * this driver wating for the auto-negotiation to
+ * complete. This happens with a specific chip id
+ * only and when the 1000baseSX-FDX is the only
+ * mode. Workaround this issue since it's unlikely
+ * to be ever addressed.
+ */
+ printf("auto-neg workaround, ");
+ bsc->serdes_flags |= BRGPHY_NOANWAIT;
}
}
@@ -532,7 +563,8 @@ brgphy_status(struct mii_softc *sc)
/* Autoneg is still in progress. */
if ((bmcr & BRGPHY_BMCR_AUTOEN) &&
- (bmsr & BRGPHY_BMSR_ACOMP) == 0) {
+ (bmsr & BRGPHY_BMSR_ACOMP) == 0 &&
+ (bsc->serdes_flags & BRGPHY_NOANWAIT) == 0) {
/* Erg, still trying, I guess... */
mii->mii_media_active |= IFM_NONE;
goto brgphy_status_exit;
_______________________________________________
svn-s...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all...@freebsd.org"
------------------------------
Message: 17
Date: Fri, 26 Mar 2010 07:58:15 +0300
From: Alexander Bubnov <alexande...@gmail.com>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Harti Brandt <ha...@freebsd.org>
Cc: freeb...@freebsd.org
Message-ID:
<c3e287ff1003252158h7b4...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello Harti and freebsd-net maillist!
One more question please in scope of snmp topic. does bsnmp support master
agentx mode?
2010/3/25 Harti Brandt <hartmut...@dlr.de>
> On Thu, 25 Mar 2010, Vasyl Samoilov wrote:
>
> VS>So far I found two options for snmp daemon - bsnmp and net-snmp.
> net-snmo
> VS>giving back invalid data, bsnmp lacks some data at all.
>
> Just two general remarks:
>
> - net-snmp is probably developed on Linux so it doesn't know how to
> access many of the informations that is available in FreeBSD.
>
> - bsnmp is lacking developers (I'm the only one). I had a surgery in
> november and took the 4 weeks after this to rewrite all the networking
> stuff. It is in principle mostly up to date and supports also IPv6. The
> problem is that I run out of time again and just cannot do the last steps
> to release it (including testing). If there were people interested in it,
> I would happily work with them.
>
> harti
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>
--
/BR, Alexander
------------------------------
Message: 18
Date: Fri, 26 Mar 2010 08:25:37 +0300
From: Alexander Bubnov <alexande...@gmail.com>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Harti Brandt <ha...@freebsd.org>
Cc: freeb...@freebsd.org
Message-ID:
<c3e287ff1003252225g8a...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
2010/3/25 Harti Brandt <hartmut...@dlr.de>
> On Thu, 25 Mar 2010, Vasyl Samoilov wrote:
>
> VS>So far I found two options for snmp daemon - bsnmp and net-snmp.
> net-snmo
> VS>giving back invalid data, bsnmp lacks some data at all.
>
> Just two general remarks:
>
> - net-snmp is probably developed on Linux so it doesn't know how to
> access many of the informations that is available in FreeBSD.
>
> - bsnmp is lacking developers (I'm the only one). I had a surgery in
> november and took the 4 weeks after this to rewrite all the networking
> stuff. It is in principle mostly up to date and supports also IPv6. The
> problem is that I run out of time again and just cannot do the last steps
> to release it (including testing). If there were people interested in it,
> I would happily work with them.
>
> harti
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>
Hi Harti!
I am sorry may be I am going to ask often asked question... Why not to
implement features which is lacking in net-snmp for FreeBSD instead of
writing new snmp (bsnmp)? As a plus net-snmp has BSD like license.
--
/BR, Alexander
------------------------------
Message: 19
Date: Fri, 26 Mar 2010 08:10:33 +0100 (CET)
From: Harti Brandt <hartmut...@dlr.de>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Shteryana Shopova <shte...@gmail.com>
Cc: freeb...@freebsd.org, Ivan Voras <ivo...@freebsd.org>
Message-ID: <2010032608...@beagle.kn.op.dlr.de>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
On Thu, 25 Mar 2010, Shteryana Shopova wrote:
SS>On Thu, Mar 25, 2010 at 1:33 PM, Harti Brandt <hartmut...@dlr.de> wrote:
SS>> On Thu, 25 Mar 2010, Vasyl Samoilov wrote:
SS>>
SS>>
SS>> - bsnmp is lacking developers (I'm the only one). I had a surgery in
SS>+ 1 (count me in that is)
SS>> november and took the 4 weeks after this to rewrite all the networking
SS>> stuff. It is in principle mostly up to date and supports also IPv6. The
SS>> problem is that I run out of time again and just cannot do the last steps
SS>> to release it (including testing). If there were people interested in it,
SS>> I would happily work with them.
SS>>
SS>> harti
SS>>
SS>sorry to hear about the surgery - I've recently resumed somewhat
SS>active work on bsnmp and modules, so if you can upload your work to an
SS>accessible repository, say svn.freebsd.org/user/harti I can take on
SS>testing and preparing the code for import. btw, I was contacted some
SS>time ago by Carlos Santos suggesting a set of patches adding IPV6
SS>transport, unfortunatelly he hasn't replied to any of my last e-mails,
SS>is this the same patchset we're talking about or a different one?
No this is different code. I guess, I should really put it on
svn.freebsd.org. I do this in the next days...
SS>P.S. Back to the thread topic - so the only problem the author is
SS>facing with bsnmp is that it lacks support for LLDP, do I understand
SS>correctly?
This is what I understood too.
harti
------------------------------
Message: 20
Date: Fri, 26 Mar 2010 08:16:18 +0100 (CET)
From: Harti Brandt <hartmut...@dlr.de>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Alexander Bubnov <alexande...@gmail.com>
Cc: freeb...@freebsd.org, Harti Brandt <ha...@freebsd.org>
Message-ID: <2010032608...@beagle.kn.op.dlr.de>
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
On Fri, 26 Mar 2010, Alexander Bubnov wrote:
AB>One more question please in scope of snmp topic. does bsnmp support master
AB>agentx mode?
No. I read through the documents and decided that I would not have time to
implement this. I often use external agents in projects, but usually use
custom protocols or shared memory with them.
harti
------------------------------
Message: 21
Date: Fri, 26 Mar 2010 08:20:02 +0100 (CET)
From: Hartmut Brandt <hartmut...@dlr.de>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Alexander Bubnov <alexande...@gmail.com>
Cc: freeb...@freebsd.org, Harti Brandt <ha...@freebsd.org>
Message-ID: <2010032608...@beagle.kn.op.dlr.de>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 26 Mar 2010, Alexander Bubnov wrote:
AB>I am sorry may be I am going to ask often asked question... Why not to
AB>implement features which is lacking in net-snmp for FreeBSD instead of
AB>writing new snmp (bsnmp)? As a plus net-snmp has BSD like license.
Many years ago I needed a small SNMP daemon for controlling some
equipment. I looked at ucd-snmp (that was the name than) but decided
against it because it was far too big. The even bigger problem was, that
it didn't care about handling errors in the places I looked at. I use
bsnmp alot in projects to do remote monitoring controlling of equipment -
you don't need SNMPv3 for them and it is easy to write a new MIB for
bsnmp.
harti
------------------------------
Message: 22
Date: Fri, 26 Mar 2010 11:18:32 +0300
From: Alexander Bubnov <alexande...@gmail.com>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Hartmut Brandt <hartmut...@dlr.de>
Cc: freeb...@freebsd.org, Harti Brandt <ha...@freebsd.org>
Message-ID:
<c3e287ff1003260118qec...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Thanks a lot for your answers.
2010/3/26 Hartmut Brandt <hartmut...@dlr.de>
> On Fri, 26 Mar 2010, Alexander Bubnov wrote:
>
> AB>I am sorry may be I am going to ask often asked question... Why not to
> AB>implement features which is lacking in net-snmp for FreeBSD instead of
> AB>writing new snmp (bsnmp)? As a plus net-snmp has BSD like license.
>
> Many years ago I needed a small SNMP daemon for controlling some
> equipment. I looked at ucd-snmp (that was the name than) but decided
> against it because it was far too big. The even bigger problem was, that
> it didn't care about handling errors in the places I looked at. I use
> bsnmp alot in projects to do remote monitoring controlling of equipment -
> you don't need SNMPv3 for them and it is easy to write a new MIB for
> bsnmp.
>
> harti
>
--
/BR, Alexander
------------------------------
Message: 23
Date: Fri, 26 Mar 2010 10:27:31 +0200
From: Vasily Samoylov <ma...@vas.org.ua>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Harti Brandt <ha...@freebsd.org>
Cc: freeb...@freebsd.org, Harti Brandt <hartmut...@dlr.de>,
Shteryana Shopova <shte...@gmail.com>, Ivan Voras
<ivo...@freebsd.org>
Message-ID: <4BAC6FF3...@vas.org.ua>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 26.03.2010 9:10, Harti Brandt wrote:
> SS>P.S. Back to the thread topic - so the only problem the author is
> SS>facing with bsnmp is that it lacks support for LLDP, do I understand
> SS>correctly?
>
> This is what I understood too.
>
> harti
>
I, probably, was to verbose, and didn't make myself clear enough. For
now, from network admin point of view, it's 3 problems:
1) No ARP support
2) Routing table not exported correctly (directly attached routes not
visible, maybe something else - at least it's nothing like netstat -rn
gives)
3) No LLDP support
------------------------------
Message: 24
Date: Fri, 26 Mar 2010 10:01:53 +0100 (CET)
From: Hartmut Brandt <hartmut...@dlr.de>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Vasily Samoylov <ma...@vas.org.ua>
Cc: freeb...@freebsd.org, Shteryana Shopova <shte...@gmail.com>,
Harti Brandt <ha...@freebsd.org>, Ivan Voras <ivo...@freebsd.org>
Message-ID: <2010032609...@beagle.kn.op.dlr.de>
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 26 Mar 2010, Vasily Samoylov wrote:
VS>On 26.03.2010 9:10, Harti Brandt wrote:
VS>> SS>P.S. Back to the thread topic - so the only problem the author is
VS>> SS>facing with bsnmp is that it lacks support for LLDP, do I understand
VS>> SS>correctly?
VS>>
VS>> This is what I understood too.
VS>>
VS>> harti
VS>>
VS>I, probably, was to verbose, and didn't make myself clear enough. For now,
VS>from network admin point of view, it's 3 problems:
VS>1) No ARP support
The ARP table should be there. It may be that it got 'lost' with the ARP
changes last year. So this should be fixable. The ARP table is the old
one, though.
VS>2) Routing table not exported correctly (directly attached routes not
VS>visible, maybe something else - at least it's nothing like netstat -rn gives)
This may be the same problem. The routing table code just fetches the
routing table from the kernel. If the directly attached routes are not in
the routing table anymore, they will not show up.
3) No LLDP support
Until two days ago I was not even aware what LLDP is :-)
harti
------------------------------
Message: 25
Date: Fri, 26 Mar 2010 11:31:54 +0200
From: Vasily Samoylov <ma...@vas.org.ua>
Subject: Re: Poor situation with snmp support in FreeBSD
To: Hartmut Brandt <hartmut...@dlr.de>
Cc: freeb...@freebsd.org, Shteryana Shopova <shte...@gmail.com>,
Harti Brandt <ha...@freebsd.org>, Ivan Voras <ivo...@freebsd.org>
Message-ID: <4BAC7F0A...@vas.org.ua>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 26.03.2010 11:01, Hartmut Brandt wrote:
> VS>I, probably, was to verbose, and didn't make myself clear enough. For now,
> VS>from network admin point of view, it's 3 problems:
> VS>1) No ARP support
>
> The ARP table should be there. It may be that it got 'lost' with the ARP
> changes last year. So this should be fixable. The ARP table is the old
> one, though.
>
I was looking for something like ipNetToPhysicalTable (ipv6 compatible)
or ipNetToMedia (depreciated, ip4 only) - both are not there. A bug, I
suppose.
net-snmp under freebsd got ipNetToMedia.
If there is anything I can do to help with testing new bsnmpd or patches
- I am ready. :)
> VS>2) Routing table not exported correctly (directly attached routes not
> VS>visible, maybe something else - at least it's nothing like netstat -rn gives)
>
> This may be the same problem. The routing table code just fetches the
> routing table from the kernel. If the directly attached routes are not in
> the routing table anymore, they will not show up.
>
Routes are in the routing table. netstat -rn show everything correctly,
and, againg, net-snmp ipCidrRoute contains all routes, but consider all
them "local". bsnmp, in the other hand, got only some of the routes.
This is obviously a bug and should be fixed.
> 3) No LLDP support
>
> Until two days ago I was not even aware what LLDP is :-)
>
You never what that is link-layer discovery protocol until it comes to
large network and you need to automate link discovery and build a
topology. LLDP daemon by itself is good, but there must be a way to
query it by snmp - otherwise it is useless. So far the best lldp daemon
for bsd systems is ladvd, link advertising daemon, but bsnmp got no
means of reading info from it, so I'm kinda stuck here.
http://www.blinkenlights.nl/software/ladvd/
ladvd uses cdp / lldp frames to inform switches about connected hosts,
which simplifies ethernet switch management. It does this by creating
a raw socket at startup, and then switching to a non-privileged user for the
remaining runtime. Every 30 seconds it will transmit CDP/LLDP packets
reflecting the current system state. Interfaces (bridge, bonding, wireless),
capabilities (bridging, forwarding, wireless) and addresses (IPv4, IPv6)
are detected dynamically.
> harti
> _______________________________________________
> freeb...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net...@freebsd.org"
>
------------------------------
Message: 26
Date: Fri, 26 Mar 2010 11:08:26 +0100
From: Giulio Ferro <au...@zirakzigil.org>
Subject: NFS lockd problem
To: "freeb...@freebsd.org" <freeb...@freebsd.org>,
freebsd...@freebsd.org
Message-ID: <4BAC879A...@zirakzigil.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Outset:
1 NFS server (with lockd)
2 NFS client (with lockd)
The clients serve several jails with apache, whose data (www) resides on
the server
From time to time everything seem to freeze. Then, after one minute or
so, the system
works again as nothing had happened.
In these occasions I get this in the logs on the client madchines:
Mar 26 10:29:38 virt1 kernel: nfs server
192.168.40.121:/data/mount_servers/wwwsec/www: lockd not responding
followed shortly after by:
Mar 26 10:29:38 virt1 kernel: nfs server
192.168.40.121:/data/mount_servers/wwwsec/www: lockd is alive again
On the server I only get this:
Mar 26 10:29:31 data1 kernel: NLM: failed to contact remote rpcbind,
stat = 5, port = 28416
I don't think it's a network problem, since all connections are local
and high speed (1Gb/s)
I must admit that, with the other nfs problem I reported weeks ago, this
kind of freebsd system seems
less than stable to me, and this is very disappointing...
Anyway I'd appreciate any pointer on this issue...
------------------------------
End of freebsd-net Digest, Vol 364, Issue 5
*******************************************