Análisis de bajo nivel de una respuesta de ping

Fecha: 17 de abril del 2023

Escenario

Aquí analizamos la respuesta de ping del escenario anterior, en formato de paquete / trama / bits, desde algo legible por humanos,

pasando por hexadecimal, bajando a binario, y codificado para ponerlo en el cable, con el agregado del preámbulo y el trailer CRC.

Sugiero tomar café antes de leerlo…

1.- Generamos el ping desde la PC:

C:\>ping 192.168.1.10

Haciendo ping a 192.168.1.10 con 32 bytes de datos:

Respuesta desde 192.168.1.10: bytes=32 tiempo=5ms TTL=255 (la respuesta de ping que nos interesa)

Respuesta desde 192.168.1.10: bytes=32 tiempo=5ms TTL=255

2.- Verificamos en el Wireshark:

La trama que analizaremos es la primer respuesta de ping (echo reply) o sea, la trama #4.

3.- Esquema en el modelo OSI:

Para cualquier otra aplicación y sus datos el proceso es exactamente igual, capa más, capa menos, con sus cabeceras, y encriptando o no

sus payloads, pero es igual. Sólo un “par de pasos más”.

4.- Dump de la trama en Wireshark:

Este es el dump de una trama/paquete recibida, pero desde el punto 5. analizaremos el proceso de envío de esta trama desde el lado del switch.

4.1.- Trama en formato “legible para humanos” :

Frame 4: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)

Ethernet II, Src: a4:18:75:bd:e5:c0, Dst: 00:1b:38:7e:f1:71 (capa 2 del modelo OSI)

Destination: 00:1b:38:7e:f1:71

Source: a4:18:75:bd:e5:c0

Type: IPv4 (0x0800)

Internet Protocol Version 4, Src: 192.168.1.10, Dst: 192.168.1.100 (capa 3 del modelo OSI)

0100 .... = Version: 4

.... 0101 = Header Length: 20 bytes (5)

Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)

Total Length: 60

Identification: 0x0067 (103)

000. .... = Flags: 0x0

...0 0000 0000 0000 = Fragment Offset: 0

Time to Live: 255 (ver que el valor de Cisco IOS es 255)

Protocol: ICMP (1)

Header Checksum: 0x379b [validation disabled]

[Header checksum status: Unverified]

Source Address: 192.168.1.10 (en hexacedimal es c0 a8 01 0a)

Destination Address: 192.168.1.100 (en hexacedimal es c0 a8 01 64)

Internet Control Message Protocol (payload de la capa 3 del modelo OSI)

Type: 0 (Echo (ping) reply) (aquí se indica que es una respuesta de eco)

Code: 0 (aquí se indica que es una respuesta de eco)

Checksum: 0x5516 [correct] (checksum de validación de la cabecera ICMP)

[Checksum Status: Good]

Identifier (BE): 1 (0x0001)

Identifier (LE): 256 (0x0100)

Sequence Number (BE): 69 (0x0045)

Sequence Number (LE): 17664 (0x4500)

Data (32 bytes) (relleno de la MTU) (ver https://www.vilarrasa.com.ar/icmp_data.htm )

Data: 6162636465666768696a6b6c6d6e6f7071727374757677616263646566676869

[Length: 32]

4.2.- Formato hexadecimal de la trama:

Detalle: Layer 2 Layer 3 Payload Data

0000 00 1b 38 7e f1 71 a4 18 75 bd e5 c0 08 00 45 00

0010 00 3c 00 67 00 00 ff 01 37 9b c0 a8 01 0a c0 a8

0020 01 64 00 00 55 16 00 01 00 45 61 62 63 64 65 66

0030 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76

0040 77 61 62 63 64 65 66 67 68 69

ß sentido de transmisión por la red ( ver https://www.vilarrasa.com.ar/sipo_piso.htm )

00 1b 38 7e f1 71 a4 18 75 bd e5 c0 08 00 45 00 00 3c 00 67 00 00 ff 01 37 9b c0 a8 01 0a c0 a8 01 64 00 00 55 16 00 01 00 45 /// sigue abajo

layer 2 | layer 3 | ICMP |

/// 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69

data |

5.- Como sería el proceso de encapsulado del payload:

A partir de ahora analizaremos el proceso de envío de esta trama desde el lado del switch.

5.1.- Tenemos la respuesta al ICMP echo:

Se agregan los parámetros descriptos como Internet Control Message Protocol en el punto 4.1.

00 00 55 16 00 01 00 45

| ICMP |

En este caso al ser una respuesta de ping necesitamos un relleno dummy para completar la trama, generalmente similar al que recibió en la solicitud de eco.

5.2.- Agregamos un payload dummy a la cabecera ICMP:

Se agregan el relleno Data que aparecen en el punto 4.1.

00 00 55 16 00 01 00 45 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69

| ICMP | data |

5.3.- Encapsulamos el paquete ICMP en un paquete IP:

45 00 00 3c 00 67 00 00 ff 01 37 9b c0 a8 01 0a c0 a8 01 64 00 00 55 16 00 01 00 45 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69

| layer 3 | ICMP | data |

5.4.- Encapsulamos en una trama ethernet:

Este es el único proceso que incluye un trailer al final (el CRC) que es una verificación de toda la trama (ver punto 5.6.2.).

Esta verificación la calculan todos los dispositivos de layer 2 que reciben la trama y la comparan con el valor del trailer, debiendo dar igual,

de lo contrario la trama se descarta y en este caso veremos un tiempo de espera agotado en el ping.

00 1b 38 7e f1 71 a4 18 75 bd e5 c0 08 00 45 00 00 3c 00 67 00 00 ff 01 37 9b c0 a8 01 0a c0 a8 01 64 00 00 55 16 00 01 00 45 /// sigue abajo

layer 2 | layer 3 | ICMP |

/// 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69 3a 28 C8 42

data | CRC |

6.- Formato binario de la trama:

Aquí la cosa se vuelve mas complicada, vayamos punto por punto.

6.1.- Inicialmente para que sea más legible hacemos una conversión de a 32 bits tipo dump de una memoria y mantenemos en colores

las capas del modelo OSI, ahora de arriba hacia abajo.

Hexa Binario

1 32 bit

001b387e 0000 0000 0001 1011 0011 1000 0111 1110

f171a418 1111 0001 0111 0001 1010 0100 0001 1000

75bde5c0 0111 0101 1011 1101 1110 0101 1100 0000

08004500 0000 1000 0000 0000 0100 0101 0000 0000

003c0067 0000 0000 0011 1100 0000 0000 0110 0111

0000ff01 0000 0000 0000 0000 1111 1111 0000 0001

379bc0a8 0011 0111 1001 1011 1100 0000 1010 1000

010ac0a8 0000 0001 0000 1010 1100 0000 1010 1000

01640000 0000 0001 0110 0100 0000 0000 0000 0000

55160001 0101 0101 0001 0110 0000 0000 0000 0001

00456162 0000 0000 0100 0101 0110 0001 0110 0010

63646566 0110 0011 0110 0100 0110 0101 0110 0110

6768696a 0110 0111 0110 1000 0110 1001 0110 1010

6b6c6d6e 0110 1011 0110 1100 0110 1101 0110 1110

6f707172 0110 1111 0111 0000 0111 0001 0111 0010

73747576 0111 0011 0111 0100 0111 0101 0111 0110

77616263 0111 0111 0110 0001 0110 0010 0110 0011

64656667 0110 0100 0110 0101 0110 0110 0110 0111

6869 0110 1000 0110 1001

6.2.- Codificación 4B/5B:

La codificación 4B/5B mapea grupos de 4 bits de datos en grupos de 5 bits para su transmisión. Estas palabras de 5 bits están predeterminadas

en un diccionario y se eligen para garantizar que habrá suficientes transiciones en el estado de línea para producir una señal de sincronización

automática . Un efecto colateral del código es que se necesita un ~25% más de bits para enviar la misma información.

Fuente: Texas instruments

Podemos apreciar como es el incremento de bits en el total de la trama, sin payload, es 7+1+6+6+2+4=26 bytes=208 bits contra 270 bits ya codificado.

6.2.1.- Mapa de codificación 4-bit > 5-bit (4B/5B):

0 0000 11110

1 0001 01001

2 0010 10100

3 0011 10101

4 0100 01010

5 0101 01011

6 0110 01110

7 0111 01111

8 1000 10010

9 1001 10011

A 1010 10110

B 1011 10111

C 1100 11010

D 1101 11011

E 1110 11100

F 1111 11101

- omitido / no aplica -

J 11000 SSD part1

K 10001 SSD part2

T 01101 ESD part1

R 00111 ESD part 2

Los datos se codifican primero usando un método llamado 4B/5B . Luego, estos datos codificados en 4B/5B se codifican aún más usando MLT-3

para 100BASE-TX y NRZ-I para 100BASE-FX. Este procedimiento de doble codificación asegura que no haya problemas de transición y que la

frecuencia de la señal sea un nivel aceptable, por debajo de 100MHz.

En otras palabras, la codificación 4B/5B se encarga del problema de transición y el MLT-3 o NRZ-I se encarga del problema de frecuencia esto lo

veremos en el punto 5.9. al momento de transmitir (ya eléctricamente hablando).

6.3.- Frame 4, 74 bytes RAW:

Detalle: Layer 2 Layer 3 Payload Data

0000 0000 0001 1011 0011 1000 0111 1110 1111 0001 0111 0001 1010 0100 0001 1000 0111 0101 1011 1101 1110 0101 1100 0000 0000 1000 0000

0000 0100 0101 0000 0000 0000 0000 0011 1100 0000 0000 0110 0111 0000 0000 0000 0000 1111 1111 0000 0001 0011 0111 1001 1011 1100 0000

1010 1000 0000 0001 0000 1010 1100 0000 1010 1000 0000 0001 0110 0100 0000 0000 0000 0000 0101 0101 0001 0110 0000 0000 0000 0001 0000

0000 0100 0101 0110 0001 0110 0010 0110 0011 0110 0100 0110 0101 0110 0110 0110 0111 0110 1000 0110 1001 0110 1010 0110 1011 0110 1100

0110 1101 0110 1110 0110 1111 0111 0000 0111 0001 0111 0010 0111 0011 0111 0100 0111 0101 0111 0110 0111 0111 0110 0001 0110 0010 0110

0011 0110 0100 0110 0101 0110 0110 0110 0111 0110 1000 0110 1001

6.4.- Frame 4, 74 bytes on wire Encoded 4B/5B:

Detalle: Layer 2 Layer 3 Payload Data

11110 11110 01001 10111 10100 10010 01111 11100 11101 01001 01111 01001 10110 01010 01001 10010 01111 01011 10111 11011 11100 01011

11010 11110 11110 10010 11110 11110 01010 01011 11110 11110 11110 11110 10100 11010 11110 11110 01110 01111 11110 11110 11110 11110

11101 11101 11110 01001 10100 01111 10011 10111 11010 11110 10110 10010 11110 01001 11110 10110 11010 11110 10110 10010 11110 01001

01110 01010 11110 11110 11110 11110 01011 01011 01001 01110 11110 11110 11110 01001 11110 11110 01010 01011 01110 01001 01110 10100

01110 10100 01110 01010 01110 01011 01110 01110 01110 01111 01110 10010 01110 10011 01110 10110 01110 10111 01110 11010 01110 11011

01110 11100 01110 11101 01111 11110 01111 01001 01111 10100 01111 10100 01111 01010 01111 01011 01111 01110 01111 01111 01110 01001

01110 10100 01110 10100 01110 01010 01110 01011 01110 01110 01110 01111 01110 10010 01110 10011

6.5.- Agregado del preámbulo y el trailer CRC:

6.5.1.- Preámbulo:

The preamble consists of a 56-bit (seven-byte) pattern of alternating 1 and 0 bits, allowing devices on the network to easily synchronize their receiver clocks,

providing bit-level synchronization. It is followed by the SFD to provide byte-level synchronization and to mark a new incoming frame.

For Ethernet variants transmitting serial bits instead of larger symbols, the (uncoded) on-the-wire bit pattern for the preamble together with the SFD portion of

the frame is 10101010 10101010 10101010 10101010 10101010 10101010 10101010 10101011. The bits are transmitted in order, from left to right

The SFD is the eight-bit (one-byte) value that marks the end of the preamble, and indicates the beginning of the Ethernet frame.

The SFD is designed to break the bit pattern of the preamble and signal the start of the actual frame.

The SFD is immediately followed by the destination MAC address, which is the first field in an Ethernet frame.

SFD is the binary sequence 10101011 (0xD5, decimal 213 in the Ethernet LSB first bit ordering).

Fuente: https://en.wikipedia.org/wiki/Ethernet_frame

IEEE 802.3 Fast Ethernet spec Start-of-Stream Delimiter chapter states: a Start-of-Stream Delimiter (SSD) is used to delineate the boundary of a data

transmission sequence and to authenticate carrier events. On transmission, the first 8 bits of the MAC preamble are replaced by the SSD simbols JK,

a replacement that is reversed on reception.

Fuente: Texas instruments

6.5.1.1.- Preámbulo en binario:

1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 1010 1011

6.5.1.2.- Preámbulo codificado:

Start-of-Stream Delimiter (símbolos J y K en 4B/5B)

| |

J K

11000 10001 10110 10110 10110 10110 10110 10110 10110 10110 10110 10110 10110 10111

6.5.2.- Trailer CRC:

Per the standard, this computation is done using the left shifting CRC32 BZIP2

(poly = 0x4C11DB7, initial CRC = 0xFFFFFFFF, CRC is post complemented, verify value = 0x38FB2284) algorithm.

Fuente: https://en.wikipedia.org/wiki/Ethernet_frame

6.5.2.1.- Cálculo del CRC:

Fuente: https://crccalc.com/

6.5.2.2.- CRC en binario:

0011 1010 0010 1000 1100 1000 0100 0010

6.5.2.3.- CRC codificado 4B/5B:

10101 10110 10100 10010 11010 10010 01010 10100

6.5.3.- Fin de trama:

Se genera un stream ESD (End Stream Delimiter) similar al preámbulo, de 1 byte y es como un aviso de fin de trama con los símbolos 4B/5B T y R.

T R

01101 00111

6.6.- Frame 4 lista para transmitir en el cable (con preámbulo y CRC 0x3A28C842):

Detalle: Preamble Layer 2 Layer 3 Payload Data CRC (Layer2) ESD (aviso de fin de trama)

11000 10001 10110 10110 10110 10110 10110 10110 10110 10110 10110 10110 10110 10111 11110 11110 01001 10111 10100 10010 01111 11100

11101 01001 01111 01001 10110 01010 01001 10010 01111 01011 10111 11011 11100 01011 11010 11110 11110 10010 11110 11110 01010 01011

11110 11110 11110 11110 10100 11010 11110 11110 01110 01111 11110 11110 11110 11110 11101 11101 11110 01001 10100 01111 10011 10111

11010 11110 10110 10010 11110 01001 11110 10110 11010 11110 10110 10010 11110 01001 01110 01010 11110 11110 11110 11110 01011 01011

01001 01110 11110 11110 11110 01001 11110 11110 01010 01011 01110 01001 01110 10100 01110 10100 01110 01010 01110 01011 01110 01110

01110 01111 01110 10010 01110 10011 01110 10110 01110 10111 01110 11010 01110 11011 01110 11100 01110 11101 01111 11110 01111 01001

01111 10100 01111 10100 01111 01010 01111 01011 01111 01110 01111 01111 01110 01001 01110 10100 01110 10100 01110 01010 01110 01011

01110 01110 01110 01111 01110 10010 01110 10011 10101 10110 10100 10010 11010 10010 01010 10100 11000 10001

6.7.- Frame 4 lista para transmitir en el cable (sin espacios entre símbolos):

Detalle: Preamble Layer 2 Layer 3 Payload Data CRC (Layer2) ESD (aviso de fin de trama)

110001000110110101101011010110101101011010110101101011010110101101011111110111100100110111101001001001111111001110101001

011110100110110010100100110010011110101110111110111110001011110101111011110100101111011110010100101111110111101111011110

101001101011110111100111001111111101111011110111101110111101111100100110100011111001110111110101111010110100101111001001

111101011011010111101011010010111100100101110010101111011110111101111001011010110100101110111101111011110010011111011110

010100101101110010010111010100011101010001110010100111001011011100111001110011110111010010011101001101110101100111010111

011101101001110110110111011100011101110101111111100111101001011111010001111101000111101010011110101101111011100111101111

011100100101110101000111010100011100101001110010110111001110011100111101110100100111010011101011011010100100101101010010

01010101001100010001

6.8.- Frame 4 y con bits invertidos para poner en cable:

Cuando se reciben datos en serie y se deben “paralelizar” para guardarlos en memoria y procesarlos posteriormente. Quien los transmite primero

debe invertir en espejo el byte, quedando por ejemplo 11001010 en 01010011 para que, al recibirlos y pasarlos por el proceso de SIPO (serial IN

Parallel OUT) queden ordenados. Este proceso se explica en detalle en https://www.vilarrasa.com.ar/sipo_piso.htm

Detalle: Preamble Layer 2 Layer 3 Payload Data CRC (Layer2) (aviso de fin de tramafin de trama)

110001000110110101101011010110101101011010110101101011010110101101011101111011111001011101001010100111110001111011110010

111101001001101010101001001001111101101011101110110011111010010110111101111010010111101111010101101001111011110111101111

001010101101111011110111011110011110111101111011111011110111011111001000101111101100111101010110111101101010010111110010

011110110101011011110110101001011111001001110010100111101111011110111111010110101001001110011110111101111100100111101111

010101101001110100100111000101011100010101110010100111011010011100111001110111100111001001011101100101110011010111011101

011100101101110110110111000111011101011111110011111111010010111100010111110001011111001010111101101011110011101111011110

011101001001110001010111000101011100101001110110100111001110011101111001110010010111011001101011011010100100101101010010

01010101001100010001

Conversión: https://www.browserling.com/tools/reverse-binary

6.9.- Frame 4 en el cable:

Podemos ver los bits yéndose por el cable de red, con la señalización MLT-3 o bipolar, donde un bit 0 no cambia del estado anterior, pero para

un bit 1 cambia de un estado de polaridad a otro.

La codificación se generó en http://www.ee.unb.ca/cgi-bin/tervo/encoding.pl

7.- Proceso de recepción:

Todo el proceso que estudiamos en este lab es el de transmisión de la respuesta de eco desde el switch a la PC, la recepción será similar, pero con

un proceso inverso, digamos en espejo, donde se recibirá y se decodificará la señal del cable, almacenará en un buffer, previa serialización, se calculará

el CRC y si la comprobación es válida, se decodificará el 4B/5B y se desencapsulará cada capa hasta llegar a interpretar que la respuesta de eco fue

exitosa y la aplicación ping nos muestre el resultado en nuestra pantalla.

C:\>ping 192.168.1.10

Haciendo ping a 192.168.1.10 con 32 bytes de datos:

Respuesta desde 192.168.1.10: bytes=32 tiempo=5ms TTL=255 (…pasaron cosas….)

…la magia del networking.

(2023) Dumping my mind in 8 bits

Rosario, Argentina