denis hainsworth

ah i see. well thank you for the changes you did make. i wish i could edit the ticket name. it turned out not to be strictly related to bloglines accounts. if you are bored and can delete "if you do not have a bloglines account" that would be more accurate if anyone else hits this

GreatNews: database upgrade fails if you do not have a bloglines account

forgot to mention why this came to my attention in the first place. Cisco Network Prime snmp receiver throws this error when boot/time is 0/0 and essentially never changes CheckTime: received message outside time window (non authorative) RFC3414 §3.2.7.a Not in time window; engineID='xxxxxxxxxxxxxxxxxxxxxxxxx', engineBoots=0, engineTime=0 While this will catch non rfc complient clients it may or may not have been an intentional check by cisco and may be considered a bug on their side, it certainly...

this bug should be closed. i think snmptrapd is working in an rfc2574 compliant fashion. also of note i was running snmptrapd 5.7.2 not 5.7.3. the confusion stems from the fact that the rules for an rfc2574 complient trap receiver seems to hinge on the assumption that the snmp trap senders are all rfc complient. any trap sender should be incrementing the msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime values, but if it doesnt the RFC doesnt cover that. with a broken client like snmptrap...

snmptrapd ignores msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime for v3 traps

snmptrap always sends v3 traps with msgAuthoritativeEngineBoots and msgAuthoritativeEngineTime set to zero