Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NFDKY9016128; Fri, 23 Jan 2004 16:13:20 +0100 Received: from cs.utwente.nl (adsl219222.adsl.utwente.nl [130.89.225.67]) by netlx010.civ.utwente.nl (8.11.7/HKD) with ESMTP id i0NFDAS04022; Fri, 23 Jan 2004 16:13:10 +0100 Message-ID: <40113A0D.6030601@cs.utwente.nl> Date: Fri, 23 Jan 2004 16:13:17 +0100 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Frank_Strau=DF?= CC: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Question on BER encoding References: <4010F0EF.2040100@cs.utwente.nl> <6780000.1074853700@hansa.ibr.cs.tu-bs.de> <40111753.4000601@cs.utwente.nl> <22420000.1074864260@hansa.ibr.cs.tu-bs.de> <40112BF8.6040307@cs.utwente.nl> <25970000.1074867737@hansa.ibr.cs.tu-bs.de> In-Reply-To: <25970000.1074867737@hansa.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Frank Strauß wrote: > If the first octet would not be present the remaining bits would start with > the most significant bit set to 1 denoting a negative value (I guess > -6777216 :-)). That's it :-) Thanks a lot Aiko Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NF46Y9011099; Fri, 23 Jan 2004 16:04:06 +0100 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 9283583214; Fri, 23 Jan 2004 16:04:05 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id A5B098305A; Fri, 23 Jan 2004 16:04:04 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 7AEC289A0; Fri, 23 Jan 2004 16:04:04 +0100 (CET) Date: Fri, 23 Jan 2004 16:04:03 +0100 From: Juergen Schoenwaelder To: Frank Strau? Cc: Aiko Pras , nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Question on BER encoding Message-ID: <20040123150403.GA917@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: Frank Strau? , Aiko Pras , nmrg@ibr.cs.tu-bs.de References: <4010F0EF.2040100@cs.utwente.nl> <6780000.1074853700@hansa.ibr.cs.tu-bs.de> <40111753.4000601@cs.utwente.nl> <22420000.1074864260@hansa.ibr.cs.tu-bs.de> <40112BF8.6040307@cs.utwente.nl> <25970000.1074867737@hansa.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25970000.1074867737@hansa.ibr.cs.tu-bs.de> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: On Fri, Jan 23, 2004 at 03:22:17PM +0100, Frank Strau? wrote: > If the first octet would not be present the remaining bits would start with > the most significant bit set to 1 denoting a negative value (I guess > -6777216 :-)). Yes, the sign is the key. Integer32 values always fit into 4 bytes but Unsigned32 or Counter32 or Gauge32 may need 5 bytes. Aiko, I guess it is time to re-read the old books. ;-) BTW, the OULU SNMP tests which caused many implementations to crash were doing much more interesting things. It is really fun to look at them. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NEMHYA022145 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 23 Jan 2004 15:22:17 +0100 Date: Fri, 23 Jan 2004 15:22:17 +0100 From: =?ISO-8859-1?Q?Frank_Strau=DF?= To: Aiko Pras cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Question on BER encoding Message-ID: <25970000.1074867737@hansa.ibr.cs.tu-bs.de> In-Reply-To: <40112BF8.6040307@cs.utwente.nl> References: <4010F0EF.2040100@cs.utwente.nl> <6780000.1074853700@hansa.ibr.cs.tu-bs.de> <40111753.4000601@cs.utwente.nl> <22420000.1074864260@hansa.ibr.cs.tu-bs.de> <40112BF8.6040307@cs.utwente.nl> X-Mailer: Mulberry/3.1.0 (Linux/x86) X-PGP-Key: 1024D/3B8A33AA 2000-08-03 Frank Strauss X-PGP-Fingerprint: F6CD 195C F141 4CF8 72AD 0CB0 CD24 F033 3B8A 33AA MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id i0NEMHYA022145 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Aiko Pras wrote: > Frank Strauß wrote: >> I found a quite extensive explanation in Stallings, "SNMP.. and RMON.." >> book. In general, it is due to the encoding of signed and unsigned values >> as ASN.1 INTEGERS, which are always signed. Thus you need to extend the >> length for the upper half of an unsigned value range to encode it as a >> (signed) INTEGER value. > > This still does not explain why, for example, decimal 10.000.000 (10 > million) is coded as 00 98 96 80. The first octet (00) is, in my opinion, > not necessary. Still this is what I find in my traces. If the first octet would not be present the remaining bits would start with the most significant bit set to 1 denoting a negative value (I guess -6777216 :-)). Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NEDQY9017718; Fri, 23 Jan 2004 15:13:26 +0100 Received: from cs.utwente.nl (adsl219222.adsl.utwente.nl [130.89.225.67]) by netlx010.civ.utwente.nl (8.11.7/HKD) with ESMTP id i0NED5S15081; Fri, 23 Jan 2004 15:13:05 +0100 Message-ID: <40112BF8.6040307@cs.utwente.nl> Date: Fri, 23 Jan 2004 15:13:12 +0100 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Frank_Strau=DF?= CC: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Question on BER encoding References: <4010F0EF.2040100@cs.utwente.nl> <6780000.1074853700@hansa.ibr.cs.tu-bs.de> <40111753.4000601@cs.utwente.nl> <22420000.1074864260@hansa.ibr.cs.tu-bs.de> In-Reply-To: <22420000.1074864260@hansa.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Frank Strauß wrote: > I found a quite extensive explanation in Stallings, "SNMP.. and RMON.." > book. In general, it is due to the encoding of signed and unsigned values > as ASN.1 INTEGERS, which are always signed. Thus you need to extend the > length for the upper half of an unsigned value range to encode it as a > (signed) INTEGER value. This still does not explain why, for example, decimal 10.000.000 (10 million) is coded as 00 98 96 80. The first octet (00) is, in my opinion, not necessary. Still this is what I find in my traces. Bye Aiko Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NDOKYA025519 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 23 Jan 2004 14:24:20 +0100 Date: Fri, 23 Jan 2004 14:24:20 +0100 From: =?ISO-8859-1?Q?Frank_Strau=DF?= To: Aiko Pras cc: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Question on BER encoding Message-ID: <22420000.1074864260@hansa.ibr.cs.tu-bs.de> In-Reply-To: <40111753.4000601@cs.utwente.nl> References: <4010F0EF.2040100@cs.utwente.nl> <6780000.1074853700@hansa.ibr.cs.tu-bs.de> <40111753.4000601@cs.utwente.nl> X-Mailer: Mulberry/3.1.0 (Linux/x86) X-PGP-Key: 1024D/3B8A33AA 2000-08-03 Frank Strauss X-PGP-Fingerprint: F6CD 195C F141 4CF8 72AD 0CB0 CD24 F033 3B8A 33AA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Aiko Pras wrote: > Your theory is correct wrt the coding of ASN.1's LENGTH field. My > question, however, relates to the ASN.1 DATA field. As far as I know, the > first bit of an octet does not have a special meaning there. > > If I look at my traces, I see that the ASN.1 DATA fields have ordinary > hex encodings. To my surprise, however, I see that the hex encoding of > large numbers get a octet with a zero value in front. I therefore get 5 > octest for large values, whereas 4 would be sufficient. I don't > understand the "zero octet" in the beginning. Oh, I mixed up the encoding of INTEGERs and the sub-ids within OIDs. Sorry for the confusion! I found a quite extensive explanation in Stallings, "SNMP.. and RMON.." book. In general, it is due to the encoding of signed and unsigned values as ASN.1 INTEGERS, which are always signed. Thus you need to extend the length for the upper half of an unsigned value range to encode it as a (signed) INTEGER value. Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NCjGY9005909; Fri, 23 Jan 2004 13:45:16 +0100 Received: from cs.utwente.nl (adsl219222.adsl.utwente.nl [130.89.225.67]) by netlx010.civ.utwente.nl (8.11.7/HKD) with ESMTP id i0NCixS14564; Fri, 23 Jan 2004 13:44:59 +0100 Message-ID: <40111753.4000601@cs.utwente.nl> Date: Fri, 23 Jan 2004 13:45:07 +0100 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Frank_Strau=DF?= CC: nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Question on BER encoding References: <4010F0EF.2040100@cs.utwente.nl> <6780000.1074853700@hansa.ibr.cs.tu-bs.de> In-Reply-To: <6780000.1074853700@hansa.ibr.cs.tu-bs.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi Frank Your theory is correct wrt the coding of ASN.1's LENGTH field. My question, however, relates to the ASN.1 DATA field. As far as I know, the first bit of an octet does not have a special meaning there. If I look at my traces, I see that the ASN.1 DATA fields have ordinary hex encodings. To my surprise, however, I see that the hex encoding of large numbers get a octet with a zero value in front. I therefore get 5 octest for large values, whereas 4 would be sufficient. I don't understand the "zero octet" in the beginning. Bye Aiko Frank Strauß wrote: > Aiko Pras wrote: > > >>I'm still looking at bandwidth consumption of SNMP. I have now a question >>wrt BER encoding. >> >>Assume I want to BER encode a 32 bit INTEGER value. The ASN.1 encoding >>will start with a 1 octet TAG field, a 1 octet LENGTH field, and then x >>octets for the value. x depends on the precise value: a zero value can be >>coded in 1 octet and MAXINT needs more octets. > > > In theory, there is no MAXINT in ASN.1. But of course, SMI type range are > limited. > > >>My question is now: how many? >>I expect that, for a 32 bit INTEGER, x never exceeds 4 octets. If I look >>at my traces, however, I often find x=5. > > > I did not look up the exact details and terminology, but in general it is > something like this: > > The most significant bit of each octet denotes whether the next octet > belongs to the value: If it's zero this octet is the last one. I.e., with > one octet (which requires that the most significant bit is 0), you can > represent values from 0 to 2^7==127 with the remaining 7 bits. With two > octets (which means that the most significant bit of the first octet is 1 > and of the second octet is 0), you can represent values up to 2^15, etc. > This also means that the "upper half" of the "traditional" 32 bit value > range needs 5 BER octets and the "lower half" needs just 4 octets (or even > less). Note also, that each single value can be represented with different > numbers of octets (with a variable number of most significant octets > containing just zeros, except the "continuation bit"). > > The series of vulnerabilites of many SNMP implementations that have been > revealed in 2002 by a finnish academic group have been based partly on the > fact that some implementations handled some of the "valid but obscure" > value encodings (e.g., integers in even more than 5 octets) badly. Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NASKYA003739 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 23 Jan 2004 11:28:20 +0100 Date: Fri, 23 Jan 2004 11:28:20 +0100 From: =?ISO-8859-1?Q?Frank_Strau=DF?= To: Aiko Pras , nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] Question on BER encoding Message-ID: <6780000.1074853700@hansa.ibr.cs.tu-bs.de> In-Reply-To: <4010F0EF.2040100@cs.utwente.nl> References: <4010F0EF.2040100@cs.utwente.nl> X-Mailer: Mulberry/3.1.0 (Linux/x86) X-PGP-Key: 1024D/3B8A33AA 2000-08-03 Frank Strauss X-PGP-Fingerprint: F6CD 195C F141 4CF8 72AD 0CB0 CD24 F033 3B8A 33AA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Aiko Pras wrote: > I'm still looking at bandwidth consumption of SNMP. I have now a question > wrt BER encoding. > > Assume I want to BER encode a 32 bit INTEGER value. The ASN.1 encoding > will start with a 1 octet TAG field, a 1 octet LENGTH field, and then x > octets for the value. x depends on the precise value: a zero value can be > coded in 1 octet and MAXINT needs more octets. In theory, there is no MAXINT in ASN.1. But of course, SMI type range are limited. > My question is now: how many? > I expect that, for a 32 bit INTEGER, x never exceeds 4 octets. If I look > at my traces, however, I often find x=5. I did not look up the exact details and terminology, but in general it is something like this: The most significant bit of each octet denotes whether the next octet belongs to the value: If it's zero this octet is the last one. I.e., with one octet (which requires that the most significant bit is 0), you can represent values from 0 to 2^7==127 with the remaining 7 bits. With two octets (which means that the most significant bit of the first octet is 1 and of the second octet is 0), you can represent values up to 2^15, etc. This also means that the "upper half" of the "traditional" 32 bit value range needs 5 BER octets and the "lower half" needs just 4 octets (or even less). Note also, that each single value can be represented with different numbers of octets (with a variable number of most significant octets containing just zeros, except the "continuation bit"). The series of vulnerabilites of many SNMP implementations that have been revealed in 2002 by a finnish academic group have been based partly on the fact that some implementations handled some of the "valid but obscure" value encodings (e.g., integers in even more than 5 octets) badly. Received: from netlx010.civ.utwente.nl (netlx010.civ.utwente.nl [130.89.1.92]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0NA2dY9023173 for ; Fri, 23 Jan 2004 11:02:41 +0100 Received: from cs.utwente.nl (adsl219222.adsl.utwente.nl [130.89.225.67]) by netlx010.civ.utwente.nl (8.11.7/HKD) with ESMTP id i0NA1CS19126; Fri, 23 Jan 2004 11:01:12 +0100 Message-ID: <4010F0EF.2040100@cs.utwente.nl> Date: Fri, 23 Jan 2004 11:01:19 +0100 From: Aiko Pras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "nmrg@ibr.cs.tu-bs.de" CC: Aiko Pras Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact helpdesk@ITBE.utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-IBRFilter-SpamReport: 0.444 () TO_ADDRESS_EQ_REAL X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=TO_ADDRESS_EQ_REAL autolearn=ham version=2.60 X-Spam-Level: Subject: [nmrg] Question on BER encoding Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Hi I'm still looking at bandwidth consumption of SNMP. I have now a question wrt BER encoding. Assume I want to BER encode a 32 bit INTEGER value. The ASN.1 encoding will start with a 1 octet TAG field, a 1 octet LENGTH field, and then x octets for the value. x depends on the precise value: a zero value can be coded in 1 octet and MAXINT needs more octets. My question is now: how many? I expect that, for a 32 bit INTEGER, x never exceeds 4 octets. If I look at my traces, however, I often find x=5. Aiko Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FEbjEC008115 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 Jan 2004 15:37:45 +0100 Date: Thu, 15 Jan 2004 15:37:45 +0100 From: =?ISO-8859-1?Q?Frank_Strau=DF?= To: nmrg@ibr.cs.tu-bs.de cc: j.schoenwaelder@iu-bremen.de Subject: Re: [nmrg] 15th NMRG meeting last week Message-ID: <26740000.1074177465@hansa.ibr.cs.tu-bs.de> In-Reply-To: <20040115125318.GC739@iu-bremen.de> References: <20040115125318.GC739@iu-bremen.de> X-Mailer: Mulberry/3.1.0 (Linux/x86) X-PGP-Key: 1024D/3B8A33AA 2000-08-03 Frank Strauss X-PGP-Fingerprint: F6CD 195C F141 4CF8 72AD 0CB0 CD24 F033 3B8A 33AA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Juergen Schoenwaelder wrote: > I think we had a nice meeting last week. I have now put all the slides > on the meeting web page for those who could not attend. > > Frank Strauss recorded the meetings in video and audio. These recordings > are basically an experiment to see whether this is doable these days with > an acceptable amount of work. Please contact Frank if you want to look > at the material (and if you look at it, please give us feedback whether > you think this is useful). The recordings are available for download at http://www.ibr.cs.tu-bs.de/projects/nmrg/recordings/. If you would like to try steaming, let me know, I've started playing with the Darwin streaming server and we could give it a try. For any reason the video recording did not work for the second part (Juergen Quittek's MIDCOM presentation), but however the audio is there. For any(!) of the recordings you definitely need the PDF slides as well, since the projections on the wall cannot be read in the video. I used standard MPEG-4 encoding to achieve a quite good compression, but unfortunately there are not many decoder implementations. Apple QuickTime (also freely available for MS Windows) works fine. A recent mplayer compiled with the appropriate libraries should work as well. Received: from merkur.iu-bremen.de (merkur.iu-bremen.de [212.201.44.27]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0FCrJEB021961 for ; Thu, 15 Jan 2004 13:53:19 +0100 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id 4935782EF0; Thu, 15 Jan 2004 13:53:19 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.18]) by merkur.iu-bremen.de (Postfix) with ESMTP id 8EB8F82CF2; Thu, 15 Jan 2004 13:53:18 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 8319687C5; Thu, 15 Jan 2004 13:53:18 +0100 (CET) Date: Thu, 15 Jan 2004 13:53:18 +0100 From: Juergen Schoenwaelder To: nmrg@ibr.cs.tu-bs.de Message-ID: <20040115125318.GC739@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: nmrg@ibr.cs.tu-bs.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Subject: [nmrg] 15th NMRG meeting last week Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: I think we had a nice meeting last week. I have now put all the slides on the meeting web page for those who could not attend. Frank Strauss recorded the meetings in video and audio. These recordings are basically an experiment to see whether this is doable these days with an acceptable amount of work. Please contact Frank if you want to look at the material (and if you look at it, please give us feedback whether you think this is useful). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany Received: from [10.0.1.4] (dagoba.ibr.cs.tu-bs.de [134.169.34.107]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0C8PYIV006450 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 12 Jan 2004 09:25:37 +0100 Date: Mon, 12 Jan 2004 09:25:35 +0100 From: =?ISO-8859-1?Q?Frank_Strau=DF?= To: Emmanuel Nataf , nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] sming soft Message-ID: <2147483647.1073899533@[10.0.1.4]> In-Reply-To: <2147483647.1073571410@[212.201.47.10]> References: <20030919130526.GA1564@iu-bremen.de> <20030921190231.GA5108@iu-bremen.de> <3FFC26AC.3040307@loria.fr> <2147483647.1073571410@[212.201.47.10]> X-Mailer: Mulberry/3.1.0 (Mac OS X) X-PGP-Key: 1024D/3B8A33AA 2000-08-03 Frank Strauss X-PGP-Fingerprint: F6CD 195C F141 4CF8 72AD 0CB0 CD24 F033 3B8A 33AA MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by agitator.ibr.cs.tu-bs.de id i0C8PYIV006450 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Frank Strauß wrote: > [...] Hence, we are currently at > draft-irtf-nmrg-sming-07 and draft-irtg-nmrg-sming-snmp-05. But the good > news is that the content did not really change. The documents are now in > last call [...] Bert just noticed me that this is not true. I misunderstood the process for non-IETF-WG I-Ds to be published as Experimental RFCs. The SMIng I-Ds are going to be put on the IESG agenda for any final IESG comments. There will be no IETF wide last call for documents like these. Thanks to Bert. Received: from [10.0.1.4] (dagoba.ibr.cs.tu-bs.de [134.169.34.107]) (authenticated bits=0) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i0ALGIIX010437 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 10 Jan 2004 22:16:25 +0100 Date: Thu, 08 Jan 2004 14:16:50 +0100 From: =?ISO-8859-1?Q?Frank_Strau=DF?= To: Emmanuel Nataf , nmrg@ibr.cs.tu-bs.de Subject: Re: [nmrg] sming soft Message-ID: <2147483647.1073571410@[212.201.47.10]> In-Reply-To: <3FFC26AC.3040307@loria.fr> References: <20030919130526.GA1564@iu-bremen.de> <20030921190231.GA5108@iu-bremen.de> <3FFC26AC.3040307@loria.fr> X-Mailer: Mulberry/3.1.0 (Mac OS X) X-PGP-Key: 1024D/3B8A33AA 2000-08-03 Frank Strauss X-PGP-Fingerprint: F6CD 195C F141 4CF8 72AD 0CB0 CD24 F033 3B8A 33AA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: Emmanuel Nataf wrote: > A new release of a java SMIng compiler and a SMIng-based proxy agent > (with JMX and SNMP) is available at : > > http://sourceforge.net/projects/sming/ > > The distribution is compliant with the draft-irtf-nmrg-sming-06 document > available at http://www/ibr.cs.tu-bs.de/projects/sming Great News! BTW, during the process to get the specs published as experimental RFCs, the RFC Editor proposed to integrate the "Modules document" as an appendix to the core document. Hence, we are currently at draft-irtf-nmrg-sming-07 and draft-irtg-nmrg-sming-snmp-05. But the good news is that the content did not really change. The documents are now in last call since 2003-12-24, so we might hope to get it published soon. Greetings from the ongoing NMRG meeting, -frank Received: from jake.unipi.it (jake.unipi.it [131.114.21.22]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i089vi9g019936 for ; Thu, 8 Jan 2004 10:57:44 +0100 Received: from [172.22.5.20] ([195.103.245.71]) by jake.unipi.it (8.12.10/8.12.8) with ESMTP id i08ASjaq001127 for ; Thu, 8 Jan 2004 11:28:46 +0100 Mime-Version: 1.0 (Apple Message framework v609) Content-Transfer-Encoding: 7bit Message-Id: <114EDD9C-41C1-11D8-9145-000393D12F16@ntop.org> Content-Type: text/plain; charset=US-ASCII; format=flowed To: nmrg@ibr.cs.tu-bs.de From: Luca Deri Date: Thu, 8 Jan 2004 10:57:28 +0100 X-Pgp-Agent: GPGMail 1.0 (v30, 10.3) X-Mailer: Apple Mail (2.609) X-IBRFilter-SpamReport: 0.691 () UPPERCASE_25_50 X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.3 required=5.0 tests=UPPERCASE_25_50 autolearn=no version=2.60 X-Spam-Level: Subject: [nmrg] Packet Capture Paper Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Loris Degioanni, Mario Baldi, Fulvio Risso and Gianluca Varenni, Profiling and Optimization of Software-Based Network-Analysis Applications, Proceedings of the 15th IEEE Symposium on Computer Architecture and High Performance Computing (SBAC-PAD 2003), Sao Paulo, Brasil, November 2003 http://winpcap.polito.it/docs/default.htm - ------- Luca Deri http://luca.ntop.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (Darwin) iD8DBQE//SmImMhDxnkh3zQRApyYAJ4iXT9ci1immkWjOILXb8SSQqLN6QCglbee psnC+lctC8TxtG5pjuzuMSs= =SPw8 -----END PGP SIGNATURE----- Received: from macker.loria.fr (macker.loria.fr [152.81.1.70]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id i07FWV9g015330 for ; Wed, 7 Jan 2004 16:32:43 +0100 Received: from localhost.loria.fr (localhost.loria.fr [127.0.0.1]) by localhost (Postfix) with ESMTP id E50A3887A for ; Wed, 7 Jan 2004 16:32:28 +0100 (MET) X-Amavix: Anti-virus check done by McAfee X-Amavix: Scanned by Amavix Received: from loria.fr (ibanez.loria.fr [152.81.8.93]) by macker.loria.fr (Postfix) with ESMTP id B6F8E8998 for ; Wed, 7 Jan 2004 16:32:23 +0100 (MET) Message-ID: <3FFC26AC.3040307@loria.fr> Date: Wed, 07 Jan 2004 16:33:00 +0100 From: Emmanuel Nataf User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.4) Gecko/20030624 X-Accept-Language: fr, en MIME-Version: 1.0 To: nmrg@ibr.cs.tu-bs.de Subject: [nmrg] sming soft References: <20030919130526.GA1564@iu-bremen.de> <20030921190231.GA5108@iu-bremen.de> In-Reply-To: <20030921190231.GA5108@iu-bremen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-IBRFilter-SpamReport: 0 () X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on agitator.ibr.cs.tu-bs.de X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Sender: nmrg-admin@ibr.cs.tu-bs.de Errors-To: nmrg-admin@ibr.cs.tu-bs.de X-BeenThere: nmrg@ibr.cs.tu-bs.de X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Network Management Research Group List-Unsubscribe: , List-Archive: A new release of a java SMIng compiler and a SMIng-based proxy agent (with JMX and SNMP) is available at : http://sourceforge.net/projects/sming/ The distribution is compliant with the draft-irtf-nmrg-sming-06 document available at http://www/ibr.cs.tu-bs.de/projects/sming E. Nataf