SecBSD/src
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

sync with OpenBSD -current

Browse source
This commit is contained in:
purplerain 2024-02-06 07:46:25 +00:00
parent 36c45cb00b
commit 0bc0a510b3
Signed by: purplerain
GPG key ID: F42C07F07E2E35B7
74 changed files with 19354 additions and 553 deletions
Download patch file Download diff file Expand all files Collapse all files

21
distrib/sets/lists/base/mi
View file

@ -2960,6 +2960,15 @@
./usr/share/relink/usr/sbin/sshd/sshd.tar
./usr/share/snmp
./usr/share/snmp/mibs
./usr/share/snmp/mibs/BRIDGE-MIB.txt
./usr/share/snmp/mibs/HOST-RESOURCES-MIB.txt
./usr/share/snmp/mibs/IANA-RTPROTO-MIB.txt
./usr/share/snmp/mibs/IANA-STORAGE-MEDIA-TYPE-MIB.txt
./usr/share/snmp/mibs/IANAifType-MIB.txt
./usr/share/snmp/mibs/IF-MIB.txt
./usr/share/snmp/mibs/INET-ADDRESS-MIB.txt
./usr/share/snmp/mibs/IP-FORWARD-MIB.txt
./usr/share/snmp/mibs/IP-MIB.txt
./usr/share/snmp/mibs/OPENBSD-BASE-MIB.txt
./usr/share/snmp/mibs/OPENBSD-CARP-MIB.txt
./usr/share/snmp/mibs/OPENBSD-MEM-MIB.txt
@ -2967,6 +2976,18 @@
./usr/share/snmp/mibs/OPENBSD-RELAYD-MIB.txt
./usr/share/snmp/mibs/OPENBSD-SENSORS-MIB.txt
./usr/share/snmp/mibs/OPENBSD-SNMPD-CONF.txt
./usr/share/snmp/mibs/SNMP-FRAMEWORK-MIB.txt
./usr/share/snmp/mibs/SNMP-USER-BASED-SM-MIB.txt
./usr/share/snmp/mibs/SNMP-USM-AES-MIB.txt
./usr/share/snmp/mibs/SNMP-USM-HMAC-SHA2-MIB.txt
./usr/share/snmp/mibs/SNMPv2-CONF.txt
./usr/share/snmp/mibs/SNMPv2-MIB.txt
./usr/share/snmp/mibs/SNMPv2-SMI.txt
./usr/share/snmp/mibs/SNMPv2-TC.txt
./usr/share/snmp/mibs/SNMPv2-TM.txt
./usr/share/snmp/mibs/TRANSPORT-ADDRESS-MIB.txt
./usr/share/snmp/mibs/UUID-TC-MIB.txt
./usr/share/snmp/mibs/VM-MIB.txt
./usr/share/tabset
./usr/share/tabset/std
./usr/share/tabset/stdcrt

10
regress/lib/libc/locale/uselocale/uselocale.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: uselocale.c,v 1.8 2022/07/25 21:29:16 guenther Exp $ */
/* $OpenBSD: uselocale.c,v 1.9 2024/02/05 06:48:04 anton Exp $ */
/*
* Copyright (c) 2017, 2022 Ingo Schwarze <schwarze@openbsd.org>
*
@ -273,10 +273,10 @@ child_func(void *arg)
TEST_R(nl_langinfo, "UTF-8", CODESET);
TEST_R(nl_langinfo_l, "UTF-8", CODESET, _LOCALE_UTF8);
TEST_R(nl_langinfo_l, "US-ASCII", CODESET, _LOCALE_C);
TEST_R(isalpha, _L, 0x65); /* e */
TEST_R(isalpha_l, _L, 0x65, _LOCALE_UTF8);
TEST_R(isalpha_l, _L, 0x65, _LOCALE_C);
TEST_R(isalpha_l, _L, 0x65, _LOCALE_C);
TEST_R(isalpha, _CTYPE_L, 0x65); /* e */
TEST_R(isalpha_l, _CTYPE_L, 0x65, _LOCALE_UTF8);
TEST_R(isalpha_l, _CTYPE_L, 0x65, _LOCALE_C);
TEST_R(isalpha_l, _CTYPE_L, 0x65, _LOCALE_C);
TEST_R(isalpha, 0, 0x30); /* 0 */
TEST_R(isalpha_l, 0, 0x30, _LOCALE_UTF8);
TEST_R(isalpha_l, 0, 0x30, _LOCALE_C);

8
regress/usr.sbin/btrace/Makefile
View file

@ -1,11 +1,11 @@
# $OpenBSD: Makefile,v 1.30 2023/09/11 19:03:53 mpi Exp $
# $OpenBSD: Makefile,v 1.31 2024/02/05 15:30:04 mpi Exp $
BTRACE?= /usr/sbin/btrace
ALLOWDT!= sysctl -n kern.allowdt 2>/dev/null
# scripts that don't need /dev/dt
BT_LANG_SCRIPTS= arithm beginend beginend-argn boolean comments delete \
exit histempty if \
BT_LANG_SCRIPTS= arithm beginend beginend-argn boolean comments \
delete exit histempty if \
map mapclear mapempty mapsyntax mapzero map-unnamed \
maxoperand min+max+sum multismts nsecs+var \
precedence print read-map-after-clear staticv-empty \
@ -14,7 +14,7 @@ BT_LANG_SCRIPTS= arithm beginend beginend-argn boolean comments delete \
BT_ARG_LANG_SCRIPTS= staticv str
# scripts that use kernel probes
BT_KERN_SCRIPTS= empty-stmts filters mapoverwrite multiprobe
BT_KERN_SCRIPTS= argn empty-stmts filters mapoverwrite multiprobe
REGRESS_EXPECTED_FAILURES= run-maxoperand

6
regress/usr.sbin/btrace/argn.bt Normal file
View file

@ -0,0 +1,6 @@
interval:hz:100
{
printf("%d %s %d %s %d %s %d %s %d %s\n",
arg0, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9);
exit();
}

1
regress/usr.sbin/btrace/argn.ok Normal file
View file

@ -0,0 +1 @@
0 0 0 0 0 0 0 0 0 0

2
regress/usr.sbin/btrace/filters.bt
View file

@ -16,7 +16,7 @@ syscall:open:return
exit();
}
interval:hz:1
interval:hz:100
{
exit();
}

8
regress/usr.sbin/btrace/map.bt
View file

@ -1,6 +1,6 @@
BEGIN
{
@map[8 - 1] = count();
@map[8 - 1, "test"] = count();
printf("=> Print with one element\n");
print(@map);
@ -8,7 +8,7 @@ BEGIN
printf("=> Print after zero:\n");
print(@map);
@map[7] = count();
@map[7, "test"] = count();
@map[5] = 42;
@map[3 + 1] = 9999;
@map[897123] = 9997;
@ -17,12 +17,12 @@ BEGIN
print(@map, @top);
printf("=> Using printf:\n");
printf("%d + %d\n", @map[4], @map[7]);
printf("%d + %d\n", @map[4], @map[7, "test"]);
}
END
{
@map[7] = count();
@map[7, "test"] = count();
printf("=> Print all map:\n");
print(@map);

6
regress/usr.sbin/btrace/map.ok
View file

@ -1,7 +1,7 @@
=> Print with one element
@map[7]: 1
@map[7, test]: 1
=> Print after zero:
@map[7]: 0
@map[7, test]: 0
=> Print top 2:
@map[4]: 9999
@map[897123]: 9997
@ -11,5 +11,5 @@
@map[4]: 9999
@map[897123]: 9997
@map[5]: 42
@map[7]: 2
@map[7, test]: 2
=> Print after clear:

2
regress/usr.sbin/btrace/mapoverwrite.bt
View file

@ -10,7 +10,7 @@ BEGIN
/*
* Overwrite map periodically to ensure there's no double-free.
*/
interval:hz:1
interval:hz:100
{
if (@counter >= 10)
exit();

4
regress/usr.sbin/btrace/multiprobe.bt
View file

@ -1,10 +1,10 @@
BEGIN,
interval:hz:2
interval:hz:50
{
printf("multi\n");
}
interval:hz:1
interval:hz:100
{
exit();
}

15
share/man/man4/ddb.4
View file

@ -1,4 +1,4 @@
.\" $OpenBSD: ddb.4,v 1.106 2023/09/19 11:36:33 claudio Exp $
.\" $OpenBSD: ddb.4,v 1.107 2024/02/05 21:33:00 jmc Exp $
.\" $NetBSD: ddb.4,v 1.5 1994/11/30 16:22:09 jtc Exp $
.\"
.\" Mach Operating System
@ -25,7 +25,7 @@
.\" any improvements or extensions that they make and grant Carnegie Mellon
.\" the rights to redistribute these changes.
.\"
.Dd $Mdocdate: September 19 2023 $
.Dd $Mdocdate: February 5 2024 $
.Dt DDB 4
.Os
.Sh NAME
@ -622,20 +622,11 @@ Prints a list of all breakpoints that have been set with the
.Ic break
command.
.\" --------------------
.It Xo
.Ic show buf
.Op Cm /f
.Ar addr
.Xc
.It Ic show buf Ar addr
Prints the
.Vt struct buf
at
.Ar addr .
If the
.Cm /f
modifier is specified output will also include
.Li softdep
printout, if those are available.
.\" --------------------
.It Ic show extents
Prints a detailed list of all extents.

8
share/man/man4/mfii.4
View file

@ -1,4 +1,4 @@
.\" $OpenBSD: mfii.4,v 1.7 2018/03/27 07:01:42 jsg Exp $
.\" $OpenBSD: mfii.4,v 1.8 2024/02/05 19:07:45 deraadt Exp $
.\"
.\" Copyright (c) 2012 David Gwynne <dlg@openbsd.org>
.\"
@ -14,7 +14,7 @@
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
.Dd $Mdocdate: March 27 2018 $
.Dd $Mdocdate: February 5 2024 $
.Dt MFII 4
.Os
.Sh NAME
@ -47,6 +47,10 @@ SAS3504
SAS3508
.It
SAS3516
.It
SAS3816
.It
SAS3916
.El
.Pp
These controllers support RAID 0, RAID 1, RAID 5, RAID 6, RAID 10, RAID 50 and

1472
share/snmp/BRIDGE-MIB.txt Normal file
View file

File diff suppressed because it is too large Load diff

1540
share/snmp/HOST-RESOURCES-MIB.txt Normal file
View file

File diff suppressed because it is too large Load diff

102
share/snmp/IANA-RTPROTO-MIB.txt Normal file
View file

@ -0,0 +1,102 @@
IANA-RTPROTO-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
ianaRtProtoMIB MODULE-IDENTITY
LAST-UPDATED "201604250000Z" -- April 25, 2016
ORGANIZATION "IANA"
CONTACT-INFO
" Internet Assigned Numbers Authority
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
Phone: +1 310 301 5800
EMail: iana&iana.org"
DESCRIPTION
"This MIB module defines the IANAipRouteProtocol and
IANAipMRouteProtocol textual conventions for use in MIBs
which need to identify unicast or multicast routing
mechanisms.
Any additions or changes to the contents of this MIB module
require either publication of an RFC, or Designated Expert
Review as defined in RFC 2434, Guidelines for Writing an
IANA Considerations Section in RFCs. The Designated Expert
will be selected by the IESG Area Director(s) of the Routing
Area."
REVISION "201604250000Z" -- April 25, 2016
DESCRIPTION "Corrected typographical error in revision date."
REVISION "201604060000Z" -- April 6, 2016
DESCRIPTION "Added ttdp(20)."
REVISION "201208300000Z" -- August 30, 2012
DESCRIPTION "Added dhcp(19)."
REVISION "201107220000Z" -- July 22, 2011
DESCRIPTION "Added rpl(18) ."
REVISION "200009260000Z" -- September 26, 2000
DESCRIPTION "Original version, published in coordination
with RFC 2932."
::= { mib-2 84 }
IANAipRouteProtocol ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A mechanism for learning routes. Inclusion of values for
routing protocols is not intended to imply that those
protocols need be supported."
SYNTAX INTEGER {
other (1), -- not specified
local (2), -- local interface
netmgmt (3), -- static route
icmp (4), -- result of ICMP Redirect
-- the following are all dynamic
-- routing protocols
egp (5), -- Exterior Gateway Protocol
ggp (6), -- Gateway-Gateway Protocol
hello (7), -- FuzzBall HelloSpeak
rip (8), -- Berkeley RIP or RIP-II
isIs (9), -- Dual IS-IS
esIs (10), -- ISO 9542
ciscoIgrp (11), -- Cisco IGRP
bbnSpfIgp (12), -- BBN SPF IGP
ospf (13), -- Open Shortest Path First
bgp (14), -- Border Gateway Protocol
idpr (15), -- InterDomain Policy Routing
ciscoEigrp (16), -- Cisco EIGRP
dvmrp (17), -- DVMRP
rpl (18), -- RPL [RFC-ietf-roll-rpl-19]
dhcp (19), -- DHCP [RFC2132]
ttdp (20) -- Train Topology Discovery Protocol (TTDP) [IEC 61375-2-5]
}
IANAipMRouteProtocol ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The multicast routing protocol. Inclusion of values for
multicast routing protocols is not intended to imply that
those protocols need be supported."
SYNTAX INTEGER {
other(1), -- none of the following
local(2), -- e.g., manually configured
netmgmt(3), -- set via net.mgmt protocol
dvmrp(4),
mospf(5),
pimSparseDense(6), -- PIMv1, both DM and SM
cbt(7),
pimSparseMode(8), -- PIM-SM
pimDenseMode(9), -- PIM-DM
igmpOnly(10),
bgmp(11),
msdp(12)
}
END

67
share/snmp/IANA-STORAGE-MEDIA-TYPE-MIB.txt Normal file
View file

@ -0,0 +1,67 @@
IANA-STORAGE-MEDIA-TYPE-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
ianaStorageMediaTypeMIB MODULE-IDENTITY
LAST-UPDATED "201510120000Z" -- 12 October 2015
ORGANIZATION "IANA"
CONTACT-INFO
"Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
United States
Tel: +1 310-301-5800
Email: iana&iana.org"
DESCRIPTION
"This MIB module defines Textual Conventions
representing the media type of a storage device.
Copyright (c) 2015 IETF Trust and the persons identified
as authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with
or without modification, is permitted pursuant to, and
subject to the license terms contained in, the
Simplified BSD License set forth in Section 4.c of the
IETF Trust's Legal Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)."
REVISION "201510120000Z" -- 12 October 2015
DESCRIPTION
"The initial version of this MIB, published as
RFC 7666."
::= { mib-2 237 }
IANAStorageMediaType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The media type of a storage device:
unknown(1) The media type is unknown, e.g., because
the implementation failed to obtain the
media type from the hypervisor.
other(2) The media type is other than those
defined in this conversion.
hardDisk(3) The media type is hard disk.
opticalDisk(4) The media type is optical disk.
floppyDisk(5) The media type is floppy disk."
SYNTAX INTEGER {
other(1),
unknown(2),
hardDisk(3),
opticalDisk(4),
floppyDisk(5)
}
END

774
share/snmp/IANAifType-MIB.txt Normal file
View file

@ -0,0 +1,774 @@
IANAifType-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
ianaifType MODULE-IDENTITY
LAST-UPDATED "202208170000Z" -- August 17, 2022
ORGANIZATION "IANA"
CONTACT-INFO " Internet Assigned Numbers Authority
Postal: ICANN
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
Tel: +1 310-301-5800
E-Mail: iana@iana.org"
DESCRIPTION "This MIB module defines the IANAifType Textual
Convention, and thus the enumerated values of
the ifType object defined in MIB-II's ifTable."
REVISION "202208170000Z" -- August 17, 2022
DESCRIPTION "Changed gpon description to refer to G.984."
REVISION "202105170000Z" -- May 17, 2021
DESCRIPTION "Registration of new IANAifType 303."
REVISION "202104230000Z" -- April 23, 2021
DESCRIPTION "Registration of new tunnelType 19 and
combined 2018-06-28 revision statements"
REVISION "202104220000Z" -- April 22, 2021
DESCRIPTION "Registration of new IANAifType 302."
REVISION "202102180000Z" -- February 18, 2021
DESCRIPTION "Registration of new IANAifType 301."
REVISION "202008270000Z" -- August 27, 2020
DESCRIPTION "Updated Interface Types (ifType) registry name."
REVISION "202007100000Z" -- July 10, 2020
DESCRIPTION "Registration of new IANAifType 300."
REVISION "202004020000Z" -- April 2, 2020
DESCRIPTION "Added reference to ifType definitions registry."
REVISION "202001100000Z" -- January 10, 2020
DESCRIPTION "Addition of IANAifType 299."
REVISION "201912030000Z" -- December 3, 2019
DESCRIPTION "Updated email address for IANA"
REVISION "201910160000Z" -- October 16, 2019
DESCRIPTION "Addition of IANAifTypes 297-298."
REVISION "201902140000Z" -- February 14, 2019
DESCRIPTION "Registration of new tunnelType 18."
REVISION "201902080000Z" -- February 8, 2019
DESCRIPTION "Added missing commas for 295-296."
REVISION "201901310000Z" -- January 31, 2019
DESCRIPTION "Registration of new IANAifTypes 295-296."
REVISION "201807040000Z" -- July 4, 2018
DESCRIPTION "Added missing commas for 291-293."
REVISION "201806280000Z" -- June 28, 2018
DESCRIPTION "Registration of new IANAifTypes 293-294."
REVISION "201806220000Z" -- June 22, 2018
DESCRIPTION "Registration of new IANAifType 292."
REVISION "201806210000Z" -- June 21, 2018
DESCRIPTION "Registration of new IANAifType 291."
REVISION "201703300000Z" -- March 30, 2017
DESCRIPTION "Registration of new IANAifType 290."
REVISION "201701190000Z" -- January 19, 2017
DESCRIPTION "Registration of new IANAifType 289."
REVISION "201611230000Z" -- November 23, 2016
DESCRIPTION "Registration of new IANAifTypes 283-288."
REVISION "201606160000Z" -- June 16, 2016
DESCRIPTION "Updated IANAtunnelType DESCRIPTION per RFC 7870"
REVISION "201606090000Z" -- June 9, 2016
DESCRIPTION "Registration of new IANAifType 282."
REVISION "201606080000Z" -- June 8, 2016
DESCRIPTION "Updated description for tunnelType 17."
REVISION "201605190000Z" -- May 19, 2016
DESCRIPTION "Updated description for tunnelType 16."
REVISION "201605030000Z" -- May 3, 2016
DESCRIPTION "Registration of new IANAifType 281."
REVISION "201604290000Z" -- April 29, 2016
DESCRIPTION "Registration of new tunnelTypes 16 and 17."
REVISION "201409240000Z" -- September 24, 2014
DESCRIPTION "Registration of new IANAifType 280."
REVISION "201409190000Z" -- September 19, 2014
DESCRIPTION "Registration of new IANAifType 279."
REVISION "201407030000Z" -- July 3, 2014
DESCRIPTION "Registration of new IANAifTypes 277-278."
REVISION "201405220000Z" -- May 22, 2014
DESCRIPTION "Updated contact info."
REVISION "201205170000Z" -- May 17, 2012
DESCRIPTION "Registration of new IANAifType 272."
REVISION "201201110000Z" -- January 11, 2012
DESCRIPTION "Registration of new IANAifTypes 266-271."
REVISION "201112180000Z" -- December 18, 2011
DESCRIPTION "Registration of new IANAifTypes 263-265."
REVISION "201110260000Z" -- October 26, 2011
DESCRIPTION "Registration of new IANAifType 262."
REVISION "201109070000Z" -- September 7, 2011
DESCRIPTION "Registration of new IANAifTypes 260 and 261."
REVISION "201107220000Z" -- July 22, 2011
DESCRIPTION "Registration of new IANAifType 259."
REVISION "201106030000Z" -- June 03, 2011
DESCRIPTION "Registration of new IANAifType 258."
REVISION "201009210000Z" -- September 21, 2010
DESCRIPTION "Registration of new IANAifTypes 256 and 257."
REVISION "201007210000Z" -- July 21, 2010
DESCRIPTION "Registration of new IANAifType 255."
REVISION "201002110000Z" -- February 11, 2010
DESCRIPTION "Registration of new IANAifType 254."
REVISION "201002080000Z" -- February 08, 2010
DESCRIPTION "Registration of new IANAifTypes 252 and 253."
REVISION "200905060000Z" -- May 06, 2009
DESCRIPTION "Registration of new IANAifType 251."
REVISION "200902060000Z" -- February 06, 2009
DESCRIPTION "Registration of new IANAtunnelType 15."
REVISION "200810090000Z" -- October 09, 2008
DESCRIPTION "Registration of new IANAifType 250."
REVISION "200808120000Z" -- August 12, 2008
DESCRIPTION "Registration of new IANAifType 249."
REVISION "200807220000Z" -- July 22, 2008
DESCRIPTION "Registration of new IANAifTypes 247 and 248."
REVISION "200806240000Z" -- June 24, 2008
DESCRIPTION "Registration of new IANAifType 246."
REVISION "200805290000Z" -- May 29, 2008
DESCRIPTION "Registration of new IANAifType 245."
REVISION "200709130000Z" -- September 13, 2007
DESCRIPTION "Registration of new IANAifTypes 243 and 244."
REVISION "200705290000Z" -- May 29, 2007
DESCRIPTION "Changed the description for IANAifType 228."
REVISION "200703080000Z" -- March 08, 2007
DESCRIPTION "Registration of new IANAifType 242."
REVISION "200701230000Z" -- January 23, 2007
DESCRIPTION "Registration of new IANAifTypes 239, 240, and 241."
REVISION "200610170000Z" -- October 17, 2006
DESCRIPTION "Deprecated/Obsoleted IANAifType 230. Registration of
IANAifType 238."
REVISION "200609250000Z" -- September 25, 2006
DESCRIPTION "Changed the description for IANA ifType
184 and added new IANA ifType 237."
REVISION "200608170000Z" -- August 17, 2006
DESCRIPTION "Changed the descriptions for IANAifTypes
20 and 21."
REVISION "200608110000Z" -- August 11, 2006
DESCRIPTION "Changed the descriptions for IANAifTypes
7, 11, 62, 69, and 117."
REVISION "200607250000Z" -- July 25, 2006
DESCRIPTION "Registration of new IANA ifType 236."
REVISION "200606140000Z" -- June 14, 2006
DESCRIPTION "Registration of new IANA ifType 235."
REVISION "200603310000Z" -- March 31, 2006
DESCRIPTION "Registration of new IANA ifType 234."
REVISION "200603300000Z" -- March 30, 2006
DESCRIPTION "Registration of new IANA ifType 233."
REVISION "200512220000Z" -- December 22, 2005
DESCRIPTION "Registration of new IANA ifTypes 231 and 232."
REVISION "200510100000Z" -- October 10, 2005
DESCRIPTION "Registration of new IANA ifType 230."
REVISION "200509090000Z" -- September 09, 2005
DESCRIPTION "Registration of new IANA ifType 229."
REVISION "200505270000Z" -- May 27, 2005
DESCRIPTION "Registration of new IANA ifType 228."
REVISION "200503030000Z" -- March 3, 2005
DESCRIPTION "Added the IANAtunnelType TC and deprecated
IANAifType sixToFour (215) per RFC4087."
REVISION "200411220000Z" -- November 22, 2004
DESCRIPTION "Registration of new IANA ifType 227 per RFC4631."
REVISION "200406170000Z" -- June 17, 2004
DESCRIPTION "Registration of new IANA ifType 226."
REVISION "200405120000Z" -- May 12, 2004
DESCRIPTION "Added description for IANAifType 6, and
changed the descriptions for IANAifTypes
180, 181, and 182."
REVISION "200405070000Z" -- May 7, 2004
DESCRIPTION "Registration of new IANAifType 225."
REVISION "200308250000Z" -- Aug 25, 2003
DESCRIPTION "Deprecated IANAifTypes 7 and 11. Obsoleted
IANAifTypes 62, 69, and 117. ethernetCsmacd (6)
should be used instead of these values"
REVISION "200308180000Z" -- Aug 18, 2003
DESCRIPTION "Registration of new IANAifType
224."
REVISION "200308070000Z" -- Aug 7, 2003
DESCRIPTION "Registration of new IANAifTypes
222 and 223."
REVISION "200303180000Z" -- Mar 18, 2003
DESCRIPTION "Registration of new IANAifType
221."
REVISION "200301130000Z" -- Jan 13, 2003
DESCRIPTION "Registration of new IANAifType
220."
REVISION "200210170000Z" -- Oct 17, 2002
DESCRIPTION "Registration of new IANAifType
219."
REVISION "200207160000Z" -- Jul 16, 2002
DESCRIPTION "Registration of new IANAifTypes
217 and 218."
REVISION "200207100000Z" -- Jul 10, 2002
DESCRIPTION "Registration of new IANAifTypes
215 and 216."
REVISION "200206190000Z" -- Jun 19, 2002
DESCRIPTION "Registration of new IANAifType
214."
REVISION "200201040000Z" -- Jan 4, 2002
DESCRIPTION "Registration of new IANAifTypes
211, 212 and 213."
REVISION "200112200000Z" -- Dec 20, 2001
DESCRIPTION "Registration of new IANAifTypes
209 and 210."
REVISION "200111150000Z" -- Nov 15, 2001
DESCRIPTION "Registration of new IANAifTypes
207 and 208."
REVISION "200111060000Z" -- Nov 6, 2001
DESCRIPTION "Registration of new IANAifType
206."
REVISION "200111020000Z" -- Nov 2, 2001
DESCRIPTION "Registration of new IANAifType
205."
REVISION "200110160000Z" -- Oct 16, 2001
DESCRIPTION "Registration of new IANAifTypes
199, 200, 201, 202, 203, and 204."
REVISION "200109190000Z" -- Sept 19, 2001
DESCRIPTION "Registration of new IANAifType
198."
REVISION "200105110000Z" -- May 11, 2001
DESCRIPTION "Registration of new IANAifType
197."
REVISION "200101120000Z" -- Jan 12, 2001
DESCRIPTION "Registration of new IANAifTypes
195 and 196."
REVISION "200012190000Z" -- Dec 19, 2000
DESCRIPTION "Registration of new IANAifTypes
193 and 194."
REVISION "200012070000Z" -- Dec 07, 2000
DESCRIPTION "Registration of new IANAifTypes
191 and 192."
REVISION "200012040000Z" -- Dec 04, 2000
DESCRIPTION "Registration of new IANAifType
190."
REVISION "200010170000Z" -- Oct 17, 2000
DESCRIPTION "Registration of new IANAifTypes
188 and 189."
REVISION "200010020000Z" -- Oct 02, 2000
DESCRIPTION "Registration of new IANAifType 187."
REVISION "200009010000Z" -- Sept 01, 2000
DESCRIPTION "Registration of new IANAifTypes
184, 185, and 186."
REVISION "200008240000Z" -- Aug 24, 2000
DESCRIPTION "Registration of new IANAifType 183."
REVISION "200008230000Z" -- Aug 23, 2000
DESCRIPTION "Registration of new IANAifTypes
174-182."
REVISION "200008220000Z" -- Aug 22, 2000
DESCRIPTION "Registration of new IANAifTypes 170,
171, 172 and 173."
REVISION "200004250000Z" -- Apr 25, 2000
DESCRIPTION "Registration of new IANAifTypes 168 and 169."
REVISION "200003060000Z" -- Mar 6, 2000
DESCRIPTION "Fixed a missing semi-colon in the IMPORT.
Also cleaned up the REVISION log a bit.
It is not complete, but from now on it will
be maintained and kept up to date with each
change to this MIB module."
REVISION "199910081430Z" -- Oct 08, 1999
DESCRIPTION "Include new name assignments up to cnr(85).
This is the first version available via the WWW
at: ftp://ftp.isi.edu/mib/ianaiftype.mib"
REVISION "199401310000Z" -- Jan 31, 1994
DESCRIPTION "Initial version of this MIB as published in
RFC 1573."
::= { mib-2 30 }
IANAifType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"This data type is used as the syntax of the ifType
object in the (updated) definition of MIB-II's
ifTable.
The definition of this textual convention with the
addition of newly assigned values is published
periodically by the IANA, in either the Assigned
Numbers RFC, or some derivative of it specific to
Internet Network Management number assignments. (The
latest arrangements can be obtained by contacting the
IANA.)
Interface types must not be directly added to the
IANAifType-MIB MIB module. They must instead be added
to the 'Interface Types (ifType)' registry at
https://www.iana.org/assignments/smi-numbers.
The relationship between the assignment of ifType
values and of OIDs to particular media-specific MIBs
is solely the purview of IANA and is subject to change
without notice. Quite often, a media-specific MIB's
OID-subtree assignment within MIB-II's 'transmission'
subtree will be the same as its ifType value.
However, in some circumstances this will not be the
case, and implementors must not pre-assume any
specific relationship between ifType values and
transmission subtree OIDs."
SYNTAX INTEGER {
other(1), -- none of the following
regular1822(2),
hdh1822(3),
ddnX25(4),
rfc877x25(5),
ethernetCsmacd(6), -- for all ethernet-like interfaces,
-- regardless of speed, as per RFC3635
iso88023Csmacd(7), -- Deprecated via RFC3635
-- ethernetCsmacd (6) should be used instead
iso88024TokenBus(8),
iso88025TokenRing(9),
iso88026Man(10),
starLan(11), -- Deprecated via RFC3635
-- ethernetCsmacd (6) should be used instead
proteon10Mbit(12),
proteon80Mbit(13),
hyperchannel(14),
fddi(15),
lapb(16),
sdlc(17),
ds1(18), -- DS1-MIB
e1(19), -- Obsolete see DS1-MIB
basicISDN(20), -- no longer used
-- see also RFC2127
primaryISDN(21), -- no longer used
-- see also RFC2127
propPointToPointSerial(22), -- proprietary serial
ppp(23),
softwareLoopback(24),
eon(25), -- CLNP over IP
ethernet3Mbit(26),
nsip(27), -- XNS over IP
slip(28), -- generic SLIP
ultra(29), -- ULTRA technologies
ds3(30), -- DS3-MIB
sip(31), -- SMDS, coffee
frameRelay(32), -- DTE only.
rs232(33),
para(34), -- parallel-port
arcnet(35), -- arcnet
arcnetPlus(36), -- arcnet plus
atm(37), -- ATM cells
miox25(38),
sonet(39), -- SONET or SDH
x25ple(40),
iso88022llc(41),
localTalk(42),
smdsDxi(43),
frameRelayService(44), -- FRNETSERV-MIB
v35(45),
hssi(46),
hippi(47),
modem(48), -- Generic modem
aal5(49), -- AAL5 over ATM
sonetPath(50),
sonetVT(51),
smdsIcip(52), -- SMDS InterCarrier Interface
propVirtual(53), -- proprietary virtual/internal
propMultiplexor(54),-- proprietary multiplexing
ieee80212(55), -- 100BaseVG
fibreChannel(56), -- Fibre Channel
hippiInterface(57), -- HIPPI interfaces
frameRelayInterconnect(58), -- Obsolete, use either
-- frameRelay(32) or
-- frameRelayService(44).
aflane8023(59), -- ATM Emulated LAN for 802.3
aflane8025(60), -- ATM Emulated LAN for 802.5
cctEmul(61), -- ATM Emulated circuit
fastEther(62), -- Obsoleted via RFC3635
-- ethernetCsmacd (6) should be used instead
isdn(63), -- ISDN and X.25
v11(64), -- CCITT V.11/X.21
v36(65), -- CCITT V.36
g703at64k(66), -- CCITT G703 at 64Kbps
g703at2mb(67), -- Obsolete see DS1-MIB
qllc(68), -- SNA QLLC
fastEtherFX(69), -- Obsoleted via RFC3635
-- ethernetCsmacd (6) should be used instead
channel(70), -- channel
ieee80211(71), -- radio spread spectrum
ibm370parChan(72), -- IBM System 360/370 OEMI Channel
escon(73), -- IBM Enterprise Systems Connection
dlsw(74), -- Data Link Switching
isdns(75), -- ISDN S/T interface
isdnu(76), -- ISDN U interface
lapd(77), -- Link Access Protocol D
ipSwitch(78), -- IP Switching Objects
rsrb(79), -- Remote Source Route Bridging
atmLogical(80), -- ATM Logical Port
ds0(81), -- Digital Signal Level 0
ds0Bundle(82), -- group of ds0s on the same ds1
bsc(83), -- Bisynchronous Protocol
async(84), -- Asynchronous Protocol
cnr(85), -- Combat Net Radio
iso88025Dtr(86), -- ISO 802.5r DTR
eplrs(87), -- Ext Pos Loc Report Sys
arap(88), -- Appletalk Remote Access Protocol
propCnls(89), -- Proprietary Connectionless Protocol
hostPad(90), -- CCITT-ITU X.29 PAD Protocol
termPad(91), -- CCITT-ITU X.3 PAD Facility
frameRelayMPI(92), -- Multiproto Interconnect over FR
x213(93), -- CCITT-ITU X213
adsl(94), -- Asymmetric Digital Subscriber Loop
radsl(95), -- Rate-Adapt. Digital Subscriber Loop
sdsl(96), -- Symmetric Digital Subscriber Loop
vdsl(97), -- Very H-Speed Digital Subscrib. Loop
iso88025CRFPInt(98), -- ISO 802.5 CRFP
myrinet(99), -- Myricom Myrinet
voiceEM(100), -- voice recEive and transMit
voiceFXO(101), -- voice Foreign Exchange Office
voiceFXS(102), -- voice Foreign Exchange Station
voiceEncap(103), -- voice encapsulation
voiceOverIp(104), -- voice over IP encapsulation
atmDxi(105), -- ATM DXI
atmFuni(106), -- ATM FUNI
atmIma (107), -- ATM IMA
pppMultilinkBundle(108), -- PPP Multilink Bundle
ipOverCdlc (109), -- IBM ipOverCdlc
ipOverClaw (110), -- IBM Common Link Access to Workstn
stackToStack (111), -- IBM stackToStack
virtualIpAddress (112), -- IBM VIPA
mpc (113), -- IBM multi-protocol channel support
ipOverAtm (114), -- IBM ipOverAtm
iso88025Fiber (115), -- ISO 802.5j Fiber Token Ring
tdlc (116), -- IBM twinaxial data link control
gigabitEthernet (117), -- Obsoleted via RFC3635
-- ethernetCsmacd (6) should be used instead
hdlc (118), -- HDLC
lapf (119), -- LAP F
v37 (120), -- V.37
x25mlp (121), -- Multi-Link Protocol
x25huntGroup (122), -- X25 Hunt Group
transpHdlc (123), -- Transp HDLC
interleave (124), -- Interleave channel
fast (125), -- Fast channel
ip (126), -- IP (for APPN HPR in IP networks)
docsCableMaclayer (127), -- CATV Mac Layer
docsCableDownstream (128), -- CATV Downstream interface
docsCableUpstream (129), -- CATV Upstream interface
a12MppSwitch (130), -- Avalon Parallel Processor
tunnel (131), -- Encapsulation interface
coffee (132), -- coffee pot
ces (133), -- Circuit Emulation Service
atmSubInterface (134), -- ATM Sub Interface
l2vlan (135), -- Layer 2 Virtual LAN using 802.1Q
l3ipvlan (136), -- Layer 3 Virtual LAN using IP
l3ipxvlan (137), -- Layer 3 Virtual LAN using IPX
digitalPowerline (138), -- IP over Power Lines
mediaMailOverIp (139), -- Multimedia Mail over IP
dtm (140), -- Dynamic syncronous Transfer Mode
dcn (141), -- Data Communications Network
ipForward (142), -- IP Forwarding Interface
msdsl (143), -- Multi-rate Symmetric DSL
ieee1394 (144), -- IEEE1394 High Performance Serial Bus
if-gsn (145), -- HIPPI-6400
dvbRccMacLayer (146), -- DVB-RCC MAC Layer
dvbRccDownstream (147), -- DVB-RCC Downstream Channel
dvbRccUpstream (148), -- DVB-RCC Upstream Channel
atmVirtual (149), -- ATM Virtual Interface
mplsTunnel (150), -- MPLS Tunnel Virtual Interface
srp (151), -- Spatial Reuse Protocol
voiceOverAtm (152), -- Voice Over ATM
voiceOverFrameRelay (153), -- Voice Over Frame Relay
idsl (154), -- Digital Subscriber Loop over ISDN
compositeLink (155), -- Avici Composite Link Interface
ss7SigLink (156), -- SS7 Signaling Link
propWirelessP2P (157), -- Prop. P2P wireless interface
frForward (158), -- Frame Forward Interface
rfc1483 (159), -- Multiprotocol over ATM AAL5
usb (160), -- USB Interface
ieee8023adLag (161), -- IEEE 802.3ad Link Aggregate
bgppolicyaccounting (162), -- BGP Policy Accounting
frf16MfrBundle (163), -- FRF .16 Multilink Frame Relay
h323Gatekeeper (164), -- H323 Gatekeeper
h323Proxy (165), -- H323 Voice and Video Proxy
mpls (166), -- MPLS
mfSigLink (167), -- Multi-frequency signaling link
hdsl2 (168), -- High Bit-Rate DSL - 2nd generation
shdsl (169), -- Multirate HDSL2
ds1FDL (170), -- Facility Data Link 4Kbps on a DS1
pos (171), -- Packet over SONET/SDH Interface
dvbAsiIn (172), -- DVB-ASI Input
dvbAsiOut (173), -- DVB-ASI Output
plc (174), -- Power Line Communtications
nfas (175), -- Non Facility Associated Signaling
tr008 (176), -- TR008
gr303RDT (177), -- Remote Digital Terminal
gr303IDT (178), -- Integrated Digital Terminal
isup (179), -- ISUP
propDocsWirelessMaclayer (180), -- Cisco proprietary Maclayer
propDocsWirelessDownstream (181), -- Cisco proprietary Downstream
propDocsWirelessUpstream (182), -- Cisco proprietary Upstream
hiperlan2 (183), -- HIPERLAN Type 2 Radio Interface
propBWAp2Mp (184), -- PropBroadbandWirelessAccesspt2multipt
-- use of this iftype for IEEE 802.16 WMAN
-- interfaces as per IEEE Std 802.16f is
-- deprecated and ifType 237 should be used instead.
sonetOverheadChannel (185), -- SONET Overhead Channel
digitalWrapperOverheadChannel (186), -- Digital Wrapper
aal2 (187), -- ATM adaptation layer 2
radioMAC (188), -- MAC layer over radio links
atmRadio (189), -- ATM over radio links
imt (190), -- Inter Machine Trunks
mvl (191), -- Multiple Virtual Lines DSL
reachDSL (192), -- Long Reach DSL
frDlciEndPt (193), -- Frame Relay DLCI End Point
atmVciEndPt (194), -- ATM VCI End Point
opticalChannel (195), -- Optical Channel
opticalTransport (196), -- Optical Transport
propAtm (197), -- Proprietary ATM
voiceOverCable (198), -- Voice Over Cable Interface
infiniband (199), -- Infiniband
teLink (200), -- TE Link
q2931 (201), -- Q.2931
virtualTg (202), -- Virtual Trunk Group
sipTg (203), -- SIP Trunk Group
sipSig (204), -- SIP Signaling
docsCableUpstreamChannel (205), -- CATV Upstream Channel
econet (206), -- Acorn Econet
pon155 (207), -- FSAN 155Mb Symetrical PON interface
pon622 (208), -- FSAN622Mb Symetrical PON interface
bridge (209), -- Transparent bridge interface
linegroup (210), -- Interface common to multiple lines
voiceEMFGD (211), -- voice E&M Feature Group D
voiceFGDEANA (212), -- voice FGD Exchange Access North American
voiceDID (213), -- voice Direct Inward Dialing
mpegTransport (214), -- MPEG transport interface
sixToFour (215), -- 6to4 interface (DEPRECATED)
gtp (216), -- GTP (GPRS Tunneling Protocol)
pdnEtherLoop1 (217), -- Paradyne EtherLoop 1
pdnEtherLoop2 (218), -- Paradyne EtherLoop 2
opticalChannelGroup (219), -- Optical Channel Group
homepna (220), -- HomePNA ITU-T G.989
gfp (221), -- Generic Framing Procedure (GFP)
ciscoISLvlan (222), -- Layer 2 Virtual LAN using Cisco ISL
actelisMetaLOOP (223), -- Acteleis proprietary MetaLOOP High Speed Link
fcipLink (224), -- FCIP Link
rpr (225), -- Resilient Packet Ring Interface Type
qam (226), -- RF Qam Interface
lmp (227), -- Link Management Protocol
cblVectaStar (228), -- Cambridge Broadband Networks Limited VectaStar
docsCableMCmtsDownstream (229), -- CATV Modular CMTS Downstream Interface
adsl2 (230), -- Asymmetric Digital Subscriber Loop Version 2
-- (DEPRECATED/OBSOLETED - please use adsl2plus 238 instead)
macSecControlledIF (231), -- MACSecControlled
macSecUncontrolledIF (232), -- MACSecUncontrolled
aviciOpticalEther (233), -- Avici Optical Ethernet Aggregate
atmbond (234), -- atmbond
voiceFGDOS (235), -- voice FGD Operator Services
mocaVersion1 (236), -- MultiMedia over Coax Alliance (MoCA) Interface
-- as documented in information provided privately to IANA
ieee80216WMAN (237), -- IEEE 802.16 WMAN interface
adsl2plus (238), -- Asymmetric Digital Subscriber Loop Version 2,
-- Version 2 Plus and all variants
dvbRcsMacLayer (239), -- DVB-RCS MAC Layer
dvbTdm (240), -- DVB Satellite TDM
dvbRcsTdma (241), -- DVB-RCS TDMA
x86Laps (242), -- LAPS based on ITU-T X.86/Y.1323
wwanPP (243), -- 3GPP WWAN
wwanPP2 (244), -- 3GPP2 WWAN
voiceEBS (245), -- voice P-phone EBS physical interface
ifPwType (246), -- Pseudowire interface type
ilan (247), -- Internal LAN on a bridge per IEEE 802.1ap
pip (248), -- Provider Instance Port on a bridge per IEEE 802.1ah PBB
aluELP (249), -- Alcatel-Lucent Ethernet Link Protection
gpon (250), -- Gigabit-capable passive optical networks (G-PON) as per ITU-T G.984
vdsl2 (251), -- Very high speed digital subscriber line Version 2 (as per ITU-T Recommendation G.993.2)
capwapDot11Profile (252), -- WLAN Profile Interface
capwapDot11Bss (253), -- WLAN BSS Interface
capwapWtpVirtualRadio (254), -- WTP Virtual Radio Interface
bits (255), -- bitsport
docsCableUpstreamRfPort (256), -- DOCSIS CATV Upstream RF Port
cableDownstreamRfPort (257), -- CATV downstream RF port
vmwareVirtualNic (258), -- VMware Virtual Network Interface
ieee802154 (259), -- IEEE 802.15.4 WPAN interface
otnOdu (260), -- OTN Optical Data Unit
otnOtu (261), -- OTN Optical channel Transport Unit
ifVfiType (262), -- VPLS Forwarding Instance Interface Type
g9981 (263), -- G.998.1 bonded interface
g9982 (264), -- G.998.2 bonded interface
g9983 (265), -- G.998.3 bonded interface
aluEpon (266), -- Ethernet Passive Optical Networks (E-PON)
aluEponOnu (267), -- EPON Optical Network Unit
aluEponPhysicalUni (268), -- EPON physical User to Network interface
aluEponLogicalLink (269), -- The emulation of a point-to-point link over the EPON layer
aluGponOnu (270), -- GPON Optical Network Unit
aluGponPhysicalUni (271), -- GPON physical User to Network interface
vmwareNicTeam (272), -- VMware NIC Team
docsOfdmDownstream (277), -- CATV Downstream OFDM interface
docsOfdmaUpstream (278), -- CATV Upstream OFDMA interface
gfast (279), -- G.fast port
sdci (280), -- SDCI (IO-Link)
xboxWireless (281), -- Xbox wireless
fastdsl (282), -- FastDSL
docsCableScte55d1FwdOob (283), -- Cable SCTE 55-1 OOB Forward Channel
docsCableScte55d1RetOob (284), -- Cable SCTE 55-1 OOB Return Channel
docsCableScte55d2DsOob (285), -- Cable SCTE 55-2 OOB Downstream Channel
docsCableScte55d2UsOob (286), -- Cable SCTE 55-2 OOB Upstream Channel
docsCableNdf (287), -- Cable Narrowband Digital Forward
docsCableNdr (288), -- Cable Narrowband Digital Return
ptm (289), -- Packet Transfer Mode
ghn (290), -- G.hn port
otnOtsi (291), -- Optical Tributary Signal
otnOtuc (292), -- OTN OTUCn
otnOduc (293), -- OTN ODUC
otnOtsig (294), -- OTN OTUC Signal
microwaveCarrierTermination (295), -- air interface of a single microwave carrier
microwaveRadioLinkTerminal (296), -- radio link interface for one or several aggregated microwave carriers
ieee8021axDrni (297), -- IEEE 802.1AX Distributed Resilient Network Interface
ax25 (298), -- AX.25 network interfaces
ieee19061nanocom (299), -- Nanoscale and Molecular Communication
cpri (300), -- Common Public Radio Interface
omni (301), -- Overlay Multilink Network Interface (OMNI)
roe (302), -- Radio over Ethernet Interface
p2pOverLan (303) -- Point to Point over LAN interface
}
IANAtunnelType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The encapsulation method used by a tunnel. The value
direct indicates that a packet is encapsulated
directly within a normal IP header, with no
intermediate header, and unicast to the remote tunnel
endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC
1933 IPv6-in-IPv4 tunnel). The value minimal indicates
that a Minimal Forwarding Header (RFC 2004) is
inserted between the outer header and the payload
packet. The value UDP indicates that the payload
packet is encapsulated within a normal UDP packet
(e.g., RFC 1234).
The values sixToFour, sixOverFour, and isatap
indicates that an IPv6 packet is encapsulated directly
within an IPv4 header, with no intermediate header,
and unicast to the destination determined by the 6to4,
6over4, or ISATAP protocol.
The remaining protocol-specific values indicate that a
header of the protocol of that name is inserted
between the outer header and the payload header.
The IP Tunnel MIB [RFC4087] is designed to manage
tunnels of any type over IPv4 and IPv6 networks;
therefore, it already supports IP-in-IP tunnels.
But in a DS-Lite scenario, the tunnel type is
point-to-multipoint IP-in-IP tunnels. The direct(2)
defined in the IP Tunnel MIB only supports point-to-point
tunnels. So, it needs to define a new tunnel type for
DS-Lite.
The assignment policy for IANAtunnelType values is
identical to the policy for assigning IANAifType
values."
SYNTAX INTEGER {
other(1), -- none of the following
direct(2), -- no intermediate header
gre(3), -- GRE encapsulation
minimal(4), -- Minimal encapsulation
l2tp(5), -- L2TP encapsulation
pptp(6), -- PPTP encapsulation
l2f(7), -- L2F encapsulation
udp(8), -- UDP encapsulation
atmp(9), -- ATMP encapsulation
msdp(10), -- MSDP encapsulation
sixToFour(11), -- 6to4 encapsulation
sixOverFour(12), -- 6over4 encapsulation
isatap(13), -- ISATAP encapsulation
teredo(14), -- Teredo encapsulation
ipHttps(15), -- IPHTTPS
softwireMesh(16), -- softwire mesh tunnel
dsLite(17), -- DS-Lite tunnel
aplusp(18), -- A+P encapsulation
ipsectunnelmode(19) -- IpSec tunnel mode encapsulation
}
END

1814
share/snmp/IF-MIB.txt Normal file
View file

File diff suppressed because it is too large Load diff

402
share/snmp/INET-ADDRESS-MIB.txt Normal file
View file

@ -0,0 +1,402 @@
INET-ADDRESS-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
inetAddressMIB MODULE-IDENTITY
LAST-UPDATED "200502040000Z"
ORGANIZATION
"IETF Operations and Management Area"
CONTACT-INFO
"Juergen Schoenwaelder (Editor)
International University Bremen
P.O. Box 750 561
28725 Bremen, Germany
Phone: +49 421 200-3587
EMail: j.schoenwaelder@iu-bremen.de
Send comments to <ietfmibs@ops.ietf.org>."
DESCRIPTION
"This MIB module defines textual conventions for
representing Internet addresses. An Internet
address can be an IPv4 address, an IPv6 address,
or a DNS domain name. This module also defines
textual conventions for Internet port numbers,
autonomous system numbers, and the length of an
Internet address prefix.
Copyright (C) The Internet Society (2005). This version
of this MIB module is part of RFC 4001, see the RFC
itself for full legal notices."
REVISION "200502040000Z"
DESCRIPTION
"Third version, published as RFC 4001. This revision
introduces the InetZoneIndex, InetScopeType, and
InetVersion textual conventions."
REVISION "200205090000Z"
DESCRIPTION
"Second version, published as RFC 3291. This
revision contains several clarifications and
introduces several new textual conventions:
InetAddressPrefixLength, InetPortNumber,
InetAutonomousSystemNumber, InetAddressIPv4z,
and InetAddressIPv6z."
REVISION "200006080000Z"
DESCRIPTION
"Initial version, published as RFC 2851."
::= { mib-2 76 }
InetAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a type of Internet address.
unknown(0) An unknown address type. This value MUST
be used if the value of the corresponding
InetAddress object is a zero-length string.
It may also be used to indicate an IP address
that is not in one of the formats defined
below.
ipv4(1) An IPv4 address as defined by the
InetAddressIPv4 textual convention.
ipv6(2) An IPv6 address as defined by the
InetAddressIPv6 textual convention.
ipv4z(3) A non-global IPv4 address including a zone
index as defined by the InetAddressIPv4z
textual convention.
ipv6z(4) A non-global IPv6 address including a zone
index as defined by the InetAddressIPv6z
textual convention.
dns(16) A DNS domain name as defined by the
InetAddressDNS textual convention.
Each definition of a concrete InetAddressType value must be
accompanied by a definition of a textual convention for use
with that InetAddressType.
To support future extensions, the InetAddressType textual
convention SHOULD NOT be sub-typed in object type definitions.
It MAY be sub-typed in compliance statements in order to
require only a subset of these address types for a compliant
implementation.
Implementations must ensure that InetAddressType objects
and any dependent objects (e.g., InetAddress objects) are
consistent. An inconsistentValue error must be generated
if an attempt to change an InetAddressType object would,
for example, lead to an undefined InetAddress value. In
particular, InetAddressType/InetAddress pairs must be
changed together if the address type changes (e.g., from
ipv6(2) to ipv4(1))."
SYNTAX INTEGER {
unknown(0),
ipv4(1),
ipv6(2),
ipv4z(3),
ipv6z(4),
dns(16)
}
InetAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic Internet address.
An InetAddress value is always interpreted within the context
of an InetAddressType value. Every usage of the InetAddress
textual convention is required to specify the InetAddressType
object that provides the context. It is suggested that the
InetAddressType object be logically registered before the
object(s) that use the InetAddress textual convention, if
they appear in the same logical row.
The value of an InetAddress object must always be
consistent with the value of the associated InetAddressType
object. Attempts to set an InetAddress object to a value
inconsistent with the associated InetAddressType
must fail with an inconsistentValue error.
When this textual convention is used as the syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the object definition MUST include a 'SIZE' clause to
limit the number of potential instance sub-identifiers;
otherwise the applicable constraints MUST be stated in
the appropriate conceptual row DESCRIPTION clauses, or
in the surrounding documentation if there is no single
DESCRIPTION clause that is appropriate."
SYNTAX OCTET STRING (SIZE (0..255))
InetAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d"
STATUS current
DESCRIPTION
"Represents an IPv4 network address:
Octets Contents Encoding
1-4 IPv4 address network-byte order
The corresponding InetAddressType value is ipv4(1).
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (4))
InetAddressIPv6 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x"
STATUS current
DESCRIPTION
"Represents an IPv6 network address:
Octets Contents Encoding
1-16 IPv6 address network-byte order
The corresponding InetAddressType value is ipv6(2).
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (16))
InetAddressIPv4z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d%4d"
STATUS current
DESCRIPTION
"Represents a non-global IPv4 network address, together
with its zone index:
Octets Contents Encoding
1-4 IPv4 address network-byte order
5-8 zone index network-byte order
The corresponding InetAddressType value is ipv4z(3).
The zone index (bytes 5-8) is used to disambiguate identical
address values on nodes that have interfaces attached to
different zones of the same scope. The zone index may contain
the special value 0, which refers to the default zone for each
scope.
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (8))
InetAddressIPv6z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d"
STATUS current
DESCRIPTION
"Represents a non-global IPv6 network address, together
with its zone index:
Octets Contents Encoding
1-16 IPv6 address network-byte order
17-20 zone index network-byte order
The corresponding InetAddressType value is ipv6z(4).
The zone index (bytes 17-20) is used to disambiguate
identical address values on nodes that have interfaces
attached to different zones of the same scope. The zone index
may contain the special value 0, which refers to the default
zone for each scope.
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (20))
InetAddressDNS ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"Represents a DNS domain name. The name SHOULD be fully
qualified whenever possible.
The corresponding InetAddressType is dns(16).
The DESCRIPTION clause of InetAddress objects that may have
InetAddressDNS values MUST fully describe how (and when)
these names are to be resolved to IP addresses.
The resolution of an InetAddressDNS value may require to
query multiple DNS records (e.g., A for IPv4 and AAAA for
IPv6). The order of the resolution process and which DNS
record takes precedence depends on the configuration of the
resolver.
This textual convention SHOULD NOT be used directly in object
definitions, as it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or in
conjunction with InetAddressType, as a pair."
SYNTAX OCTET STRING (SIZE (1..255))
InetAddressPrefixLength ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Denotes the length of a generic Internet network address
prefix. A value of n corresponds to an IP address mask
that has n contiguous 1-bits from the most significant
bit (MSB), with all other bits set to 0.
An InetAddressPrefixLength value is always interpreted within
the context of an InetAddressType value. Every usage of the
InetAddressPrefixLength textual convention is required to
specify the InetAddressType object that provides the
context. It is suggested that the InetAddressType object be
logically registered before the object(s) that use the
InetAddressPrefixLength textual convention, if they appear
in the same logical row.
InetAddressPrefixLength values larger than
the maximum length of an IP address for a specific
InetAddressType are treated as the maximum significant
value applicable for the InetAddressType. The maximum
significant value is 32 for the InetAddressType
'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType
'ipv6(2)' and 'ipv6z(4)'. The maximum significant value
for the InetAddressType 'dns(16)' is 0.
The value zero is object-specific and must be defined as
part of the description of any object that uses this
syntax. Examples of the usage of zero might include
situations where the Internet network address prefix
is unknown or does not apply.
The upper bound of the prefix length has been chosen to
be consistent with the maximum size of an InetAddress."
SYNTAX Unsigned32 (0..2040)
InetPortNumber ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Represents a 16 bit port number of an Internet transport
layer protocol. Port numbers are assigned by IANA. A
current list of all assignments is available from
<http://www.iana.org/>.
The value zero is object-specific and must be defined as
part of the description of any object that uses this
syntax. Examples of the usage of zero might include
situations where a port number is unknown, or when the
value zero is used as a wildcard in a filter."
REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960"
SYNTAX Unsigned32 (0..65535)
InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"Represents an autonomous system number that identifies an
Autonomous System (AS). An AS is a set of routers under a
single technical administration, using an interior gateway
protocol and common metrics to route packets within the AS,
and using an exterior gateway protocol to route packets to
other ASes'. IANA maintains the AS number space and has
delegated large parts to the regional registries.
Autonomous system numbers are currently limited to 16 bits
(0..65535). There is, however, work in progress to enlarge the
autonomous system number space to 32 bits. Therefore, this
textual convention uses an Unsigned32 value without a
range restriction in order to support a larger autonomous
system number space."
REFERENCE "RFC 1771, RFC 1930"
SYNTAX Unsigned32
InetScopeType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a scope type. This textual convention can be used
in cases where a MIB has to represent different scope types
and there is no context information, such as an InetAddress
object, that implicitly defines the scope type.
Note that not all possible values have been assigned yet, but
they may be assigned in future revisions of this specification.
Applications should therefore be able to deal with values
not yet assigned."
REFERENCE "RFC 3513"
SYNTAX INTEGER {
-- reserved(0),
interfaceLocal(1),
linkLocal(2),
subnetLocal(3),
adminLocal(4),
siteLocal(5), -- site-local unicast addresses
-- have been deprecated by RFC 3879
-- unassigned(6),
-- unassigned(7),
organizationLocal(8),
-- unassigned(9),
-- unassigned(10),
-- unassigned(11),
-- unassigned(12),
-- unassigned(13),
global(14)
-- reserved(15)
}
InetZoneIndex ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d"
STATUS current
DESCRIPTION
"A zone index identifies an instance of a zone of a
specific scope.
The zone index MUST disambiguate identical address
values. For link-local addresses, the zone index will
typically be the interface index (ifIndex as defined in the
IF-MIB) of the interface on which the address is configured.
The zone index may contain the special value 0, which refers
to the default zone. The default zone may be used in cases
where the valid zone index is not known (e.g., when a
management application has to write a link-local IPv6
address without knowing the interface index value). The
default zone SHOULD NOT be used as an easy way out in
cases where the zone index for a non-global IPv6 address
is known."
REFERENCE "RFC4007"
SYNTAX Unsigned32
InetVersion ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value representing a version of the IP protocol.
unknown(0) An unknown or unspecified version of the IP
protocol.
ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5).
ipv6(2) The IPv6 protocol as defined in RFC 2460.
Note that this textual convention SHOULD NOT be used to
distinguish different address types associated with IP
protocols. The InetAddressType has been designed for this
purpose."
REFERENCE "RFC 791, RFC 2460"
SYNTAX INTEGER {
unknown(0),
ipv4(1),
ipv6(2)
}
END

1277
share/snmp/IP-FORWARD-MIB.txt Normal file
View file

File diff suppressed because it is too large Load diff

4993
share/snmp/IP-MIB.txt Normal file
View file

File diff suppressed because it is too large Load diff

12
share/snmp/Makefile
View file

@ -1,10 +1,20 @@
# $OpenBSD: Makefile,v 1.7 2019/12/21 21:40:00 espie Exp $
# $OpenBSD: Makefile,v 1.8 2024/02/05 11:46:58 martijn Exp $
# OpenBSD
FILES= OPENBSD-SNMPD-CONF.txt OPENBSD-BASE-MIB.txt
FILES+= OPENBSD-MEM-MIB.txt OPENBSD-SENSORS-MIB.txt
FILES+= OPENBSD-CARP-MIB.txt OPENBSD-PF-MIB.txt
FILES+= OPENBSD-RELAYD-MIB.txt
# IANA/IETF
FILES+= BRIDGE-MIB.txt HOST-RESOURCES-MIB.txt IANA-RTPROTO-MIB.txt
FILES+= IANA-STORAGE-MEDIA-TYPE-MIB.txt IANAifType-MIB.txt IF-MIB.txt
FILES+= INET-ADDRESS-MIB.txt IP-FORWARD-MIB.txt IP-MIB.txt
FILES+= SNMP-FRAMEWORK-MIB.txt SNMP-USER-BASED-SM-MIB.txt SNMP-USM-AES-MIB.txt
FILES+= SNMP-USM-HMAC-SHA2-MIB.txt SNMPv2-CONF.txt SNMPv2-MIB.txt SNMPv2-SMI.txt
FILES+= SNMPv2-TC.txt SNMPv2-TM.txt TRANSPORT-ADDRESS-MIB.txt UUID-TC-MIB.txt
FILES+= VM-MIB.txt
all clean cleandir obj tags: _SUBDIRUSE
realinstall:

526
share/snmp/SNMP-FRAMEWORK-MIB.txt Normal file
View file

@ -0,0 +1,526 @@
SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY,
snmpModules FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
snmpFrameworkMIB MODULE-IDENTITY
LAST-UPDATED "200210140000Z"
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-EMail: snmpv3@lists.tislabs.com
Subscribe: snmpv3-request@lists.tislabs.com
Co-Chair: Russ Mundy
Network Associates Laboratories
postal: 15204 Omega Drive, Suite 300
Rockville, MD 20850-4601
USA
EMail: mundy@tislabs.com
phone: +1 301-947-7107
Co-Chair &
Co-editor: David Harrington
Enterasys Networks
postal: 35 Industrial Way
P. O. Box 5005
Rochester, New Hampshire 03866-5005
USA
EMail: dbh@enterasys.com
phone: +1 603-337-2614
Co-editor: Randy Presuhn
BMC Software, Inc.
postal: 2141 North First Street
San Jose, California 95131
USA
EMail: randy_presuhn@bmc.com
phone: +1 408-546-1006
Co-editor: Bert Wijnen
Lucent Technologies
postal: Schagen 33
3461 GL Linschoten
Netherlands
EMail: bwijnen@lucent.com
phone: +31 348-680-485
"
DESCRIPTION "The SNMP Management Architecture MIB
Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3411;
see the RFC itself for full legal notices.
"
REVISION "200210140000Z" -- 14 October 2002
DESCRIPTION "Changes in this revision:
- Updated various administrative information.
- Corrected some typos.
- Corrected typo in description of SnmpEngineID
that led to range overlap for 127.
- Changed '255a' to '255t' in definition of
SnmpAdminString to align with current SMI.
- Reworded 'reserved' for value zero in
DESCRIPTION of SnmpSecurityModel.
- The algorithm for allocating security models
should give 256 per enterprise block, rather
than 255.
- The example engine ID of 'abcd' is not
legal. Replaced with '800002b804616263'H based
on example enterprise 696, string 'abc'.
- Added clarification that engineID should
persist across re-initializations.
This revision published as RFC 3411.
"
REVISION "199901190000Z" -- 19 January 1999
DESCRIPTION "Updated editors' addresses, fixed typos.
Published as RFC 2571.
"
REVISION "199711200000Z" -- 20 November 1997
DESCRIPTION "The initial version, published in RFC 2271.
"
::= { snmpModules 10 }
-- Textual Conventions used in the SNMP Management Architecture ***
SnmpEngineID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An SNMP engine's administratively-unique identifier.
Objects of this type are for identification, not for
addressing, even though it is possible that an
address may have been used in the generation of
a specific value.
The value for this object may not be all zeros or
all 'ff'H or the empty (zero length) string.
The initial value for this object may be configured
via an operator console entry or via an algorithmic
function. In the latter case, the following
example algorithm is recommended.
In cases where there are multiple engines on the
same system, the use of this algorithm is NOT
appropriate, as it would result in all of those
engines ending up with the same ID value.
1) The very first bit is used to indicate how the
rest of the data is composed.
0 - as defined by enterprise using former methods
that existed before SNMPv3. See item 2 below.
1 - as defined by this architecture, see item 3
below.
Note that this allows existing uses of the
engineID (also known as AgentID [RFC1910]) to
co-exist with any new uses.
2) The snmpEngineID has a length of 12 octets.
The first four octets are set to the binary
equivalent of the agent's SNMP management
private enterprise number as assigned by the
Internet Assigned Numbers Authority (IANA).
For example, if Acme Networks has been assigned
{ enterprises 696 }, the first four octets would
be assigned '000002b8'H.
The remaining eight octets are determined via
one or more enterprise-specific methods. Such
methods must be designed so as to maximize the
possibility that the value of this object will
be unique in the agent's administrative domain.
For example, it may be the IP address of the SNMP
entity, or the MAC address of one of the
interfaces, with each address suitably padded
with random octets. If multiple methods are
defined, then it is recommended that the first
octet indicate the method being used and the
remaining octets be a function of the method.
3) The length of the octet string varies.
The first four octets are set to the binary
equivalent of the agent's SNMP management
private enterprise number as assigned by the
Internet Assigned Numbers Authority (IANA).
For example, if Acme Networks has been assigned
{ enterprises 696 }, the first four octets would
be assigned '000002b8'H.
The very first bit is set to 1. For example, the
above value for Acme Networks now changes to be
'800002b8'H.
The fifth octet indicates how the rest (6th and
following octets) are formatted. The values for
the fifth octet are:
0 - reserved, unused.
1 - IPv4 address (4 octets)
lowest non-special IP address
2 - IPv6 address (16 octets)
lowest non-special IP address
3 - MAC address (6 octets)
lowest IEEE MAC address, canonical
order
4 - Text, administratively assigned
Maximum remaining length 27
5 - Octets, administratively assigned
Maximum remaining length 27
6-127 - reserved, unused
128-255 - as defined by the enterprise
Maximum remaining length 27
"
SYNTAX OCTET STRING (SIZE(5..32))
SnmpSecurityModel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An identifier that uniquely identifies a
Security Model of the Security Subsystem within
this SNMP Management Architecture.
The values for securityModel are allocated as
follows:
- The zero value does not identify any particular
security model.
- Values between 1 and 255, inclusive, are reserved
for standards-track Security Models and are
managed by the Internet Assigned Numbers Authority
(IANA).
- Values greater than 255 are allocated to
enterprise-specific Security Models. An
enterprise-specific securityModel value is defined
to be:
enterpriseID * 256 + security model within
enterprise
For example, the fourth Security Model defined by
the enterprise whose enterpriseID is 1 would be
259.
This scheme for allocation of securityModel
values allows for a maximum of 255 standards-
based Security Models, and for a maximum of
256 Security Models per enterprise.
It is believed that the assignment of new
securityModel values will be rare in practice
because the larger the number of simultaneously
utilized Security Models, the larger the
chance that interoperability will suffer.
Consequently, it is believed that such a range
will be sufficient. In the unlikely event that
the standards committee finds this number to be
insufficient over time, an enterprise number
can be allocated to obtain an additional 256
possible values.
Note that the most significant bit must be zero;
hence, there are 23 bits allocated for various
organizations to design and define non-standard
securityModels. This limits the ability to
define new proprietary implementations of Security
Models to the first 8,388,608 enterprises.
It is worthwhile to note that, in its encoded
form, the securityModel value will normally
require only a single byte since, in practice,
the leftmost bits will be zero for most messages
and sign extension is suppressed by the encoding
rules.
As of this writing, there are several values
of securityModel defined for use with SNMP or
reserved for use with supporting MIB objects.
They are as follows:
0 reserved for 'any'
1 reserved for SNMPv1
2 reserved for SNMPv2c
3 User-Based Security Model (USM)
"
SYNTAX INTEGER(0 .. 2147483647)
SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An identifier that uniquely identifies a Message
Processing Model of the Message Processing
Subsystem within this SNMP Management Architecture.
The values for messageProcessingModel are
allocated as follows:
- Values between 0 and 255, inclusive, are
reserved for standards-track Message Processing
Models and are managed by the Internet Assigned
Numbers Authority (IANA).
- Values greater than 255 are allocated to
enterprise-specific Message Processing Models.
An enterprise messageProcessingModel value is
defined to be:
enterpriseID * 256 +
messageProcessingModel within enterprise
For example, the fourth Message Processing Model
defined by the enterprise whose enterpriseID
is 1 would be 259.
This scheme for allocating messageProcessingModel
values allows for a maximum of 255 standards-
based Message Processing Models, and for a
maximum of 256 Message Processing Models per
enterprise.
It is believed that the assignment of new
messageProcessingModel values will be rare
in practice because the larger the number of
simultaneously utilized Message Processing Models,
the larger the chance that interoperability
will suffer. It is believed that such a range
will be sufficient. In the unlikely event that
the standards committee finds this number to be
insufficient over time, an enterprise number
can be allocated to obtain an additional 256
possible values.
Note that the most significant bit must be zero;
hence, there are 23 bits allocated for various
organizations to design and define non-standard
messageProcessingModels. This limits the ability
to define new proprietary implementations of
Message Processing Models to the first 8,388,608
enterprises.
It is worthwhile to note that, in its encoded
form, the messageProcessingModel value will
normally require only a single byte since, in
practice, the leftmost bits will be zero for
most messages and sign extension is suppressed
by the encoding rules.
As of this writing, there are several values of
messageProcessingModel defined for use with SNMP.
They are as follows:
0 reserved for SNMPv1
1 reserved for SNMPv2c
2 reserved for SNMPv2u and SNMPv2*
3 reserved for SNMPv3
"
SYNTAX INTEGER(0 .. 2147483647)
SnmpSecurityLevel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "A Level of Security at which SNMP messages can be
sent or with which operations are being processed;
in particular, one of:
noAuthNoPriv - without authentication and
without privacy,
authNoPriv - with authentication but
without privacy,
authPriv - with authentication and
with privacy.
These three values are ordered such that
noAuthNoPriv is less than authNoPriv and
authNoPriv is less than authPriv.
"
SYNTAX INTEGER { noAuthNoPriv(1),
authNoPriv(2),
authPriv(3)
}
SnmpAdminString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255t"
STATUS current
DESCRIPTION "An octet string containing administrative
information, preferably in human-readable form.
To facilitate internationalization, this
information is represented using the ISO/IEC
IS 10646-1 character set, encoded as an octet
string using the UTF-8 transformation format
described in [RFC2279].
Since additional code points are added by
amendments to the 10646 standard from time
to time, implementations must be prepared to
encounter any code point from 0x00000000 to
0x7fffffff. Byte sequences that do not
correspond to the valid UTF-8 encoding of a
code point or are outside this range are
prohibited.
The use of control codes should be avoided.
When it is necessary to represent a newline,
the control code sequence CR LF should be used.
The use of leading or trailing white space should
be avoided.
For code points not directly supported by user
interface hardware or software, an alternative
means of entry and display, such as hexadecimal,
may be provided.
For information encoded in 7-bit US-ASCII,
the UTF-8 encoding is identical to the
US-ASCII encoding.
UTF-8 may require multiple bytes to represent a
single character / code point; thus the length
of this object in octets may be different from
the number of characters encoded. Similarly,
size constraints refer to the number of encoded
octets, not the number of characters represented
by an encoding.
Note that when this TC is used for an object that
is used or envisioned to be used as an index, then
a SIZE restriction MUST be specified so that the
number of sub-identifiers for any object instance
does not exceed the limit of 128, as defined by
[RFC3416].
Note that the size of an SnmpAdminString object is
measured in octets, not characters.
"
SYNTAX OCTET STRING (SIZE (0..255))
-- Administrative assignments ***************************************
snmpFrameworkAdmin
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
snmpFrameworkMIBObjects
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
snmpFrameworkMIBConformance
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }
-- the snmpEngine Group ********************************************
snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }
snmpEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An SNMP engine's administratively-unique identifier.
This information SHOULD be stored in non-volatile
storage so that it remains constant across
re-initializations of the SNMP engine.
"
::= { snmpEngine 1 }
snmpEngineBoots OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times that the SNMP engine has
(re-)initialized itself since snmpEngineID
was last configured.
"
::= { snmpEngine 2 }
snmpEngineTime OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of seconds since the value of
the snmpEngineBoots object last changed.
When incrementing this object's value would
cause it to exceed its maximum,
snmpEngineBoots is incremented as if a
re-initialization had occurred, and this
object's value consequently reverts to zero.
"
::= { snmpEngine 3 }
snmpEngineMaxMessageSize OBJECT-TYPE
SYNTAX INTEGER (484..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum length in octets of an SNMP message
which this SNMP engine can send or receive and
process, determined as the minimum of the maximum
message size values supported among all of the
transports available to and supported by the engine.
"
::= { snmpEngine 4 }
-- Registration Points for Authentication and Privacy Protocols **
snmpAuthProtocols OBJECT-IDENTITY
STATUS current
DESCRIPTION "Registration point for standards-track
authentication protocols used in SNMP Management
Frameworks.
"
::= { snmpFrameworkAdmin 1 }
snmpPrivProtocols OBJECT-IDENTITY
STATUS current
DESCRIPTION "Registration point for standards-track privacy
protocols used in SNMP Management Frameworks.
"
::= { snmpFrameworkAdmin 2 }
-- Conformance information ******************************************
snmpFrameworkMIBCompliances
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
snmpFrameworkMIBGroups
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}
-- compliance statements
snmpFrameworkMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines which
implement the SNMP Management Framework MIB.
"
MODULE -- this module
MANDATORY-GROUPS { snmpEngineGroup }
::= { snmpFrameworkMIBCompliances 1 }
-- units of conformance
snmpEngineGroup OBJECT-GROUP
OBJECTS {
snmpEngineID,
snmpEngineBoots,
snmpEngineTime,
snmpEngineMaxMessageSize
}
STATUS current
DESCRIPTION "A collection of objects for identifying and
determining the configuration and current timeliness
values of an SNMP engine.
"
::= { snmpFrameworkMIBGroups 1 }
END

912
share/snmp/SNMP-USER-BASED-SM-MIB.txt Normal file
View file

@ -0,0 +1,912 @@
SNMP-USER-BASED-SM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE,
OBJECT-IDENTITY,
snmpModules, Counter32 FROM SNMPv2-SMI
TEXTUAL-CONVENTION, TestAndIncr,
RowStatus, RowPointer,
StorageType, AutonomousType FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF
SnmpAdminString, SnmpEngineID,
snmpAuthProtocols, snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB;
snmpUsmMIB MODULE-IDENTITY
LAST-UPDATED "200210160000Z" -- 16 Oct 2002, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG-email: snmpv3@lists.tislabs.com
Subscribe: majordomo@lists.tislabs.com
In msg body: subscribe snmpv3
Chair: Russ Mundy
Network Associates Laboratories
postal: 15204 Omega Drive, Suite 300
Rockville, MD 20850-4601
USA
email: mundy@tislabs.com
phone: +1 301-947-7107
Co-Chair: David Harrington
Enterasys Networks
Postal: 35 Industrial Way
P. O. Box 5004
Rochester, New Hampshire 03866-5005
USA
EMail: dbh@enterasys.com
Phone: +1 603-337-2614
Co-editor Uri Blumenthal
Lucent Technologies
postal: 67 Whippany Rd.
Whippany, NJ 07981
USA
email: uri@lucent.com
phone: +1-973-386-2163
Co-editor: Bert Wijnen
Lucent Technologies
postal: Schagen 33
3461 GL Linschoten
Netherlands
email: bwijnen@lucent.com
phone: +31-348-480-685
"
DESCRIPTION "The management information definitions for the
SNMP User-based Security Model.
Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3414;
see the RFC itself for full legal notices.
"
-- Revision history
REVISION "200210160000Z" -- 16 Oct 2002, midnight
DESCRIPTION "Changes in this revision:
- Updated references and contact info.
- Clarification to usmUserCloneFrom DESCRIPTION
clause
- Fixed 'command responder' into 'command generator'
in last para of DESCRIPTION clause of
usmUserTable.
This revision published as RFC3414.
"
REVISION "199901200000Z" -- 20 Jan 1999, midnight
DESCRIPTION "Clarifications, published as RFC2574"
REVISION "199711200000Z" -- 20 Nov 1997, midnight
DESCRIPTION "Initial version, published as RFC2274"
::= { snmpModules 15 }
-- Administrative assignments ****************************************
usmMIBObjects OBJECT IDENTIFIER ::= { snmpUsmMIB 1 }
usmMIBConformance OBJECT IDENTIFIER ::= { snmpUsmMIB 2 }
-- Identification of Authentication and Privacy Protocols ************
usmNoAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "No Authentication Protocol."
::= { snmpAuthProtocols 1 }
usmHMACMD5AuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The HMAC-MD5-96 Digest Authentication Protocol."
REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti HMAC:
Keyed-Hashing for Message Authentication,
RFC2104, Feb 1997.
- Rivest, R., Message Digest Algorithm MD5, RFC1321.
"
::= { snmpAuthProtocols 2 }
usmHMACSHAAuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The HMAC-SHA-96 Digest Authentication Protocol."
REFERENCE "- H. Krawczyk, M. Bellare, R. Canetti, HMAC:
Keyed-Hashing for Message Authentication,
RFC2104, Feb 1997.
- Secure Hash Algorithm. NIST FIPS 180-1.
"
::= { snmpAuthProtocols 3 }
usmNoPrivProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "No Privacy Protocol."
::= { snmpPrivProtocols 1 }
usmDESPrivProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The CBC-DES Symmetric Encryption Protocol."
REFERENCE "- Data Encryption Standard, National Institute of
Standards and Technology. Federal Information
Processing Standard (FIPS) Publication 46-1.
Supersedes FIPS Publication 46,
(January, 1977; reaffirmed January, 1988).
- Data Encryption Algorithm, American National
Standards Institute. ANSI X3.92-1981,
(December, 1980).
- DES Modes of Operation, National Institute of
Standards and Technology. Federal Information
Processing Standard (FIPS) Publication 81,
(December, 1980).
- Data Encryption Algorithm - Modes of Operation,
American National Standards Institute.
ANSI X3.106-1983, (May 1983).
"
::= { snmpPrivProtocols 2 }
-- Textual Conventions ***********************************************
KeyChange ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Every definition of an object with this syntax must identify
a protocol P, a secret key K, and a hash algorithm H
that produces output of L octets.
The object's value is a manager-generated, partially-random
value which, when modified, causes the value of the secret
key K, to be modified via a one-way function.
The value of an instance of this object is the concatenation
of two components: first a 'random' component and then a
'delta' component.
The lengths of the random and delta components
are given by the corresponding value of the protocol P;
if P requires K to be a fixed length, the length of both the
random and delta components is that fixed length; if P
allows the length of K to be variable up to a particular
maximum length, the length of the random component is that
maximum length and the length of the delta component is any
length less than or equal to that maximum length.
For example, usmHMACMD5AuthProtocol requires K to be a fixed
length of 16 octets and L - of 16 octets.
usmHMACSHAAuthProtocol requires K to be a fixed length of
20 octets and L - of 20 octets. Other protocols may define
other sizes, as deemed appropriate.
When a requester wants to change the old key K to a new
key keyNew on a remote entity, the 'random' component is
obtained from either a true random generator, or from a
pseudorandom generator, and the 'delta' component is
computed as follows:
- a temporary variable is initialized to the existing value
of K;
- if the length of the keyNew is greater than L octets,
then:
- the random component is appended to the value of the
temporary variable, and the result is input to the
the hash algorithm H to produce a digest value, and
the temporary variable is set to this digest value;
- the value of the temporary variable is XOR-ed with
the first (next) L-octets (16 octets in case of MD5)
of the keyNew to produce the first (next) L-octets
(16 octets in case of MD5) of the 'delta' component.
- the above two steps are repeated until the unused
portion of the keyNew component is L octets or less,
- the random component is appended to the value of the
temporary variable, and the result is input to the
hash algorithm H to produce a digest value;
- this digest value, truncated if necessary to be the same
length as the unused portion of the keyNew, is XOR-ed
with the unused portion of the keyNew to produce the
(final portion of the) 'delta' component.
For example, using MD5 as the hash algorithm H:
iterations = (lenOfDelta - 1)/16; /* integer division */
temp = keyOld;
for (i = 0; i < iterations; i++) {
temp = MD5 (temp || random);
delta[i*16 .. (i*16)+15] =
temp XOR keyNew[i*16 .. (i*16)+15];
}
temp = MD5 (temp || random);
delta[i*16 .. lenOfDelta-1] =
temp XOR keyNew[i*16 .. lenOfDelta-1];
The 'random' and 'delta' components are then concatenated as
described above, and the resulting octet string is sent to
the recipient as the new value of an instance of this object.
At the receiver side, when an instance of this object is set
to a new value, then a new value of K is computed as follows:
- a temporary variable is initialized to the existing value
of K;
- if the length of the delta component is greater than L
octets, then:
- the random component is appended to the value of the
temporary variable, and the result is input to the
hash algorithm H to produce a digest value, and the
temporary variable is set to this digest value;
- the value of the temporary variable is XOR-ed with
the first (next) L-octets (16 octets in case of MD5)
of the delta component to produce the first (next)
L-octets (16 octets in case of MD5) of the new value
of K.
- the above two steps are repeated until the unused
portion of the delta component is L octets or less,
- the random component is appended to the value of the
temporary variable, and the result is input to the
hash algorithm H to produce a digest value;
- this digest value, truncated if necessary to be the same
length as the unused portion of the delta component, is
XOR-ed with the unused portion of the delta component to
produce the (final portion of the) new value of K.
For example, using MD5 as the hash algorithm H:
iterations = (lenOfDelta - 1)/16; /* integer division */
temp = keyOld;
for (i = 0; i < iterations; i++) {
temp = MD5 (temp || random);
keyNew[i*16 .. (i*16)+15] =
temp XOR delta[i*16 .. (i*16)+15];
}
temp = MD5 (temp || random);
keyNew[i*16 .. lenOfDelta-1] =
temp XOR delta[i*16 .. lenOfDelta-1];
The value of an object with this syntax, whenever it is
retrieved by the management protocol, is always the zero
length string.
Note that the keyOld and keyNew are the localized keys.
Note that it is probably wise that when an SNMP entity sends
a SetRequest to change a key, that it keeps a copy of the old
key until it has confirmed that the key change actually
succeeded.
"
SYNTAX OCTET STRING
-- Statistics for the User-based Security Model **********************
usmStats OBJECT IDENTIFIER ::= { usmMIBObjects 1 }
usmStatsUnsupportedSecLevels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they requested a
securityLevel that was unknown to the SNMP engine
or otherwise unavailable.
"
::= { usmStats 1 }
usmStatsNotInTimeWindows OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they appeared
outside of the authoritative SNMP engine's window.
"
::= { usmStats 2 }
usmStatsUnknownUserNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they referenced a
user that was not known to the SNMP engine.
"
::= { usmStats 3 }
usmStatsUnknownEngineIDs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they referenced an
snmpEngineID that was not known to the SNMP engine.
"
::= { usmStats 4 }
usmStatsWrongDigests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they didn't
contain the expected digest value.
"
::= { usmStats 5 }
usmStatsDecryptionErrors OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The total number of packets received by the SNMP
engine which were dropped because they could not be
decrypted.
"
::= { usmStats 6 }
-- The usmUser Group ************************************************
usmUser OBJECT IDENTIFIER ::= { usmMIBObjects 2 }
usmUserSpinLock OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION "An advisory lock used to allow several cooperating
Command Generator Applications to coordinate their
use of facilities to alter secrets in the
usmUserTable.
"
::= { usmUser 1 }
-- The table of valid users for the User-based Security Model ********
usmUserTable OBJECT-TYPE
SYNTAX SEQUENCE OF UsmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "The table of users configured in the SNMP engine's
Local Configuration Datastore (LCD).
To create a new user (i.e., to instantiate a new
conceptual row in this table), it is recommended to
follow this procedure:
1) GET(usmUserSpinLock.0) and save in sValue.
2) SET(usmUserSpinLock.0=sValue,
usmUserCloneFrom=templateUser,
usmUserStatus=createAndWait)
You should use a template user to clone from
which has the proper auth/priv protocol defined.
If the new user is to use privacy:
3) generate the keyChange value based on the secret
privKey of the clone-from user and the secret key
to be used for the new user. Let us call this
pkcValue.
4) GET(usmUserSpinLock.0) and save in sValue.
5) SET(usmUserSpinLock.0=sValue,
usmUserPrivKeyChange=pkcValue
usmUserPublic=randomValue1)
6) GET(usmUserPulic) and check it has randomValue1.
If not, repeat steps 4-6.
If the new user will never use privacy:
7) SET(usmUserPrivProtocol=usmNoPrivProtocol)
If the new user is to use authentication:
8) generate the keyChange value based on the secret
authKey of the clone-from user and the secret key
to be used for the new user. Let us call this
akcValue.
9) GET(usmUserSpinLock.0) and save in sValue.
10) SET(usmUserSpinLock.0=sValue,
usmUserAuthKeyChange=akcValue
usmUserPublic=randomValue2)
11) GET(usmUserPulic) and check it has randomValue2.
If not, repeat steps 9-11.
If the new user will never use authentication:
12) SET(usmUserAuthProtocol=usmNoAuthProtocol)
Finally, activate the new user:
13) SET(usmUserStatus=active)
The new user should now be available and ready to be
used for SNMPv3 communication. Note however that access
to MIB data must be provided via configuration of the
SNMP-VIEW-BASED-ACM-MIB.
The use of usmUserSpinlock is to avoid conflicts with
another SNMP command generator application which may
also be acting on the usmUserTable.
"
::= { usmUser 2 }
usmUserEntry OBJECT-TYPE
SYNTAX UsmUserEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A user configured in the SNMP engine's Local
Configuration Datastore (LCD) for the User-based
Security Model.
"
INDEX { usmUserEngineID,
usmUserName
}
::= { usmUserTable 1 }
UsmUserEntry ::= SEQUENCE
{
usmUserEngineID SnmpEngineID,
usmUserName SnmpAdminString,
usmUserSecurityName SnmpAdminString,
usmUserCloneFrom RowPointer,
usmUserAuthProtocol AutonomousType,
usmUserAuthKeyChange KeyChange,
usmUserOwnAuthKeyChange KeyChange,
usmUserPrivProtocol AutonomousType,
usmUserPrivKeyChange KeyChange,
usmUserOwnPrivKeyChange KeyChange,
usmUserPublic OCTET STRING,
usmUserStorageType StorageType,
usmUserStatus RowStatus
}
usmUserEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "An SNMP engine's administratively-unique identifier.
In a simple agent, this value is always that agent's
own snmpEngineID value.
The value can also take the value of the snmpEngineID
of a remote SNMP engine with which this user can
communicate.
"
::= { usmUserEntry 1 }
usmUserName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..32))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION "A human readable string representing the name of
the user.
This is the (User-based Security) Model dependent
security ID.
"
::= { usmUserEntry 2 }
usmUserSecurityName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION "A human readable string representing the user in
Security Model independent format.
The default transformation of the User-based Security
Model dependent security ID to the securityName and
vice versa is the identity function so that the
securityName is the same as the userName.
"
::= { usmUserEntry 3 }
usmUserCloneFrom OBJECT-TYPE
SYNTAX RowPointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A pointer to another conceptual row in this
usmUserTable. The user in this other conceptual
row is called the clone-from user.
When a new user is created (i.e., a new conceptual
row is instantiated in this table), the privacy and
authentication parameters of the new user must be
cloned from its clone-from user. These parameters are:
- authentication protocol (usmUserAuthProtocol)
- privacy protocol (usmUserPrivProtocol)
They will be copied regardless of what the current
value is.
Cloning also causes the initial values of the secret
authentication key (authKey) and the secret encryption
key (privKey) of the new user to be set to the same
values as the corresponding secrets of the clone-from
user to allow the KeyChange process to occur as
required during user creation.
The first time an instance of this object is set by
a management operation (either at or after its
instantiation), the cloning process is invoked.
Subsequent writes are successful but invoke no
action to be taken by the receiver.
The cloning process fails with an 'inconsistentName'
error if the conceptual row representing the
clone-from user does not exist or is not in an active
state when the cloning process is invoked.
When this object is read, the ZeroDotZero OID
is returned.
"
::= { usmUserEntry 4 }
usmUserAuthProtocol OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "An indication of whether messages sent on behalf of
this user to/from the SNMP engine identified by
usmUserEngineID, can be authenticated, and if so,
the type of authentication protocol which is used.
An instance of this object is created concurrently
with the creation of any other object instance for
the same user (i.e., as part of the processing of
the set operation which creates the first object
instance in the same conceptual row).
If an initial set operation (i.e. at row creation time)
tries to set a value for an unknown or unsupported
protocol, then a 'wrongValue' error must be returned.
The value will be overwritten/set when a set operation
is performed on the corresponding instance of
usmUserCloneFrom.
Once instantiated, the value of such an instance of
this object can only be changed via a set operation to
the value of the usmNoAuthProtocol.
If a set operation tries to change the value of an
existing instance of this object to any value other
than usmNoAuthProtocol, then an 'inconsistentValue'
error must be returned.
If a set operation tries to set the value to the
usmNoAuthProtocol while the usmUserPrivProtocol value
in the same row is not equal to usmNoPrivProtocol,
then an 'inconsistentValue' error must be returned.
That means that an SNMP command generator application
must first ensure that the usmUserPrivProtocol is set
to the usmNoPrivProtocol value before it can set
the usmUserAuthProtocol value to usmNoAuthProtocol.
"
DEFVAL { usmNoAuthProtocol }
::= { usmUserEntry 5 }
usmUserAuthKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5
-- typically (SIZE (0 | 40)) for HMACSHA
MAX-ACCESS read-create
STATUS current
DESCRIPTION "An object, which when modified, causes the secret
authentication key used for messages sent on behalf
of this user to/from the SNMP engine identified by
usmUserEngineID, to be modified via a one-way
function.
The associated protocol is the usmUserAuthProtocol.
The associated secret key is the user's secret
authentication key (authKey). The associated hash
algorithm is the algorithm used by the user's
usmUserAuthProtocol.
When creating a new user, it is an 'inconsistentName'
error for a set operation to refer to this object
unless it is previously or concurrently initialized
through a set operation on the corresponding instance
of usmUserCloneFrom.
When the value of the corresponding usmUserAuthProtocol
is usmNoAuthProtocol, then a set is successful, but
effectively is a no-op.
When this object is read, the zero-length (empty)
string is returned.
The recommended way to do a key change is as follows:
1) GET(usmUserSpinLock.0) and save in sValue.
2) generate the keyChange value based on the old
(existing) secret key and the new secret key,
let us call this kcValue.
If you do the key change on behalf of another user:
3) SET(usmUserSpinLock.0=sValue,
usmUserAuthKeyChange=kcValue
usmUserPublic=randomValue)
If you do the key change for yourself:
4) SET(usmUserSpinLock.0=sValue,
usmUserOwnAuthKeyChange=kcValue
usmUserPublic=randomValue)
If you get a response with error-status of noError,
then the SET succeeded and the new key is active.
If you do not get a response, then you can issue a
GET(usmUserPublic) and check if the value is equal
to the randomValue you did send in the SET. If so, then
the key change succeeded and the new key is active
(probably the response got lost). If not, then the SET
request probably never reached the target and so you
can start over with the procedure above.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 6 }
usmUserOwnAuthKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for HMACMD5
-- typically (SIZE (0 | 40)) for HMACSHA
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Behaves exactly as usmUserAuthKeyChange, with one
notable difference: in order for the set operation
to succeed, the usmUserName of the operation
requester must match the usmUserName that
indexes the row which is targeted by this
operation.
In addition, the USM security model must be
used for this operation.
The idea here is that access to this column can be
public, since it will only allow a user to change
his own secret authentication key (authKey).
Note that this can only be done once the row is active.
When a set is received and the usmUserName of the
requester is not the same as the umsUserName that
indexes the row which is targeted by this operation,
then a 'noAccess' error must be returned.
When a set is received and the security model in use
is not USM, then a 'noAccess' error must be returned.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 7 }
usmUserPrivProtocol OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "An indication of whether messages sent on behalf of
this user to/from the SNMP engine identified by
usmUserEngineID, can be protected from disclosure,
and if so, the type of privacy protocol which is used.
An instance of this object is created concurrently
with the creation of any other object instance for
the same user (i.e., as part of the processing of
the set operation which creates the first object
instance in the same conceptual row).
If an initial set operation (i.e. at row creation time)
tries to set a value for an unknown or unsupported
protocol, then a 'wrongValue' error must be returned.
The value will be overwritten/set when a set operation
is performed on the corresponding instance of
usmUserCloneFrom.
Once instantiated, the value of such an instance of
this object can only be changed via a set operation to
the value of the usmNoPrivProtocol.
If a set operation tries to change the value of an
existing instance of this object to any value other
than usmNoPrivProtocol, then an 'inconsistentValue'
error must be returned.
Note that if any privacy protocol is used, then you
must also use an authentication protocol. In other
words, if usmUserPrivProtocol is set to anything else
than usmNoPrivProtocol, then the corresponding instance
of usmUserAuthProtocol cannot have a value of
usmNoAuthProtocol. If it does, then an
'inconsistentValue' error must be returned.
"
DEFVAL { usmNoPrivProtocol }
::= { usmUserEntry 8 }
usmUserPrivKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES
MAX-ACCESS read-create
STATUS current
DESCRIPTION "An object, which when modified, causes the secret
encryption key used for messages sent on behalf
of this user to/from the SNMP engine identified by
usmUserEngineID, to be modified via a one-way
function.
The associated protocol is the usmUserPrivProtocol.
The associated secret key is the user's secret
privacy key (privKey). The associated hash
algorithm is the algorithm used by the user's
usmUserAuthProtocol.
When creating a new user, it is an 'inconsistentName'
error for a set operation to refer to this object
unless it is previously or concurrently initialized
through a set operation on the corresponding instance
of usmUserCloneFrom.
When the value of the corresponding usmUserPrivProtocol
is usmNoPrivProtocol, then a set is successful, but
effectively is a no-op.
When this object is read, the zero-length (empty)
string is returned.
See the description clause of usmUserAuthKeyChange for
a recommended procedure to do a key change.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 9 }
usmUserOwnPrivKeyChange OBJECT-TYPE
SYNTAX KeyChange -- typically (SIZE (0 | 32)) for DES
MAX-ACCESS read-create
STATUS current
DESCRIPTION "Behaves exactly as usmUserPrivKeyChange, with one
notable difference: in order for the Set operation
to succeed, the usmUserName of the operation
requester must match the usmUserName that indexes
the row which is targeted by this operation.
In addition, the USM security model must be
used for this operation.
The idea here is that access to this column can be
public, since it will only allow a user to change
his own secret privacy key (privKey).
Note that this can only be done once the row is active.
When a set is received and the usmUserName of the
requester is not the same as the umsUserName that
indexes the row which is targeted by this operation,
then a 'noAccess' error must be returned.
When a set is received and the security model in use
is not USM, then a 'noAccess' error must be returned.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 10 }
usmUserPublic OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..32))
MAX-ACCESS read-create
STATUS current
DESCRIPTION "A publicly-readable value which can be written as part
of the procedure for changing a user's secret
authentication and/or privacy key, and later read to
determine whether the change of the secret was
effected.
"
DEFVAL { ''H } -- the empty string
::= { usmUserEntry 11 }
usmUserStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The storage type for this conceptual row.
Conceptual rows having the value 'permanent' must
allow write-access at a minimum to:
- usmUserAuthKeyChange, usmUserOwnAuthKeyChange
and usmUserPublic for a user who employs
authentication, and
- usmUserPrivKeyChange, usmUserOwnPrivKeyChange
and usmUserPublic for a user who employs
privacy.
Note that any user who employs authentication or
privacy must allow its secret(s) to be updated and
thus cannot be 'readOnly'.
If an initial set operation tries to set the value to
'readOnly' for a user who employs authentication or
privacy, then an 'inconsistentValue' error must be
returned. Note that if the value has been previously
set (implicit or explicit) to any value, then the rules
as defined in the StorageType Textual Convention apply.
It is an implementation issue to decide if a SET for
a readOnly or permanent row is accepted at all. In some
contexts this may make sense, in others it may not. If
a SET for a readOnly or permanent row is not accepted
at all, then a 'wrongValue' error must be returned.
"
DEFVAL { nonVolatile }
::= { usmUserEntry 12 }
usmUserStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION "The status of this conceptual row.
Until instances of all corresponding columns are
appropriately configured, the value of the
corresponding instance of the usmUserStatus column
is 'notReady'.
In particular, a newly created row for a user who
employs authentication, cannot be made active until the
corresponding usmUserCloneFrom and usmUserAuthKeyChange
have been set.
Further, a newly created row for a user who also
employs privacy, cannot be made active until the
usmUserPrivKeyChange has been set.
The RowStatus TC [RFC2579] requires that this
DESCRIPTION clause states under which circumstances
other objects in this row can be modified:
The value of this object has no effect on whether
other objects in this conceptual row can be modified,
except for usmUserOwnAuthKeyChange and
usmUserOwnPrivKeyChange. For these 2 objects, the
value of usmUserStatus MUST be active.
"
::= { usmUserEntry 13 }
-- Conformance Information *******************************************
usmMIBCompliances OBJECT IDENTIFIER ::= { usmMIBConformance 1 }
usmMIBGroups OBJECT IDENTIFIER ::= { usmMIBConformance 2 }
-- Compliance statements
usmMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION "The compliance statement for SNMP engines which
implement the SNMP-USER-BASED-SM-MIB.
"
MODULE -- this module
MANDATORY-GROUPS { usmMIBBasicGroup }
OBJECT usmUserAuthProtocol
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
OBJECT usmUserPrivProtocol
MIN-ACCESS read-only
DESCRIPTION "Write access is not required."
::= { usmMIBCompliances 1 }
-- Units of compliance
usmMIBBasicGroup OBJECT-GROUP
OBJECTS {
usmStatsUnsupportedSecLevels,
usmStatsNotInTimeWindows,
usmStatsUnknownUserNames,
usmStatsUnknownEngineIDs,
usmStatsWrongDigests,
usmStatsDecryptionErrors,
usmUserSpinLock,
usmUserSecurityName,
usmUserCloneFrom,
usmUserAuthProtocol,
usmUserAuthKeyChange,
usmUserOwnAuthKeyChange,
usmUserPrivProtocol,
usmUserPrivKeyChange,
usmUserOwnPrivKeyChange,
usmUserPublic,
usmUserStorageType,
usmUserStatus
}
STATUS current
DESCRIPTION "A collection of objects providing for configuration
of an SNMP engine which implements the SNMP
User-based Security Model.
"
::= { usmMIBGroups 1 }
END

62
share/snmp/SNMP-USM-AES-MIB.txt Normal file
View file

@ -0,0 +1,62 @@
SNMP-USM-AES-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY,
snmpModules FROM SNMPv2-SMI -- [RFC2578]
snmpPrivProtocols FROM SNMP-FRAMEWORK-MIB; -- [RFC3411]
snmpUsmAesMIB MODULE-IDENTITY
LAST-UPDATED "200406140000Z"
ORGANIZATION "IETF"
CONTACT-INFO "Uri Blumenthal
Lucent Technologies / Bell Labs
67 Whippany Rd.
14D-318
Whippany, NJ 07981, USA
973-386-2163
uri@bell-labs.com
Fabio Maino
Andiamo Systems, Inc.
375 East Tasman Drive
San Jose, CA 95134, USA
408-853-7530
fmaino@andiamo.com
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706, USA
408-526-5260
kzm@cisco.com"
DESCRIPTION "Definitions of Object Identities needed for
the use of AES by SNMP's User-based Security
Model.
Copyright (C) The Internet Society (2004).
This version of this MIB module is part of RFC 3826;
see the RFC itself for full legal notices.
Supplementary information may be available on
http://www.ietf.org/copyrights/ianamib.html."
REVISION "200406140000Z"
DESCRIPTION "Initial version, published as RFC3826"
::= { snmpModules 20 }
usmAesCfb128Protocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The CFB128-AES-128 Privacy Protocol."
REFERENCE "- Specification for the ADVANCED ENCRYPTION
STANDARD. Federal Information Processing
Standard (FIPS) Publication 197.
(November 2001).
- Dworkin, M., NIST Recommendation for Block
Cipher Modes of Operation, Methods and
Techniques. NIST Special Publication 800-38A
(December 2001).
"
::= { snmpPrivProtocols 4 }
END

103
share/snmp/SNMP-USM-HMAC-SHA2-MIB.txt Normal file
View file

@ -0,0 +1,103 @@
SNMP-USM-HMAC-SHA2-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY,
mib-2 FROM SNMPv2-SMI -- RFC 2578
snmpAuthProtocols FROM SNMP-FRAMEWORK-MIB; -- RFC 3411
snmpUsmHmacSha2MIB MODULE-IDENTITY
LAST-UPDATED "201604180000Z" -- 18 April 2016, midnight
ORGANIZATION "SNMPv3 Working Group"
CONTACT-INFO "WG email: OPSAWG@ietf.org
Subscribe:
https://www.ietf.org/mailman/listinfo/opsawg
Editor: Johannes Merkle
secunet Security Networks
Postal: Mergenthaler Allee 77
D-65760 Eschborn
Germany
Phone: +49 20154543091
Email: johannes.merkle@secunet.com
Co-Editor: Manfred Lochter
Bundesamt fuer Sicherheit in der
Informationstechnik (BSI)
Postal: Postfach 200363
D-53133 Bonn
Germany
Phone: +49 228 9582 5643
Email: manfred.lochter@bsi.bund.de"
DESCRIPTION
"Definitions of Object Identities needed for the use of
HMAC-SHA2 Authentication Protocols by SNMP's User-based Security
Model.
Copyright (c) 2016 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info)."
REVISION "201604180000Z" -- 18 April 2016, midnight
DESCRIPTION
"Version correcting the MODULE-IDENTITY value,
published as RFC 7860"
REVISION "201510140000Z" -- 14 October 2015, midnight
DESCRIPTION
"Initial version, published as RFC 7630"
::= { mib-2 235 }
usmHMAC128SHA224AuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The Authentication Protocol
usmHMAC128SHA224AuthProtocol uses HMAC-SHA-224 and
truncates output to 128 bits."
REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti,
HMAC: Keyed-Hashing for Message Authentication,
RFC 2104.
- National Institute of Standards and Technology,
Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
::= { snmpAuthProtocols 4 }
usmHMAC192SHA256AuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The Authentication Protocol
usmHMAC192SHA256AuthProtocol uses HMAC-SHA-256 and
truncates output to 192 bits."
REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti,
HMAC: Keyed-Hashing for Message Authentication,
RFC 2104.
- National Institute of Standards and Technology,
Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
::= { snmpAuthProtocols 5 }
usmHMAC256SHA384AuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The Authentication Protocol
usmHMAC256SHA384AuthProtocol uses HMAC-SHA-384 and
truncates output to 256 bits."
REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti,
HMAC: Keyed-Hashing for Message Authentication,
RFC 2104.
- National Institute of Standards and Technology,
Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
::= { snmpAuthProtocols 6 }
usmHMAC384SHA512AuthProtocol OBJECT-IDENTITY
STATUS current
DESCRIPTION "The Authentication Protocol
usmHMAC384SHA512AuthProtocol uses HMAC-SHA-512 and
truncates output to 384 bits."
REFERENCE "- Krawczyk, H., Bellare, M., and R. Canetti,
HMAC: Keyed-Hashing for Message Authentication,
RFC 2104.
- National Institute of Standards and Technology,
Secure Hash Standard (SHS), FIPS PUB 180-4, 2012."
::= { snmpAuthProtocols 7 }
END

322
share/snmp/SNMPv2-CONF.txt Normal file
View file

@ -0,0 +1,322 @@
SNMPv2-CONF DEFINITIONS ::= BEGIN
IMPORTS ObjectName, NotificationName, ObjectSyntax
FROM SNMPv2-SMI;
-- definitions for conformance groups
OBJECT-GROUP MACRO ::=
BEGIN
TYPE NOTATION ::=
ObjectsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
ObjectsPart ::=
"OBJECTS" "{" Objects "}"
Objects ::=
Object
| Objects "," Object
Object ::=
value(ObjectName)
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
-- a character string as defined in [2]
Text ::= value(IA5String)
END
-- more definitions for conformance groups
NOTIFICATION-GROUP MACRO ::=
BEGIN
TYPE NOTATION ::=
NotificationsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
NotificationsPart ::=
"NOTIFICATIONS" "{" Notifications "}"
Notifications ::=
Notification
| Notifications "," Notification
Notification ::=
value(NotificationName)
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
-- a character string as defined in [2]
Text ::= value(IA5String)
END
-- definitions for compliance statements
MODULE-COMPLIANCE MACRO ::=
BEGIN
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
ModulePart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
ModulePart ::=
Modules
Modules ::=
Module
| Modules Module
Module ::=
-- name of module --
"MODULE" ModuleName
MandatoryPart
CompliancePart
ModuleName ::=
-- identifier must start with uppercase letter
identifier ModuleIdentifier
-- must not be empty unless contained
-- in MIB Module
| empty
ModuleIdentifier ::=
value(OBJECT IDENTIFIER)
| empty
MandatoryPart ::=
"MANDATORY-GROUPS" "{" Groups "}"
| empty
Groups ::=
Group
| Groups "," Group
Group ::=
value(OBJECT IDENTIFIER)
CompliancePart ::=
Compliances
| empty
Compliances ::=
Compliance
| Compliances Compliance
Compliance ::=
ComplianceGroup
| Object
ComplianceGroup ::=
"GROUP" value(OBJECT IDENTIFIER)
"DESCRIPTION" Text
Object ::=
"OBJECT" value(ObjectName)
SyntaxPart
WriteSyntaxPart
AccessPart
"DESCRIPTION" Text
-- must be a refinement for object's SYNTAX clause
SyntaxPart ::= "SYNTAX" Syntax
| empty
-- must be a refinement for object's SYNTAX clause
WriteSyntaxPart ::= "WRITE-SYNTAX" Syntax
| empty
Syntax ::= -- Must be one of the following:
-- a base type (or its refinement),
-- a textual convention (or its refinement), or
-- a BITS pseudo-type
type
| "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
AccessPart ::=
"MIN-ACCESS" Access
| empty
Access ::=
"not-accessible"
| "accessible-for-notify"
| "read-only"
| "read-write"
| "read-create"
-- a character string as defined in [2]
Text ::= value(IA5String)
END
-- definitions for capabilities statements
AGENT-CAPABILITIES MACRO ::=
BEGIN
TYPE NOTATION ::=
"PRODUCT-RELEASE" Text
"STATUS" Status
"DESCRIPTION" Text
ReferPart
ModulePart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
Status ::=
"current"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
ModulePart ::=
Modules
| empty
Modules ::=
Module
| Modules Module
Module ::=
-- name of module --
"SUPPORTS" ModuleName
"INCLUDES" "{" Groups "}"
VariationPart
ModuleName ::=
-- identifier must start with uppercase letter
identifier ModuleIdentifier
ModuleIdentifier ::=
value(OBJECT IDENTIFIER)
| empty
Groups ::=
Group
| Groups "," Group
Group ::=
value(OBJECT IDENTIFIER)
VariationPart ::=
Variations
| empty
Variations ::=
Variation
| Variations Variation
Variation ::=
ObjectVariation
| NotificationVariation
NotificationVariation ::=
"VARIATION" value(NotificationName)
AccessPart
"DESCRIPTION" Text
ObjectVariation ::=
"VARIATION" value(ObjectName)
SyntaxPart
WriteSyntaxPart
AccessPart
CreationPart
DefValPart
"DESCRIPTION" Text
-- must be a refinement for object's SYNTAX clause
SyntaxPart ::= "SYNTAX" Syntax
| empty
WriteSyntaxPart ::= "WRITE-SYNTAX" Syntax
| empty
Syntax ::= -- Must be one of the following:
-- a base type (or its refinement),
-- a textual convention (or its refinement), or
-- a BITS pseudo-type
type
| "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
AccessPart ::=
"ACCESS" Access
| empty
Access ::=
"not-implemented"
-- only "not-implemented" for notifications
| "accessible-for-notify"
| "read-only"
| "read-write"
| "read-create"
-- following is for backward-compatibility only
| "write-only"
CreationPart ::=
"CREATION-REQUIRES" "{" Cells "}"
| empty
Cells ::=
Cell
| Cells "," Cell
Cell ::=
value(ObjectName)
DefValPart ::= "DEFVAL" "{" Defvalue "}"
| empty
Defvalue ::= -- must be valid for the object's syntax
-- in this macro's SYNTAX clause, if present,
-- or if not, in object's OBJECT-TYPE macro
value(ObjectSyntax)
| "{" BitsValue "}"
BitsValue ::= BitNames
| empty
BitNames ::= BitName
| BitNames "," BitName
BitName ::= identifier
-- a character string as defined in [2]
Text ::= value(IA5String)
END
END

854
share/snmp/SNMPv2-MIB.txt Normal file
View file

@ -0,0 +1,854 @@
SNMPv2-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
TimeTicks, Counter32, snmpModules, mib-2
FROM SNMPv2-SMI
DisplayString, TestAndIncr, TimeStamp
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF;
snmpMIB MODULE-IDENTITY
LAST-UPDATED "200210160000Z"
ORGANIZATION "IETF SNMPv3 Working Group"
CONTACT-INFO
"WG-EMail: snmpv3@lists.tislabs.com
Subscribe: snmpv3-request@lists.tislabs.com
Co-Chair: Russ Mundy
Network Associates Laboratories
postal: 15204 Omega Drive, Suite 300
Rockville, MD 20850-4601
USA
EMail: mundy@tislabs.com
phone: +1 301 947-7107
Co-Chair: David Harrington
Enterasys Networks
postal: 35 Industrial Way
P. O. Box 5005
Rochester, NH 03866-5005
USA
EMail: dbh@enterasys.com
phone: +1 603 337-2614
Editor: Randy Presuhn
BMC Software, Inc.
postal: 2141 North First Street
San Jose, CA 95131
USA
EMail: randy_presuhn@bmc.com
phone: +1 408 546-1006"
DESCRIPTION
"The MIB module for SNMP entities.
Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3418;
see the RFC itself for full legal notices.
"
REVISION "200210160000Z"
DESCRIPTION
"This revision of this MIB module was published as
RFC 3418."
REVISION "199511090000Z"
DESCRIPTION
"This revision of this MIB module was published as
RFC 1907."
REVISION "199304010000Z"
DESCRIPTION
"The initial revision of this MIB module was published
as RFC 1450."
::= { snmpModules 1 }
snmpMIBObjects OBJECT IDENTIFIER ::= { snmpMIB 1 }
-- ::= { snmpMIBObjects 1 } this OID is obsolete
-- ::= { snmpMIBObjects 2 } this OID is obsolete
-- ::= { snmpMIBObjects 3 } this OID is obsolete
-- the System group
--
-- a collection of objects common to all managed systems.
system OBJECT IDENTIFIER ::= { mib-2 1 }
sysDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual description of the entity. This value should
include the full name and version identification of
the system's hardware type, software operating-system,
and networking software."
::= { system 1 }
sysObjectID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The vendor's authoritative identification of the
network management subsystem contained in the entity.
This value is allocated within the SMI enterprises
subtree (1.3.6.1.4.1) and provides an easy and
unambiguous means for determining `what kind of box' is
being managed. For example, if vendor `Flintstones,
Inc.' was assigned the subtree 1.3.6.1.4.1.424242,
it could assign the identifier 1.3.6.1.4.1.424242.1.1
to its `Fred Router'."
::= { system 2 }
sysUpTime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time (in hundredths of a second) since the
network management portion of the system was last
re-initialized."
::= { system 3 }
sysContact OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The textual identification of the contact person for
this managed node, together with information on how
to contact this person. If no contact information is
known, the value is the zero-length string."
::= { system 4 }
sysName OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An administratively-assigned name for this managed
node. By convention, this is the node's fully-qualified
domain name. If the name is unknown, the value is
the zero-length string."
::= { system 5 }
sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The physical location of this node (e.g., 'telephone
closet, 3rd floor'). If the location is unknown, the
value is the zero-length string."
::= { system 6 }
sysServices OBJECT-TYPE
SYNTAX INTEGER (0..127)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A value which indicates the set of services that this
entity may potentially offer. The value is a sum.
This sum initially takes the value zero. Then, for
each layer, L, in the range 1 through 7, that this node
performs transactions for, 2 raised to (L - 1) is added
to the sum. For example, a node which performs only
routing functions would have a value of 4 (2^(3-1)).
In contrast, a node which is a host offering application
services would have a value of 72 (2^(4-1) + 2^(7-1)).
Note that in the context of the Internet suite of
protocols, values should be calculated accordingly:
layer functionality
1 physical (e.g., repeaters)
2 datalink/subnetwork (e.g., bridges)
3 internet (e.g., supports the IP)
4 end-to-end (e.g., supports the TCP)
7 applications (e.g., supports the SMTP)
For systems including OSI protocols, layers 5 and 6
may also be counted."
::= { system 7 }
-- object resource information
--
-- a collection of objects which describe the SNMP entity's
-- (statically and dynamically configurable) support of
-- various MIB modules.
sysORLastChange OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time of the most recent
change in state or value of any instance of sysORID."
::= { system 8 }
sysORTable OBJECT-TYPE
SYNTAX SEQUENCE OF SysOREntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table listing the capabilities of
the local SNMP application acting as a command
responder with respect to various MIB modules.
SNMP entities having dynamically-configurable support
of MIB modules will have a dynamically-varying number
of conceptual rows."
::= { system 9 }
sysOREntry OBJECT-TYPE
SYNTAX SysOREntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) in the sysORTable."
INDEX { sysORIndex }
::= { sysORTable 1 }
SysOREntry ::= SEQUENCE {
sysORIndex INTEGER,
sysORID OBJECT IDENTIFIER,
sysORDescr DisplayString,
sysORUpTime TimeStamp
}
sysORIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The auxiliary variable used for identifying instances
of the columnar objects in the sysORTable."
::= { sysOREntry 1 }
sysORID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An authoritative identification of a capabilities
statement with respect to various MIB modules supported
by the local SNMP application acting as a command
responder."
::= { sysOREntry 2 }
sysORDescr OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual description of the capabilities identified
by the corresponding instance of sysORID."
::= { sysOREntry 3 }
sysORUpTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of sysUpTime at the time this conceptual
row was last instantiated."
::= { sysOREntry 4 }
-- the SNMP group
--
-- a collection of objects providing basic instrumentation and
-- control of an SNMP entity.
snmp OBJECT IDENTIFIER ::= { mib-2 11 }
snmpInPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of messages delivered to the SNMP
entity from the transport service."
::= { snmp 1 }
snmpInBadVersions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of SNMP messages which were delivered
to the SNMP entity and were for an unsupported SNMP
version."
::= { snmp 3 }
snmpInBadCommunityNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of community-based SNMP messages (for
example, SNMPv1) delivered to the SNMP entity which
used an SNMP community name not known to said entity.
Also, implementations which authenticate community-based
SNMP messages using check(s) in addition to matching
the community name (for example, by also checking
whether the message originated from a transport address
allowed to use a specified community name) MAY include
in this value the number of messages which failed the
additional check(s). It is strongly RECOMMENDED that
the documentation for any security model which is used
to authenticate community-based SNMP messages specify
the precise conditions that contribute to this value."
::= { snmp 4 }
snmpInBadCommunityUses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of community-based SNMP messages (for
example, SNMPv1) delivered to the SNMP entity which
represented an SNMP operation that was not allowed for
the SNMP community named in the message. The precise
conditions under which this counter is incremented
(if at all) depend on how the SNMP entity implements
its access control mechanism and how its applications
interact with that access control mechanism. It is
strongly RECOMMENDED that the documentation for any
access control mechanism which is used to control access
to and visibility of MIB instrumentation specify the
precise conditions that contribute to this value."
::= { snmp 5 }
snmpInASNParseErrs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of ASN.1 or BER errors encountered by
the SNMP entity when decoding received SNMP messages."
::= { snmp 6 }
snmpEnableAuthenTraps OBJECT-TYPE
SYNTAX INTEGER { enabled(1), disabled(2) }
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Indicates whether the SNMP entity is permitted to
generate authenticationFailure traps. The value of this
object overrides any configuration information; as such,
it provides a means whereby all authenticationFailure
traps may be disabled.
Note that it is strongly recommended that this object
be stored in non-volatile memory so that it remains
constant across re-initializations of the network
management system."
::= { snmp 30 }
snmpSilentDrops OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Confirmed Class PDUs (such as
GetRequest-PDUs, GetNextRequest-PDUs,
GetBulkRequest-PDUs, SetRequest-PDUs, and
InformRequest-PDUs) delivered to the SNMP entity which
were silently dropped because the size of a reply
containing an alternate Response Class PDU (such as a
Response-PDU) with an empty variable-bindings field
was greater than either a local constraint or the
maximum message size associated with the originator of
the request."
::= { snmp 31 }
snmpProxyDrops OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The total number of Confirmed Class PDUs
(such as GetRequest-PDUs, GetNextRequest-PDUs,
GetBulkRequest-PDUs, SetRequest-PDUs, and
InformRequest-PDUs) delivered to the SNMP entity which
were silently dropped because the transmission of
the (possibly translated) message to a proxy target
failed in a manner (other than a time-out) such that
no Response Class PDU (such as a Response-PDU) could
be returned."
::= { snmp 32 }
-- information for notifications
--
-- a collection of objects which allow the SNMP entity, when
-- supporting a notification originator application,
-- to be configured to generate SNMPv2-Trap-PDUs.
snmpTrap OBJECT IDENTIFIER ::= { snmpMIBObjects 4 }
snmpTrapOID OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The authoritative identification of the notification
currently being sent. This variable occurs as
the second varbind in every SNMPv2-Trap-PDU and
InformRequest-PDU."
::= { snmpTrap 1 }
-- ::= { snmpTrap 2 } this OID is obsolete
snmpTrapEnterprise OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
MAX-ACCESS accessible-for-notify
STATUS current
DESCRIPTION
"The authoritative identification of the enterprise
associated with the trap currently being sent. When an
SNMP proxy agent is mapping an RFC1157 Trap-PDU
into a SNMPv2-Trap-PDU, this variable occurs as the
last varbind."
::= { snmpTrap 3 }
-- ::= { snmpTrap 4 } this OID is obsolete
-- well-known traps
snmpTraps OBJECT IDENTIFIER ::= { snmpMIBObjects 5 }
coldStart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"A coldStart trap signifies that the SNMP entity,
supporting a notification originator application, is
reinitializing itself and that its configuration may
have been altered."
::= { snmpTraps 1 }
warmStart NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"A warmStart trap signifies that the SNMP entity,
supporting a notification originator application,
is reinitializing itself such that its configuration
is unaltered."
::= { snmpTraps 2 }
-- Note the linkDown NOTIFICATION-TYPE ::= { snmpTraps 3 }
-- and the linkUp NOTIFICATION-TYPE ::= { snmpTraps 4 }
-- are defined in RFC 2863 [RFC2863]
authenticationFailure NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"An authenticationFailure trap signifies that the SNMP
entity has received a protocol message that is not
properly authenticated. While all implementations
of SNMP entities MAY be capable of generating this
trap, the snmpEnableAuthenTraps object indicates
whether this trap will be generated."
::= { snmpTraps 5 }
-- Note the egpNeighborLoss notification is defined
-- as { snmpTraps 6 } in RFC 1213
-- the set group
--
-- a collection of objects which allow several cooperating
-- command generator applications to coordinate their use of the
-- set operation.
snmpSet OBJECT IDENTIFIER ::= { snmpMIBObjects 6 }
snmpSetSerialNo OBJECT-TYPE
SYNTAX TestAndIncr
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"An advisory lock used to allow several cooperating
command generator applications to coordinate their
use of the SNMP set operation.
This object is used for coarse-grain coordination.
To achieve fine-grain coordination, one or more similar
objects might be defined within each MIB group, as
appropriate."
::= { snmpSet 1 }
-- conformance information
snmpMIBConformance
OBJECT IDENTIFIER ::= { snmpMIB 2 }
snmpMIBCompliances
OBJECT IDENTIFIER ::= { snmpMIBConformance 1 }
snmpMIBGroups OBJECT IDENTIFIER ::= { snmpMIBConformance 2 }
-- compliance statements
-- ::= { snmpMIBCompliances 1 } this OID is obsolete
snmpBasicCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The compliance statement for SNMPv2 entities which
implement the SNMPv2 MIB.
This compliance statement is replaced by
snmpBasicComplianceRev2."
MODULE -- this module
MANDATORY-GROUPS { snmpGroup, snmpSetGroup, systemGroup,
snmpBasicNotificationsGroup }
GROUP snmpCommunityGroup
DESCRIPTION
"This group is mandatory for SNMPv2 entities which
support community-based authentication."
::= { snmpMIBCompliances 2 }
snmpBasicComplianceRev2 MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which
implement this MIB module."
MODULE -- this module
MANDATORY-GROUPS { snmpGroup, snmpSetGroup, systemGroup,
snmpBasicNotificationsGroup }
GROUP snmpCommunityGroup
DESCRIPTION
"This group is mandatory for SNMP entities which
support community-based authentication."
GROUP snmpWarmStartNotificationGroup
DESCRIPTION
"This group is mandatory for an SNMP entity which
supports command responder applications, and is
able to reinitialize itself such that its
configuration is unaltered."
::= { snmpMIBCompliances 3 }
-- units of conformance
-- ::= { snmpMIBGroups 1 } this OID is obsolete
-- ::= { snmpMIBGroups 2 } this OID is obsolete
-- ::= { snmpMIBGroups 3 } this OID is obsolete
-- ::= { snmpMIBGroups 4 } this OID is obsolete
snmpGroup OBJECT-GROUP
OBJECTS { snmpInPkts,
snmpInBadVersions,
snmpInASNParseErrs,
snmpSilentDrops,
snmpProxyDrops,
snmpEnableAuthenTraps }
STATUS current
DESCRIPTION
"A collection of objects providing basic instrumentation
and control of an SNMP entity."
::= { snmpMIBGroups 8 }
snmpCommunityGroup OBJECT-GROUP
OBJECTS { snmpInBadCommunityNames,
snmpInBadCommunityUses }
STATUS current
DESCRIPTION
"A collection of objects providing basic instrumentation
of a SNMP entity which supports community-based
authentication."
::= { snmpMIBGroups 9 }
snmpSetGroup OBJECT-GROUP
OBJECTS { snmpSetSerialNo }
STATUS current
DESCRIPTION
"A collection of objects which allow several cooperating
command generator applications to coordinate their
use of the set operation."
::= { snmpMIBGroups 5 }
systemGroup OBJECT-GROUP
OBJECTS { sysDescr, sysObjectID, sysUpTime,
sysContact, sysName, sysLocation,
sysServices,
sysORLastChange, sysORID,
sysORUpTime, sysORDescr }
STATUS current
DESCRIPTION
"The system group defines objects which are common to all
managed systems."
::= { snmpMIBGroups 6 }
snmpBasicNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { coldStart, authenticationFailure }
STATUS current
DESCRIPTION
"The basic notifications implemented by an SNMP entity
supporting command responder applications."
::= { snmpMIBGroups 7 }
snmpWarmStartNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS { warmStart }
STATUS current
DESCRIPTION
"An additional notification for an SNMP entity supporting
command responder applications, if it is able to reinitialize
itself such that its configuration is unaltered."
::= { snmpMIBGroups 11 }
snmpNotificationGroup OBJECT-GROUP
OBJECTS { snmpTrapOID, snmpTrapEnterprise }
STATUS current
DESCRIPTION
"These objects are required for entities
which support notification originator applications."
::= { snmpMIBGroups 12 }
-- definitions in RFC 1213 made obsolete by the inclusion of a
-- subset of the snmp group in this MIB
snmpOutPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Messages which were
passed from the SNMP protocol entity to the
transport service."
::= { snmp 2 }
-- { snmp 7 } is not used
snmpInTooBigs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP PDUs which were
delivered to the SNMP protocol entity and for
which the value of the error-status field was
`tooBig'."
::= { snmp 8 }
snmpInNoSuchNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP PDUs which were
delivered to the SNMP protocol entity and for
which the value of the error-status field was
`noSuchName'."
::= { snmp 9 }
snmpInBadValues OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP PDUs which were
delivered to the SNMP protocol entity and for
which the value of the error-status field was
`badValue'."
::= { snmp 10 }
snmpInReadOnlys OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number valid SNMP PDUs which were delivered
to the SNMP protocol entity and for which the value
of the error-status field was `readOnly'. It should
be noted that it is a protocol error to generate an
SNMP PDU which contains the value `readOnly' in the
error-status field, as such this object is provided
as a means of detecting incorrect implementations of
the SNMP."
::= { snmp 11 }
snmpInGenErrs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP PDUs which were delivered
to the SNMP protocol entity and for which the value
of the error-status field was `genErr'."
::= { snmp 12 }
snmpInTotalReqVars OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of MIB objects which have been
retrieved successfully by the SNMP protocol entity
as the result of receiving valid SNMP Get-Request
and Get-Next PDUs."
::= { snmp 13 }
snmpInTotalSetVars OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of MIB objects which have been
altered successfully by the SNMP protocol entity as
the result of receiving valid SNMP Set-Request PDUs."
::= { snmp 14 }
snmpInGetRequests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Get-Request PDUs which
have been accepted and processed by the SNMP
protocol entity."
::= { snmp 15 }
snmpInGetNexts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Get-Next PDUs which have been
accepted and processed by the SNMP protocol entity."
::= { snmp 16 }
snmpInSetRequests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Set-Request PDUs which
have been accepted and processed by the SNMP protocol
entity."
::= { snmp 17 }
snmpInGetResponses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Get-Response PDUs which
have been accepted and processed by the SNMP protocol
entity."
::= { snmp 18 }
snmpInTraps OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Trap PDUs which have been
accepted and processed by the SNMP protocol entity."
::= { snmp 19 }
snmpOutTooBigs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP PDUs which were generated
by the SNMP protocol entity and for which the value
of the error-status field was `tooBig.'"
::= { snmp 20 }
snmpOutNoSuchNames OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP PDUs which were generated
by the SNMP protocol entity and for which the value
of the error-status was `noSuchName'."
::= { snmp 21 }
snmpOutBadValues OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP PDUs which were generated
by the SNMP protocol entity and for which the value
of the error-status field was `badValue'."
::= { snmp 22 }
-- { snmp 23 } is not used
snmpOutGenErrs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP PDUs which were generated
by the SNMP protocol entity and for which the value
of the error-status field was `genErr'."
::= { snmp 24 }
snmpOutGetRequests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Get-Request PDUs which
have been generated by the SNMP protocol entity."
::= { snmp 25 }
snmpOutGetNexts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Get-Next PDUs which have
been generated by the SNMP protocol entity."
::= { snmp 26 }
snmpOutSetRequests OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Set-Request PDUs which
have been generated by the SNMP protocol entity."
::= { snmp 27 }
snmpOutGetResponses OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Get-Response PDUs which
have been generated by the SNMP protocol entity."
::= { snmp 28 }
snmpOutTraps OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS obsolete
DESCRIPTION
"The total number of SNMP Trap PDUs which have
been generated by the SNMP protocol entity."
::= { snmp 29 }
snmpObsoleteGroup OBJECT-GROUP
OBJECTS { snmpOutPkts, snmpInTooBigs, snmpInNoSuchNames,
snmpInBadValues, snmpInReadOnlys, snmpInGenErrs,
snmpInTotalReqVars, snmpInTotalSetVars,
snmpInGetRequests, snmpInGetNexts, snmpInSetRequests,
snmpInGetResponses, snmpInTraps, snmpOutTooBigs,
snmpOutNoSuchNames, snmpOutBadValues,
snmpOutGenErrs, snmpOutGetRequests, snmpOutGetNexts,
snmpOutSetRequests, snmpOutGetResponses, snmpOutTraps
}
STATUS obsolete
DESCRIPTION
"A collection of objects from RFC 1213 made obsolete
by this MIB module."
::= { snmpMIBGroups 10 }
END

344
share/snmp/SNMPv2-SMI.txt Normal file
View file

@ -0,0 +1,344 @@
SNMPv2-SMI DEFINITIONS ::= BEGIN
-- the path to the root
org OBJECT IDENTIFIER ::= { iso 3 } -- "iso" = 1
dod OBJECT IDENTIFIER ::= { org 6 }
internet OBJECT IDENTIFIER ::= { dod 1 }
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
transmission OBJECT IDENTIFIER ::= { mib-2 10 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
enterprises OBJECT IDENTIFIER ::= { private 1 }
security OBJECT IDENTIFIER ::= { internet 5 }
snmpV2 OBJECT IDENTIFIER ::= { internet 6 }
-- transport domains
snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 }
-- transport proxies
snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 }
-- module identities
snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 }
-- Extended UTCTime, to allow dates with four-digit years
-- (Note that this definition of ExtUTCTime is not to be IMPORTed
-- by MIB modules.)
ExtUTCTime ::= OCTET STRING(SIZE(11 | 13))
-- format is YYMMDDHHMMZ or YYYYMMDDHHMMZ
-- where: YY - last two digits of year (only years
-- between 1900-1999)
-- YYYY - last four digits of the year (any year)
-- MM - month (01 through 12)
-- DD - day of month (01 through 31)
-- HH - hours (00 through 23)
-- MM - minutes (00 through 59)
-- Z - denotes GMT (the ASCII character Z)
--
-- For example, "9502192015Z" and "199502192015Z" represent
-- 8:15pm GMT on 19 February 1995. Years after 1999 must use
-- the four digit year format. Years 1900-1999 may use the
-- two or four digit format.
-- definitions for information modules
MODULE-IDENTITY MACRO ::=
BEGIN
TYPE NOTATION ::=
"LAST-UPDATED" value(Update ExtUTCTime)
"ORGANIZATION" Text
"CONTACT-INFO" Text
"DESCRIPTION" Text
RevisionPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
RevisionPart ::=
Revisions
| empty
Revisions ::=
Revision
| Revisions Revision
Revision ::=
"REVISION" value(Update ExtUTCTime)
"DESCRIPTION" Text
-- a character string as defined in section 3.1.1
Text ::= value(IA5String)
END
OBJECT-IDENTITY MACRO ::=
BEGIN
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
-- a character string as defined in section 3.1.1
Text ::= value(IA5String)
END
-- names of objects
-- (Note that these definitions of ObjectName and NotificationName
-- are not to be IMPORTed by MIB modules.)
ObjectName ::=
OBJECT IDENTIFIER
NotificationName ::=
OBJECT IDENTIFIER
-- syntax of objects
-- the "base types" defined here are:
-- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER
-- 8 application-defined types: Integer32, IpAddress, Counter32,
-- Gauge32, Unsigned32, TimeTicks, Opaque, and Counter64
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
-- note that SEQUENCEs for conceptual tables and
-- rows are not mentioned here...
application-wide
ApplicationSyntax
}
-- built-in ASN.1 types
SimpleSyntax ::=
CHOICE {
-- INTEGERs with a more restrictive range
-- may also be used
integer-value -- includes Integer32
INTEGER (-2147483648..2147483647),
-- OCTET STRINGs with a more restrictive size
-- may also be used
string-value
OCTET STRING (SIZE (0..65535)),
objectID-value
OBJECT IDENTIFIER
}
-- indistinguishable from INTEGER, but never needs more than
-- 32-bits for a two's complement representation
Integer32 ::=
INTEGER (-2147483648..2147483647)
-- application-wide types
ApplicationSyntax ::=
CHOICE {
ipAddress-value
IpAddress,
counter-value
Counter32,
timeticks-value
TimeTicks,
arbitrary-value
Opaque,
big-counter-value
Counter64,
unsigned-integer-value -- includes Gauge32
Unsigned32
}
-- in network-byte order
-- (this is a tagged type for historical reasons)
IpAddress ::=
[APPLICATION 0]
IMPLICIT OCTET STRING (SIZE (4))
-- this wraps
Counter32 ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)
-- this doesn't wrap
Gauge32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
-- an unsigned 32-bit quantity
-- indistinguishable from Gauge32
Unsigned32 ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
-- hundredths of seconds since an epoch
TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)
-- for backward-compatibility only
Opaque ::=
[APPLICATION 4]
IMPLICIT OCTET STRING
-- for counters that wrap in less than one hour with only 32 bits
Counter64 ::=
[APPLICATION 6]
IMPLICIT INTEGER (0..18446744073709551615)
-- definition for objects
OBJECT-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::=
"SYNTAX" Syntax
UnitsPart
"MAX-ACCESS" Access
"STATUS" Status
"DESCRIPTION" Text
ReferPart
IndexPart
DefValPart
VALUE NOTATION ::=
value(VALUE ObjectName)
Syntax ::= -- Must be one of the following:
-- a base type (or its refinement),
-- a textual convention (or its refinement), or
-- a BITS pseudo-type
type
| "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
UnitsPart ::=
"UNITS" Text
| empty
Access ::=
"not-accessible"
| "accessible-for-notify"
| "read-only"
| "read-write"
| "read-create"
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
IndexPart ::=
"INDEX" "{" IndexTypes "}"
| "AUGMENTS" "{" Entry "}"
| empty
IndexTypes ::=
IndexType
| IndexTypes "," IndexType
IndexType ::=
"IMPLIED" Index
| Index
Index ::=
-- use the SYNTAX value of the
-- correspondent OBJECT-TYPE invocation
value(ObjectName)
Entry ::=
-- use the INDEX value of the
-- correspondent OBJECT-TYPE invocation
value(ObjectName)
DefValPart ::= "DEFVAL" "{" Defvalue "}"
| empty
Defvalue ::= -- must be valid for the type specified in
-- SYNTAX clause of same OBJECT-TYPE macro
value(ObjectSyntax)
| "{" BitsValue "}"
BitsValue ::= BitNames
| empty
BitNames ::= BitName
| BitNames "," BitName
BitName ::= identifier
-- a character string as defined in section 3.1.1
Text ::= value(IA5String)
END
-- definitions for notifications
NOTIFICATION-TYPE MACRO ::=
BEGIN
TYPE NOTATION ::=
ObjectsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
VALUE NOTATION ::=
value(VALUE NotificationName)
ObjectsPart ::=
"OBJECTS" "{" Objects "}"
| empty
Objects ::=
Object
| Objects "," Object
Object ::=
value(ObjectName)
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
-- a character string as defined in section 3.1.1
Text ::= value(IA5String)
END
-- definitions of administrative identifiers
zeroDotZero OBJECT-IDENTITY
STATUS current
DESCRIPTION
"A value used for null identifiers."
::= { 0 0 }
END

772
share/snmp/SNMPv2-TC.txt Normal file
View file

@ -0,0 +1,772 @@
SNMPv2-TC DEFINITIONS ::= BEGIN
IMPORTS
TimeTicks FROM SNMPv2-SMI;
-- definition of textual conventions
TEXTUAL-CONVENTION MACRO ::=
BEGIN
TYPE NOTATION ::=
DisplayPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
"SYNTAX" Syntax
VALUE NOTATION ::=
value(VALUE Syntax) -- adapted ASN.1
DisplayPart ::=
"DISPLAY-HINT" Text
| empty
Status ::=
"current"
| "deprecated"
| "obsolete"
ReferPart ::=
"REFERENCE" Text
| empty
-- a character string as defined in [2]
Text ::= value(IA5String)
Syntax ::= -- Must be one of the following:
-- a base type (or its refinement), or
-- a BITS pseudo-type
type
| "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
END
DisplayString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION
"Represents textual information taken from the NVT ASCII
character set, as defined in pages 4, 10-11 of RFC 854.
To summarize RFC 854, the NVT ASCII repertoire specifies:
- the use of character codes 0-127 (decimal)
- the graphics characters (32-126) are interpreted as
US ASCII
- NUL, LF, CR, BEL, BS, HT, VT and FF have the special
meanings specified in RFC 854
- the other 25 codes have no standard interpretation
- the sequence 'CR LF' means newline
- the sequence 'CR NUL' means carriage-return
- an 'LF' not preceded by a 'CR' means moving to the
same column on the next line.
- the sequence 'CR x' for any x other than LF or NUL is
illegal. (Note that this also means that a string may
end with either 'CR LF' or 'CR NUL', but not with CR.)
Any object defined using this syntax may not exceed 255
characters in length."
SYNTAX OCTET STRING (SIZE (0..255))
PhysAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x:"
STATUS current
DESCRIPTION
"Represents media- or physical-level addresses."
SYNTAX OCTET STRING
MacAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1x:"
STATUS current
DESCRIPTION
"Represents an 802 MAC address represented in the
`canonical' order defined by IEEE 802.1a, i.e., as if it
were transmitted least significant bit first, even though
802.5 (in contrast to other 802.x protocols) requires MAC
addresses to be transmitted most significant bit first."
SYNTAX OCTET STRING (SIZE (6))
TruthValue ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a boolean value."
SYNTAX INTEGER { true(1), false(2) }
TestAndIncr ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents integer-valued information used for atomic
operations. When the management protocol is used to specify
that an object instance having this syntax is to be
modified, the new value supplied via the management protocol
must precisely match the value presently held by the
instance. If not, the management protocol set operation
fails with an error of `inconsistentValue'. Otherwise, if
the current value is the maximum value of 2^31-1 (2147483647
decimal), then the value held by the instance is wrapped to
zero; otherwise, the value held by the instance is
incremented by one. (Note that regardless of whether the
management protocol set operation succeeds, the variable-
binding in the request and response PDUs are identical.)
The value of the ACCESS clause for objects having this
syntax is either `read-write' or `read-create'. When an
instance of a columnar object having this syntax is created,
any value may be supplied via the management protocol.
When the network management portion of the system is re-
initialized, the value of every object instance having this
syntax must either be incremented from its value prior to
the re-initialization, or (if the value prior to the re-
initialization is unknown) be set to a pseudo-randomly
generated value."
SYNTAX INTEGER (0..2147483647)
AutonomousType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an independently extensible type identification
value. It may, for example, indicate a particular sub-tree
with further MIB definitions, or define a particular type of
protocol or hardware."
SYNTAX OBJECT IDENTIFIER
InstancePointer ::= TEXTUAL-CONVENTION
STATUS obsolete
DESCRIPTION
"A pointer to either a specific instance of a MIB object or
a conceptual row of a MIB table in the managed device. In
the latter case, by convention, it is the name of the
particular instance of the first accessible columnar object
in the conceptual row.
The two uses of this textual convention are replaced by
VariablePointer and RowPointer, respectively."
SYNTAX OBJECT IDENTIFIER
VariablePointer ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A pointer to a specific object instance. For example,
sysContact.0 or ifInOctets.3."
SYNTAX OBJECT IDENTIFIER
RowPointer ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents a pointer to a conceptual row. The value is the
name of the instance of the first accessible columnar object
in the conceptual row.
For example, ifIndex.3 would point to the 3rd row in the
ifTable (note that if ifIndex were not-accessible, then
ifDescr.3 would be used instead)."
SYNTAX OBJECT IDENTIFIER
RowStatus ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The RowStatus textual convention is used to manage the
creation and deletion of conceptual rows, and is used as the
value of the SYNTAX clause for the status column of a
conceptual row (as described in Section 7.7.1 of [2].)
The status column has six defined values:
- `active', which indicates that the conceptual row is
available for use by the managed device;
- `notInService', which indicates that the conceptual
row exists in the agent, but is unavailable for use by
the managed device (see NOTE below); 'notInService' has
no implication regarding the internal consistency of
the row, availability of resources, or consistency with
the current state of the managed device;
- `notReady', which indicates that the conceptual row
exists in the agent, but is missing information
necessary in order to be available for use by the
managed device (i.e., one or more required columns in
the conceptual row have not been instanciated);
- `createAndGo', which is supplied by a management
station wishing to create a new instance of a
conceptual row and to have its status automatically set
to active, making it available for use by the managed
device;
- `createAndWait', which is supplied by a management
station wishing to create a new instance of a
conceptual row (but not make it available for use by
the managed device); and,
- `destroy', which is supplied by a management station
wishing to delete all of the instances associated with
an existing conceptual row.
Whereas five of the six values (all except `notReady') may
be specified in a management protocol set operation, only
three values will be returned in response to a management
protocol retrieval operation: `notReady', `notInService' or
`active'. That is, when queried, an existing conceptual row
has only three states: it is either available for use by
the managed device (the status column has value `active');
it is not available for use by the managed device, though
the agent has sufficient information to attempt to make it
so (the status column has value `notInService'); or, it is
not available for use by the managed device, and an attempt
to make it so would fail because the agent has insufficient
information (the state column has value `notReady').
NOTE WELL
This textual convention may be used for a MIB table,
irrespective of whether the values of that table's
conceptual rows are able to be modified while it is
active, or whether its conceptual rows must be taken
out of service in order to be modified. That is, it is
the responsibility of the DESCRIPTION clause of the
status column to specify whether the status column must
not be `active' in order for the value of some other
column of the same conceptual row to be modified. If
such a specification is made, affected columns may be
changed by an SNMP set PDU if the RowStatus would not
be equal to `active' either immediately before or after
processing the PDU. In other words, if the PDU also
contained a varbind that would change the RowStatus
value, the column in question may be changed if the
RowStatus was not equal to `active' as the PDU was
received, or if the varbind sets the status to a value
other than 'active'.
Also note that whenever any elements of a row exist, the
RowStatus column must also exist.
To summarize the effect of having a conceptual row with a
status column having a SYNTAX clause value of RowStatus,
consider the following state diagram:
STATE
+--------------+-----------+-------------+-------------
| A | B | C | D
| |status col.|status column|
|status column | is | is |status column
ACTION |does not exist| notReady | notInService| is active
--------------+--------------+-----------+-------------+-------------
set status |noError ->D|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndGo |inconsistent- | | |
| Value| | |
--------------+--------------+-----------+-------------+-------------
set status |noError see 1|inconsist- |inconsistent-|inconsistent-
column to | or | entValue| Value| Value
createAndWait |wrongValue | | |
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError
column to | Value| entValue| |
active | | | |
| | or | |
| | | |
| |see 2 ->D|see 8 ->D| ->D
--------------+--------------+-----------+-------------+-------------
set status |inconsistent- |inconsist- |noError |noError ->C
column to | Value| entValue| |
notInService | | | |
| | or | | or
| | | |
| |see 3 ->C| ->C|see 6
--------------+--------------+-----------+-------------+-------------
set status |noError |noError |noError |noError ->A
column to | | | | or
destroy | ->A| ->A| ->A|see 7
--------------+--------------+-----------+-------------+-------------
set any other |see 4 |noError |noError |see 5
column to some| | | |
value | | see 1| ->C| ->D
--------------+--------------+-----------+-------------+-------------
(1) goto B or C, depending on information available to the
agent.
(2) if other variable bindings included in the same PDU,
provide values for all columns which are missing but
required, and all columns have acceptable values, then
return noError and goto D.
(3) if other variable bindings included in the same PDU,
provide legal values for all columns which are missing but
required, then return noError and goto C.
(4) at the discretion of the agent, the return value may be
either:
inconsistentName: because the agent does not choose to
create such an instance when the corresponding
RowStatus instance does not exist, or
inconsistentValue: if the supplied value is
inconsistent with the state of some other MIB object's
value, or
noError: because the agent chooses to create the
instance.
If noError is returned, then the instance of the status
column must also be created, and the new state is B or C,
depending on the information available to the agent. If
inconsistentName or inconsistentValue is returned, the row
remains in state A.
(5) depending on the MIB definition for the column/table,
either noError or inconsistentValue may be returned.
(6) the return value can indicate one of the following
errors:
wrongValue: because the agent does not support
notInService (e.g., an agent which does not support
createAndWait), or
inconsistentValue: because the agent is unable to take
the row out of service at this time, perhaps because it
is in use and cannot be de-activated.
(7) the return value can indicate the following error:
inconsistentValue: because the agent is unable to
remove the row at this time, perhaps because it is in
use and cannot be de-activated.
(8) the transition to D can fail, e.g., if the values of the
conceptual row are inconsistent, then the error code would
be inconsistentValue.
NOTE: Other processing of (this and other varbinds of) the
set request may result in a response other than noError
being returned, e.g., wrongValue, noCreation, etc.
Conceptual Row Creation
There are four potential interactions when creating a
conceptual row: selecting an instance-identifier which is
not in use; creating the conceptual row; initializing any
objects for which the agent does not supply a default; and,
making the conceptual row available for use by the managed
device.
Interaction 1: Selecting an Instance-Identifier
The algorithm used to select an instance-identifier varies
for each conceptual row. In some cases, the instance-
identifier is semantically significant, e.g., the
destination address of a route, and a management station
selects the instance-identifier according to the semantics.
In other cases, the instance-identifier is used solely to
distinguish conceptual rows, and a management station
without specific knowledge of the conceptual row might
examine the instances present in order to determine an
unused instance-identifier. (This approach may be used, but
it is often highly sub-optimal; however, it is also a
questionable practice for a naive management station to
attempt conceptual row creation.)
Alternately, the MIB module which defines the conceptual row
might provide one or more objects which provide assistance
in determining an unused instance-identifier. For example,
if the conceptual row is indexed by an integer-value, then
an object having an integer-valued SYNTAX clause might be
defined for such a purpose, allowing a management station to
issue a management protocol retrieval operation. In order
to avoid unnecessary collisions between competing management
stations, `adjacent' retrievals of this object should be
different.
Finally, the management station could select a pseudo-random
number to use as the index. In the event that this index
was already in use and an inconsistentValue was returned in
response to the management protocol set operation, the
management station should simply select a new pseudo-random
number and retry the operation.
A MIB designer should choose between the two latter
algorithms based on the size of the table (and therefore the
efficiency of each algorithm). For tables in which a large
number of entries are expected, it is recommended that a MIB
object be defined that returns an acceptable index for
creation. For tables with small numbers of entries, it is
recommended that the latter pseudo-random index mechanism be
used.
Interaction 2: Creating the Conceptual Row
Once an unused instance-identifier has been selected, the
management station determines if it wishes to create and
activate the conceptual row in one transaction or in a
negotiated set of interactions.
Interaction 2a: Creating and Activating the Conceptual Row
The management station must first determine the column
requirements, i.e., it must determine those columns for
which it must or must not provide values. Depending on the
complexity of the table and the management station's
knowledge of the agent's capabilities, this determination
can be made locally by the management station. Alternately,
the management station issues a management protocol get
operation to examine all columns in the conceptual row that
it wishes to create. In response, for each column, there
are three possible outcomes:
- a value is returned, indicating that some other
management station has already created this conceptual
row. We return to interaction 1.
- the exception `noSuchInstance' is returned,
indicating that the agent implements the object-type
associated with this column, and that this column in at
least one conceptual row would be accessible in the MIB
view used by the retrieval were it to exist. For those
columns to which the agent provides read-create access,
the `noSuchInstance' exception tells the management
station that it should supply a value for this column
when the conceptual row is to be created.
- the exception `noSuchObject' is returned, indicating
that the agent does not implement the object-type
associated with this column or that there is no
conceptual row for which this column would be
accessible in the MIB view used by the retrieval. As
such, the management station can not issue any
management protocol set operations to create an
instance of this column.
Once the column requirements have been determined, a
management protocol set operation is accordingly issued.
This operation also sets the new instance of the status
column to `createAndGo'.
When the agent processes the set operation, it verifies that
it has sufficient information to make the conceptual row
available for use by the managed device. The information
available to the agent is provided by two sources: the
management protocol set operation which creates the
conceptual row, and, implementation-specific defaults
supplied by the agent (note that an agent must provide
implementation-specific defaults for at least those objects
which it implements as read-only). If there is sufficient
information available, then the conceptual row is created, a
`noError' response is returned, the status column is set to
`active', and no further interactions are necessary (i.e.,
interactions 3 and 4 are skipped). If there is insufficient
information, then the conceptual row is not created, and the
set operation fails with an error of `inconsistentValue'.
On this error, the management station can issue a management
protocol retrieval operation to determine if this was
because it failed to specify a value for a required column,
or, because the selected instance of the status column
already existed. In the latter case, we return to
interaction 1. In the former case, the management station
can re-issue the set operation with the additional
information, or begin interaction 2 again using
`createAndWait' in order to negotiate creation of the
conceptual row.
NOTE WELL
Regardless of the method used to determine the column
requirements, it is possible that the management
station might deem a column necessary when, in fact,
the agent will not allow that particular columnar
instance to be created or written. In this case, the
management protocol set operation will fail with an
error such as `noCreation' or `notWritable'. In this
case, the management station decides whether it needs
to be able to set a value for that particular columnar
instance. If not, the management station re-issues the
management protocol set operation, but without setting
a value for that particular columnar instance;
otherwise, the management station aborts the row
creation algorithm.
Interaction 2b: Negotiating the Creation of the Conceptual
Row
The management station issues a management protocol set
operation which sets the desired instance of the status
column to `createAndWait'. If the agent is unwilling to
process a request of this sort, the set operation fails with
an error of `wrongValue'. (As a consequence, such an agent
must be prepared to accept a single management protocol set
operation, i.e., interaction 2a above, containing all of the
columns indicated by its column requirements.) Otherwise,
the conceptual row is created, a `noError' response is
returned, and the status column is immediately set to either
`notInService' or `notReady', depending on whether it has
sufficient information to (attempt to) make the conceptual
row available for use by the managed device. If there is
sufficient information available, then the status column is
set to `notInService'; otherwise, if there is insufficient
information, then the status column is set to `notReady'.
Regardless, we proceed to interaction 3.
Interaction 3: Initializing non-defaulted Objects
The management station must now determine the column
requirements. It issues a management protocol get operation
to examine all columns in the created conceptual row. In
the response, for each column, there are three possible
outcomes:
- a value is returned, indicating that the agent
implements the object-type associated with this column
and had sufficient information to provide a value. For
those columns to which the agent provides read-create
access (and for which the agent allows their values to
be changed after their creation), a value return tells
the management station that it may issue additional
management protocol set operations, if it desires, in
order to change the value associated with this column.
- the exception `noSuchInstance' is returned,
indicating that the agent implements the object-type
associated with this column, and that this column in at
least one conceptual row would be accessible in the MIB
view used by the retrieval were it to exist. However,
the agent does not have sufficient information to
provide a value, and until a value is provided, the
conceptual row may not be made available for use by the
managed device. For those columns to which the agent
provides read-create access, the `noSuchInstance'
exception tells the management station that it must
issue additional management protocol set operations, in
order to provide a value associated with this column.
- the exception `noSuchObject' is returned, indicating
that the agent does not implement the object-type
associated with this column or that there is no
conceptual row for which this column would be
accessible in the MIB view used by the retrieval. As
such, the management station can not issue any
management protocol set operations to create an
instance of this column.
If the value associated with the status column is
`notReady', then the management station must first deal with
all `noSuchInstance' columns, if any. Having done so, the
value of the status column becomes `notInService', and we
proceed to interaction 4.
Interaction 4: Making the Conceptual Row Available
Once the management station is satisfied with the values
associated with the columns of the conceptual row, it issues
a management protocol set operation to set the status column
to `active'. If the agent has sufficient information to
make the conceptual row available for use by the managed
device, the management protocol set operation succeeds (a
`noError' response is returned). Otherwise, the management
protocol set operation fails with an error of
`inconsistentValue'.
NOTE WELL
A conceptual row having a status column with value
`notInService' or `notReady' is unavailable to the
managed device. As such, it is possible for the
managed device to create its own instances during the
time between the management protocol set operation
which sets the status column to `createAndWait' and the
management protocol set operation which sets the status
column to `active'. In this case, when the management
protocol set operation is issued to set the status
column to `active', the values held in the agent
supersede those used by the managed device.
If the management station is prevented from setting the
status column to `active' (e.g., due to management station
or network failure) the conceptual row will be left in the
`notInService' or `notReady' state, consuming resources
indefinitely. The agent must detect conceptual rows that
have been in either state for an abnormally long period of
time and remove them. It is the responsibility of the
DESCRIPTION clause of the status column to indicate what an
abnormally long period of time would be. This period of
time should be long enough to allow for human response time
(including `think time') between the creation of the
conceptual row and the setting of the status to `active'.
In the absence of such information in the DESCRIPTION
clause, it is suggested that this period be approximately 5
minutes in length. This removal action applies not only to
newly-created rows, but also to previously active rows which
are set to, and left in, the notInService state for a
prolonged period exceeding that which is considered normal
for such a conceptual row.
Conceptual Row Suspension
When a conceptual row is `active', the management station
may issue a management protocol set operation which sets the
instance of the status column to `notInService'. If the
agent is unwilling to do so, the set operation fails with an
error of `wrongValue' or `inconsistentValue'. Otherwise,
the conceptual row is taken out of service, and a `noError'
response is returned. It is the responsibility of the
DESCRIPTION clause of the status column to indicate under
what circumstances the status column should be taken out of
service (e.g., in order for the value of some other column
of the same conceptual row to be modified).
Conceptual Row Deletion
For deletion of conceptual rows, a management protocol set
operation is issued which sets the instance of the status
column to `destroy'. This request may be made regardless of
the current value of the status column (e.g., it is possible
to delete conceptual rows which are either `notReady',
`notInService' or `active'.) If the operation succeeds,
then all instances associated with the conceptual row are
immediately removed."
SYNTAX INTEGER {
-- the following two values are states:
-- these values may be read or written
active(1),
notInService(2),
-- the following value is a state:
-- this value may be read, but not written
notReady(3),
-- the following three values are
-- actions: these values may be written,
-- but are never read
createAndGo(4),
createAndWait(5),
destroy(6)
}
TimeStamp ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The value of the sysUpTime object at which a specific
occurrence happened. The specific occurrence must be
defined in the description of any object defined using this
type.
If sysUpTime is reset to zero as a result of a re-
initialization of the network management (sub)system, then
the values of all TimeStamp objects are also reset.
However, after approximately 497 days without a re-
initialization, the sysUpTime object will reach 2^^32-1 and
then increment around to zero; in this case, existing values
of TimeStamp objects do not change. This can lead to
ambiguities in the value of TimeStamp objects."
SYNTAX TimeTicks
TimeInterval ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A period of time, measured in units of 0.01 seconds."
SYNTAX INTEGER (0..2147483647)
DateAndTime ::= TEXTUAL-CONVENTION
DISPLAY-HINT "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"
STATUS current
DESCRIPTION
"A date-time specification.
field octets contents range
----- ------ -------- -----
1 1-2 year* 0..65536
2 3 month 1..12
3 4 day 1..31
4 5 hour 0..23
5 6 minutes 0..59
6 7 seconds 0..60
(use 60 for leap-second)
7 8 deci-seconds 0..9
8 9 direction from UTC '+' / '-'
9 10 hours from UTC* 0..13
10 11 minutes from UTC 0..59
* Notes:
- the value of year is in network-byte order
- daylight saving time in New Zealand is +13
For example, Tuesday May 26, 1992 at 1:30:15 PM EDT would be
displayed as:
1992-5-26,13:30:15.0,-4:0
Note that if only local time is known, then timezone
information (fields 8-10) is not present."
SYNTAX OCTET STRING (SIZE (8 | 11))
StorageType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Describes the memory realization of a conceptual row. A
row which is volatile(2) is lost upon reboot. A row which
is either nonVolatile(3), permanent(4) or readOnly(5), is
backed up by stable storage. A row which is permanent(4)
can be changed but not deleted. A row which is readOnly(5)
cannot be changed nor deleted.
If the value of an object with this syntax is either
permanent(4) or readOnly(5), it cannot be written.
Conversely, if the value is either other(1), volatile(2) or
nonVolatile(3), it cannot be modified to be permanent(4) or
readOnly(5). (All illegal modifications result in a
'wrongValue' error.)
Every usage of this textual convention is required to
specify the columnar objects which a permanent(4) row must
at a minimum allow to be writable."
SYNTAX INTEGER {
other(1), -- eh?
volatile(2), -- e.g., in RAM
nonVolatile(3), -- e.g., in NVRAM
permanent(4), -- e.g., partially in ROM
readOnly(5) -- e.g., completely in ROM
}
TDomain ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a kind of transport service.
Some possible values, such as snmpUDPDomain, are defined in
the SNMPv2-TM MIB module. Other possible values are defined
in other MIB modules."
REFERENCE "The SNMPv2-TM MIB module is defined in RFC 1906."
SYNTAX OBJECT IDENTIFIER
TAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a transport service address.
A TAddress value is always interpreted within the context of a
TDomain value. Thus, each definition of a TDomain value must
be accompanied by a definition of a textual convention for use
with that TDomain. Some possible textual conventions, such as
SnmpUDPAddress for snmpUDPDomain, are defined in the SNMPv2-TM
MIB module. Other possible textual conventions are defined in
other MIB modules."
REFERENCE "The SNMPv2-TM MIB module is defined in RFC 1906."
SYNTAX OCTET STRING (SIZE (1..255))
END

176
share/snmp/SNMPv2-TM.txt Normal file
View file

@ -0,0 +1,176 @@
SNMPv2-TM DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY,
snmpModules, snmpDomains, snmpProxys
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
snmpv2tm MODULE-IDENTITY
LAST-UPDATED "200210160000Z"
ORGANIZATION "IETF SNMPv3 Working Group"
CONTACT-INFO
"WG-EMail: snmpv3@lists.tislabs.com
Subscribe: snmpv3-request@lists.tislabs.com
Co-Chair: Russ Mundy
Network Associates Laboratories
postal: 15204 Omega Drive, Suite 300
Rockville, MD 20850-4601
USA
EMail: mundy@tislabs.com
phone: +1 301 947-7107
Co-Chair: David Harrington
Enterasys Networks
postal: 35 Industrial Way
P. O. Box 5005
Rochester, NH 03866-5005
USA
EMail: dbh@enterasys.com
phone: +1 603 337-2614
Editor: Randy Presuhn
BMC Software, Inc.
postal: 2141 North First Street
San Jose, CA 95131
USA
EMail: randy_presuhn@bmc.com
phone: +1 408 546-1006"
DESCRIPTION
"The MIB module for SNMP transport mappings.
Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3417;
see the RFC itself for full legal notices.
"
REVISION "200210160000Z"
DESCRIPTION
"Clarifications, published as RFC 3417."
REVISION "199601010000Z"
DESCRIPTION
"Clarifications, published as RFC 1906."
REVISION "199304010000Z"
DESCRIPTION
"The initial version, published as RFC 1449."
::= { snmpModules 19 }
-- SNMP over UDP over IPv4
snmpUDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over UDP over IPv4 transport domain.
The corresponding transport address is of type
SnmpUDPAddress."
::= { snmpDomains 1 }
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP over IPv4 address:
octets contents encoding
1-4 IP-address network-byte order
5-6 UDP-port network-byte order
"
SYNTAX OCTET STRING (SIZE (6))
-- SNMP over OSI
snmpCLNSDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over CLNS transport domain.
The corresponding transport address is of type
SnmpOSIAddress."
::= { snmpDomains 2 }
snmpCONSDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over CONS transport domain.
The corresponding transport address is of type
SnmpOSIAddress."
::= { snmpDomains 3 }
SnmpOSIAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "*1x:/1x:"
STATUS current
DESCRIPTION
"Represents an OSI transport-address:
octets contents encoding
1 length of NSAP 'n' as an unsigned-integer
(either 0 or from 3 to 20)
2..(n+1) NSAP concrete binary representation
(n+2)..m TSEL string of (up to 64) octets
"
SYNTAX OCTET STRING (SIZE (1 | 4..85))
-- SNMP over DDP
snmpDDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over DDP transport domain. The corresponding
transport address is of type SnmpNBPAddress."
::= { snmpDomains 4 }
SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an NBP name:
octets contents encoding
1 length of object 'n' as an unsigned integer
2..(n+1) object string of (up to 32) octets
n+2 length of type 'p' as an unsigned integer
(n+3)..(n+2+p) type string of (up to 32) octets
n+3+p length of zone 'q' as an unsigned integer
(n+4+p)..(n+3+p+q) zone string of (up to 32) octets
For comparison purposes, strings are
case-insensitive. All strings may contain any octet
other than 255 (hex ff)."
SYNTAX OCTET STRING (SIZE (3..99))
-- SNMP over IPX
snmpIPXDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMP over IPX transport domain. The corresponding
transport address is of type SnmpIPXAddress."
::= { snmpDomains 5 }
SnmpIPXAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
STATUS current
DESCRIPTION
"Represents an IPX address:
octets contents encoding
1-4 network-number network-byte order
5-10 physical-address network-byte order
11-12 socket-number network-byte order
"
SYNTAX OCTET STRING (SIZE (12))
-- for proxy to SNMPv1 (RFC 1157)
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Domain OBJECT-IDENTITY
STATUS deprecated
DESCRIPTION
"The transport domain for SNMPv1 over UDP over IPv4.
The corresponding transport address is of type
SnmpUDPAddress."
::= { rfc1157Proxy 1 }
-- ::= { rfc1157Proxy 2 } this OID is obsolete
END

421
share/snmp/TRANSPORT-ADDRESS-MIB.txt Normal file
View file

@ -0,0 +1,421 @@
TRANSPORT-ADDRESS-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI
TEXTUAL-CONVENTION FROM SNMPv2-TC;
transportAddressMIB MODULE-IDENTITY
LAST-UPDATED "200211010000Z"
ORGANIZATION
"IETF Operations and Management Area"
CONTACT-INFO
"Juergen Schoenwaelder (Editor)
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig, Germany
Phone: +49 531 391-3289
EMail: schoenw@ibr.cs.tu-bs.de
Send comments to <mibs@ops.ietf.org>."
DESCRIPTION
"This MIB module provides commonly used transport
address definitions.
Copyright (C) The Internet Society (2002). This version of
this MIB module is part of RFC 3419; see the RFC itself for
full legal notices."
-- Revision log
REVISION "200211010000Z"
DESCRIPTION
"Initial version, published as RFC 3419."
::= { mib-2 100 }
transportDomains OBJECT IDENTIFIER ::= { transportAddressMIB 1 }
transportDomainUdpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses."
::= { transportDomains 1 }
transportDomainUdpIpv6 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6 for
global IPv6 addresses."
::= { transportDomains 2 }
transportDomainUdpIpv4z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4z for
scoped IPv4 addresses with a zone index."
::= { transportDomains 3 }
transportDomainUdpIpv6z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6z for
scoped IPv6 addresses with a zone index."
::= { transportDomains 4 }
transportDomainTcpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses."
::= { transportDomains 5 }
transportDomainTcpIpv6 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6 for
global IPv6 addresses."
::= { transportDomains 6 }
transportDomainTcpIpv4z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4z for
scoped IPv4 addresses with a zone index."
::= { transportDomains 7 }
transportDomainTcpIpv6z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6z for
scoped IPv6 addresses with a zone index."
::= { transportDomains 8 }
transportDomainSctpIpv4 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4 for
global IPv4 addresses. This transport domain usually
represents the primary address on multihomed SCTP
endpoints."
::= { transportDomains 9 }
transportDomainSctpIpv6 OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6 for
global IPv6 addresses. This transport domain usually
represents the primary address on multihomed SCTP
endpoints."
::= { transportDomains 10 }
transportDomainSctpIpv4z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv4 transport domain. The corresponding
transport address is of type TransportAddressIPv4z for
scoped IPv4 addresses with a zone index. This transport
domain usually represents the primary address on
multihomed SCTP endpoints."
::= { transportDomains 11 }
transportDomainSctpIpv6z OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP over IPv6 transport domain. The corresponding
transport address is of type TransportAddressIPv6z for
scoped IPv6 addresses with a zone index. This transport
domain usually represents the primary address on
multihomed SCTP endpoints."
::= { transportDomains 12 }
transportDomainLocal OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The Posix Local IPC transport domain. The corresponding
transport address is of type TransportAddressLocal.
The Posix Local IPC transport domain incorporates the
well-known UNIX domain sockets."
::= { transportDomains 13 }
transportDomainUdpDns OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The UDP transport domain using fully qualified domain
names. The corresponding transport address is of type
TransportAddressDns."
::= { transportDomains 14 }
transportDomainTcpDns OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The TCP transport domain using fully qualified domain
names. The corresponding transport address is of type
TransportAddressDns."
::= { transportDomains 15 }
transportDomainSctpDns OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SCTP transport domain using fully qualified domain
names. The corresponding transport address is of type
TransportAddressDns."
::= { transportDomains 16 }
TransportDomain ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a transport domain.
Some possible values, such as transportDomainUdpIpv4, are
defined in this module. Other possible values can be
defined in other MIB modules."
SYNTAX OBJECT IDENTIFIER
--
-- The enumerated values of the textual convention below should
-- be identical to the last sub-identifier of the OID registered
-- for the same domain.
--
TransportAddressType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"A value that represents a transport domain. This is the
enumerated version of the transport domain registrations
in this MIB module. The enumerated values have the
following meaning:
unknown(0) unknown transport address type
udpIpv4(1) transportDomainUdpIpv4
udpIpv6(2) transportDomainUdpIpv6
udpIpv4z(3) transportDomainUdpIpv4z
udpIpv6z(4) transportDomainUdpIpv6z
tcpIpv4(5) transportDomainTcpIpv4
tcpIpv6(6) transportDomainTcpIpv6
tcpIpv4z(7) transportDomainTcpIpv4z
tcpIpv6z(8) transportDomainTcpIpv6z
sctpIpv4(9) transportDomainSctpIpv4
sctpIpv6(10) transportDomainSctpIpv6
sctpIpv4z(11) transportDomainSctpIpv4z
sctpIpv6z(12) transportDomainSctpIpv6z
local(13) transportDomainLocal
udpDns(14) transportDomainUdpDns
tcpDns(15) transportDomainTcpDns
sctpDns(16) transportDomainSctpDns
This textual convention can be used to represent transport
domains in situations where a syntax of TransportDomain is
unwieldy (for example, when used as an index).
The usage of this textual convention implies that additional
transport domains can only be supported by updating this MIB
module. This extensibility restriction does not apply for the
TransportDomain textual convention which allows MIB authors
to define additional transport domains independently in
other MIB modules."
SYNTAX INTEGER {
unknown(0),
udpIpv4(1),
udpIpv6(2),
udpIpv4z(3),
udpIpv6z(4),
tcpIpv4(5),
tcpIpv6(6),
tcpIpv4z(7),
tcpIpv6z(8),
sctpIpv4(9),
sctpIpv6(10),
sctpIpv4z(11),
sctpIpv6z(12),
local(13),
udpDns(14),
tcpDns(15),
sctpDns(16)
}
TransportAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Denotes a generic transport address.
A TransportAddress value is always interpreted within the
context of a TransportAddressType or TransportDomain value.
Every usage of the TransportAddress textual convention MUST
specify the TransportAddressType or TransportDomain object
which provides the context. Furthermore, MIB authors SHOULD
define a separate TransportAddressType or TransportDomain
object for each TransportAddress object. It is suggested that
the TransportAddressType or TransportDomain is logically
registered before the object(s) which use the
TransportAddress textual convention if they appear in the
same logical row.
The value of a TransportAddress object must always be
consistent with the value of the associated
TransportAddressType or TransportDomain object. Attempts
to set a TransportAddress object to a value which is
inconsistent with the associated TransportAddressType or
TransportDomain must fail with an inconsistentValue error.
When this textual convention is used as a syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the OBJECT-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers."
SYNTAX OCTET STRING (SIZE (0..255))
TransportAddressIPv4 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv4
address and a port number (as used for example by UDP,
TCP and SCTP):
octets contents encoding
1-4 IPv4 address network-byte order
5-6 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (6))
TransportAddressIPv6 ::= TEXTUAL-CONVENTION
DISPLAY-HINT "0a[2x:2x:2x:2x:2x:2x:2x:2x]0a:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv6
address and a port number (as used for example by UDP,
TCP and SCTP):
octets contents encoding
1-16 IPv6 address network-byte order
17-18 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (18))
TransportAddressIPv4z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d%4d:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv4
address, a zone index and a port number (as used for
example by UDP, TCP and SCTP):
octets contents encoding
1-4 IPv4 address network-byte order
5-8 zone index network-byte order
9-10 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (10))
TransportAddressIPv6z ::= TEXTUAL-CONVENTION
DISPLAY-HINT "0a[2x:2x:2x:2x:2x:2x:2x:2x%4d]0a:2d"
STATUS current
DESCRIPTION
"Represents a transport address consisting of an IPv6
address, a zone index and a port number (as used for
example by UDP, TCP and SCTP):
octets contents encoding
1-16 IPv6 address network-byte order
17-20 zone index network-byte order
21-22 port number network-byte order
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair."
SYNTAX OCTET STRING (SIZE (22))
TransportAddressLocal ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents a POSIX Local IPC transport address:
octets contents encoding
all POSIX Local IPC address string
The Posix Local IPC transport domain subsumes UNIX domain
sockets.
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair.
When this textual convention is used as a syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the OBJECT-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers."
REFERENCE
"Protocol Independent Interfaces (IEEE POSIX 1003.1g)"
SYNTAX OCTET STRING (SIZE (1..255))
TransportAddressDns ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1a"
STATUS current
DESCRIPTION
"Represents a DNS domain name followed by a colon ':'
(ASCII character 0x3A) and a port number in ASCII.
The name SHOULD be fully qualified whenever possible.
Values of this textual convention are not directly useable as
transport-layer addressing information, and require runtime
resolution. As such, applications that write them must be
prepared for handling errors if such values are not
supported, or cannot be resolved (if resolution occurs at the
time of the management operation).
The DESCRIPTION clause of TransportAddress objects that may
have TransportAddressDns values must fully describe how (and
when) such names are to be resolved to IP addresses and vice
versa.
This textual convention SHOULD NOT be used directly in object
definitions since it restricts addresses to a specific format.
However, if it is used, it MAY be used either on its own or
in conjunction with TransportAddressType or TransportDomain
as a pair.
When this textual convention is used as a syntax of an
index object, there may be issues with the limit of 128
sub-identifiers specified in SMIv2, STD 58. In this case,
the OBJECT-TYPE declaration MUST include a 'SIZE' clause
to limit the number of potential instance sub-identifiers."
SYNTAX OCTET STRING (SIZE (1..255))
END

86
share/snmp/UUID-TC-MIB.txt Normal file
View file

@ -0,0 +1,86 @@
UUID-TC-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, mib-2
FROM SNMPv2-SMI -- RFC 2578
TEXTUAL-CONVENTION
FROM SNMPv2-TC -- RFC 2579
;
uuidTCMIB MODULE-IDENTITY
LAST-UPDATED "201304050000Z" -- April 5, 2013
ORGANIZATION "IETF Energy Management Working Group"
CONTACT-INFO "WG Email: eman@ietf.org
Mailing list subscription info:
http://www.ietf.org/mailman/listinfo/eman
Dan Romascanu
Avaya
Park Atidim, Bldg. #3
Tel Aviv, 61581
Israel
Phone: +972-3-6458414
Email: dromasca@avaya.com
Juergen Quittek
NEC Europe Ltd.
Network Research Division
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 6221 4342-115
Email: quittek@neclab.eu
Mouli Chandramouli
Cisco Systems, Inc.
Sarjapur Outer Ring Road
Bangalore 560103
India
Phone: +91 80 4429 2409
Email: moulchan@cisco.com"
DESCRIPTION
"This MIB module defines TEXTUAL-CONVENTIONs
representing Universally Unique IDentifiers
(UUIDs).
Copyright (c) 2013 IETF Trust and the persons
identified as authors of the code. All rights
reserved.
Redistribution and use in source and binary forms,
with or without modification, is permitted
pursuant to, and subject to the license terms
contained in, the Simplified BSD License set forth
in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info)."
REVISION "201304050000Z" -- April 5, 2013
DESCRIPTION "Initial version of this MIB as published in
RFC 6933."
::= { mib-2 217 }
-- Textual Conventions
UUID ::= TEXTUAL-CONVENTION
DISPLAY-HINT "4x-2x-2x-1x1x-6x"
STATUS current
DESCRIPTION
"Universally Unique Identifier information. The syntax must
conform to RFC 4122, Section 4.1."
SYNTAX OCTET STRING (SIZE (16))
UUIDorZero ::= TEXTUAL-CONVENTION
DISPLAY-HINT "4x-2x-2x-1x1x-6x"
STATUS current
DESCRIPTION
"Universally Unique Identifier information. The syntax must
conform to RFC 4122, Section 4.1.
The semantics of the value zero-length OCTET STRING are
object-specific and must therefore be defined as part of
the description of any object that uses this syntax."
SYNTAX OCTET STRING (SIZE (0|16))
END

1673
share/snmp/VM-MIB.txt Normal file
View file

File diff suppressed because it is too large Load diff

10
share/zoneinfo/datfiles/africa
View file

@ -1,4 +1,4 @@
# $OpenBSD: africa,v 1.74 2024/01/02 22:43:20 millert Exp $
# $OpenBSD: africa,v 1.75 2024/02/05 17:07:23 millert Exp $
# tzdb data for Africa and environs
# This file is in the public domain, so clarified as of
@ -31,6 +31,10 @@
# Milne J. Civil time. Geogr J. 1899 Feb;13(2):173-94.
# https://www.jstor.org/stable/1774359
#
# For the 1911/1912 establishment of standard time in French possessions, see:
# Société Française de Physique, Recueil de constantes physiques (1913),
# page 752, 18b.
#
# European-style abbreviations are commonly used along the Mediterranean.
# For sub-Saharan Africa abbreviations were less standardized.
# Previous editions of this database used WAT, CAT, SAT, and EAT
@ -154,7 +158,7 @@ Zone Africa/Bangui 1:14:20 - LMT 1912
# Chad
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone Africa/Ndjamena 1:00:12 - LMT 1912 # N'Djamena
Zone Africa/Ndjamena 1:00:12 - LMT 1912 Jan 1 # N'Djamena
1:00 - WAT 1979 Oct 14
1:00 1:00 WAST 1980 Mar 8
1:00 - WAT
@ -189,7 +193,7 @@ Zone Africa/Brazzaville 1:01:08 - LMT 1912
# Inaccessible, Nightingale: uninhabited
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone Africa/Abidjan -0:16:08 - LMT 1912
Zone Africa/Abidjan -0:16:08 - LMT 1912 Jan 1
0:00 - GMT
# Djibouti

164
share/zoneinfo/datfiles/asia
View file

@ -1,4 +1,4 @@
# $OpenBSD: asia,v 1.108 2024/01/02 22:43:20 millert Exp $
# $OpenBSD: asia,v 1.109 2024/02/05 17:07:23 millert Exp $
# tzdb data for Asia and environs
# This file is in the public domain, so clarified as of
@ -2479,18 +2479,33 @@ Zone Asia/Amman 2:23:44 - LMT 1931
# effective December 21st, 2018....
# http://adilet.zan.kz/rus/docs/P1800000817 (russian language).
# From Zhanbolat Raimbekov (2024-01-19):
# Kazakhstan (all parts) switching to UTC+5 on March 1, 2024
# https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru
# [in Russian]
# (2024-01-20): https://primeminister.kz/ru/decisions/19012024-20
#
# From Alexander Krivenyshev (2024-01-19):
# According to a different news and the official web site for the Ministry of
# Trade and Integration of the Republic of Kazakhstan:
# https://en.inform.kz/news/kazakhstan-to-switch-to-single-hour-zone-mar-1-54ad0b/
# Zone NAME STDOFF RULES FORMAT [UNTIL]
#
# Almaty (formerly Alma-Ata), representing most locations in Kazakhstan
# This includes KZ-AKM, KZ-ALA, KZ-ALM, KZ-AST, KZ-BAY, KZ-VOS, KZ-ZHA,
# KZ-KAR, KZ-SEV, KZ-PAV, and KZ-YUZ.
# This includes Abai/Abay (ISO 3166-2 code KZ-10), Aqmola/Akmola (KZ-11),
# Almaty (KZ-19), Almaty city (KZ-75), Astana city (KZ-71),
# East Kazkhstan (KZ-63), Jambyl/Zhambyl (KZ-31), Jetisu/Zhetysu (KZ-33),
# Karaganda (KZ-35), North Kazakhstan (KZ-59), Pavlodar (KZ-55),
# Shyumkent city (KZ-79), Turkistan (KZ-61), and Ulytau (KZ-62).
Zone Asia/Almaty 5:07:48 - LMT 1924 May 2 # or Alma-Ata
5:00 - +05 1930 Jun 21
6:00 RussiaAsia +06/+07 1991 Mar 31 2:00s
5:00 RussiaAsia +05/+06 1992 Jan 19 2:00s
6:00 RussiaAsia +06/+07 2004 Oct 31 2:00s
6:00 - +06
# Qyzylorda (aka Kyzylorda, Kizilorda, Kzyl-Orda, etc.) (KZ-KZY)
6:00 - +06 2024 Mar 1 0:00
5:00 - +05
# Qyzylorda (aka Kyzylorda, Kizilorda, Kzyl-Orda, etc.) (KZ-43)
Zone Asia/Qyzylorda 4:21:52 - LMT 1924 May 2
4:00 - +04 1930 Jun 21
5:00 - +05 1981 Apr 1
@ -2503,8 +2518,7 @@ Zone Asia/Qyzylorda 4:21:52 - LMT 1924 May 2
5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s
6:00 - +06 2018 Dec 21 0:00
5:00 - +05
#
# Qostanay (aka Kostanay, Kustanay) (KZ-KUS)
# Qostanay (aka Kostanay, Kustanay) (KZ-39)
# The 1991/2 rules are unclear partly because of the 1997 Turgai
# reorganization.
Zone Asia/Qostanay 4:14:28 - LMT 1924 May 2
@ -2515,9 +2529,9 @@ Zone Asia/Qostanay 4:14:28 - LMT 1924 May 2
5:00 RussiaAsia +05/+06 1991 Mar 31 2:00s
4:00 RussiaAsia +04/+05 1992 Jan 19 2:00s
5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s
6:00 - +06
# Aqtöbe (aka Aktobe, formerly Aktyubinsk) (KZ-AKT)
6:00 - +06 2024 Mar 1 0:00
5:00 - +05
# Aqtöbe (aka Aktobe, formerly Aktyubinsk) (KZ-15)
Zone Asia/Aqtobe 3:48:40 - LMT 1924 May 2
4:00 - +04 1930 Jun 21
5:00 - +05 1981 Apr 1
@ -2527,7 +2541,7 @@ Zone Asia/Aqtobe 3:48:40 - LMT 1924 May 2
4:00 RussiaAsia +04/+05 1992 Jan 19 2:00s
5:00 RussiaAsia +05/+06 2004 Oct 31 2:00s
5:00 - +05
# Mangghystaū (KZ-MAN)
# Mangghystaū (KZ-47)
# Aqtau was not founded until 1963, but it represents an inhabited region,
# so include timestamps before 1963.
Zone Asia/Aqtau 3:21:04 - LMT 1924 May 2
@ -2539,7 +2553,7 @@ Zone Asia/Aqtau 3:21:04 - LMT 1924 May 2
5:00 RussiaAsia +05/+06 1994 Sep 25 2:00s
4:00 RussiaAsia +04/+05 2004 Oct 31 2:00s
5:00 - +05
# Atyraū (KZ-ATY) is like Mangghystaū except it switched from
# Atyraū (KZ-23) is like Mangghystaū except it switched from
# +04/+05 to +05/+06 in spring 1999, not fall 1994.
Zone Asia/Atyrau 3:27:44 - LMT 1924 May 2
3:00 - +03 1930 Jun 21
@ -2550,7 +2564,7 @@ Zone Asia/Atyrau 3:27:44 - LMT 1924 May 2
5:00 RussiaAsia +05/+06 1999 Mar 28 2:00s
4:00 RussiaAsia +04/+05 2004 Oct 31 2:00s
5:00 - +05
# West Kazakhstan (KZ-ZAP)
# West Kazakhstan (KZ-27)
# From Paul Eggert (2016-03-18):
# The 1989 transition is from USSR act No. 227 (1989-03-14).
Zone Asia/Oral 3:25:24 - LMT 1924 May 2 # or Ural'sk
@ -3481,19 +3495,26 @@ Zone Asia/Karachi 4:28:12 - LMT 1907
# ... winter time will begin in Palestine from Saturday 10-28-2023,
# 02:00 AM by 60 minutes back.
#
# From Paul Eggert (2023-03-22):
# From Heba Hamad (2024-01-25):
# the summer time for the years 2024,2025 will begin in Palestine
# from Saturday at 02:00 AM by 60 minutes forward as shown below:
# year date
# 2024 2024-04-20
# 2025 2025-04-12
#
# From Paul Eggert (2024-01-25):
# For now, guess that spring and fall transitions will normally
# continue to use 2022's rules, that during DST Palestine will switch
# to standard time at 02:00 the last Saturday before Ramadan and back
# to DST at 02:00 the first Saturday after Ramadan, and that
# to DST at 02:00 the second Saturday after Ramadan, and that
# if the normal spring-forward or fall-back transition occurs during
# Ramadan the former is delayed and the latter advanced.
# To implement this, I predicted Ramadan-oriented transition dates for
# 2023 through 2086 by running the following program under GNU Emacs 28.2,
# 2026 through 2086 by running the following program under GNU Emacs 29.2,
# with the results integrated by hand into the table below.
# Predictions after 2086 are approximated without Ramadan.
#
# (let ((islamic-year 1444))
# (let ((islamic-year 1447))
# (require 'cal-islam)
# (while (< islamic-year 1510)
# (let ((a (calendar-islamic-to-absolute (list 9 1 islamic-year)))
@ -3502,6 +3523,7 @@ Zone Asia/Karachi 4:28:12 - LMT 1907
# (while (/= saturday (mod (setq a (1- a)) 7)))
# (while (/= saturday (mod b 7))
# (setq b (1+ b)))
# (setq b (+ 7 b))
# (setq a (calendar-gregorian-from-absolute a))
# (setq b (calendar-gregorian-from-absolute b))
# (insert
@ -3552,84 +3574,84 @@ Rule Palestine 2021 only - Oct 29 1:00 0 -
Rule Palestine 2022 only - Mar 27 0:00 1:00 S
Rule Palestine 2022 2035 - Oct Sat<=30 2:00 0 -
Rule Palestine 2023 only - Apr 29 2:00 1:00 S
Rule Palestine 2024 only - Apr 13 2:00 1:00 S
Rule Palestine 2025 only - Apr 5 2:00 1:00 S
Rule Palestine 2024 only - Apr 20 2:00 1:00 S
Rule Palestine 2025 only - Apr 12 2:00 1:00 S
Rule Palestine 2026 2054 - Mar Sat<=30 2:00 1:00 S
Rule Palestine 2036 only - Oct 18 2:00 0 -
Rule Palestine 2037 only - Oct 10 2:00 0 -
Rule Palestine 2038 only - Sep 25 2:00 0 -
Rule Palestine 2039 only - Sep 17 2:00 0 -
Rule Palestine 2039 only - Oct 22 2:00 1:00 S
Rule Palestine 2039 2067 - Oct Sat<=30 2:00 0 -
Rule Palestine 2040 only - Sep 1 2:00 0 -
Rule Palestine 2040 only - Oct 13 2:00 1:00 S
Rule Palestine 2040 only - Oct 20 2:00 1:00 S
Rule Palestine 2040 2067 - Oct Sat<=30 2:00 0 -
Rule Palestine 2041 only - Aug 24 2:00 0 -
Rule Palestine 2041 only - Sep 28 2:00 1:00 S
Rule Palestine 2041 only - Oct 5 2:00 1:00 S
Rule Palestine 2042 only - Aug 16 2:00 0 -
Rule Palestine 2042 only - Sep 20 2:00 1:00 S
Rule Palestine 2042 only - Sep 27 2:00 1:00 S
Rule Palestine 2043 only - Aug 1 2:00 0 -
Rule Palestine 2043 only - Sep 12 2:00 1:00 S
Rule Palestine 2043 only - Sep 19 2:00 1:00 S
Rule Palestine 2044 only - Jul 23 2:00 0 -
Rule Palestine 2044 only - Aug 27 2:00 1:00 S
Rule Palestine 2044 only - Sep 3 2:00 1:00 S
Rule Palestine 2045 only - Jul 15 2:00 0 -
Rule Palestine 2045 only - Aug 19 2:00 1:00 S
Rule Palestine 2045 only - Aug 26 2:00 1:00 S
Rule Palestine 2046 only - Jun 30 2:00 0 -
Rule Palestine 2046 only - Aug 11 2:00 1:00 S
Rule Palestine 2046 only - Aug 18 2:00 1:00 S
Rule Palestine 2047 only - Jun 22 2:00 0 -
Rule Palestine 2047 only - Jul 27 2:00 1:00 S
Rule Palestine 2047 only - Aug 3 2:00 1:00 S
Rule Palestine 2048 only - Jun 6 2:00 0 -
Rule Palestine 2048 only - Jul 18 2:00 1:00 S
Rule Palestine 2048 only - Jul 25 2:00 1:00 S
Rule Palestine 2049 only - May 29 2:00 0 -
Rule Palestine 2049 only - Jul 3 2:00 1:00 S
Rule Palestine 2049 only - Jul 10 2:00 1:00 S
Rule Palestine 2050 only - May 21 2:00 0 -
Rule Palestine 2050 only - Jun 25 2:00 1:00 S
Rule Palestine 2050 only - Jul 2 2:00 1:00 S
Rule Palestine 2051 only - May 6 2:00 0 -
Rule Palestine 2051 only - Jun 17 2:00 1:00 S
Rule Palestine 2051 only - Jun 24 2:00 1:00 S
Rule Palestine 2052 only - Apr 27 2:00 0 -
Rule Palestine 2052 only - Jun 1 2:00 1:00 S
Rule Palestine 2052 only - Jun 8 2:00 1:00 S
Rule Palestine 2053 only - Apr 12 2:00 0 -
Rule Palestine 2053 only - May 24 2:00 1:00 S
Rule Palestine 2053 only - May 31 2:00 1:00 S
Rule Palestine 2054 only - Apr 4 2:00 0 -
Rule Palestine 2054 only - May 16 2:00 1:00 S
Rule Palestine 2055 only - May 1 2:00 1:00 S
Rule Palestine 2056 only - Apr 22 2:00 1:00 S
Rule Palestine 2057 only - Apr 7 2:00 1:00 S
Rule Palestine 2058 max - Mar Sat<=30 2:00 1:00 S
Rule Palestine 2054 only - May 23 2:00 1:00 S
Rule Palestine 2055 only - May 8 2:00 1:00 S
Rule Palestine 2056 only - Apr 29 2:00 1:00 S
Rule Palestine 2057 only - Apr 14 2:00 1:00 S
Rule Palestine 2058 only - Apr 6 2:00 1:00 S
Rule Palestine 2059 max - Mar Sat<=30 2:00 1:00 S
Rule Palestine 2068 only - Oct 20 2:00 0 -
Rule Palestine 2069 only - Oct 12 2:00 0 -
Rule Palestine 2070 only - Oct 4 2:00 0 -
Rule Palestine 2071 only - Sep 19 2:00 0 -
Rule Palestine 2072 only - Sep 10 2:00 0 -
Rule Palestine 2072 only - Oct 15 2:00 1:00 S
Rule Palestine 2072 only - Oct 22 2:00 1:00 S
Rule Palestine 2072 max - Oct Sat<=30 2:00 0 -
Rule Palestine 2073 only - Sep 2 2:00 0 -
Rule Palestine 2073 only - Oct 7 2:00 1:00 S
Rule Palestine 2073 only - Oct 14 2:00 1:00 S
Rule Palestine 2074 only - Aug 18 2:00 0 -
Rule Palestine 2074 only - Sep 29 2:00 1:00 S
Rule Palestine 2074 only - Oct 6 2:00 1:00 S
Rule Palestine 2075 only - Aug 10 2:00 0 -
Rule Palestine 2075 only - Sep 14 2:00 1:00 S
Rule Palestine 2075 only - Sep 21 2:00 1:00 S
Rule Palestine 2076 only - Jul 25 2:00 0 -
Rule Palestine 2076 only - Sep 5 2:00 1:00 S
Rule Palestine 2076 only - Sep 12 2:00 1:00 S
Rule Palestine 2077 only - Jul 17 2:00 0 -
Rule Palestine 2077 only - Aug 28 2:00 1:00 S
Rule Palestine 2077 only - Sep 4 2:00 1:00 S
Rule Palestine 2078 only - Jul 9 2:00 0 -
Rule Palestine 2078 only - Aug 13 2:00 1:00 S
Rule Palestine 2078 only - Aug 20 2:00 1:00 S
Rule Palestine 2079 only - Jun 24 2:00 0 -
Rule Palestine 2079 only - Aug 5 2:00 1:00 S
Rule Palestine 2079 only - Aug 12 2:00 1:00 S
Rule Palestine 2080 only - Jun 15 2:00 0 -
Rule Palestine 2080 only - Jul 20 2:00 1:00 S
Rule Palestine 2080 only - Jul 27 2:00 1:00 S
Rule Palestine 2081 only - Jun 7 2:00 0 -
Rule Palestine 2081 only - Jul 12 2:00 1:00 S
Rule Palestine 2081 only - Jul 19 2:00 1:00 S
Rule Palestine 2082 only - May 23 2:00 0 -
Rule Palestine 2082 only - Jul 4 2:00 1:00 S
Rule Palestine 2082 only - Jul 11 2:00 1:00 S
Rule Palestine 2083 only - May 15 2:00 0 -
Rule Palestine 2083 only - Jun 19 2:00 1:00 S
Rule Palestine 2083 only - Jun 26 2:00 1:00 S
Rule Palestine 2084 only - Apr 29 2:00 0 -
Rule Palestine 2084 only - Jun 10 2:00 1:00 S
Rule Palestine 2084 only - Jun 17 2:00 1:00 S
Rule Palestine 2085 only - Apr 21 2:00 0 -
Rule Palestine 2085 only - Jun 2 2:00 1:00 S
Rule Palestine 2085 only - Jun 9 2:00 1:00 S
Rule Palestine 2086 only - Apr 13 2:00 0 -
Rule Palestine 2086 only - May 18 2:00 1:00 S
Rule Palestine 2086 only - May 25 2:00 1:00 S
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone Asia/Gaza 2:17:52 - LMT 1900 Oct
@ -3657,7 +3679,7 @@ Zone Asia/Hebron 2:20:23 - LMT 1900 Oct
# Philippines
# From Paul Eggert (2018-11-18):
# From Paul Eggert (2024-01-21):
# The Spanish initially used American (west-of-Greenwich) time.
# It is unknown what time Manila kept when the British occupied it from
# 1762-10-06 through 1764-04; for now assume it kept American time.
@ -3665,7 +3687,7 @@ Zone Asia/Hebron 2:20:23 - LMT 1900 Oct
# Philippines, issued a proclamation announcing that 1844-12-30 was to
# be immediately followed by 1845-01-01; see R.H. van Gent's
# History of the International Date Line
# https://www.staff.science.uu.nl/~gent0113/idl/idl_philippines.htm
# https://webspace.science.uu.nl/~gent0113/idl/idl_philippines.htm
# The rest of the data entries are from Shanks & Pottenger.
# From Jesper Nørgaard Welen (2006-04-26):
@ -4082,7 +4104,8 @@ Zone Asia/Tashkent 4:37:11 - LMT 1924 May 2
# The English-language name of Vietnam's most populous city is "Ho Chi Minh
# City"; use Ho_Chi_Minh below to avoid a name of more than 14 characters.
# From Paul Eggert (2022-07-27) after a 2014 heads-up from Trần Ngọc Quân:
# From Paul Eggert (2024-01-14) after a 2014 heads-up from Trần Ngọc Quân
# and a 2024-01-14 heads-up from Đoàn Trần Công Danh:
# Trần Tiến Bình's authoritative book "Lịch Việt Nam: thế kỷ XX-XXI (1901-2100)"
# (Nhà xuất bản Văn Hoá - Thông Tin, Hanoi, 2005), pp 49-50,
# is quoted verbatim in:
@ -4120,6 +4143,27 @@ Zone Asia/Tashkent 4:37:11 - LMT 1924 May 2
#
# Lê Thành Lân: "Lịch hai thế kỷ (1802-2010) và các lịch vĩnh cửu",
# NXB Thuận Hoá, Huế, 1995.
#
# Here is the decision for the September 1945 transition:
# Võ Nguyên Giáp, Việt Nam Dân Quốc Công Báo, No. 1 (1945-09-29), page 13
# http://baochi.nlv.gov.vn/baochi/cgi-bin/baochi?a=d&d=JwvzO19450929.2.5&dliv=none
# It says that on 1945-09-01 at 24:00, Vietnam moved back two hours, to +07.
# It also mentions a 1945-03-29 decree (by a Japanese Goveror-General)
# to set the time zone to +09, but does not say whether that decree
# merely legalized an earlier change to +09.
#
# July 1955 transition:
# Ngô Đình Diệm, Công Báo Việt Nam, No. 92 (1955-07-02), page 1780-1781
# Ordinance (Dụ) No. 46 (1955-06-25)
# http://ddsnext.crl.edu/titles/32341#?c=0&m=29&s=0&cv=4&r=0&xywh=-89%2C342%2C1724%2C1216
# It says that on 1955-07-01 at 01:00, South Vietnam moved back 1 hour (to +07).
#
# December 1959 transition:
# Ngô Đình Diệm, Công Báo Việt Nam Cộng Hòa, 1960 part 1 (1960-01-02), page 62
# Decree (Sắc lệnh) No. 362-TTP (1959-12-30)
# http://ddsnext.crl.edu/titles/32341#?c=0&m=138&s=0&cv=793&r=0&xywh=-54%2C1504%2C1705%2C1202
# It says that on 1959-12-31 at 23:00, South Vietnam moved forward 1 hour (to +08).
# Zone NAME STDOFF RULES FORMAT [UNTIL]
#STDOFF 7:06:30.13
@ -4127,9 +4171,9 @@ Zone Asia/Ho_Chi_Minh 7:06:30 - LMT 1906 Jul 1
7:06:30 - PLMT 1911 May 1 # Phù Liễn MT
7:00 - +07 1942 Dec 31 23:00
8:00 - +08 1945 Mar 14 23:00
9:00 - +09 1945 Sep 2
9:00 - +09 1945 Sep 1 24:00
7:00 - +07 1947 Apr 1
8:00 - +08 1955 Jul 1
8:00 - +08 1955 Jul 1 01:00
7:00 - +07 1959 Dec 31 23:00
8:00 - +08 1975 Jun 13
7:00 - +07

16
share/zoneinfo/datfiles/australasia
View file

@ -1,4 +1,4 @@
# $OpenBSD: australasia,v 1.78 2024/01/02 22:43:20 millert Exp $
# $OpenBSD: australasia,v 1.79 2024/02/05 17:07:23 millert Exp $
# tzdb data for Australasia and environs, and for much of the Pacific
# This file is in the public domain, so clarified as of
@ -431,11 +431,11 @@ Zone Pacific/Fiji 11:55:44 - LMT 1915 Oct 26 # Suva
# French Polynesia
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone Pacific/Gambier -8:59:48 - LMT 1912 Oct # Rikitea
Zone Pacific/Gambier -8:59:48 - LMT 1912 Oct 1 # Rikitea
-9:00 - -09
Zone Pacific/Marquesas -9:18:00 - LMT 1912 Oct
Zone Pacific/Marquesas -9:18:00 - LMT 1912 Oct 1
-9:30 - -0930
Zone Pacific/Tahiti -9:58:16 - LMT 1912 Oct # Papeete
Zone Pacific/Tahiti -9:58:16 - LMT 1912 Oct 1 # Papeete
-10:00 - -10
# Clipperton (near North America) is administered from French Polynesia;
# it is uninhabited.
@ -844,7 +844,7 @@ Zone Pacific/Apia 12:33:04 - LMT 1892 Jul 5
# Solomon Is
# excludes Bougainville, for which see Papua New Guinea
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct # Honiara
Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct 1 # Honiara
11:00 - +11
# Tokelau
@ -1026,6 +1026,10 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901
# Milne J. Civil time. Geogr J. 1899 Feb;13(2):173-94.
# https://www.jstor.org/stable/1774359
#
# For the 1911/1912 establishment of standard time in French possessions, see:
# Société Française de Physique, Recueil de constantes physiques (1913),
# page 752, 18b.
#
# A reliable and entertaining source about time zones is
# Derek Howse, Greenwich time and longitude, Philip Wilson Publishers (1997).
#
@ -2102,7 +2106,7 @@ Zone Pacific/Wallis 12:15:20 - LMT 1901
# ordaining - by a masterpiece of diplomatic flattery - that
# the Fourth of July should be celebrated twice in that year."
# This happened in 1892, according to the Evening News (Sydney) of 1892-07-20.
# https://www.staff.science.uu.nl/~gent0113/idl/idl.htm
# https://webspace.science.uu.nl/~gent0113/idl/idl_alaska_samoa.htm
# Although Shanks & Pottenger says they both switched to UT -11:30
# in 1911, and to -11 in 1950. many earlier sources give -11

4
share/zoneinfo/datfiles/etcetera
View file

@ -1,4 +1,4 @@
# $OpenBSD: etcetera,v 1.21 2022/10/31 15:35:12 millert Exp $
# $OpenBSD: etcetera,v 1.22 2024/02/05 17:07:23 millert Exp $
# tzdb data for ships at sea and other miscellany
# This file is in the public domain, so clarified as of
@ -6,7 +6,7 @@
# These entries are for uses not otherwise covered by the tz database.
# Their main practical use is for platforms like Android that lack
# support for POSIX-style TZ strings. On such platforms these entries
# support for POSIX.1-2017-style TZ strings. On such platforms these entries
# can be useful if the timezone database is wrong or if a ship or
# aircraft at sea is not in a timezone.

31
share/zoneinfo/datfiles/europe
View file

@ -1,4 +1,4 @@
# $OpenBSD: europe,v 1.91 2024/01/02 22:43:20 millert Exp $
# $OpenBSD: europe,v 1.92 2024/02/05 17:07:23 millert Exp $
# tzdb data for Europe and environs
# This file is in the public domain, so clarified as of
@ -1029,9 +1029,34 @@ Zone Europe/Zagreb 1:03:52 - LMT 1884
# Czech Republic (Czechia)
#
# From Paul Eggert (2018-04-15):
# The source for Czech data is: Kdy začíná a končí letní čas. 2018-04-15.
# From Ivan Benovic (2024-01-30):
# https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/1946/54/
# (This is an official link to the Czechoslovak Summer Time Act of
# March 8, 1946 that authorizes the Czechoslovak government to set the
# exact dates of change to summer time and back to Central European Time.
# The act also implicitly confirms Central European Time as the
# official time zone of Czechoslovakia and currently remains in force
# in both the Czech Republic and Slovakia.)
# https://www.psp.cz/eknih/1945pns/tisky/t0216_00.htm
# (This is a link to the original legislative proposal dating back to
# February 22, 1946. The accompanying memorandum to the proposal says
# that an advisory committee on European railroad transportation that
# met in Brussels in October 1945 decided that the change of time
# should be carried out in all participating countries in a strictly
# coordinated manner....)
#
# From Paul Eggert (2024-01-30):
# The source for Czech data is: Kdy začíná a končí letní čas.
# https://kalendar.beda.cz/kdy-zacina-a-konci-letni-cas
# Its main text disagrees with its quoted sources only in 1918,
# where the main text says spring and autumn transitions
# occurred at 02:00 and 03:00 respectively (as usual),
# whereas the 1918 source "Oznámení o zavedení letního času v roce 1918"
# says transitions were at 01:00 and 02:00 respectively.
# As the 1918 source appears to be a humorous piece, and it is
# unlikely that Prague would have disagreed with its neighbors by an hour,
# go with the main text for now.
#
# We know of no English-language name for historical Czech winter time;
# abbreviate it as "GMT", as it happened to be GMT.
#

273
share/zoneinfo/datfiles/leap-seconds.list
View file

@ -1,214 +1,88 @@
# $OpenBSD: leap-seconds.list,v 1.2 2024/01/02 22:43:20 millert Exp $
# $OpenBSD: leap-seconds.list,v 1.3 2024/02/05 17:07:23 millert Exp $
# ATOMIC TIME.
# The Coordinated Universal Time (UTC) is the reference time scale derived
# from The "Temps Atomique International" (TAI) calculated by the Bureau
# International des Poids et Mesures (BIPM) using a worldwide network of atomic
# clocks. UTC differs from TAI by an integer number of seconds; it is the basis
# of all activities in the world.
#
# In the following text, the symbol '#' introduces
# a comment, which continues from that symbol until
# the end of the line. A plain comment line has a
# whitespace character following the comment indicator.
# There are also special comment lines defined below.
# A special comment will always have a non-whitespace
# character in column 2.
#
# A blank line should be ignored.
# ASTRONOMICAL TIME (UT1) is the time scale based on the rate of rotation of the earth.
# It is now mainly derived from Very Long Baseline Interferometry (VLBI). The various
# irregular fluctuations progressively detected in the rotation rate of the Earth lead
# in 1972 to the replacement of UT1 by UTC as the reference time scale.
#
# The following table shows the corrections that must
# be applied to compute International Atomic Time (TAI)
# from the Coordinated Universal Time (UTC) values that
# are transmitted by almost all time services.
#
# The first column shows an epoch as a number of seconds
# since 1 January 1900, 00:00:00 (1900.0 is also used to
# indicate the same epoch.) Both of these time stamp formats
# ignore the complexities of the time scales that were
# used before the current definition of UTC at the start
# of 1972. (See note 3 below.)
# The second column shows the number of seconds that
# must be added to UTC to compute TAI for any timestamp
# at or after that epoch. The value on each line is
# valid from the indicated initial instant until the
# epoch given on the next one or indefinitely into the
# future if there is no next line.
# (The comment on each line shows the representation of
# the corresponding initial epoch in the usual
# day-month-year format. The epoch always begins at
# 00:00:00 UTC on the indicated day. See Note 5 below.)
# LEAP SECOND
# Atomic clocks are more stable than the rate of the earth rotation since the latter
# undergoes a full range of geophysical perturbations at various time scales: lunisolar
# and core-mantle torques, atmospheric and oceanic effetcs, etc.
# Leap seconds are needed to keep the two time scales in agreement, i.e. UT1-UTC smaller
# than 0.9 second. Therefore, when necessary a "leap second" is applied to UTC.
# Since the adoption of this system in 1972 it has been necessary to add a number of seconds to UTC,
# firstly due to the initial choice of the value of the second (1/86400 mean solar day of
# the year 1820) and secondly to the general slowing down of the Earth's rotation. It is
# theorically possible to have a negative leap second (a second removed from UTC), but so far,
# all leap seconds have been positive (a second has been added to UTC). Based on what we know about
# the earth's rotation, it is unlikely that we will ever have a negative leap second.
#
# Important notes:
#
# 1. Coordinated Universal Time (UTC) is often referred to
# as Greenwich Mean Time (GMT). The GMT time scale is no
# longer used, and the use of GMT to designate UTC is
# discouraged.
# HISTORY
# The first leap second was added on June 30, 1972. Until yhe year 2000, it was necessary in average to add a
# leap second at a rate of 1 to 2 years. Since the year 2000 leap seconds are introduced with an
# average interval of 3 to 4 years due to the acceleration of the Earth rotation speed.
#
# 2. The UTC time scale is realized by many national
# laboratories and timing centers. Each laboratory
# identifies its realization with its name: Thus
# UTC(NIST), UTC(USNO), etc. The differences among
# these different realizations are typically on the
# order of a few nanoseconds (i.e., 0.000 000 00x s)
# and can be ignored for many purposes. These differences
# are tabulated in Circular T, which is published monthly
# by the International Bureau of Weights and Measures
# (BIPM). See www.bipm.org for more information.
#
# 3. The current definition of the relationship between UTC
# and TAI dates from 1 January 1972. A number of different
# time scales were in use before that epoch, and it can be
# quite difficult to compute precise timestamps and time
# intervals in those "prehistoric" days. For more information,
# consult:
#
# The Explanatory Supplement to the Astronomical
# Ephemeris.
# or
# Terry Quinn, "The BIPM and the Accurate Measurement
# of Time," Proc. of the IEEE, Vol. 79, pp. 894-905,
# July, 1991. <http://dx.doi.org/10.1109/5.84965>
# reprinted in:
# Christine Hackman and Donald B Sullivan (eds.)
# Time and Frequency Measurement
# American Association of Physics Teachers (1996)
# <http://tf.nist.gov/general/pdf/1168.pdf>, pp. 75-86
#
# 4. The decision to insert a leap second into UTC is currently
# the responsibility of the International Earth Rotation and
# Reference Systems Service. (The name was changed from the
# International Earth Rotation Service, but the acronym IERS
# is still used.)
#
# Leap seconds are announced by the IERS in its Bulletin C.
#
# See www.iers.org for more details.
#
# Every national laboratory and timing center uses the
# data from the BIPM and the IERS to construct UTC(lab),
# their local realization of UTC.
#
# Although the definition also includes the possibility
# of dropping seconds ("negative" leap seconds), this has
# never been done and is unlikely to be necessary in the
# foreseeable future.
#
# 5. If your system keeps time as the number of seconds since
# some epoch (e.g., NTP timestamps), then the algorithm for
# assigning a UTC time stamp to an event that happens during a positive
# leap second is not well defined. The official name of that leap
# second is 23:59:60, but there is no way of representing that time
# in these systems.
# Many systems of this type effectively stop the system clock for
# one second during the leap second and use a time that is equivalent
# to 23:59:59 UTC twice. For these systems, the corresponding TAI
# timestamp would be obtained by advancing to the next entry in the
# following table when the time equivalent to 23:59:59 UTC
# is used for the second time. Thus the leap second which
# occurred on 30 June 1972 at 23:59:59 UTC would have TAI
# timestamps computed as follows:
#
# ...
# 30 June 1972 23:59:59 (2287785599, first time): TAI= UTC + 10 seconds
# 30 June 1972 23:59:60 (2287785599,second time): TAI= UTC + 11 seconds
# 1 July 1972 00:00:00 (2287785600) TAI= UTC + 11 seconds
# ...
#
# If your system realizes the leap second by repeating 00:00:00 UTC twice
# (this is possible but not usual), then the advance to the next entry
# in the table must occur the second time that a time equivalent to
# 00:00:00 UTC is used. Thus, using the same example as above:
#
# ...
# 30 June 1972 23:59:59 (2287785599): TAI= UTC + 10 seconds
# 30 June 1972 23:59:60 (2287785600, first time): TAI= UTC + 10 seconds
# 1 July 1972 00:00:00 (2287785600,second time): TAI= UTC + 11 seconds
# ...
#
# in both cases the use of timestamps based on TAI produces a smooth
# time scale with no discontinuity in the time interval. However,
# although the long-term behavior of the time scale is correct in both
# methods, the second method is technically not correct because it adds
# the extra second to the wrong day.
#
# This complexity would not be needed for negative leap seconds (if they
# are ever used). The UTC time would skip 23:59:59 and advance from
# 23:59:58 to 00:00:00 in that case. The TAI offset would decrease by
# 1 second at the same instant. This is a much easier situation to deal
# with, since the difficulty of unambiguously representing the epoch
# during the leap second does not arise.
#
# Some systems implement leap seconds by amortizing the leap second
# over the last few minutes of the day. The frequency of the local
# clock is decreased (or increased) to realize the positive (or
# negative) leap second. This method removes the time step described
# above. Although the long-term behavior of the time scale is correct
# in this case, this method introduces an error during the adjustment
# period both in time and in frequency with respect to the official
# definition of UTC.
# RESPONSABILITY OF THE DECISION TO INTRODUCE A LEAP SECOND IN UTC
# The decision to introduce a leap second in UTC is the responsibility of the Earth Orientation Center of
# the International Earth Rotation and reference System Service (IERS). This center is located at Paris
# Observatory. According to international agreements, leap seconds should only be scheduled for certain dates:
# first preference is given to the end of December and June, and second preference at the end of March
# and September. Since the introduction of leap seconds in 1972, only dates in June and December were used.
#
# Questions or comments to:
# Judah Levine
# Time and Frequency Division
# NIST
# Boulder, Colorado
# Judah.Levine@nist.gov
# Christian Bizouard: christian.bizouard@obspm.fr
# Earth orientation Center of the IERS
# Paris Observatory, France
#
# Last Update of leap second values: 8 July 2016
#
# The following line shows this last update date in NTP timestamp
# format. This is the date on which the most recent change to
# the leap second data was added to the file. This line can
# be identified by the unique pair of characters in the first two
# columns as shown below.
#
#$ 3676924800
# COPYRIGHT STATUS OF THIS FILE
# This file is in the public domain.
#
# The NTP timestamps are in units of seconds since the NTP epoch,
# which is 1 January 1900, 00:00:00. The Modified Julian Day number
# corresponding to the NTP time stamp, X, can be computed as
#
# X/86400 + 15020
# VALIDITY OF THE FILE
# It is important to express the validity of the file. These next two dates are
# given in units of seconds since 1900.0.
#
# where the first term converts seconds to days and the second
# term adds the MJD corresponding to the time origin defined above.
# The integer portion of the result is the integer MJD for that
# day, and any remainder is the time of day, expressed as the
# fraction of the day since 0 hours UTC. The conversion from day
# fraction to seconds or to hours, minutes, and seconds may involve
# rounding or truncation, depending on the method used in the
# computation.
# 1) Last update of the file.
#
# The data in this file will be updated periodically as new leap
# seconds are announced. In addition to being entered on the line
# above, the update time (in NTP format) will be added to the basic
# file name leap-seconds to form the name leap-seconds.<NTP TIME>.
# In addition, the generic name leap-seconds.list will always point to
# the most recent version of the file.
# Updated through IERS Bulletin C (https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat)
#
# This update procedure will be performed only when a new leap second
# is announced.
# The following line shows the last update of this file in NTP timestamp:
#
# The following entry specifies the expiration date of the data
# in this file in units of seconds since the origin at the instant
# 1 January 1900, 00:00:00. This expiration date will be changed
# at least twice per year whether or not a new leap second is
# announced. These semi-annual changes will be made no later
# than 1 June and 1 December of each year to indicate what
# action (if any) is to be taken on 30 June and 31 December,
# respectively. (These are the customary effective dates for new
# leap seconds.) This expiration date will be identified by a
# unique pair of characters in columns 1 and 2 as shown below.
# In the unlikely event that a leap second is announced with an
# effective date other than 30 June or 31 December, then this
# file will be edited to include that leap second as soon as it is
# announced or at least one month before the effective date
# (whichever is later).
# If an announcement by the IERS specifies that no leap second is
# scheduled, then only the expiration date of the file will
# be advanced to show that the information in the file is still
# current -- the update time stamp, the data and the name of the file
# will not change.
#$ 3913697179
#
# Updated through IERS Bulletin C66
# File expires on: 28 June 2024
# 2) Expiration date of the file given on a semi-annual basis: last June or last December
#
#@ 3928521600
# File expires on 28 December 2024
#
# Expire date in NTP timestamp:
#
#@ 3944332800
#
#
# LIST OF LEAP SECONDS
# NTP timestamp (X parameter) is the number of seconds since 1900.0
#
# MJD: The Modified Julian Day number. MJD = X/86400 + 15020
#
# DTAI: The difference DTAI= TAI-UTC in units of seconds
# It is the quantity to add to UTC to get the time in TAI
#
# Day Month Year : epoch in clear
#
#NTP Time DTAI Day Month Year
#
2272060800 10 # 1 Jan 1972
2287785600 11 # 1 Jul 1972
@ -239,18 +113,9 @@
3644697600 36 # 1 Jul 2015
3692217600 37 # 1 Jan 2017
#
# the following special comment contains the
# hash value of the data in this file computed
# use the secure hash algorithm as specified
# by FIPS 180-1. See the files in ~/pub/sha for
# the details of how this hash value is
# computed. Note that the hash computation
# ignores comments and whitespace characters
# in data lines. It includes the NTP values
# of both the last modification time and the
# expiration time of the file, but not the
# white space on those lines.
# the hash line is also ignored in the
# computation.
# A hash code has been generated to be able to verify the integrity
# of this file. For more information about using this hash code,
# please see the readme file in the 'source' directory :
# https://hpiers.obspm.fr/iers/bul/bulc/ntp/sources/README
#
#h 16edd0f0 3666784f 37db6bdd e74ced87 59af48f1
#h 9dac5845 8acd32c0 2947d462 daf4a943 f58d9391

31
share/zoneinfo/datfiles/northamerica
View file

@ -1,4 +1,4 @@
# $OpenBSD: northamerica,v 1.85 2024/01/02 22:43:20 millert Exp $
# $OpenBSD: northamerica,v 1.86 2024/02/05 17:07:23 millert Exp $
# tzdb data for North and Central America and environs
# This file is in the public domain, so clarified as of
@ -1269,6 +1269,10 @@ Zone America/Menominee -5:50:27 - LMT 1885 Sep 18 12:00
# <http://cs.ucla.edu/~eggert/The-Waste-of-Daylight-19th.pdf>
# [PDF] (1914-03)
#
# For the 1911/1912 establishment of standard time in French possessions, see:
# Société Française de Physique, Recueil de constantes physiques (1913),
# page 752, 18b.
#
# See the 'europe' file for Greenland.
# Canada
@ -1355,7 +1359,7 @@ Zone America/Menominee -5:50:27 - LMT 1885 Sep 18 12:00
# From Paul Eggert (2014-10-18):
# H. David Matthews and Mary Vincent's map
# "It's about TIME", _Canadian Geographic_ (September-October 1998)
# http://www.canadiangeographic.ca/Magazine/SO98/alacarte.asp
# https://web.archive.org/web/19990827055050/https://canadiangeographic.ca/SO98/geomap.htm
# contains detailed boundaries for regions observing nonstandard
# time and daylight saving time arrangements in Canada circa 1998.
#
@ -1647,6 +1651,15 @@ Zone America/Blanc-Sablon -3:48:28 - LMT 1884
# Some cities in the United States have pushed the deadline back
# three weeks and will change over from daylight saving in October.
# From Chris Walton (2024-01-09):
# The [Toronto] changes in 1947, 1948, and 1949 took place at 2:00 a.m. local
# time instead of midnight.... Toronto Daily Star - ...
# April 2, 1947 - Page 39 ... April 7, 1948 - Page 13 ...
# April 2, 1949 - Page 1 ... April 7, 1949 - Page 24 ...
# November 25, 1949 - Page 52 ... April 21, 1950 - Page 14 ...
# September 19, 1950 - Page 46 ... September 20, 1950 - Page 3 ...
# November 24, 1950 - Page 21
# From Arthur David Olson (2010-07-17):
#
# "Standard Time and Time Zones in Canada" appeared in
@ -1708,13 +1721,9 @@ Rule Toronto 1927 1937 - Sep Sun>=25 2:00 0 S
Rule Toronto 1928 1937 - Apr Sun>=25 2:00 1:00 D
Rule Toronto 1938 1940 - Apr lastSun 2:00 1:00 D
Rule Toronto 1938 1939 - Sep lastSun 2:00 0 S
Rule Toronto 1945 1946 - Sep lastSun 2:00 0 S
Rule Toronto 1946 only - Apr lastSun 2:00 1:00 D
Rule Toronto 1947 1949 - Apr lastSun 0:00 1:00 D
Rule Toronto 1947 1948 - Sep lastSun 0:00 0 S
Rule Toronto 1949 only - Nov lastSun 0:00 0 S
Rule Toronto 1950 1973 - Apr lastSun 2:00 1:00 D
Rule Toronto 1950 only - Nov lastSun 2:00 0 S
Rule Toronto 1945 1948 - Sep lastSun 2:00 0 S
Rule Toronto 1946 1973 - Apr lastSun 2:00 1:00 D
Rule Toronto 1949 1950 - Nov lastSun 2:00 0 S
Rule Toronto 1951 1956 - Sep lastSun 2:00 0 S
# Shanks & Pottenger say Toronto ended DST a week early in 1971,
# namely on 1971-10-24, but Mark Brader wrote (2003-05-31) that this
@ -3502,7 +3511,7 @@ Zone America/Jamaica -5:07:10 - LMT 1890 # Kingston
# Martinique
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone America/Martinique -4:04:20 - LMT 1890 # Fort-de-France
-4:04:20 - FFMT 1911 May # Fort-de-France MT
-4:04:20 - FFMT 1911 May 1 # Fort-de-France MT
-4:00 - AST 1980 Apr 6
-4:00 1:00 ADT 1980 Sep 28
-4:00 - AST
@ -3605,7 +3614,7 @@ Zone America/St_Lucia -4:04:00 - LMT 1890 # Castries
# St Pierre and Miquelon
# There are too many St Pierres elsewhere, so we'll use 'Miquelon'.
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre
Zone America/Miquelon -3:44:40 - LMT 1911 Jun 15 # St Pierre
-4:00 - AST 1980 May
-3:00 - -03 1987
-3:00 Canada -03/-02

7
share/zoneinfo/datfiles/southamerica
View file

@ -1,4 +1,4 @@
# $OpenBSD: southamerica,v 1.80 2024/01/02 22:43:20 millert Exp $
# $OpenBSD: southamerica,v 1.81 2024/02/05 17:07:23 millert Exp $
# tzdb data for South America and environs
# This file is in the public domain, so clarified as of
@ -1584,8 +1584,11 @@ Zone Atlantic/Stanley -3:51:24 - LMT 1890
-3:00 - -03
# French Guiana
# For the 1911/1912 establishment of standard time in French possessions, see:
# Société Française de Physique, Recueil de constantes physiques (1913),
# page 752, 18b.
# Zone NAME STDOFF RULES FORMAT [UNTIL]
Zone America/Cayenne -3:29:20 - LMT 1911 Jul
Zone America/Cayenne -3:29:20 - LMT 1911 Jul 1
-4:00 - -04 1967 Oct
-3:00 - -03

11
share/zoneinfo/leapseconds.awk
View file

@ -1,4 +1,4 @@
# Generate zic format 'leapseconds' from NIST format 'leap-seconds.list'.
# Generate zic format 'leapseconds' from NIST/IERS format 'leap-seconds.list'.
# This file is in the public domain.
@ -21,13 +21,10 @@ BEGIN {
print "# This file is in the public domain."
print ""
print "# This file is generated automatically from the data in the public-domain"
print "# NIST format leap-seconds.list file, which can be copied from"
print "# <ftp://ftp.nist.gov/pub/time/leap-seconds.list>"
print "# or <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>."
print "# The NIST file is used instead of its IERS upstream counterpart"
print "# NIST/IERS format leap-seconds.list file, which can be copied from"
print "# <https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>"
print "# because under US law the NIST file is public domain"
print "# whereas the IERS file's copyright and license status is unclear."
print "# or, in a variant with different comments, from"
print "# <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>."
print "# For more about leap-seconds.list, please see"
print "# The NTP Timescale and Leap Seconds"
print "# <https://www.eecis.udel.edu/~mills/leap.html>."

98
share/zoneinfo/zishrink.awk
View file

@ -162,7 +162,7 @@ function make_line(n, field, \
# Process the input line LINE and save it for later output.
function process_input_line(line, \
f, field, end, i, n, r, startdef, \
f, field, end, n, outline, r, \
linkline, ruleline, zoneline)
{
# Remove comments, normalize spaces, and append a space to each line.
@ -199,8 +199,10 @@ function process_input_line(line, \
}
# Abbreviate "max", "min", "only" and month names.
gsub(/ max /, " ma ", line)
gsub(/ min /, " mi ", line)
# Although "max" and "min" can both be abbreviated to just "m",
# the longer forms "ma" and "mi" are needed with zic 2023d and earlier.
gsub(/ max /, dataform == "vanguard" ? " m " : " ma ", line)
gsub(/ min /, dataform == "vanguard" ? " m " : " mi ", line)
gsub(/ only /, " o ", line)
gsub(/ Jan /, " Ja ", line)
gsub(/ Feb /, " F ", line)
@ -234,66 +236,96 @@ function process_input_line(line, \
rule_used[r] = 1
}
# If this zone supersedes an earlier one, delete the earlier one
# from the saved output lines.
startdef = ""
if (zoneline)
zonename = startdef = field[2]
else if (linkline)
zonename = startdef = field[3]
else if (ruleline)
zonename = ""
if (startdef) {
i = zonedef[startdef]
if (i) {
do
output_line[i - 1] = ""
while (output_line[i++] ~ /^[-+0-9]/);
}
}
zonedef[zonename] = nout + 1
# Save the line for later output.
output_line[nout++] = make_line(n, field)
# Save the information for later output.
outline = make_line(n, field)
if (ruleline)
rule_output_line[nrule_out++] = outline
else if (linkline) {
# In vanguard format with Gawk, links are output sorted by destination.
if (dataform == "vanguard" && PROCINFO["version"])
linkdef[zonename] = field[2]
else
link_output_line[nlink_out++] = outline
}else
zonedef[zonename] = (zoneline ? "" : zonedef[zonename] "\n") outline
}
function omit_unused_rules( \
i, field)
{
for (i = 0; i < nout; i++) {
split(output_line[i], field)
if (field[1] == "R" && !rule_used[field[2]]) {
output_line[i] = ""
}
for (i = 0; i < nrule_out; i++) {
split(rule_output_line[i], field)
if (!rule_used[field[2]])
rule_output_line[i] = ""
}
}
function abbreviate_rule_names( \
abbr, f, field, i, n, r)
abbr, f, field, i, n, newdef, newline, r, \
zoneline, zonelines, zonename)
{
for (i = 0; i < nout; i++) {
n = split(output_line[i], field)
for (i = 0; i < nrule_out; i++) {
n = split(rule_output_line[i], field)
if (n) {
f = field[1] == "Z" ? 4 : field[1] == "L" ? 0 : 2
r = field[f]
r = field[2]
if (r ~ /^[^-+0-9]/) {
abbr = rule[r]
if (!abbr) {
rule[r] = abbr = gen_rule_name(r)
}
field[f] = abbr
output_line[i] = make_line(n, field)
field[2] = abbr
rule_output_line[i] = make_line(n, field)
}
}
}
for (zonename in zonedef) {
zonelines = split(zonedef[zonename], zoneline, /\n/)
newdef = ""
for (i = 1; i <= zonelines; i++) {
newline = zoneline[i]
n = split(newline, field)
f = i == 1 ? 4 : 2
r = rule[field[f]]
if (r) {
field[f] = r
newline = make_line(n, field)
}
newdef = (newdef ? newdef "\n" : "") newline
}
zonedef[zonename] = newdef
}
}
function output_saved_lines( \
i)
i, zonename)
{
for (i = 0; i < nout; i++)
if (output_line[i])
print output_line[i]
for (i = 0; i < nrule_out; i++)
if (rule_output_line[i])
print rule_output_line[i]
# When using gawk, output zones sorted by name.
# This makes the output a bit more compressible.
PROCINFO["sorted_in"] = "@ind_str_asc"
for (zonename in zonedef)
print zonedef[zonename]
if (nlink_out)
for (i = 0; i < nlink_out; i++)
print link_output_line[i]
else {
# When using gawk, output links sorted by destination.
# This also helps compressibility a bit.
PROCINFO["sorted_in"] = "@val_type_asc"
for (zonename in linkdef)
printf "L %s %s\n", linkdef[zonename], zonename
}
}
BEGIN {

5
sys/dev/pci/if_qwx_pci.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: if_qwx_pci.c,v 1.5 2024/02/03 20:07:19 kettenis Exp $ */
/* $OpenBSD: if_qwx_pci.c,v 1.6 2024/02/05 10:45:47 kettenis Exp $ */
/*
* Copyright 2023 Stefan Sperling <stsp@openbsd.org>
@ -3180,6 +3180,9 @@ qwx_mhi_ready_state_transition(struct qwx_pci_softc *psc)
void
qwx_mhi_ee_amss_state_transition(struct qwx_pci_softc *psc)
{
/* XXX without this delay starting the channels may fail */
delay(1000);
qwx_mhi_start_channels(psc);
}

10
sys/dev/pci/mfii.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: mfii.c,v 1.89 2023/07/06 10:17:43 visa Exp $ */
/* $OpenBSD: mfii.c,v 1.90 2024/02/05 19:08:29 deraadt Exp $ */
/*
* Copyright (c) 2012 David Gwynne <dlg@openbsd.org>
@ -600,6 +600,14 @@ const struct mfii_device mfii_devices[] = {
{ PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_3416,
&mfii_iop_35 },
{ PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_3516,
&mfii_iop_35 },
{ PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_38XX,
&mfii_iop_35 },
{ PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_38XX_2,
&mfii_iop_35 },
{ PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_39XX,
&mfii_iop_35 },
{ PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_39XX_2,
&mfii_iop_35 }
};

6
sys/dev/pci/pcidevs
View file

@ -1,4 +1,4 @@
$OpenBSD: pcidevs,v 1.2060 2023/12/03 00:14:53 jsg Exp $
$OpenBSD: pcidevs,v 1.2061 2024/02/05 19:07:45 deraadt Exp $
/* $NetBSD: pcidevs,v 1.30 1997/06/24 06:20:24 thorpej Exp $ */
/*
@ -9177,6 +9177,10 @@ product SYMBIOS YELLOWFIN_1 0x0701 Yellowfin
product SYMBIOS YELLOWFIN_2 0x0702 Yellowfin
product SYMBIOS 61C102 0x0901 61C102
product SYMBIOS 63C815 0x1000 63C815
product SYMBIOS MEGARAID_39XX 0x10e1 MegaRAID SAS39XX
product SYMBIOS MEGARAID_39XX_2 0x10e2 MegaRAID SAS39XX
product SYMBIOS MEGARAID_38XX 0x10e5 MegaRAID SAS38XX
product SYMBIOS MEGARAID_38XX_2 0x10e6 MegaRAID SAS38XX
product SYMBIOS 1030R 0x1030 53c1030R
product SYMBIOS MEGARAID 0x1960 MegaRAID

6
sys/dev/pci/pcidevs.h
View file

@ -2,7 +2,7 @@
* THIS FILE AUTOMATICALLY GENERATED. DO NOT EDIT.
*
* generated from:
* OpenBSD: pcidevs,v 1.2060 2023/12/03 00:14:53 jsg Exp
* OpenBSD: pcidevs,v 1.2061 2024/02/05 19:07:45 deraadt Exp
*/
/* $NetBSD: pcidevs,v 1.30 1997/06/24 06:20:24 thorpej Exp $ */
@ -9182,6 +9182,10 @@
#define PCI_PRODUCT_SYMBIOS_YELLOWFIN_2 0x0702 /* Yellowfin */
#define PCI_PRODUCT_SYMBIOS_61C102 0x0901 /* 61C102 */
#define PCI_PRODUCT_SYMBIOS_63C815 0x1000 /* 63C815 */
#define PCI_PRODUCT_SYMBIOS_MEGARAID_39XX 0x10e1 /* MegaRAID SAS39XX */
#define PCI_PRODUCT_SYMBIOS_MEGARAID_39XX_2 0x10e2 /* MegaRAID SAS39XX */
#define PCI_PRODUCT_SYMBIOS_MEGARAID_38XX 0x10e5 /* MegaRAID SAS38XX */
#define PCI_PRODUCT_SYMBIOS_MEGARAID_38XX_2 0x10e6 /* MegaRAID SAS38XX */
#define PCI_PRODUCT_SYMBIOS_1030R 0x1030 /* 53c1030R */
#define PCI_PRODUCT_SYMBIOS_MEGARAID 0x1960 /* MegaRAID */

18
sys/dev/pci/pcidevs_data.h
View file

@ -2,7 +2,7 @@
* THIS FILE AUTOMATICALLY GENERATED. DO NOT EDIT.
*
* generated from:
* OpenBSD: pcidevs,v 1.2060 2023/12/03 00:14:53 jsg Exp
* OpenBSD: pcidevs,v 1.2061 2024/02/05 19:07:45 deraadt Exp
*/
/* $NetBSD: pcidevs,v 1.30 1997/06/24 06:20:24 thorpej Exp $ */
@ -32995,6 +32995,22 @@ static const struct pci_known_product pci_known_products[] = {
PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_63C815,
"63C815",
},
{
PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_39XX,
"MegaRAID SAS39XX",
},
{
PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_39XX_2,
"MegaRAID SAS39XX",
},
{
PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_38XX,
"MegaRAID SAS38XX",
},
{
PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_MEGARAID_38XX_2,
"MegaRAID SAS38XX",
},
{
PCI_VENDOR_SYMBIOS, PCI_PRODUCT_SYMBIOS_1030R,
"53c1030R",

12
sys/kern/uipc_socket.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: uipc_socket.c,v 1.316 2024/02/03 22:50:08 mvs Exp $ */
/* $OpenBSD: uipc_socket.c,v 1.317 2024/02/05 20:21:38 mvs Exp $ */
/* $NetBSD: uipc_socket.c,v 1.21 1996/02/04 02:17:52 christos Exp $ */
/*
@ -1224,7 +1224,9 @@ sorflush(struct socket *so)
m = sb->sb_mb;
memset(&sb->sb_startzero, 0,
(caddr_t)&sb->sb_endzero - (caddr_t)&sb->sb_startzero);
mtx_enter(&sb->sb_mtx);
sb->sb_timeo_nsecs = INFSLP;
mtx_leave(&sb->sb_mtx);
sbunlock(so, sb);
if (pr->pr_flags & PR_RIGHTS && pr->pr_domain->dom_dispose)
(*pr->pr_domain->dom_dispose)(m);
@ -1907,9 +1909,9 @@ sosetopt(struct socket *so, int level, int optname, struct mbuf *m)
if (nsecs == 0)
nsecs = INFSLP;
solock(so);
mtx_enter(&sb->sb_mtx);
sb->sb_timeo_nsecs = nsecs;
sounlock(so);
mtx_leave(&sb->sb_mtx);
break;
}
@ -2047,9 +2049,9 @@ sogetopt(struct socket *so, int level, int optname, struct mbuf *m)
struct timeval tv;
uint64_t nsecs;
solock_shared(so);
mtx_enter(&sb->sb_mtx);
nsecs = sb->sb_timeo_nsecs;
sounlock_shared(so);
mtx_leave(&sb->sb_mtx);
m->m_len = sizeof(struct timeval);
memset(&tv, 0, sizeof(tv));

10
sys/kern/uipc_socket2.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: uipc_socket2.c,v 1.141 2024/02/03 22:50:08 mvs Exp $ */
/* $OpenBSD: uipc_socket2.c,v 1.142 2024/02/05 20:21:38 mvs Exp $ */
/* $NetBSD: uipc_socket2.c,v 1.11 1996/02/04 02:17:55 christos Exp $ */
/*
@ -216,10 +216,14 @@ sonewconn(struct socket *head, int connstatus, int wait)
goto fail;
so->so_snd.sb_wat = head->so_snd.sb_wat;
so->so_snd.sb_lowat = head->so_snd.sb_lowat;
mtx_enter(&head->so_snd.sb_mtx);
so->so_snd.sb_timeo_nsecs = head->so_snd.sb_timeo_nsecs;
mtx_leave(&head->so_snd.sb_mtx);
so->so_rcv.sb_wat = head->so_rcv.sb_wat;
so->so_rcv.sb_lowat = head->so_rcv.sb_lowat;
mtx_enter(&head->so_rcv.sb_mtx);
so->so_rcv.sb_timeo_nsecs = head->so_rcv.sb_timeo_nsecs;
mtx_leave(&head->so_rcv.sb_mtx);
sigio_copy(&so->so_sigio, &head->so_sigio);
@ -506,15 +510,17 @@ sosleep_nsec(struct socket *so, void *ident, int prio, const char *wmesg,
int
sbwait(struct socket *so, struct sockbuf *sb)
{
uint64_t timeo_nsecs;
int prio = (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK | PCATCH;
soassertlocked(so);
mtx_enter(&sb->sb_mtx);
timeo_nsecs = sb->sb_timeo_nsecs;
sb->sb_flags |= SB_WAIT;
mtx_leave(&sb->sb_mtx);
return sosleep_nsec(so, &sb->sb_cc, prio, "netio", sb->sb_timeo_nsecs);
return sosleep_nsec(so, &sb->sb_cc, prio, "netio", timeo_nsecs);
}
int

4
sys/net/if.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: if.c,v 1.716 2024/01/06 11:42:11 bluhm Exp $ */
/* $OpenBSD: if.c,v 1.718 2024/02/06 00:18:53 bluhm Exp $ */
/* $NetBSD: if.c,v 1.35 1996/05/07 05:26:04 thorpej Exp $ */
/*
@ -1788,8 +1788,10 @@ if_linkstate(struct ifnet *ifp)
{
NET_ASSERT_LOCKED();
if (panicstr == NULL) {
rtm_ifchg(ifp);
rt_if_track(ifp);
}
if_hooks_run(&ifp->if_linkstatehooks);
}

4
sys/net/route.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: route.c,v 1.427 2024/01/31 14:56:42 bluhm Exp $ */
/* $OpenBSD: route.c,v 1.428 2024/02/05 23:16:39 bluhm Exp $ */
/* $NetBSD: route.c,v 1.14 1996/02/13 22:00:46 christos Exp $ */
/*
@ -214,9 +214,11 @@ route_cache(struct route *ro, struct in_addr addr, u_int rtableid)
ro->ro_tableid == rtableid &&
ro->ro_dst.sa_family == AF_INET &&
satosin(&ro->ro_dst)->sin_addr.s_addr == addr.s_addr) {
ipstat_inc(ips_rtcachehit);
return;
}
ipstat_inc(ips_rtcachemiss);
rtfree(ro->ro_rt);
ro->ro_rt = NULL;
ro->ro_generation = gen;

4
sys/net/route.h
View file

@ -1,4 +1,4 @@
/* $OpenBSD: route.h,v 1.204 2024/01/31 14:56:42 bluhm Exp $ */
/* $OpenBSD: route.h,v 1.205 2024/02/05 12:52:11 aoyama Exp $ */
/* $NetBSD: route.h,v 1.9 1996/02/13 22:00:49 christos Exp $ */
/*
@ -444,13 +444,11 @@ extern u_long rtgeneration;
struct mbuf;
struct socket;
struct ifnet;
struct in_addr;
struct sockaddr_in6;
struct if_ieee80211_data;
struct bfd_config;
void route_init(void);
void route_cache(struct route *, struct in_addr, u_int);
void rtm_ifchg(struct ifnet *);
void rtm_ifannounce(struct ifnet *, int);
void rtm_bfd(struct bfd_config *);

5
sys/netinet/in.h
View file

@ -1,4 +1,4 @@
/* $OpenBSD: in.h,v 1.145 2023/11/10 20:05:22 bluhm Exp $ */
/* $OpenBSD: in.h,v 1.146 2024/02/05 12:52:11 aoyama Exp $ */
/* $NetBSD: in.h,v 1.20 1996/02/13 23:41:47 christos Exp $ */
/*
@ -770,6 +770,7 @@ struct sockaddr;
struct sockaddr_in;
struct ifaddr;
struct in_ifaddr;
struct route;
void ipv4_input(struct ifnet *, struct mbuf *);
struct mbuf *
@ -788,6 +789,8 @@ void in_len2mask(struct in_addr *, int);
int in_nam2sin(const struct mbuf *, struct sockaddr_in **);
int in_sa2sin(struct sockaddr *, struct sockaddr_in **);
void route_cache(struct route *, struct in_addr, u_int);
char *inet_ntoa(struct in_addr);
int inet_nat64(int, const void *, void *, const void *, u_int8_t);
int inet_nat46(int, const void *, void *, const void *, u_int8_t);

6
sys/netinet/ip_var.h
View file

@ -1,4 +1,4 @@
/* $OpenBSD: ip_var.h,v 1.111 2024/02/03 22:50:09 mvs Exp $ */
/* $OpenBSD: ip_var.h,v 1.112 2024/02/05 23:16:39 bluhm Exp $ */
/* $NetBSD: ip_var.h,v 1.16 1996/02/13 23:43:20 christos Exp $ */
/*
@ -87,6 +87,8 @@ struct ipstat {
u_long ips_inswcsum; /* software checksummed on input */
u_long ips_outswcsum; /* software checksummed on output */
u_long ips_notmember; /* multicasts for unregistered groups */
u_long ips_rtcachehit; /* valid route found in cache */
u_long ips_rtcachemiss; /* route cache with new destination */
u_long ips_wrongif; /* packet received on wrong interface */
u_long ips_idropped; /* lost input due to nobufs, etc. */
};
@ -133,6 +135,8 @@ enum ipstat_counters {
ips_inswcsum, /* software checksummed on input */
ips_outswcsum, /* software checksummed on output */
ips_notmember, /* multicasts for unregistered groups */
ips_rtcachehit, /* valid route to destination found in cache */
ips_rtcachemiss, /* route cache filled with new destination */
ips_wrongif, /* packet received on wrong interface */
ips_idropped, /* lost input packets due to nobufs, etc. */

10
sys/netinet6/ip6_var.h
View file

@ -1,4 +1,4 @@
/* $OpenBSD: ip6_var.h,v 1.110 2024/02/03 22:50:09 mvs Exp $ */
/* $OpenBSD: ip6_var.h,v 1.111 2024/02/05 23:16:39 bluhm Exp $ */
/* $KAME: ip6_var.h,v 1.33 2000/06/11 14:59:20 jinmei Exp $ */
/*
@ -196,8 +196,8 @@ struct ip6stat {
/* number of times that an deprecated address is chosen */
u_int64_t ip6s_sources_deprecated[16];
u_int64_t ip6s_forward_cachehit;
u_int64_t ip6s_forward_cachemiss;
u_int64_t ip6s_rtcachehit; /* valid route found in cache */
u_int64_t ip6s_rtcachemiss; /* route cache with new destination */
u_int64_t ip6s_wrongif; /* packet received on wrong interface */
u_int64_t ip6s_idropped; /* lost input due to nobufs, etc. */
};
@ -243,8 +243,8 @@ enum ip6stat_counters {
ip6s_sources_samescope = ip6s_sources_otherif + 16,
ip6s_sources_otherscope = ip6s_sources_samescope + 16,
ip6s_sources_deprecated = ip6s_sources_otherscope + 16,
ip6s_forward_cachehit = ip6s_sources_deprecated + 16,
ip6s_forward_cachemiss,
ip6s_rtcachehit = ip6s_sources_deprecated + 16,
ip6s_rtcachemiss,
ip6s_wrongif,
ip6s_idropped,

12
sys/nfs/nfs_socket.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: nfs_socket.c,v 1.144 2023/08/03 09:49:09 mvs Exp $ */
/* $OpenBSD: nfs_socket.c,v 1.145 2024/02/05 20:21:39 mvs Exp $ */
/* $NetBSD: nfs_socket.c,v 1.27 1996/04/15 20:20:00 thorpej Exp $ */
/*
@ -295,7 +295,6 @@ nfs_connect(struct nfsmount *nmp, struct nfsreq *rep)
goto bad;
}
solock(so);
/*
* Protocols that do not require connections may be optionally left
* unconnected for servers that reply from a port other than NFS_PORT.
@ -303,9 +302,10 @@ nfs_connect(struct nfsmount *nmp, struct nfsreq *rep)
if (nmp->nm_flag & NFSMNT_NOCONN) {
if (nmp->nm_soflags & PR_CONNREQUIRED) {
error = ENOTCONN;
goto bad_locked;
goto bad;
}
} else {
solock(so);
error = soconnect(so, nmp->nm_nam);
if (error)
goto bad_locked;
@ -330,17 +330,21 @@ nfs_connect(struct nfsmount *nmp, struct nfsreq *rep)
so->so_error = 0;
goto bad_locked;
}
sounlock(so);
}
/*
* Always set receive timeout to detect server crash and reconnect.
* Otherwise, we can get stuck in soreceive forever.
*/
mtx_enter(&so->so_rcv.sb_mtx);
so->so_rcv.sb_timeo_nsecs = SEC_TO_NSEC(5);
mtx_leave(&so->so_rcv.sb_mtx);
mtx_enter(&so->so_snd.sb_mtx);
if (nmp->nm_flag & (NFSMNT_SOFT | NFSMNT_INT))
so->so_snd.sb_timeo_nsecs = SEC_TO_NSEC(5);
else
so->so_snd.sb_timeo_nsecs = INFSLP;
sounlock(so);
mtx_leave(&so->so_snd.sb_mtx);
if (nmp->nm_sotype == SOCK_DGRAM) {
sndreserve = nmp->nm_wsize + NFS_MAXPKTHDR;
rcvreserve = (max(nmp->nm_rsize, nmp->nm_readdirsize) +

6
sys/nfs/nfs_syscalls.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: nfs_syscalls.c,v 1.120 2024/01/12 08:47:46 ratchov Exp $ */
/* $OpenBSD: nfs_syscalls.c,v 1.121 2024/02/05 20:21:39 mvs Exp $ */
/* $NetBSD: nfs_syscalls.c,v 1.19 1996/02/18 11:53:52 fvdl Exp $ */
/*
@ -277,9 +277,13 @@ nfssvc_addsock(struct file *fp, struct mbuf *mynam)
}
solock(so);
so->so_rcv.sb_flags &= ~SB_NOINTR;
mtx_enter(&so->so_rcv.sb_mtx);
so->so_rcv.sb_timeo_nsecs = INFSLP;
mtx_leave(&so->so_rcv.sb_mtx);
so->so_snd.sb_flags &= ~SB_NOINTR;
mtx_enter(&so->so_snd.sb_mtx);
so->so_snd.sb_timeo_nsecs = INFSLP;
mtx_leave(&so->so_snd.sb_mtx);
sounlock(so);
if (tslp)
slp = tslp;

4
usr.bin/netstat/inet.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: inet.c,v 1.179 2023/09/04 23:00:36 bluhm Exp $ */
/* $OpenBSD: inet.c,v 1.180 2024/02/05 23:16:39 bluhm Exp $ */
/* $NetBSD: inet.c,v 1.14 1995/10/03 21:42:37 thorpej Exp $ */
/*
@ -621,6 +621,8 @@ ip_stats(char *name)
p(ips_inswcsum, "\t%lu input datagram%s software-checksummed\n");
p(ips_outswcsum, "\t%lu output datagram%s software-checksummed\n");
p(ips_notmember, "\t%lu multicast packet%s which we don't join\n");
p1(ips_rtcachehit, "\t%lu route cache hit\n");
p1(ips_rtcachemiss, "\t%lu route cache miss\n");
p(ips_wrongif, "\t%lu packet%s received on wrong interface\n");
p(ips_idropped, "\t%lu input packet%s dropped due to no bufs, etc.\n");
#undef p

9
usr.bin/netstat/inet6.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: inet6.c,v 1.56 2022/08/12 14:49:15 bluhm Exp $ */
/* $OpenBSD: inet6.c,v 1.57 2024/02/05 23:16:39 bluhm Exp $ */
/* BSDI inet.c,v 2.3 1995/10/24 02:19:29 prb Exp */
/*
* Copyright (c) 1983, 1988, 1993
@ -371,7 +371,6 @@ ip6_stats(char *name)
p(ip6s_cantfrag, "\t%llu datagram%s that can't be fragmented\n");
p(ip6s_badscope, "\t%llu packet%s that violated scope rules\n");
p(ip6s_notmember, "\t%llu multicast packet%s which we don't join\n");
p(ip6s_wrongif, "\t%llu packet%s received on wrong interface\n");
for (first = 1, i = 0; i < 256; i++)
if (ip6stat.ip6s_nxthist[i] != 0) {
if (first) {
@ -478,9 +477,9 @@ ip6_stats(char *name)
PRINT_SCOPESTAT(ip6s_sources_deprecated[i], i);
}
}
p1(ip6s_forward_cachehit, "\t%llu forward cache hit\n");
p1(ip6s_forward_cachemiss, "\t%llu forward cache miss\n");
p1(ip6s_rtcachehit, "\t%llu route cache hit\n");
p1(ip6s_rtcachemiss, "\t%llu route cache miss\n");
p(ip6s_wrongif, "\t%llu packet%s received on wrong interface\n");
p(ip6s_idropped,
"\t%llu input packet%s dropped due to no bufs, etc.\n");
#undef p

8
usr.sbin/btrace/btrace.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: btrace.c,v 1.83 2024/01/25 20:50:58 mpi Exp $ */
/* $OpenBSD: btrace.c,v 1.84 2024/02/05 15:11:35 mpi Exp $ */
/*
* Copyright (c) 2019 - 2023 Martin Pieuchot <mpi@openbsd.org>
@ -450,9 +450,9 @@ rules_do(int fd)
if (ioctl(fd, DTIOCGSTATS, &dtst))
warn("DTIOCGSTATS");
printf("%llu events read\n", dtst.dtst_readevt);
printf("%llu events dropped\n", dtst.dtst_dropevt);
printf("%llu events filtered\n", bt_filtered);
fprintf(stderr, "%llu events read\n", dtst.dtst_readevt);
fprintf(stderr, "%llu events dropped\n", dtst.dtst_dropevt);
fprintf(stderr, "%llu events filtered\n", bt_filtered);
}
}

9
usr.sbin/rpki-client/aspa.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: aspa.c,v 1.24 2023/10/13 12:06:49 job Exp $ */
/* $OpenBSD: aspa.c,v 1.25 2024/02/05 19:23:58 job Exp $ */
/*
* Copyright (c) 2022 Job Snijders <job@fastly.com>
* Copyright (c) 2022 Theo Buehler <tb@openbsd.org>
@ -129,13 +129,20 @@ aspa_parse_providers(struct parse *p, const STACK_OF(ASN1_INTEGER) *providers)
static int
aspa_parse_econtent(const unsigned char *d, size_t dsz, struct parse *p)
{
const unsigned char *oder;
ASProviderAttestation *aspa;
int rc = 0;
oder = d;
if ((aspa = d2i_ASProviderAttestation(NULL, &d, dsz)) == NULL) {
warnx("%s: ASPA: failed to parse ASProviderAttestation", p->fn);
goto out;
}
if (d != oder + dsz) {
warnx("%s: %td bytes trailing garbage in eContent", p->fn,
oder + dsz - d);
goto out;
}
if (!valid_econtent_version(p->fn, aspa->version, 1))
goto out;

9
usr.sbin/rpki-client/mft.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: mft.c,v 1.105 2024/02/04 00:53:27 job Exp $ */
/* $OpenBSD: mft.c,v 1.106 2024/02/05 19:23:58 job Exp $ */
/*
* Copyright (c) 2022 Theo Buehler <tb@openbsd.org>
* Copyright (c) 2019 Kristaps Dzonsons <kristaps@bsd.lv>
@ -232,15 +232,22 @@ mft_parse_filehash(struct parse *p, const FileAndHash *fh)
static int
mft_parse_econtent(const unsigned char *d, size_t dsz, struct parse *p)
{
const unsigned char *oder;
Manifest *mft;
FileAndHash *fh;
int i, rc = 0;
oder = d;
if ((mft = d2i_Manifest(NULL, &d, dsz)) == NULL) {
warnx("%s: RFC 6486 section 4: failed to parse Manifest",
p->fn);
goto out;
}
if (d != oder + dsz) {
warnx("%s: %td bytes trailing garbage in eContent", p->fn,
oder + dsz - d);
goto out;
}
if (!valid_econtent_version(p->fn, mft->version, 0))
goto out;

9
usr.sbin/rpki-client/roa.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: roa.c,v 1.72 2023/12/14 07:52:53 tb Exp $ */
/* $OpenBSD: roa.c,v 1.73 2024/02/05 19:23:58 job Exp $ */
/*
* Copyright (c) 2022 Theo Buehler <tb@openbsd.org>
* Copyright (c) 2019 Kristaps Dzonsons <kristaps@bsd.lv>
@ -101,6 +101,7 @@ IMPLEMENT_ASN1_FUNCTIONS(RouteOriginAttestation);
static int
roa_parse_econtent(const unsigned char *d, size_t dsz, struct parse *p)
{
const unsigned char *oder;
RouteOriginAttestation *roa;
const ROAIPAddressFamily *addrfam;
const STACK_OF(ROAIPAddress) *addrs;
@ -113,11 +114,17 @@ roa_parse_econtent(const unsigned char *d, size_t dsz, struct parse *p)
int ipaddrblocksz;
int i, j, rc = 0;
oder = d;
if ((roa = d2i_RouteOriginAttestation(NULL, &d, dsz)) == NULL) {
warnx("%s: RFC 6482 section 3: failed to parse "
"RouteOriginAttestation", p->fn);
goto out;
}
if (d != oder + dsz) {
warnx("%s: %td bytes trailing garbage in eContent", p->fn,
oder + dsz - d);
goto out;
}
if (!valid_econtent_version(p->fn, roa->version, 0))
goto out;

9
usr.sbin/rpki-client/rsc.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: rsc.c,v 1.29 2023/10/13 12:06:49 job Exp $ */
/* $OpenBSD: rsc.c,v 1.30 2024/02/05 19:23:58 job Exp $ */
/*
* Copyright (c) 2022 Theo Buehler <tb@openbsd.org>
* Copyright (c) 2022 Job Snijders <job@fastly.com>
@ -325,6 +325,7 @@ rsc_parse_checklist(struct parse *p, const STACK_OF(FileNameAndHash) *checkList)
static int
rsc_parse_econtent(const unsigned char *d, size_t dsz, struct parse *p)
{
const unsigned char *oder;
RpkiSignedChecklist *rsc;
ResourceBlock *resources;
int rc = 0;
@ -333,10 +334,16 @@ rsc_parse_econtent(const unsigned char *d, size_t dsz, struct parse *p)
* RFC 9323 section 4
*/
oder = d;
if ((rsc = d2i_RpkiSignedChecklist(NULL, &d, dsz)) == NULL) {
warnx("%s: RSC: failed to parse RpkiSignedChecklist", p->fn);
goto out;
}
if (d != oder + dsz) {
warnx("%s: %td bytes trailing garbage in eContent", p->fn,
oder + dsz - d);
goto out;
}
if (!valid_econtent_version(p->fn, rsc->version, 0))
goto out;

9
usr.sbin/rpki-client/tak.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: tak.c,v 1.13 2023/10/13 12:06:49 job Exp $ */
/* $OpenBSD: tak.c,v 1.14 2024/02/05 19:23:58 job Exp $ */
/*
* Copyright (c) 2022 Job Snijders <job@fastly.com>
* Copyright (c) 2022 Theo Buehler <tb@openbsd.org>
@ -184,16 +184,23 @@ parse_takey(const char *fn, const TAKey *takey)
static int
tak_parse_econtent(const unsigned char *d, size_t dsz, struct parse *p)
{
const unsigned char *oder;
TAK *tak;
const char *fn;
int rc = 0;
fn = p->fn;
oder = d;
if ((tak = d2i_TAK(NULL, &d, dsz)) == NULL) {
warnx("%s: failed to parse Trust Anchor Key", fn);
goto out;
}
if (d != oder + dsz) {
warnx("%s: %td bytes trailing garbage in eContent", p->fn,
oder + dsz - d);
goto out;
}
if (!valid_econtent_version(fn, tak->version, 0))
goto out;

27
usr.sbin/vmd/config.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: config.c,v 1.74 2024/01/18 14:49:59 claudio Exp $ */
/* $OpenBSD: config.c,v 1.75 2024/02/05 21:58:09 dv Exp $ */
/*
* Copyright (c) 2015 Reyk Floeter <reyk@openbsd.org>
@ -284,7 +284,7 @@ config_setvm(struct privsep *ps, struct vmd_vm *vm, uint32_t peerid, uid_t uid)
if (!(vm->vm_state & VM_STATE_RECEIVED) && vm->vm_kernel == -1) {
if (vm->vm_kernel_path != NULL) {
/* Open external kernel for child */
kernfd = open(vm->vm_kernel_path, O_RDONLY);
kernfd = open(vm->vm_kernel_path, O_RDONLY | O_CLOEXEC);
if (kernfd == -1) {
ret = errno;
log_warn("%s: can't open kernel or BIOS "
@ -301,7 +301,8 @@ config_setvm(struct privsep *ps, struct vmd_vm *vm, uint32_t peerid, uid_t uid)
* license.
*/
if (kernfd == -1) {
if ((kernfd = open(VM_DEFAULT_BIOS, O_RDONLY)) == -1) {
if ((kernfd = open(VM_DEFAULT_BIOS,
O_RDONLY | O_CLOEXEC)) == -1) {
log_warn("can't open %s", VM_DEFAULT_BIOS);
ret = VMD_BIOS_MISSING;
goto fail;
@ -341,14 +342,17 @@ config_setvm(struct privsep *ps, struct vmd_vm *vm, uint32_t peerid, uid_t uid)
}
}
/* Open disk images for child */
/*
* Open disk images for child. Don't set O_CLOEXEC as these must be
* explicitly closed by the vm process during virtio subprocess launch.
*/
for (i = 0 ; i < vmc->vmc_ndisks; i++) {
if (strlcpy(path, vmc->vmc_disks[i], sizeof(path))
>= sizeof(path))
log_warnx("disk path %s too long", vmc->vmc_disks[i]);
memset(vmc->vmc_diskbases, 0, sizeof(vmc->vmc_diskbases));
oflags = O_RDWR|O_EXLOCK|O_NONBLOCK;
aflags = R_OK|W_OK;
oflags = O_RDWR | O_EXLOCK | O_NONBLOCK;
aflags = R_OK | W_OK;
for (j = 0; j < VM_MAX_BASE_PER_DISK; j++) {
/* Stat disk[i] to ensure it is a regular file */
if ((diskfds[i][j] = open(path, oflags)) == -1) {
@ -372,7 +376,7 @@ config_setvm(struct privsep *ps, struct vmd_vm *vm, uint32_t peerid, uid_t uid)
* All writes should go to the top image, allowing them
* to be shared.
*/
oflags = O_RDONLY|O_NONBLOCK;
oflags = O_RDONLY | O_NONBLOCK;
aflags = R_OK;
n = virtio_get_base(diskfds[i][j], base, sizeof(base),
vmc->vmc_disktypes[i], path);
@ -407,7 +411,9 @@ config_setvm(struct privsep *ps, struct vmd_vm *vm, uint32_t peerid, uid_t uid)
/*
* Either open the requested tap(4) device or get
* the next available one.
* the next available one. Don't set O_CLOEXEC as these
* should be closed by the vm process during virtio device
* launch.
*/
if (s != NULL) {
snprintf(path, PATH_MAX, "/dev/%s", s);
@ -454,7 +460,10 @@ config_setvm(struct privsep *ps, struct vmd_vm *vm, uint32_t peerid, uid_t uid)
vmc->vmc_ifflags[i] & (VMIFF_UP|VMIFF_OPTMASK);
}
/* Open TTY */
/*
* Open TTY. Duplicate the fd before sending so the privileged parent
* process can perform permissions cleanup of the pty on vm termination.
*/
if (vm->vm_ttyname[0] == '\0') {
if (vm_opentty(vm) == -1) {
log_warn("%s: can't open tty %s", __func__,

7
usr.sbin/vmd/vioblk.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: vioblk.c,v 1.11 2024/02/04 14:54:51 dv Exp $ */
/* $OpenBSD: vioblk.c,v 1.12 2024/02/05 21:58:09 dv Exp $ */
/*
* Copyright (c) 2023 Dave Voutila <dv@openbsd.org>
@ -176,11 +176,6 @@ vioblk_main(int fd, int fd_vmm)
/* Configure our sync channel event handler. */
log_debug("%s: wiring in sync channel handler (fd=%d)", __func__,
dev.sync_fd);
if (fcntl(dev.sync_fd, F_SETFL, O_NONBLOCK) == -1) {
ret = errno;
log_warn("%s: fcntl", __func__);
goto fail;
}
imsg_init(&dev.sync_iev.ibuf, dev.sync_fd);
dev.sync_iev.handler = handle_sync_io;
dev.sync_iev.data = &dev;

7
usr.sbin/vmd/vionet.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: vionet.c,v 1.9 2024/02/03 21:41:35 dv Exp $ */
/* $OpenBSD: vionet.c,v 1.10 2024/02/05 21:58:09 dv Exp $ */
/*
* Copyright (c) 2023 Dave Voutila <dv@openbsd.org>
@ -203,11 +203,6 @@ vionet_main(int fd, int fd_vmm)
/* Configure our sync channel event handler. */
log_debug("%s: wiring in sync channel handler (fd=%d)", __func__,
dev.sync_fd);
if (fcntl(dev.sync_fd, F_SETFL, O_NONBLOCK) == -1) {
ret = errno;
log_warn("%s: fcntl", __func__);
goto fail;
}
imsg_init(&dev.sync_iev.ibuf, dev.sync_fd);
dev.sync_iev.handler = handle_sync_io;
dev.sync_iev.data = &dev;

83
usr.sbin/vmd/virtio.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: virtio.c,v 1.110 2023/11/03 11:16:43 dv Exp $ */
/* $OpenBSD: virtio.c,v 1.111 2024/02/05 21:58:09 dv Exp $ */
/*
* Copyright (c) 2015 Mike Larkin <mlarkin@openbsd.org>
@ -73,6 +73,7 @@ SLIST_HEAD(virtio_dev_head, virtio_dev) virtio_devs;
static int virtio_dev_launch(struct vmd_vm *, struct virtio_dev *);
static void virtio_dispatch_dev(int, short, void *);
static int handle_dev_msg(struct viodev_msg *, struct virtio_dev *);
static int virtio_dev_closefds(struct virtio_dev *);
const char *
virtio_reg_name(uint8_t reg)
@ -1303,6 +1304,7 @@ virtio_dev_launch(struct vmd_vm *vm, struct virtio_dev *dev)
int data_fds[VM_MAX_BASE_PER_DISK], sync_fds[2], async_fds[2], ret = 0;
size_t i, data_fds_sz, sz = 0;
struct viodev_msg msg;
struct virtio_dev *dev_entry;
struct imsg imsg;
struct imsgev *iev = &dev->sync_iev;
@ -1326,27 +1328,17 @@ virtio_dev_launch(struct vmd_vm *vm, struct virtio_dev *dev)
}
/* We need two channels: one synchronous (IO reads) and one async. */
if (socketpair(AF_UNIX, SOCK_STREAM, PF_UNSPEC, sync_fds) == -1) {
if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, PF_UNSPEC,
sync_fds) == -1) {
log_warn("failed to create socketpair");
return (errno);
}
if (socketpair(AF_UNIX, SOCK_STREAM, PF_UNSPEC, async_fds) == -1) {
if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, PF_UNSPEC,
async_fds) == -1) {
log_warn("failed to create async socketpair");
return (errno);
}
/* Keep communication channels open after exec. */
if (fcntl(sync_fds[1], F_SETFD, 0)) {
ret = errno;
log_warn("%s: fcntl", __func__);
goto err;
}
if (fcntl(async_fds[1], F_SETFD, 0)) {
ret = errno;
log_warn("%s: fcnt", __func__);
goto err;
}
/* Fork... */
dev_pid = fork();
if (dev_pid == -1) {
@ -1371,13 +1363,6 @@ virtio_dev_launch(struct vmd_vm *vm, struct virtio_dev *dev)
for (i = 0; i < data_fds_sz; i++)
close_fd(data_fds[i]);
/* Set our synchronous channel to non-blocking. */
if (fcntl(sync_fds[0], F_SETFL, O_NONBLOCK) == -1) {
ret = errno;
log_warn("%s: fcntl", __func__);
goto err;
}
/* 1. Send over our configured device. */
log_debug("%s: sending '%c' type device struct", __func__,
dev->dev_type);
@ -1446,15 +1431,21 @@ virtio_dev_launch(struct vmd_vm *vm, struct virtio_dev *dev)
close_fd(async_fds[0]);
close_fd(sync_fds[0]);
/* Keep data file descriptors open after exec. */
for (i = 0; i < data_fds_sz; i++) {
log_debug("%s: marking fd %d !close-on-exec", __func__,
data_fds[i]);
if (fcntl(data_fds[i], F_SETFD, 0)) {
ret = errno;
log_warn("%s: fcntl", __func__);
goto err;
/* Close pty. Virtio devices do not need it. */
close_fd(vm->vm_tty);
vm->vm_tty = -1;
if (vm->vm_cdrom != -1) {
close_fd(vm->vm_cdrom);
vm->vm_cdrom = -1;
}
/* Keep data file descriptors open after exec. */
SLIST_FOREACH(dev_entry, &virtio_devs, dev_next) {
if (dev_entry == dev)
continue;
if (virtio_dev_closefds(dev_entry) == -1)
fatalx("unable to close other virtio devs");
}
memset(&nargv, 0, sizeof(nargv));
@ -1520,11 +1511,6 @@ vm_device_pipe(struct virtio_dev *dev, void (*cb)(int, short, void *))
log_debug("%s: initializing '%c' device pipe (fd=%d)", __func__,
dev->dev_type, fd);
if (fcntl(fd, F_SETFL, O_NONBLOCK) == -1) {
log_warn("failed to set nonblocking mode on vm device pipe");
return (-1);
}
imsg_init(&iev->ibuf, fd);
iev->handler = cb;
iev->data = dev;
@ -1764,3 +1750,30 @@ virtio_deassert_pic_irq(struct virtio_dev *dev, int vcpu)
if (ret == -1)
log_warnx("%s: failed to deassert irq %d", __func__, dev->irq);
}
/*
* Close all underlying file descriptors for a given virtio device.
*/
static int
virtio_dev_closefds(struct virtio_dev *dev)
{
size_t i;
switch (dev->dev_type) {
case VMD_DEVTYPE_DISK:
for (i = 0; i < dev->vioblk.ndisk_fd; i++) {
close_fd(dev->vioblk.disk_fd[i]);
dev->vioblk.disk_fd[i] = -1;
}
break;
case VMD_DEVTYPE_NET:
close_fd(dev->vionet.data_fd);
dev->vionet.data_fd = -1;
break;
default:
log_warnx("%s: invalid device type", __func__);
return (-1);
}
return (0);
}

18
usr.sbin/vmd/vm.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: vm.c,v 1.96 2024/01/18 14:49:59 claudio Exp $ */
/* $OpenBSD: vm.c,v 1.97 2024/02/05 21:58:09 dv Exp $ */
/*
* Copyright (c) 2015 Mike Larkin <mlarkin@openbsd.org>
@ -221,13 +221,18 @@ static const struct vcpu_reg_state vcpu_init_flat16 = {
* fd_vmm: file descriptor for communicating with vmm(4) device
*/
void
vm_main(int fd, int vmm_fd)
vm_main(int fd, int fd_vmm)
{
struct vm_create_params *vcp = NULL;
struct vmd_vm vm;
size_t sz = 0;
int ret = 0;
/*
* The vm process relies on global state. Set the fd for /dev/vmm.
*/
env->vmd_fd = fd_vmm;
/*
* We aren't root, so we can't chroot(2). Use unveil(2) instead.
*/
@ -277,11 +282,6 @@ vm_main(int fd, int vmm_fd)
vcp->vcp_name);
_exit(EINVAL);
}
if (fcntl(vm.vm_kernel, F_SETFL, O_NONBLOCK) == -1) {
ret = errno;
log_warn("failed to set nonblocking mode on boot fd");
_exit(ret);
}
}
ret = start_vm(&vm, fd);
@ -2454,7 +2454,7 @@ vm_pipe_init(struct vm_dev_pipe *p, void (*cb)(int, short, void *))
memset(p, 0, sizeof(struct vm_dev_pipe));
ret = pipe(fds);
ret = pipe2(fds, O_CLOEXEC);
if (ret)
fatal("failed to create vm_dev_pipe pipe");
@ -2507,7 +2507,7 @@ vm_pipe_recv(struct vm_dev_pipe *p)
}
/*
* Re-map the guest address space using the shared memory file descriptor.
* Re-map the guest address space using vmm(4)'s VMM_IOC_SHARE
*
* Returns 0 on success, non-zero in event of failure.
*/

38
usr.sbin/vmd/vmd.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: vmd.c,v 1.154 2024/02/04 14:56:45 dv Exp $ */
/* $OpenBSD: vmd.c,v 1.155 2024/02/05 21:58:09 dv Exp $ */
/*
* Copyright (c) 2015 Reyk Floeter <reyk@openbsd.org>
@ -800,6 +800,8 @@ main(int argc, char **argv)
if ((env = calloc(1, sizeof(*env))) == NULL)
fatal("calloc: env");
env->vmd_fd = -1;
env->vmd_fd6 = -1;
while ((ch = getopt(argc, argv, "D:P:I:V:X:df:i:nt:vp:")) != -1) {
switch (ch) {
@ -891,7 +893,6 @@ main(int argc, char **argv)
ps = &env->vmd_ps;
ps->ps_env = env;
env->vmd_fd = vmm_fd;
if (config_init(env) == -1)
fatal("failed to initialize configuration");
@ -924,7 +925,7 @@ main(int argc, char **argv)
/* Open /dev/vmm early. */
if (env->vmd_noaction == 0 && proc_id == PROC_PARENT) {
env->vmd_fd = open(VMM_NODE, O_RDWR);
env->vmd_fd = open(VMM_NODE, O_RDWR | O_CLOEXEC);
if (env->vmd_fd == -1)
fatal("%s", VMM_NODE);
}
@ -1014,9 +1015,6 @@ vmd_configure(void)
int ncpu_mib[] = {CTL_HW, HW_NCPUONLINE};
size_t ncpus_sz = sizeof(ncpus);
if ((env->vmd_ptmfd = open(PATH_PTMDEV, O_RDWR|O_CLOEXEC)) == -1)
fatal("open %s", PATH_PTMDEV);
/*
* pledge in the parent process:
* stdio - for malloc and basic I/O including events.
@ -1034,6 +1032,9 @@ vmd_configure(void)
" chown fattr flock", NULL) == -1)
fatal("pledge");
if ((env->vmd_ptmfd = getptmfd()) == -1)
fatal("getptmfd %s", PATH_PTMDEV);
if (parse_config(env->vmd_conffile) == -1) {
proc_kill(&env->vmd_ps);
exit(1);
@ -1846,32 +1847,29 @@ vm_checkaccess(int fd, unsigned int uflag, uid_t uid, int amode)
int
vm_opentty(struct vmd_vm *vm)
{
struct ptmget ptm;
struct stat st;
struct group *gr;
uid_t uid;
gid_t gid;
mode_t mode;
int on;
int on = 1, tty_slave;
/*
* Open tty with pre-opened PTM fd
*/
if ((ioctl(env->vmd_ptmfd, PTMGET, &ptm) == -1))
if (fdopenpty(env->vmd_ptmfd, &vm->vm_tty, &tty_slave, vm->vm_ttyname,
NULL, NULL) == -1) {
log_warn("fdopenpty");
return (-1);
}
close(tty_slave);
/*
* We use user ioctl(2) mode to pass break commands.
*/
on = 1;
if (ioctl(ptm.cfd, TIOCUCNTL, &on) == -1)
fatal("could not enable user ioctl mode");
vm->vm_tty = ptm.cfd;
close(ptm.sfd);
if (strlcpy(vm->vm_ttyname, ptm.sn, sizeof(vm->vm_ttyname))
>= sizeof(vm->vm_ttyname)) {
log_warnx("%s: truncated ttyname", __func__);
if (ioctl(vm->vm_tty, TIOCUCNTL, &on) == -1) {
log_warn("could not enable user ioctl mode on %s",
vm->vm_ttyname);
goto fail;
}
@ -1896,8 +1894,10 @@ vm_opentty(struct vmd_vm *vm)
* Change ownership and mode of the tty as required.
* Loosely based on the implementation of sshpty.c
*/
if (stat(vm->vm_ttyname, &st) == -1)
if (fstat(vm->vm_tty, &st) == -1) {
log_warn("fstat failed for %s", vm->vm_ttyname);
goto fail;
}
if (st.st_uid != uid || st.st_gid != gid) {
if (chown(vm->vm_ttyname, uid, gid) == -1) {

39
usr.sbin/vmd/vmm.c
View file

@ -1,4 +1,4 @@
/* $OpenBSD: vmm.c,v 1.118 2024/02/04 14:57:00 dv Exp $ */
/* $OpenBSD: vmm.c,v 1.119 2024/02/05 21:58:09 dv Exp $ */
/*
* Copyright (c) 2015 Mike Larkin <mlarkin@openbsd.org>
@ -52,6 +52,7 @@
#include "vmd.h"
#include "vmm.h"
#include "atomicio.h"
#include "proc.h"
void vmm_sighdlr(int, short, void *);
int vmm_start_vm(struct imsg *, uint32_t *, pid_t *);
@ -467,8 +468,14 @@ vmm_pipe(struct vmd_vm *vm, int fd, void (*cb)(int, short, void *))
{
struct imsgev *iev = &vm->vm_iev;
if (fcntl(fd, F_SETFL, O_NONBLOCK) == -1) {
log_warn("failed to set nonblocking mode on vm pipe");
/*
* Set to close-on-exec as vmm_pipe is used after fork+exec to
* establish async ipc between vm and vmd's vmm process. This
* prevents future vm processes or virtio subprocesses from
* inheriting this control channel.
*/
if (fcntl(fd, F_SETFD, FD_CLOEXEC) == -1) {
log_warn("failed to set close-on-exec for vmm ipc channel");
return (-1);
}
@ -661,16 +668,10 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *pid)
}
}
if (socketpair(AF_UNIX, SOCK_STREAM, PF_UNSPEC, fds) == -1)
if (socketpair(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, PF_UNSPEC, fds)
== -1)
fatal("socketpair");
/* Keep our channel open after exec. */
if (fcntl(fds[1], F_SETFD, 0)) {
ret = errno;
log_warn("%s: fcntl", __func__);
goto err;
}
/* Start child vmd for this VM (fork, chroot, drop privs) */
vm_pid = fork();
if (vm_pid == -1) {
@ -745,7 +746,6 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *pid)
/* Wire up our pipe into the event handling. */
if (vmm_pipe(vm, fds[0], vmm_dispatch_vm) == -1)
fatal("setup vm pipe");
} else {
/* Child. Create a new session. */
if (setsid() == -1)
@ -764,21 +764,6 @@ vmm_start_vm(struct imsg *imsg, uint32_t *id, pid_t *pid)
close(fd);
}
/* Toggle all fds to not close on exec. */
for (i = 0 ; i < vm->vm_params.vmc_ndisks; i++)
for (j = 0; j < VM_MAX_BASE_PER_DISK; j++)
if (vm->vm_disks[i][j] != -1)
fcntl(vm->vm_disks[i][j], F_SETFD, 0);
for (i = 0 ; i < vm->vm_params.vmc_nnics; i++)
fcntl(vm->vm_ifs[i].vif_fd, F_SETFD, 0);
if (vm->vm_kernel != -1)
fcntl(vm->vm_kernel, F_SETFD, 0);
if (vm->vm_cdrom != -1)
fcntl(vm->vm_cdrom, F_SETFD, 0);
if (vm->vm_tty != -1)
fcntl(vm->vm_tty, F_SETFD, 0);
fcntl(env->vmd_fd, F_SETFD, 0); /* vmm device fd */
/*
* Prepare our new argv for execvp(2) with the fd of our open
* pipe to the parent/vmm process as an argument.