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
Respuesta desde 192.168.1.10: bytes=32 tiempo=5ms
TTL=255
^C
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