Re: spamd: greyreader failed (Error 2) (was: Re: CVS: cvs.openbsd.org: src)
On 2013-W40-2 16:56 -0600, Todd C. Miller wrote: > On Mon, 30 Sep 2013 19:26:20 -0700, "Constantine A. Murenin" wrote: > > > Whereas it remains to be seen what kind of bug I'm facing here > > (Google reveals I'm not alone), it would appear that changes > > introduced in 5.4-current would no longer cause spamd to report > > such situation, because the 0 that would still be returned at the > > end of greyreader() would no longer cause greywatcher() to produce > > the error message that I have received (it'll still quit, though). > > Yes, that was an unrelated change that snuck in there. Personally, > I've only seen that error on shutdown, where it is spurious. If > you are getting a read error on the pipe it must mean that the spamd > on the other end died. Yes, I gather that's what it means -- the other end of the pipe is gone. However, there were no other messages reported. In my case, it was definitely not a shutdown-related error -- the system was not rebooted at that time, nor were any mail-related settings modified or any services restarted. I think it would make sense for this part to be reverted and for the error message to be brought back; otherwise, there'd pretty much not even be a record of when spamd actually stops working here. C.
Re: spamd: greyreader failed (Error 2) (was: Re: CVS: cvs.openbsd.org: src)
On Mon, 30 Sep 2013 19:26:20 -0700, "Constantine A. Murenin" wrote: > Whereas it remains to be seen what kind of bug I'm facing here > (Google reveals I'm not alone), it would appear that changes > introduced in 5.4-current would no longer cause spamd to report > such situation, because the 0 that would still be returned at the > end of greyreader() would no longer cause greywatcher() to produce > the error message that I have received (it'll still quit, though). Yes, that was an unrelated change that snuck in there. Personally, I've only seen that error on shutdown, where it is spurious. If you are getting a read error on the pipe it must mean that the spamd on the other end died. - todd
fix snmpd(8) bulk support
Hi,
some time ago, martinh@ fixed the PRs 6468 and 6071 in snmpd.
Unfortunately, that broke GETBULK support and nobody noticed.
GETBULK calls mps_getnextreq() multiple times and relies on the
incremented/updated OID in "o". Without this diff, non-table OIDs
were not incremented and returned multiple times in a single GETBULK
response.
I also tested the bug reports from the old PRs and this diff does not
reintroduce their bugs.
OK?
Reyk
Index: mps.c
===
RCS file: /cvs/src/usr.sbin/snmpd/mps.c,v
retrieving revision 1.17
diff -u -p -u -p -r1.17 mps.c
--- mps.c 1 Oct 2012 11:36:55 - 1.17
+++ mps.c 1 Oct 2013 20:51:47 -
@@ -210,16 +210,11 @@ mps_getnextreq(struct ber_element *root,
break;
}
} else if (o->bo_n == value->o_oidlen && value->o_get != NULL) {
- /* No instance identifier specified. Append .0. */
- if (o->bo_n + 1 > BER_MAX_OID_LEN)
- return (NULL);
- ber = ber_add_noid(ber, o, o->bo_n + 1);
- if ((ret = value->o_get(value, o, &ber)) != 0)
- return (NULL);
- return (ber);
+ next = value;
+ goto appendzero;
}
-getnext:
+ getnext:
for (next = value; next != NULL;) {
next = smi_next(next);
if (next == NULL)
@@ -246,8 +241,11 @@ getnext:
}
} else {
bcopy(&next->o_id, o, sizeof(*o));
- ber = ber_add_noid(ber, &next->o_id,
- next->o_oidlen + 1);
+ appendzero:
+ /* No instance identifier specified. Append .0. */
+ if (o->bo_n + 1 > BER_MAX_OID_LEN)
+ return (NULL);
+ ber = ber_add_noid(ber, o, ++o->bo_n);
if ((ret = next->o_get(next, o, &ber)) != 0)
return (NULL);
}
re(4) diff that needs testing
Some re(4) variants now use msi. Unfortunately the interrupt handler isn't careful enough, and we might miss an interrupt. The diff below seems to fix that by disabling the interrupts while processing an interrupt. This is what FreeBSD & Linux seem to do. Needs testing on a wide variety of re(4), especially on thoe that don't use msi yet. Index: re.c === RCS file: /cvs/src/sys/dev/ic/re.c,v retrieving revision 1.143 diff -u -p -r1.143 re.c --- re.c7 Aug 2013 01:06:30 - 1.143 +++ re.c21 Aug 2013 19:50:39 - @@ -1650,6 +1650,9 @@ re_intr(void *arg) if (!(ifp->if_flags & IFF_RUNNING)) return (0); + /* Disable interrupts. */ + CSR_WRITE_2(sc, RL_IMR, 0); + rx = tx = 0; status = CSR_READ_2(sc, RL_ISR); /* If the card has gone away the read returns 0x. */ @@ -1715,6 +1718,8 @@ re_intr(void *arg) if (tx && !IFQ_IS_EMPTY(&ifp->if_snd)) re_start(ifp); + + CSR_WRITE_2(sc, RL_IMR, sc->rl_intrs); return (claimed); }
Re: snmp client (aka "walk")
On 2013/10/01 18:20, Reyk Floeter wrote: > what oid did you specify? snmpctl only displays "oid system" by > default and does not continue, but you can specify the parent or even > "oid 1.3" to display everything. aha - that explains it then, thanks.
Re: snmp client (aka "walk")
On Tue, Oct 01, 2013 at 04:08:48PM +0100, Stuart Henderson wrote: > Most things are working fine for me. > thanks for testing! > v4 and v6 with opensnmpd OK (need two instances of the daemon > to test this as it only opens one socket). > > v4 with net-snmp OK (v6 is possibly a bit broken in the net-snmp > port's snmpd at present). > > v4 and v6 against Zyxel GS1910 (using link-local for v6) OK. > > Only problem I've hit so far is against D-Link DGS-1224T where > snmpctl only prints the system oids, whereas net-snmp snmpwalk goes > on to walk IF-MIB, TCP-MIB, UDP-MIB. > what oid did you specify? snmpctl only displays "oid system" by default and does not continue, but you can specify the parent or even "oid 1.3" to display everything. > system.sysDescr.0="DGS-1224T4.21.02" > system.sysOID.0=iso.org.dod.internet.private.enterprises.171.10.76.5 > system.sysUpTime.0=337019590 > system.sysContact.0="" > system.sysName.0="ott-dlink-gig24" > system.sysLocation.0="the attic" > system.sysServices.0=2 > > > SNMPv2-MIB::sysDescr.0 = STRING: DGS-1224T > 4.21.02 > SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.171.10.76.5 > SNMPv2-MIB::sysUpTime.0 = Timeticks: (337032680) 39 days, 0:12:06.80 > SNMPv2-MIB::sysContact.0 = STRING: > SNMPv2-MIB::sysName.0 = STRING: ott-dlink-gig24 > SNMPv2-MIB::sysLocation.0 = STRING: the attic > SNMPv2-MIB::sysServices.0 = INTEGER: 2 > IF-MIB::ifNumber.0 = INTEGER: 25 > IF-MIB::ifIndex.1 = INTEGER: 1 > IF-MIB::ifIndex.2 = INTEGER: 2 > IF-MIB::ifIndex.3 = INTEGER: 3 > IF-MIB::ifIndex.4 = INTEGER: 4 > ... > > > 15:57:48.845525 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] > |30|30|02|01|04|0fC=XXX > |a1|1aGetNextRequest(26)|02|04|02|01|02|01|30|0c > |30|0a|06|06.1.3.6.1.2.1.1|05|00 (ttl 64, id 50398, len 78) > 15:57:48.848682 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] > |30|82|00|66|02|01|04|0fC=XXX > |a2|82|00|4eGetResponse(78)|02|04|02|01|02|01|30|82|00|3e > |30|3c|06|08.1.3.6.1.2.1.1.1.0=|04|30"DGS-1224T > 4.21.02" (DF) (ttl 254, id 65014, len 134) > 15:57:48.848956 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] > |30|32|02|01|04|0fC=XXX > |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e > |30|0c|06|08.1.3.6.1.2.1.1.1.0|05|00 (ttl 64, id 49660, len 80) > 15:57:48.851836 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] > |30|82|00|40|02|01|04|0fC=XXX > |a2|82|00|28GetResponse(40)|02|04|02|01|02|01|30|82|00|18 > |30|16|06|08.1.3.6.1.2.1.1.2.0=|06|0a.1.3.6.1.4.1.171.10.76.5 (DF) (ttl 254, > id 65015, len 96) > 15:57:48.851979 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] > |30|32|02|01|04|0fC=XXX > |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e > |30|0c|06|08.1.3.6.1.2.1.1.2.0|05|00 (ttl 64, id 61889, len 80) > 15:57:48.854907 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] > |30|82|00|3a|02|01|04|0fC=XXX > |a2|82|00|22GetResponse(34)|02|04|02|01|02|01|30|82|00|12 > |30|10|06|08.1.3.6.1.2.1.1.3.0=|43|04336972620 (DF) (ttl 254, id 65016, len > 90) > 15:57:48.855016 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] > |30|32|02|01|04|0fC=XXX > |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e > |30|0c|06|08.1.3.6.1.2.1.1.3.0|05|00 (ttl 64, id 30100, len 80) > 15:57:48.857873 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] > |30|82|00|36|02|01|04|0fC=XXX > |a2|82|00|1eGetResponse(30)|02|04|02|01|02|01|30|82|00|0e > |30|0c|06|08.1.3.6.1.2.1.1.4.0=|04|00"" (DF) (ttl 254, id 65017, len 86) > 15:57:48.857983 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] > |30|32|02|01|04|0fC=XXX > |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e > |30|0c|06|08.1.3.6.1.2.1.1.4.0|05|00 (ttl 64, id 5047, len 80) > 15:57:48.860909 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] > |30|82|00|45|02|01|04|0fC=XXX > |a2|82|00|2dGetResponse(45)|02|04|02|01|02|01|30|82|00|1d > |30|1b|06|08.1.3.6.1.2.1.1.5.0=|04|0f"ott-dlink-gig24" (DF) (ttl 254, id > 65018, len 101) > 15:57:48.861018 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] > |30|32|02|01|04|0fC=XXX > |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e > |30|0c|06|08.1.3.6.1.2.1.1.5.0|05|00 (ttl 64, id 25590, len 80) > 15:57:48.863971 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] > |30|82|00|3f|02|01|04|0fC=XXX > |a2|82|00|27GetResponse(39)|02|04|02|01|02|01|30|82|00|17 > |30|15|06|08.1.3.6.1.2.1.1.6.0=|04|09"the attic" (DF) (ttl 254, id 65019, len > 95) > 15:57:48.864032 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] > |30|32|02|01|04|0fC=XXX > |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e > |30|0c|06|08.1.3.6.1.2.1.1.6.0|05|00 (ttl 64, id 19230, len 80) > 15:57:48.866926 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] > |30|82|00|37|02|01|04|0fC=XXX > |a2|82|00|1fGetResponse(31)|02|04|02|01|02|01|30
Re: Multicast macros and global list of addresses
On Tue, Oct 1, 2013 at 3:33 PM, Martin Pieuchot wrote:
> On 19/09/13(Thu) 13:59, Martin Pieuchot wrote:
>> Diff below change the macros used to iterate over the multicast
>> records linked to an interface without using the global lists of
>> addresses.
>>
>> These records are currently link to the first address descriptor,
>> respectively v4 and v6, even if they are per-interface. So I
>> changed the code to loop over the global interface list instead
>> of iterating over all existing addresses.
>>
>> Tested here with a carp setup. Comments, ok?
What kind of test coverage are you looking for specifically ?
>
> I got one ok for this diff but no other feedback.
>
> Did somebody tried it on a different setup? I would really help me to
> get this in to move forward, so I appreciate any tests, reviews or ok.
>
>> Index: netinet/igmp.c
>> ===
>> RCS file: /home/ncvs/src/sys/netinet/igmp.c,v
>> retrieving revision 1.33
>> diff -u -p -r1.33 igmp.c
>> --- netinet/igmp.c2 May 2013 11:54:10 - 1.33
>> +++ netinet/igmp.c13 Sep 2013 09:07:42 -
>> @@ -104,6 +104,7 @@ int igmp_timers_are_running;
>> static struct router_info *rti_head;
>> struct igmpstat igmpstat;
>>
>> +void igmp_checktimer(struct ifnet *);
>> void igmp_sendpkt(struct in_multi *, int, in_addr_t);
>> int rti_fill(struct in_multi *);
>> struct router_info * rti_find(struct ifnet *);
>> @@ -193,7 +194,6 @@ igmp_input(struct mbuf *m, ...)
>> int igmplen;
>> int minlen;
>> struct in_multi *inm;
>> - struct in_multistep step;
>> struct router_info *rti;
>> struct in_ifaddr *ia;
>> int timer;
>> @@ -266,17 +266,14 @@ igmp_input(struct mbuf *m, ...)
>>* except those that are already running and those
>>* that belong to a "local" group (224.0.0.X).
>>*/
>> - IN_FIRST_MULTI(step, inm);
>> - while (inm != NULL) {
>> - if (inm->inm_ia->ia_ifp == ifp &&
>> - inm->inm_timer == 0 &&
>> + IN_FOREACH_MULTI(ia, ifp, inm) {
>> + if (inm->inm_timer == 0 &&
>> !IN_LOCAL_GROUP(inm->inm_addr.s_addr)) {
>> inm->inm_state = IGMP_DELAYING_MEMBER;
>> inm->inm_timer = IGMP_RANDOM_DELAY(
>> IGMP_MAX_HOST_REPORT_DELAY *
>> PR_FASTHZ);
>> igmp_timers_are_running = 1;
>> }
>> - IN_NEXT_MULTI(step, inm);
>> }
>> } else {
>> if (!IN_MULTICAST(ip->ip_dst.s_addr)) {
>> @@ -297,10 +294,8 @@ igmp_input(struct mbuf *m, ...)
>>* timers already running, check if they need to be
>>* reset.
>>*/
>> - IN_FIRST_MULTI(step, inm);
>> - while (inm != NULL) {
>> - if (inm->inm_ia->ia_ifp == ifp &&
>> - !IN_LOCAL_GROUP(inm->inm_addr.s_addr) &&
>> + IN_FOREACH_MULTI(ia, ifp, inm) {
>> + if (!IN_LOCAL_GROUP(inm->inm_addr.s_addr) &&
>> (ip->ip_dst.s_addr ==
>> INADDR_ALLHOSTS_GROUP ||
>>ip->ip_dst.s_addr ==
>> inm->inm_addr.s_addr)) {
>> switch (inm->inm_state) {
>> @@ -323,7 +318,6 @@ igmp_input(struct mbuf *m, ...)
>> break;
>> }
>> }
>> - IN_NEXT_MULTI(step, inm);
>> }
>> }
>>
>> @@ -505,8 +499,7 @@ igmp_leavegroup(struct in_multi *inm)
>> void
>> igmp_fasttimo(void)
>> {
>> - struct in_multi *inm;
>> - struct in_multistep step;
>> + struct ifnet *ifp;
>> int s;
>>
>> /*
>> @@ -518,8 +511,21 @@ igmp_fasttimo(void)
>>
>> s = splsoftnet();
>> igmp_timers_are_running = 0;
>> - IN_FIRST_MULTI(step, inm);
>> - while (inm != NULL) {
>> + TAILQ_FOREACH(ifp, &ifnet, if_list)
>> + igmp_checktimer(ifp);
>> + splx(s);
>> +}
>> +
>> +
>> +void
>> +igmp_checktimer(struct ifnet *ifp)
>> +{
>> + struct in_multi *inm;
>> + struct in_ifaddr *ia;
>> +
>> + splsoftassert(IPL_SOFTNET);
>> +
>> + IN_FOREACH_MULTI(ia, ifp, inm) {
>> if (inm->inm_timer == 0) {
>> /* do nothing */
>> } else if (--inm->inm_timer == 0) {
>> @@ -535,9 +541,7 @@ igmp_fasttimo(void)
>> } else {
>> igmp_timers_are_runni
Re: snmp client (aka "walk")
On 2013/10/01 16:17, Reyk Floeter wrote: > Hi, > > I just committed a simple SNMP client implementation to snmpctl/snmpd. > You can use it as an in-tree alternative to net-snmp's > snmpwalk/snmpget. > > Examples: > $ snmpctl walk 127.0.0.1 > $ snmpctl walk printer.my.domain version 1 oid printerWorkingGroup > $ snmpctl -n walk 203.0.113.240 oid ifMIB community "blah" > > Limitations: > - no SNMPv3/USM support yet > - no bulk support yet (bulkwalk) > - not so many fancy options. > > snmpd does not support loading of external MIB files, so you have to > use net-snmp if you want to load additional MIBs for the symbolic name > parsing. snmpctl only shows symbolic names there are found in snmpd's > mib.h. > > Testing welcome, especially with non-snmpd(8) agents. > > Reyk > Most things are working fine for me. v4 and v6 with opensnmpd OK (need two instances of the daemon to test this as it only opens one socket). v4 with net-snmp OK (v6 is possibly a bit broken in the net-snmp port's snmpd at present). v4 and v6 against Zyxel GS1910 (using link-local for v6) OK. Only problem I've hit so far is against D-Link DGS-1224T where snmpctl only prints the system oids, whereas net-snmp snmpwalk goes on to walk IF-MIB, TCP-MIB, UDP-MIB. system.sysDescr.0="DGS-1224T4.21.02" system.sysOID.0=iso.org.dod.internet.private.enterprises.171.10.76.5 system.sysUpTime.0=337019590 system.sysContact.0="" system.sysName.0="ott-dlink-gig24" system.sysLocation.0="the attic" system.sysServices.0=2 SNMPv2-MIB::sysDescr.0 = STRING: DGS-1224T 4.21.02 SNMPv2-MIB::sysObjectID.0 = OID: SNMPv2-SMI::enterprises.171.10.76.5 SNMPv2-MIB::sysUpTime.0 = Timeticks: (337032680) 39 days, 0:12:06.80 SNMPv2-MIB::sysContact.0 = STRING: SNMPv2-MIB::sysName.0 = STRING: ott-dlink-gig24 SNMPv2-MIB::sysLocation.0 = STRING: the attic SNMPv2-MIB::sysServices.0 = INTEGER: 2 IF-MIB::ifNumber.0 = INTEGER: 25 IF-MIB::ifIndex.1 = INTEGER: 1 IF-MIB::ifIndex.2 = INTEGER: 2 IF-MIB::ifIndex.3 = INTEGER: 3 IF-MIB::ifIndex.4 = INTEGER: 4 ... 15:57:48.845525 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] |30|30|02|01|04|0fC=XXX |a1|1aGetNextRequest(26)|02|04|02|01|02|01|30|0c |30|0a|06|06.1.3.6.1.2.1.1|05|00 (ttl 64, id 50398, len 78) 15:57:48.848682 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] |30|82|00|66|02|01|04|0fC=XXX |a2|82|00|4eGetResponse(78)|02|04|02|01|02|01|30|82|00|3e |30|3c|06|08.1.3.6.1.2.1.1.1.0=|04|30"DGS-1224T 4.21.02" (DF) (ttl 254, id 65014, len 134) 15:57:48.848956 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] |30|32|02|01|04|0fC=XXX |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e |30|0c|06|08.1.3.6.1.2.1.1.1.0|05|00 (ttl 64, id 49660, len 80) 15:57:48.851836 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] |30|82|00|40|02|01|04|0fC=XXX |a2|82|00|28GetResponse(40)|02|04|02|01|02|01|30|82|00|18 |30|16|06|08.1.3.6.1.2.1.1.2.0=|06|0a.1.3.6.1.4.1.171.10.76.5 (DF) (ttl 254, id 65015, len 96) 15:57:48.851979 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] |30|32|02|01|04|0fC=XXX |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e |30|0c|06|08.1.3.6.1.2.1.1.2.0|05|00 (ttl 64, id 61889, len 80) 15:57:48.854907 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] |30|82|00|3a|02|01|04|0fC=XXX |a2|82|00|22GetResponse(34)|02|04|02|01|02|01|30|82|00|12 |30|10|06|08.1.3.6.1.2.1.1.3.0=|43|04336972620 (DF) (ttl 254, id 65016, len 90) 15:57:48.855016 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] |30|32|02|01|04|0fC=XXX |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e |30|0c|06|08.1.3.6.1.2.1.1.3.0|05|00 (ttl 64, id 30100, len 80) 15:57:48.857873 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] |30|82|00|36|02|01|04|0fC=XXX |a2|82|00|1eGetResponse(30)|02|04|02|01|02|01|30|82|00|0e |30|0c|06|08.1.3.6.1.2.1.1.4.0=|04|00"" (DF) (ttl 254, id 65017, len 86) 15:57:48.857983 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] |30|32|02|01|04|0fC=XXX |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e |30|0c|06|08.1.3.6.1.2.1.1.4.0|05|00 (ttl 64, id 5047, len 80) 15:57:48.860909 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] |30|82|00|45|02|01|04|0fC=XXX |a2|82|00|2dGetResponse(45)|02|04|02|01|02|01|30|82|00|1d |30|1b|06|08.1.3.6.1.2.1.1.5.0=|04|0f"ott-dlink-gig24" (DF) (ttl 254, id 65018, len 101) 15:57:48.861018 85.158.44.149.31774 > 10.15.3.2.161: [udp sum ok] |30|32|02|01|04|0fC=XXX |a1|1cGetNextRequest(28)|02|04|02|01|02|01|30|0e |30|0c|06|08.1.3.6.1.2.1.1.5.0|05|00 (ttl 64, id 25590, len 80) 15:57:48.863971 10.15.3.2.161 > 85.158.44.149.31774: [udp sum ok] |30|82|00|3f|02|01|04|0fC=XXX |a2|82|00|27GetResponse(39)|02|04|02|01|02|01|30|82|00|17 |30|15|06|08.1.3.6.1.2.1.1.6.0=|04|09"the attic" (DF) (ttl 254, id 65019, len 95) 15:57:48.864032 85.158.44.149.31774 > 10.15.3
snmp client (aka "walk")
Hi, I just committed a simple SNMP client implementation to snmpctl/snmpd. You can use it as an in-tree alternative to net-snmp's snmpwalk/snmpget. Examples: $ snmpctl walk 127.0.0.1 $ snmpctl walk printer.my.domain version 1 oid printerWorkingGroup $ snmpctl -n walk 203.0.113.240 oid ifMIB community "blah" Limitations: - no SNMPv3/USM support yet - no bulk support yet (bulkwalk) - not so many fancy options. snmpd does not support loading of external MIB files, so you have to use net-snmp if you want to load additional MIBs for the symbolic name parsing. snmpctl only shows symbolic names there are found in snmpd's mib.h. Testing welcome, especially with non-snmpd(8) agents. Reyk
Re: Multicast macros and global list of addresses
On 19/09/13(Thu) 13:59, Martin Pieuchot wrote:
> Diff below change the macros used to iterate over the multicast
> records linked to an interface without using the global lists of
> addresses.
>
> These records are currently link to the first address descriptor,
> respectively v4 and v6, even if they are per-interface. So I
> changed the code to loop over the global interface list instead
> of iterating over all existing addresses.
>
> Tested here with a carp setup. Comments, ok?
I got one ok for this diff but no other feedback.
Did somebody tried it on a different setup? I would really help me to
get this in to move forward, so I appreciate any tests, reviews or ok.
> Index: netinet/igmp.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/igmp.c,v
> retrieving revision 1.33
> diff -u -p -r1.33 igmp.c
> --- netinet/igmp.c2 May 2013 11:54:10 - 1.33
> +++ netinet/igmp.c13 Sep 2013 09:07:42 -
> @@ -104,6 +104,7 @@ int igmp_timers_are_running;
> static struct router_info *rti_head;
> struct igmpstat igmpstat;
>
> +void igmp_checktimer(struct ifnet *);
> void igmp_sendpkt(struct in_multi *, int, in_addr_t);
> int rti_fill(struct in_multi *);
> struct router_info * rti_find(struct ifnet *);
> @@ -193,7 +194,6 @@ igmp_input(struct mbuf *m, ...)
> int igmplen;
> int minlen;
> struct in_multi *inm;
> - struct in_multistep step;
> struct router_info *rti;
> struct in_ifaddr *ia;
> int timer;
> @@ -266,17 +266,14 @@ igmp_input(struct mbuf *m, ...)
>* except those that are already running and those
>* that belong to a "local" group (224.0.0.X).
>*/
> - IN_FIRST_MULTI(step, inm);
> - while (inm != NULL) {
> - if (inm->inm_ia->ia_ifp == ifp &&
> - inm->inm_timer == 0 &&
> + IN_FOREACH_MULTI(ia, ifp, inm) {
> + if (inm->inm_timer == 0 &&
> !IN_LOCAL_GROUP(inm->inm_addr.s_addr)) {
> inm->inm_state = IGMP_DELAYING_MEMBER;
> inm->inm_timer = IGMP_RANDOM_DELAY(
> IGMP_MAX_HOST_REPORT_DELAY *
> PR_FASTHZ);
> igmp_timers_are_running = 1;
> }
> - IN_NEXT_MULTI(step, inm);
> }
> } else {
> if (!IN_MULTICAST(ip->ip_dst.s_addr)) {
> @@ -297,10 +294,8 @@ igmp_input(struct mbuf *m, ...)
>* timers already running, check if they need to be
>* reset.
>*/
> - IN_FIRST_MULTI(step, inm);
> - while (inm != NULL) {
> - if (inm->inm_ia->ia_ifp == ifp &&
> - !IN_LOCAL_GROUP(inm->inm_addr.s_addr) &&
> + IN_FOREACH_MULTI(ia, ifp, inm) {
> + if (!IN_LOCAL_GROUP(inm->inm_addr.s_addr) &&
> (ip->ip_dst.s_addr == INADDR_ALLHOSTS_GROUP
> ||
>ip->ip_dst.s_addr ==
> inm->inm_addr.s_addr)) {
> switch (inm->inm_state) {
> @@ -323,7 +318,6 @@ igmp_input(struct mbuf *m, ...)
> break;
> }
> }
> - IN_NEXT_MULTI(step, inm);
> }
> }
>
> @@ -505,8 +499,7 @@ igmp_leavegroup(struct in_multi *inm)
> void
> igmp_fasttimo(void)
> {
> - struct in_multi *inm;
> - struct in_multistep step;
> + struct ifnet *ifp;
> int s;
>
> /*
> @@ -518,8 +511,21 @@ igmp_fasttimo(void)
>
> s = splsoftnet();
> igmp_timers_are_running = 0;
> - IN_FIRST_MULTI(step, inm);
> - while (inm != NULL) {
> + TAILQ_FOREACH(ifp, &ifnet, if_list)
> + igmp_checktimer(ifp);
> + splx(s);
> +}
> +
> +
> +void
> +igmp_checktimer(struct ifnet *ifp)
> +{
> + struct in_multi *inm;
> + struct in_ifaddr *ia;
> +
> + splsoftassert(IPL_SOFTNET);
> +
> + IN_FOREACH_MULTI(ia, ifp, inm) {
> if (inm->inm_timer == 0) {
> /* do nothing */
> } else if (--inm->inm_timer == 0) {
> @@ -535,9 +541,7 @@ igmp_fasttimo(void)
> } else {
> igmp_timers_are_running = 1;
> }
> - IN_NEXT_MULTI(step, inm);
> }
> - splx(s);
> }
>
> void
> Index: netinet/in_var.h
> ===
> RCS file: /home/ncvs/src/s
Re: openbsd ioctl fix (in6.c)
On 30/09/13(Mon) 14:17, Loganaden Velvindron wrote:
> On Mon, Sep 30, 2013 at 10:51:47PM +0200, Alexander Bluhm wrote:
> > On Wed, Sep 18, 2013 at 12:01:10AM -0700, Loganaden Velvindron wrote:
> > > Index: in6.c
> > > ===
> > > RCS file: /cvs/src/sys/netinet6/in6.c,v
> > > retrieving revision 1.118
> > > diff -u -p -r1.118 in6.c
> > > --- in6.c 26 Aug 2013 07:15:58 - 1.118
> > > +++ in6.c 18 Sep 2013 06:54:13 -
> > > @@ -426,8 +426,11 @@ in6_control(struct socket *so, u_long cm
> > > sa6 = &ifr->ifr_addr;
> > > break;
> > > case SIOCSIFADDR:
> > > + case SIOCSIFDSTADDR:
> > > + case SIOCSIFBRDADDR:
> > > + case SIOCSIFNETMASK:
> > > /*
> > > -* Do not pass this ioctl to driver handler since it is
> > > not
> > > +* Do not pass those ioctl to driver handler since they
> > > are not
> > > * properly setup. Instead just error out.
> > > */
> > > return (EOPNOTSUPP);
> >
> > This diff uses spaces instead of tabs. Please use tabs to make
> > diffs apply cleanly.
> >
> > The errno EAFNOSUPPORT "Address family not supported by protocol
> > family" is more specific for that error, at least if_ppp and if_sl
> > use that.
>
> Fixed style issues:
>
> Index: netinet6/in6.c
> ===
> RCS file: /cvs/src/sys/netinet6/in6.c,v
> retrieving revision 1.118
> diff -u -p -r1.118 in6.c
> --- netinet6/in6.c26 Aug 2013 07:15:58 - 1.118
> +++ netinet6/in6.c30 Sep 2013 21:14:43 -
> @@ -426,8 +426,11 @@ in6_control(struct socket *so, u_long cm
> sa6 = &ifr->ifr_addr;
> break;
> case SIOCSIFADDR:
> + case SIOCSIFDSTADDR:
> + case SIOCSIFBRDADDR:
> + case SIOCSIFNETMASK:
> /*
> - * Do not pass this ioctl to driver handler since it is not
> + * Do not pass those ioctl to driver handler since they are not
>* properly setup. Instead just error out.
>*/
> return (EOPNOTSUPP);
>
> >
> > anyway, code is correct, OK bluhm@
Committed, thanks.
> Can you please elaborate a bit concerning the cleanup for if_tun.c that
> mpi@ mentioned ?
Well what could be done is to remove the SIOCSIFBRDADDR case because it is
never reached, diff below.
Index: net/if_tun.c
===
RCS file: /home/ncvs/src/sys/net/if_tun.c,v
retrieving revision 1.115
diff -u -p -r1.115 if_tun.c
--- net/if_tun.c25 May 2013 10:05:52 - 1.115
+++ net/if_tun.c10 Sep 2013 12:54:41 -
@@ -493,10 +493,6 @@ tun_ioctl(struct ifnet *ifp, u_long cmd,
tuninit(tp);
TUNDEBUG(("%s: destination address set\n", ifp->if_xname));
break;
- case SIOCSIFBRDADDR:
- tuninit(tp);
- TUNDEBUG(("%s: broadcast address set\n", ifp->if_xname));
- break;
case SIOCSIFMTU:
if (ifr->ifr_mtu < ETHERMIN || ifr->ifr_mtu > TUNMRU)
error = EINVAL;
