The throughput can be enhanced up to factor three
using the V42bis compression method or the Stac LZS
compression algorithm. V42bis is currently supported
with the ip-lapb and mpr-lapb encapsulation. Stac LZS
compression algorithm is provided using PPP encapsulated
links, stac(3) indicates support of Sequence checking,
ms-stac(4) indicates support of Extended mode which is
prefered by Microsoft. Both check modes are implemented
according RFC 1974.
When set to mppc(5), the Microsoft Point-to-Point
Compression (MPPC) Protocol according RFC 2118 is
negotiated. MPPC uses an LZ based algorithm with a
sliding window history buffer.
Parsed from file mibppp.mib.txt
Company: None
Module: BIANCA-BRICK-PPP-MIB
The throughput can be enhanced up to factor three
using the V42bis compression method or the Stac LZS
compression algorithm. V42bis is currently supported
with the ip-lapb and mpr-lapb encapsulation. Stac LZS
compression algorithm is provided using PPP encapsulated
links, stac(3) indicates support of Sequence checking,
ms-stac(4) indicates support of Extended mode which is
prefered by Microsoft. Both check modes are implemented
according RFC 1974.
When set to mppc(5), the Microsoft Point-to-Point
Compression (MPPC) Protocol according RFC 2118 is
negotiated. MPPC uses an LZ based algorithm with a
sliding window history buffer.
Parsed from file BIANCA-BRICK-PPP-MIB.mib
Module: BIANCA-BRICK-PPP-MIB
Vendor: BinTec Communications GmbH
Module: BIANCA-BRICK-PPP-MIB
[Automatically extracted from oidview.com]
biboPPPCompression OBJECT-TYPE SYNTAX INTEGER { none(1), v42bis(2), stac(3), ms-stac(4), mppc(5) } ACCESS read-write STATUS mandatory DESCRIPTION "The throughput can be enhanced up to factor three using the V42bis compression method or the Stac LZS compression algorithm. V42bis is currently supported with the ip-lapb and mpr-lapb encapsulation. Stac LZS compression algorithm is provided using PPP encapsulated links, stac(3) indicates support of Sequence checking, ms-stac(4) indicates support of Extended mode which is prefered by Microsoft. Both check modes are implemented according RFC 1974. When set to mppc(5), the Microsoft Point-to-Point Compression (MPPC) Protocol according RFC 2118 is negotiated. MPPC uses an LZ based algorithm with a sliding window history buffer." ::= { biboPPPEntry 6 }
biboPPPCompression OBJECT-TYPE SYNTAX INTEGER { none(1), v42bis(2), stac(3), ms-stac(4), mppc(5) } ACCESS read-write STATUS mandatory DESCRIPTION "The throughput can be enhanced up to factor three using the V42bis compression method or the Stac LZS compression algorithm. V42bis is currently supported with the ip-lapb and mpr-lapb encapsulation. Stac LZS compression algorithm is provided using PPP encapsulated links, stac(3) indicates support of Sequence checking, ms-stac(4) indicates support of Extended mode which is prefered by Microsoft. Both check modes are implemented according RFC 1974. When set to mppc(5), the Microsoft Point-to-Point Compression (MPPC) Protocol according RFC 2118 is negotiated. MPPC uses an LZ based algorithm with a sliding window history buffer." ::= { biboPPPEntry 6 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.272.4.3.1.1.1 | biboPPPIfIndex | 0 | 0 | Correlating PPP interface index. This value is assigned automatically by the system. |
| 1.3.6.1.4.1.272.4.3.1.1.2 | biboPPPType | 0 | 0 | The type of link. A new dialup link is created when this field is set to the value isdn-dialup(1), dialin-only(3) or multiuser(5)… |
| 1.3.6.1.4.1.272.4.3.1.1.3 | biboPPPEncapsulation | 0 | 0 | The layer 2 encapsulation of the link. The use of ppp(1) as described in RFC 1661 is the preferred encapsulation for point-to-poi… |
| 1.3.6.1.4.1.272.4.3.1.1.4 | biboPPPKeepalive | 0 | 0 | When set to on(1), keepalive packets are sent in regular intervals during the connection. Keepalive packets can not be sent using… |
| 1.3.6.1.4.1.272.4.3.1.1.5 | biboPPPTimeout | 0 | 0 | The number of milliseconds waiting before retransmitting a PPP configure packet. |
| 1.3.6.1.4.1.272.4.3.1.1.7 | biboPPPAuthentication | 0 | 0 | The type of authentication used on the point-to-point link as described in RFC 1334. The authentication protocol supports pap(2) … |
| 1.3.6.1.4.1.272.4.3.1.1.8 | biboPPPAuthIdent | 0 | 0 | The remote authentication identification string. The local authentication identification string is taken from the contents of the… |
| 1.3.6.1.4.1.272.4.3.1.1.9 | biboPPPAuthSecret | 0 | 0 | The authentication secret, which is used symmetrically for both local and remote sides of the PPP link. |
| 1.3.6.1.4.1.272.4.3.1.1.10 | biboPPPIpAddress | 0 | 0 | The IP control protocol as described in RFC1332 has a means of negotiating IP-addresses. When this option is set to dynamic-serve… |
| 1.3.6.1.4.1.272.4.3.1.1.11 | biboPPPRetryTime | 0 | 0 | Time in seconds to wait before retrying a call; currently not used. |
| 1.3.6.1.4.1.272.4.3.1.1.12 | biboPPPBlockTime | 0 | 0 | Time in seconds to wait after a connection failure (e.g. the number of biboPPPMaxRetries calls failed). When set to zero, the int… |
| 1.3.6.1.4.1.272.4.3.1.1.13 | biboPPPMaxRetries | 0 | 0 | The number of dialup retries before changing to the blocked state. |
| 1.3.6.1.4.1.272.4.3.1.1.14 | biboPPPShortHold | 0 | 0 | The time in seconds to wait, once the channel is silent, (that is, no data is being received or transmitted) before terminating t… |
| 1.3.6.1.4.1.272.4.3.1.1.15 | biboPPPInitConn | 0 | 0 | The number of channels to initially set up for this interface. |
| 1.3.6.1.4.1.272.4.3.1.1.16 | biboPPPMaxConn | 0 | 0 | The maximum number of channels bundled for this interface. |
| 1.3.6.1.4.1.272.4.3.1.1.17 | biboPPPMinConn | 0 | 0 | The minimum number of channels bundled for this interface. |
| 1.3.6.1.4.1.272.4.3.1.1.18 | biboPPPCallback | 0 | 0 | If this object is enabled(1), and the call is recognized by the dialed number then calls are never accepted, and a callback is fo… |
| 1.3.6.1.4.1.272.4.3.1.1.19 | biboPPPLayer1Protocol | 0 | 0 | This entry is used to select the layer 1 protocol settings for this partner. Normally the correct entry is hdlc-64. |
| 1.3.6.1.4.1.272.4.3.1.1.20 | biboPPPLoginString | 0 | 0 | A textual string containing a login sequence (script) composed of fields in the format [expect send], comparable to chat scripts … |
| 1.3.6.1.4.1.272.4.3.1.1.21 | biboPPPVJHeaderComp | 0 | 0 | This entry is used to enable Van Jacobsen TCP/IP header compression, which reduces the size of TCP/IP packet headers and increase… |
| 1.3.6.1.4.1.272.4.3.1.1.22 | biboPPPLayer2Mode | 0 | 0 | This object specifies the layer 2 mode to be used for a connection. It is only relevant, if the Encapsulation involves an LAPB pr… |
| 1.3.6.1.4.1.272.4.3.1.1.23 | biboPPPDynShortHold | 0 | 0 | Optimizes idle time disconnects depending on the charging information received during the connection. This value specifies the mi… |
| 1.3.6.1.4.1.272.4.3.1.1.24 | biboPPPLocalIdent | 0 | 0 | This is the local identification string used for PPP authentication(PAP/CHAP). If this entry is empty the variable biboAdmLocalPP… |
| 1.3.6.1.4.1.272.4.3.1.1.25 | biboPPPDNSNegotiation | 0 | 0 | The IP control protocol extensions as described in RFC 1877 has a means of negotiating primary and secondary Domain Name System (… |
| 1.3.6.1.4.1.272.4.3.1.1.26 | biboPPPEncryption | 0 | 0 | This field specifies the data encryption scheme for en(de)crypting PPP encapsulated multi-protocol datagrams. Setting to mppe-40(… |
| 1.3.6.1.4.1.272.4.3.1.1.27 | biboPPPLQMonitoring | 0 | 0 | This parameter enables (2) or disables (1) PPP Link Quality Monitoring (LQM) according RFC 1989. When set to on(2) LQM is added t… |
| 1.3.6.1.4.1.272.4.3.1.1.28 | biboPPPIpPoolId | 0 | 0 | Pool ID value to select an IP address pool for dynamic IP address assignment via IPCP. See also PPPIpAssignTable for further deta… |
| 1.3.6.1.4.1.272.4.3.1.1.29 | biboPPPSessionTimeout | 0 | 0 | Maximum number of seconds before termination the established PPP session, regardless there is any data throughput on the correspo… |
| 1.3.6.1.4.1.272.4.3.1.1.30 | biboPPPLayer1DiscDelay | 0 | 0 | This parameter specifies wether the link (layer 1) should be disconnected immediately (after receiving a layer 2 disconnect) or d… |