С този пач - http://people.freebsd.org/~syrinx/snmp/bsnmpbulkwalk-20110308-01.diff - bsnmpwalk(1) във FreeBSD вече може да прави BulkWalks, т.е. да обхожда MIB променливи/таблици с Requests от вида "Дай ми следващите 90 обекта след този" вместо с "Дай ми следващия обект след този", например по следния начин -


#bsnmpwalk -p getbulk -M 90 -v 2 -s public@


Определено работи по-добре но при големи заявки за над 95 обекта агентът се чупи


> sudo /usr/sbin/bsnmpd -d -c /etc/snmpd.config
snmpd[36702]: stack overflow detected; terminated
> sudo gdb bsnmpd
...
Program received signal SIGABRT, Aborted.
0x281cfb27 in kill () from /lib/libc.so.7
(gdb) bt
#0 0x281cfb27 in kill () from /lib/libc.so.7
#1 0x28106f6c in __stack_chk_fail_local () from /lib/libc.so.7
#2 0x0804f7a1 in snmp_input_finish (pdu=Variable "pdu" is not available.
)
at /usr/compat/linux/home/shteryana/bsnmp_usm/usr.sbin/bsnmpd/bsnmpd/../../../contrib/bsnmp/snmpd/main.c:759
#3 0x00000001 in ?? ()
...

Вторият пач, който чака в опашката от декември месец е за "коректна" работа със connected UDP sockets - http://people.freebsd.org/~syrinx/snmp/bsnmp-20101220-03.diff .
Така се решава проблемът с едни неприятни логове

snmpd[29955]: send: Connection refused

когато агента се опитва да прати трап, но от другата страна на UDP сокета не слуша никой. Но пък се появи нов проблем, който впрочем погрешка е вече в SVN - linkUp траповете се изпращат преди coldStart.

И двата фикса ще трябва да се доизтестват и изчистят преди да заминат в SVN, но няма лошо да са в нет-а.

This blog has been moved back here due to the fact that shteryana.org domain has expired and Shteryana thinks it's not worth paying the money to keep it. If you dear reader feel otherwise - feel free to pay for it and donate it back to me... ;)
What I've been up to lately... Google Summer of Code (TM) is on again and of course I'm in again. :)) This year for a change I'll be the one reviewing the code produced not writing it. I am mentoring Constantine A. Murenin and his Unified Hardware Monitoring Interface for FreeBSD project. So far we have agreed to track the project's progress via cnst@'s blog - http://cnst.livejournal.com . Which means I need to figure out a "quick'n'easy" way to update / upgrade my Russian ;) Suggestions welcome.

This blog has been moved to http://blog.shteryana.org.

http://people.freebsd.org/~julian/layer2b.pdf
http://www.freebsd.org/~julian/layer2-current.pdf

Julian Elischer's comment:

I'm looking at what we can do to simplify this..
it's a mess.. Personally (I am biased of course) we could have
imlemented almost everything
outside of basic processing as netgraph modules.

firewall, divert, bridging, vlans, CARP, flow control.
these could have all been implemented as graph nodes..
well, too late for that.

There are problems for example I'd rather that the if_bridge code didn't
call
the driver queue directly on output but passed it to the driver by
calling ether_output_frame()
and I'm not sure that the ipfw hook on output shouldn't be in
ether_output() instead
of in ether_output_frame().

I do think the output hook of netgraph should be above the bridging hook.
If you are using netgraph you probably will use netgraph bridging as
well but
if you are using bridging that doesn't mean you don't want to do
something with netgraph..

It's a bit of a problem actually. The order of calling these things
almost wants to be adjustable because
different people seem to want to call them in different orders.

ftp://ftp.rfc-editor.org/in-notes/rfc4188.txt

Пристигна чека от Google - ама не Initial Funding, ами тоя големия - Final...Иначе още не са обявили официално одобрените проекти, ама на кой му пука - аз не мога да си намеря мястото от радост

http://people.apache.org/~rbowen/presentations/apacheconEU2005/hate_apache.pdf
No comment
:)