Resumen

  • RFC 1317 definió una MIB física para enlaces serie semejantes a RS-232, con registros separados para puertos generales, asíncronos, síncronos y señales de entrada y salida.
  • Al habilitar autobaud, la gestión podía observar temporalmente velocidad, paridad o tamaño de carácter distintos de lo configurado.
  • Esa divergencia no demostraba por sí sola una escritura administrativa, una persona responsable, un cambio permanente, la identidad del otro extremo, una sesión, datos entregados o éxito de la aplicación.

No era una contradicción de la consola

La idea cómoda es que la telemetría debe reflejar la configuración. Se fija un valor, se consulta y aparece el mismo. Si no coincide, alguien lo cambió. RFC 1317 describía un puerto capaz de adaptarse a la entrada y, por tanto, rompía ese espejo.

El documento cubría RS-232, RS-422, RS-423, V.35 y otros enlaces físicos serie, tanto asíncronos como síncronos. Situaba la MIB debajo de capas como Character o PPP. El puerto podía sostener un terminal o una conexión de red sin que su dato físico se convirtiera en dato de usuario, sesión o aplicación.

El objeto rs232AsyncPortAutobaud permitía detectar automáticamente la velocidad de entrada. Su explicación advertía que el puerto podía adoptar valores diferentes de velocidad, paridad y tamaño de carácter, y que la gestión podía verlos temporalmente. El ajuste previo y la lectura presente podían ser verdaderos a la vez porque no contestaban la misma pregunta.

Cada tabla conservaba un verbo

La tabla general asignaba índice local, tipo de hardware, número de señales detectables o afirmables y velocidades de entrada y salida. El índice debía conservar estabilidad entre reinicios del agente y, cuando fuera posible, corresponder a un conector. No era la identidad de un usuario, un módem remoto o una entidad.

La tabla asíncrona separaba bits por carácter, bits de parada, paridad, autobaud y contadores de errores de paridad, trama y sobrecarga. La tabla síncrona contenía la fuente de reloj y contadores de tramas. Otras dos tablas distinguían señales de entrada de señales de salida.

Así quedaban separados los verbos: configurar, detectar, observar, contar y afirmar. Reducirlo todo a «estado del puerto» elimina quién produjo el dato y qué autoridad tiene. El diseño de RFC 1317 era más útil precisamente porque no hacía esa compresión.

Un valor observado no era un historial de cambios

Si la lectura de paridad no coincide con el registro de configuración, la lectura demuestra primero lo que la MIB expuso en ese instante. Con autobaud activo existe una causa permitida para la diferencia. El objeto no revela qué secuencia la provocó, cuánto duró, si hubo una escritura autenticada o si el puerto regresó después al ajuste anterior.

Tampoco identifica al otro extremo. Adaptarse al ritmo físico puede ayudar a correlacionar un enlace, pero no autentica un dispositivo o una persona. No prueba que se formó una sesión Character, que PPP terminó de negociar ni qué contenido circuló.

Llamar «deriva de configuración» al dato inicial añade persistencia y carácter indeseado. El registro más fiel dice: valor previamente fijado, autobaud habilitado, otro valor observado a una hora determinada. La deriva requiere pruebas adicionales sobre duración, estado deseado y autoridad de cambio.

El contador clasificaba, no explicaba

Los contadores asíncronos registraban errores de paridad, trama y sobrecarga desde la reinicialización, mientras el puerto estuviera up o test. Un aumento confirma que el agente clasificó más caracteres dentro de esa categoría y ventana. Puede orientar la revisión de parámetros, cableado, equipo o carga, pero no escoge una causa.

Un total de paridad no demuestra por sí mismo una configuración errónea. Un total de trama no nombra al emisor. Una sobrecarga no identifica la aplicación que no consumió datos ni el resultado que perdió. Además, el acumulado no conserva el orden, la duración o los parámetros activos en cada aparición.

Los contadores síncronos —comprobación de trama, falta de datos al transmisor, sobrecarga del receptor, interrupciones o abortos— tienen la misma limitación. Son observaciones de su capa, no automáticamente una incidencia de servicio, una transacción fallida o una atribución de culpa.

Los nombres de señales no eran identidades

Request to Send, Clear to Send, Data Set Ready, Data Terminal Ready, Ring Indicator y Received Line Signal Detector parecen narrar una llamada. En la MIB son líneas físicas con dirección, estado none/on/off y contador de cambios.

Detectar una entrada no autentica al extremo remoto. Afirmar una salida no demuestra que el remoto obedeció. El contador de transiciones no cuenta llamadas, usuarios, sesiones o mensajes. Para correlacionarlo hay que conservar índice, dirección, nombre de señal, lectura, total, hora y agente.

La revisión de 1994 mantuvo el límite

RFC 1659 sustituyó RFC 1317 y llevó la MIB a SMIv2. Conservó la ubicación física y la advertencia de autobaud. La persistencia muestra que la separación entre ajuste y observación no era accidental; no demuestra, sin embargo, que hubiera un despliegue concreto.

Una investigación sólida necesita una tupla: puerto y hardware, valores fijados, autobaud, lecturas con hora, límite de reinicialización, deltas de errores, señales y referencias de capa superior obtenidas de otros sistemas. El historial autenticado prueba escrituras; el registro de sesión prueba la sesión; la aplicación prueba entrega y resultado. RFC 1317 no prestaba ninguna de esas conclusiones a una lectura física.

Fuentes y límites de la evidencia

El análisis usa RFC 1317, de abril de 1992, y su sucesor SMIv2 RFC 1659, de julio de 1994. Respaldan el alcance físico, las tablas, autobaud, los contadores limitados, las señales y la sustitución documental. No prueban un dispositivo, ajuste, escritura, operador, par, sesión, contenido, despliegue, entrega o resultado real.