# in-Band research

En este documento vamos a investigar como hizo nuestro querido rumano de confianza la implementación de control in-band en el switch BOFUSS. Recordemos con que repositorios vamos a estar trabajando.

* Switch de boby in-band, `a.k.a` **`in-BOFUSS`**: https://github.com/NETSERV-UAH/in-BOFUSS
* Basic OpenFlow Software Switch, `a.k.a` **`BOFUSS`**: https://github.com/CPqD/ofsoftswitch13

## Un poco de historia :book:

Si queremos la historia más detallada nos podemos ir al papers del switch y listo... :joy_cat: Dejo el link por aqui para los interesados. Aquí vamos a seguir una descripción un poco más breve.

* [The road to BOFUSS: The basic OpenFlow userspace software switch](https://www.sciencedirect.com/science/article/pii/S1084804520301594)

Este switch nació como una primera implementación por el 2008 en la universidad de Stanford, acuñado como: *The Stanford Reference OpenFlow Switch*. Hablando en plata, era un minimo producto viable para demostrar y ayudar en el procesode estandarización del protocolo `Openflow 1.0`. Dicho minimo producto viable, fue retomado por los laboratorios de Ericsson (*Ericsson
Research TrafficLab*) para desarrollar la versión `Openflow 1.1`. Este último desarrollo fue retomado por nuestro compañero Eder, desde Brasil, fue parte de su TFM y PhD, donde completo lo que hoy conocemos como el BOFUSS, el cual da soporte para la versión `Openflow 1.3`. Por último, este switch fue tomado por mi compañero Boby y modificado para hacer una implementación de In-band. En la siguiente figura se puede ver un pequeño resumen de ka historia del switch que vamos a meterle la pezuña.


Enlaces utiles:

* OF 1.0: https://github.com/mininet/openflow
* OF 1.1: https://github.com/TrafficLab/of11softswitch
* OF 1.3: https://github.com/CPqD/ofsoftswitch13
* OF 1.3 + in-band: https://github.com/NETSERV-UAH/in-BOFUSS

Documentación encontrada al respecto:

* TFM-Boby: https://ebuah.uah.es/dspace/handle/10017/46908
* TFM-Villa: https://ebuah.uah.es/dspace/handle/10017/49672
* Tesis-JAH: https://ebuah.uah.es/dspace/handle/10017/50437
* Tesis-Eder: https://www.dca.fee.unicamp.br/~chesteve/thesis/Dissertacao-Eder-SoftSwitch13-20150416.pdf
* Wiki de github: https://github.com/CPqD/ofsoftswitch13/wiki
* Publicación no oficial de Eder: https://www.dca.fee.unicamp.br/~chesteve/pubs/sbrc14-ferramentas-ofsoftswitch13.pdf
* Publicación oficial de eder y compañía: https://www.sciencedirect.com/science/article/pii/S1084804520301594

Cuando mucha gente ha metido la pezuña en un proyecto... malo. Sabes que toca hacer un poco de arquelogía. Nuestro plan es el siguiente:

1. Entender la arquitectura del BOFUSS :ballot_box_with_check:
2. Entender la interfaz del BOFUSS :ballot_box_with_check:
3. Conseguir debuggear al BOFUSS :ballot_box_with_check:
4. Ver los cambios realizados por nuestro amigo Bobys :ballot_box_with_check:
5. Identificar la motivación de los cambios añadidos por boby :ballot_box_with_check:
6. Ver que tenemos que adaptar para tener el in-band en wireless.

## Arqueología I :t-rex: : La arquitectura del BOFUSS

La arquitectura del BOFUSS se puede apreciar en la siguiente figura:


Según se ha podido leer, por el propio creador, está arquitura si bien es cierto que no trara de replicar la especificación al 100%, es la implementación más cercana a la especificación oficial de `OpenFlow 1.3`. Las siguientes sections no siguen ningún grupo lógico de la especificación estandar de OpenFlow, son solo agrupaciones que se han creadido adeacuadas despues de ver y consultar la documentación oficial del BOFUSS y relacionados.

Como se puede ver en la figura anterior, el software switch se compone de dos bloques fundamentales.

* Plano de datos, `a.k.a` **`Datapath`**, en la herramienta al plano de datos lo podemos encontrar como `udatapath/ofdatapath`.
* Plano de control, `a.k.a` **`Control plane`**, en la herramienta al plano de control lo podemos encontrar como `secchan/ofprotocol`.

El primero de ellos, el `udatapath/ofdatapath` se caracteriza por ser el bloque funcional de gestionar el procesamiento de los paquetes datos, y en ocariones de control (en función del paradigma de control). Dentro de este bloque funcional se pueden encontrar elementos internos como por ejemplo, los puertos, conocidos como `Port`, los `Flow`, `Meter`, `Group`, `Table` y el `Packet Parser`. El bloque del agente de control, es el encargado de gestionar la información de control entre el controlador y el dispositivo. Los mensajes de Openflow viajarán desde el plano de secure channel, a la librería de de oflib, y de ahí al datapath para instanciar en las tablas de flujos correspondientes. Más adelante se explican en detalle cada bloque de la arquitectura.

### Ports

Los puertos OpenFlow desempeñan un papel fundamental como puntos de entrada y salida para los paquetes de datos en un entorno OpenFlow. Cuando se ejecuta un software switch en una máquina, puede utilizar interfaces físicas o virtuales como sus puertos (interfaces físicas o virtuales como veths o también radio taps emulados). Los puertos físicos permiten el control de interfaces Ethernet o **WiFi**, lo que facilita la gestion de tanto topologías de red realistas como emuladas. Aunque la velocidad del software switch puede ser limitada dado que trabaja en espacio de usuario, la posibilidad de crear un entorno de pruebas boostea la experiencia de los usuarios que desarrollan y evalúan aplicaciones OpenFlow. Se podría pensar que los puertos del switch se limitan simplemente a enviar y recibir paquetes de red. ERROR. También tienen una serie de mini-responsabilidades realcionadas con la gestión del protocolo openflow. Estas responsabilidades se pueden resumir:

* OpenFlow permite cierto nivel de control sobre el comportamiento que tiene que tener un puerto en particular. Si se recibe un mensaje de modificación de puerto, este tiene que permitir configurar el estado del puerto. Los puertos pueden configurarse para que droppen todos los paquetes recibidos, prohíban la generación de mensajes de tipo openflow `Packet In` a partir de los paquetes que llegan, además de marcar el estado del pueblo como fuera de servicio. El agente que gestione el puerto deben gestionar estos mensajes de configuración que le lleguen, y cambiar el comportamiento del puerto según la configuración recibida.
* Los puertos Openflow tienen que llevar un monitoreo del estado de la interfaz física o emulada que gestionan. Si bien es cierto que el controlador no puede actuar sobre el estado real de la interfaz, el switch tiene que informar sobre los cambios de estado del enlace.
* Generalmente cuando se lleva a cabo un `Packet-In` por que hay un miss, solo se manda al controlador las cebeceras del mensaje a consultar junto al propio mensaje del `Packet-In`. Los puertos, durante dicha consulta tendrán que gestionar los buffers que almacenarán los paquetes a consultar para ser procesados más tarde.
* El controlador a través del agente de control, también puede consultar sobre la descripción de un puerto.Por tsnto, el software switch tendrá que recolectar la información que onsidere oporturna como por ejemplo la velocidad actual y máxima de las interfaces reales, almacenarla para enviarla posteriormente cuando el controlador se lo requiera.
* Las colas según hemos podido consultar no son parte de la definición estandar de Openflow. SIn embargo, Openflow puede confirgurar colas asociadas a unos puertos dados. Los puertos por tanto tendrán la responsabilidad de llevar a cabo la asociación de configuración de cola y asociación de cola con un puerto además de actulizar los contadores de paquetes de puerto y cola asociada.

Ficheros relacionados a consultar:

[udapath/dp_ports.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/dp_ports.h)
[udapath/dp_ports.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/dp_ports.c)
[udapath/dp_buffers.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/dp_buffers.h)
[udapath/dp_buffers.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/dp_buffers.c)
[lib/netdev.h](https://github.com/CPqD/ofsoftswitch13/blob/master/lib/netdev.h)
[lib/netdev.c](https://github.com/CPqD/ofsoftswitch13/blob/master/lib/netdev.c)

### Packet Parser

Antes que el paquete en cuestión llegue a la pipeline de procesamiento del software switch, este debe ser parseado para adaptarlo a las estructuras de datos que se manejan en el switch. Para ello, el cómo se tiene que parsear los paquetes se definió en el estandar de `OpenFlow 1.1`. Esto es importante, ya que debe haber consistencia en como los paquetes deben ser paserados, pero esto a su vez supuso una limitación para nuevos diseños de switches, y supone modificaciones cada vez que se añade un nuevo protocolo. Por ello, más adelante con especificaciones posteriores del protocolo esta limitación se vio eleiminada. Nuestro parser quetenemos en el BOFUSS hace uso de **NetBee** coomo disector y parseador de paquetes. Una vez que se han identificado los campos de protocolo que contiene el paquete, se crea una estructura de matching con la cual se atacará a la pipeline de procesamiento del switch.

Este proceso anteriormente descrito se puede dar en dos ocasiones.

* Que el paquete de red entre por uno de los puertos gestionados por el software switch.
* Que un paquete que ya ha sido modificado y redirigido por la pipeline de procesamiento, o enviado a una nueva tabla de adelante con la instrucción de *Go To Table*.

Esto es así dado que una revalidación del paquete es necesaria, y el parsear tambien se encarga de comprobar la valided del TTL. Además de añadir información de metadatos al mismo. Cada vez que se quiera dar soporte a nuevos protocolos, se tendrá que modificar el parsing del switch. Para ello, se tiene que llevar modificaciones a cabo en el fichero `*.xml` en lenguaje NetPDL. NetPDL es un lenguaje de descripción que describe cómo Netbee debe analizar los protocolos.


Ficheros relacionados a consultar:

[udatapath/packet_handle_std.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/packet_handle_std.h)
[udatapath/packet_handle_std.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/packet_handle_std.c)
[udapath/packet.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/packet.h)
[udapath/packet.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/packet.c)
[nbee_link/nbee_link.h](https://github.com/CPqD/ofsoftswitch13/blob/master/nbee_link/nbee_link.h)
[nbee_link/nbee_link.cpp](https://github.com/CPqD/ofsoftswitch13/blob/master/nbee_link/nbee_link.cpp)

Fichero NetPDL importante que describe el parsing
[customnetpdl.xml](https://github.com/CPqD/ofsoftswitch13/blob/master/customnetpdl.xml)

### Flow Tables

Las `Flow Tables` son el core de procesamiento del software switch. Las flow tables siempre son el siguiente paso despues del procesamiento y podrían considerarse el corazón del entorno openflow dado que son el primer componente en la pipeline de procesamiento del switch. Aunque el uso de multiples tablas de flujos es opcional, la especififcaión indica que se utilice al menos una tabla, a la hora de la implementación se considera más que recomendado dado que inviable el hecho de gestionar el escalado de una apliación con unicamente solo una tabla de flujo.

En pocas palabras podríamos definir una `Flow Table` como una lista de flujos, donde cada flujo se compone de unos campos de matching y de unas intrucciones asocidas en caso de que haya match. Instrucciones que como se indican, tienen que estár definidas previamente en la especificación de Openflow. Una vez el paquete se ha validado y se ha parseado en una estructura de matching, se comprueba con una entrada de un flujo con el campo de matching, en caso de coincida con dicho flujo, las instrucciones asociadas se ejecutan.

A continuación se indican algunos de los aspectos que tienen que cumplir las tablas de flujo.

- La implementación de una tabla de `miss` es obligatoria, ya que el switch tiene que hacer algo con los paquetes los cuales no matchean con ninguna flow entry. Por el contrario, si no se implementa ninguna tabla de `miss`, se tiene que establecer una action por defecto. En el caso del switch se ha establecido que se tiren los paquetes.
- Otro aspecto a considerar, el cual, tiene que ser gestionado por las `Flow table` es la gestión de los paquetes `Flow-Mod`. Estos mensjaes son generados desde el controlador y gestionados por el agente de control del switch para creación o eliminación de entradas de flujo en alguna `Flow Table`.
- El switch debe permitir al controlador de reconfigurar sus prestaciones. Es decir, las propiedades de las tablas deben ser conocidad por el controlador, y las tablas deben en todo modomento responder a los mensajes de consulta de features.
- Por cada paquete del plano de datos que les lleguen, deben llevar a cabo un *look up*, es decir, consultar si el paquete entrante de datos coincide con algún campo de match de algún flujo de la tabla. En caso de que exista algún match, se ejecutará la instrucción asociada.
- Otro aspecto-tarea, a llevar a cabo por el switch, es llevar el recuento de las estadisticas de las entradas activas, los *look ups* realizados, y paquetes que han hecho match.

En cuanto aspectos de implementación, podemos destacar, las reglas se indexan en la tablas de flujos en orden de prioridad, si tienen la misma prioridad, se indexarán en orden de llegada. En cuanto a la complejidad del tiempo de *look up*, es lineal es decir `O(n)`, donde `n` es el número de flujos. Esto no es muy eficiente dado que crece de forma lineal según el número de flujos aumenta. Aunque según ha indicado el autor, es suficiente para llevar prueas de concepto. Otro detealle de implementación, que tenemos que tener en cuenta es el numero de entras de flujos por tabla de flujos, actualmente esta definido a 64 por una macro. Si se quisiera cambiar este param solo habría que cambiar la macro y recompilar el proyecto. Por útlimo, mencionar que las tablas de flujos tienen una lista de *idle* y *hard timeout*. Las tablas comprueban cada 100ms si alguna de sus entradas de flujos han expirado.

Ficheros relacionados a consultar:

[udatapath/pipeline.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/pipeline.h)
[udatapath/pipeline.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/pipeline.c)
[udatapath/std_match.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/std_match.h)
[udatapath/std_match.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/std_match.c)
[udatapath/dp_actions.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/dp_actions.h)
[udatapath/dp_actions.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/dp_actions.c)
[udatapath/action_set.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/action_set.h)
[udatapath/action_set.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/action_set.c)
[udatapath/flow_entry.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/flow_entry.h)
[udatapath/flow_entry.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/flow_entry.c)
[udatapath/flow_table.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/flow_table.h)
[udatapath/flow_table.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/flow_table.c)

### Group Table

Tampoco voy ahondar mucho en esta section dado que no las vamos a utilizar. Las `Group Tables`, se utilizan para agregar flow entries que tienen una politica de acción similar. Una vez agregadas llevan a cabo una serie de acciones. Para ello, desde las flow tables se les asigna una identifiacodr de tabla de grupo. Con dicha ID van a una entrada de una tabla de grupo y se lleva a cabo una acción. Estas entraadas tambien tienen contadores para llevar un conteo de los matches que ha habido.


Ficheros relacionados a consultar:

[udatapath/group_entry.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/group_entry.h)
[udatapath/group_entry.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/group_entry.c)
[udatapath/group_table.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/group_table.h)
[udatapath/group_table.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/group_table.c)

### Meter Table

La `Meter Table` es el core del QoS del software switch. Para cada flujo se tienen unas meter asociadas en la propia entrada en la tabla de flujo. Dichas meters, tienen una entrada en la meter table. Cada entrada se compone de una ID, un contador, y unas meter bands. Estas últimas, las meters-bands son las encargadas de de llevar a cabo las operaciones de QoS. Cada Meter-band debe tener un tipo, un ratio, el cual será el limite que tiene que superarse para aplicar la action definida por el tipo de la meter. A cotninuación, se indica una figura que ilustra la arquitectura de una Meter table.


Entre las responsabilidades de las meter tables podemos encontrarnos las siguientes:

- Creación, destrucción y modificación de las entradas de las meters
- Medir el ratio de aquellos maqutees que han matchado en una flow entry, y apuntan a una meter table.
- mantener actualizado los contadores de las estadisticas de los paquetes procesados por cada entarda en la meter table.

Ficheros relacionados a consultar:

[udatapath/meter_entry.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/flow_entry.h)
[udatapath/meter_entry.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/meter_entry.c)
[udatapath/meter_table.h](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/meter_table.h)
[udatapath/meter_table.c](https://github.com/CPqD/ofsoftswitch13/blob/master/udatapath/meter_table.c)

### `oflib` (Marshaling/Unmarshaling library)

Los mensajes de OpenFlow están definidos, de una manera en particular para ser transmitidos por la red. Los mensajes tienen que estar en modo 8-byte alineados, por lo que habrá alguna ocasión donde se tenga que añadir padding para que se cumpla esta regla. Otro requisito es que el mensaje tiene que estar en Network byte order, `a.k.a` Big Endian. Los mensajes OpenFlow que se mandan por la red tienen que estar en el formato indicado anteriormente, es decir, el byte de mayor peso de una palabra tiene que estar almacenado en la posción más pequeña (dir más baja).

Las arquitecturas de cada máquina pueden variar, y el formato de datos con en el que trabajan tambien. Por ejemplo para ARM e Intel el formato con el cual trabajan ambas arquitecturas es Little Endian byte order. Por ello, en arás de manejar y codificar mensajes openflow re qrequiere una conversión big-endian a little-endian.


Debido a cual, se necesita una capa de abstración de la arquitectura donde se vaya a correr dicho software switch. Por ello, aunque el estandar de Openflow no lo indique se ha añadido esta librería denominada como `Oflib`. La función principal de esta librería es las operacioens de *Marshaling*/*Unmarshaling*. para que la transmisión de información de mensajes OPenflow a la red se completamente autonoma. Las responsabilidades de esta librería son las siguientes:

- Cada mensaje openflow debe tener una función para empaquetarlo y despaquetarlo. De aqui en adelante, y en el repositorio, nos referimos a hacer un *pack* es coger una estructura de datos openflow y prepararla para ser transmitida por la red. Cuando realziamos una operación de *unpack*, cogemos info que viene por la red, y la convertimos a estructuras que entienda la arquitectura sobre la cual está corriendo nuestro software switch.
- Otra esponsabilidad que tiene la librería es señalar con errores o warnings en caso de los mensajes Openflow estén mal codificados.

Ficheros relacionados a consultar:

[oflib](https://github.com/CPqD/ofsoftswitch13/tree/master/oflib)

### Communication Channel

El software switch se comuniaca con el controlador SDN a través de este agente de control que acuta de proxy como proxy entre el datapath y el controlador SDN. Este agente se encarga de gestionar las conexiones con el controlador SDN, aunque, si bien es cierto que este agente no está pactado en el estandar de Openflow, esto da libertad a las diferentes implementaciones para configurar la conexion hacia al controlador como quieran. Por ejemplo, si se quiere que la conexión sea segura extremo a extremo, se tendría que utilizar TLS encima de TCP.

Entre las responsabilidades de esta capa podemos mencionar las siguientes.

- El agente de control se tiene que encargar de abrir una conexión TCP conentre el switch y el controlador.
- El establecimiento de la conexión es responsabilidad del agente de control. Despues del inicio de la conexión, el switch negocia la versión Openflow a utilizarentre el switch y el controlador. Este proceso se conoce como handshake.
- El agente de control debe soportar más de un controlador.
- Además, el agente de control debe soportar más de una conexión con el mismo controlador.

Ficheros relacionados a consultar:

[secchan](https://github.com/CPqD/ofsoftswitch13/tree/master/secchan)

## Arqueología II :t-rex: : El interfaz del BOFUSS

La interfaz del BOFUSS se puede dividir en dos binarios claramente diferenciados. El primero de ellos, `ofprotocol` y el `ofdatapath`.

### Binario **`ofprotocol`**

El binario de `ofprotocol` establece un canal seguro de comuniación entre el datapath OPenFlow y el controlador remoto. Este conecta con el datapath mediante Netlink o TCP, y con el controlador remoto mediante TCP o SSL, actuando de proxy entre los dos mundos.

 ofprotocol [options] datapath controller[,controller...]

Uno de los parametros obligatorios es el datapath a gestionar. Este se puede indicar de las siguientes formas:

* `unix:file` se indica un descriptor de un socket UNIX el cual es el mismo indicado por el `ofdatapath`. Mediante este socket unix se comuniacarán datapath y plano de control.
* `tcp:HOST[:PORT]` En este caso se puede conectar tambien en red mediante puerto y dirección IP. Este caso se usa cuando se quiere tener separado en máquinas diferentes datapath y agente de control. Puerto por defecto, 6653.

En cambio el parametro del controlador es opcional, y solo soporta conexiones TCP. Para la conexión con el controlador se contemplan dos formas diferenciadas para la conexión del controlador.

* **out-of-band**: con esta configuración el tráfico OpenFlow utiliza una red privada para comunicarse con el controlador.
* **in-band**: con esta configuración el tráfico OpenFlow viaja por la misma red que la red de datos. Esta opción, es la opción por defecto.

Para configurar el control in-band manualmente se tiene que especificar la ubicación del controlador a la hora de ofprotocol. También se debe configurar la interfaz de red como el puerto local OpenFlow para permitir que ofprotocol se conecte el controlador.

El puerto local OpenFlow es un puerto de red virtual que ofprotocol conecta a los puertos físicos del conmutador. El nombre del dispositivo de red del puerto local puede especificarse en la línea de comandos ofdatapath, utilizando la opción --local-port. A menudo es tap0.

### Binario **`ofdatapath`**

La herramienta de `ofdatapath` es una implementación de espacio de usuario para una datapath OpenFlow. Este monitorea una o más interfaces de red, las cuales reenviarán paquetes este ellas de acuerto a la politica de reenvio descrita en las tablas de flujos.

ofdatapath [options] -i netdev[,netdev]...  method [method]... 

Cuando este binario se usa junto al binario `ofprotocol`, se conforma lo que se conoce como BOFUSS (Basic OpenFlow Software Switch).

Para el acceso a las interfaces de red, el binario normalmente tiene que correr como root. Otro detalle a tener en cuenta es como los binarios se van a comunicar entre si, normalmente se lleva a cabo mediante un socket UNIX, pero tambien se puede llevar a cabo mediante una conexión TCP para llevara a cabo una conexión pasiva.

* `punix:file`, escucha por una conexión en el descriptor del socket UNIX indicado
* `ptcp:[port]`, escucha por conexiones TCP en el puerto por defecto ~~975~~ **6653**.

Esto de puerto por defecto el 975 es más falso que una moneda de tres euros. Prueba rápida:



A pastar perro sanche :joy_cat: además dejo por aquí el link del puerto en cuestión donde se define.

https://github.com/CPqD/ofsoftswitch13/blob/master/include/openflow/openflow.h#LL75C1-L75C27

Sigamos con los parametros de configuración del software switch. Uno de los más importantes, es indicar los puertos a gestionar el switch. Es decir, que interfaces va a manejar.

* `-i, --interfaces=netdev[,netdev]` Con este comando indicamos cada puerto que tendrá el switch. Cada interfaz se le asiganará un número de puerto. Otro, detalle a tener en cuenta es que las interfaces no pueden tener IPs.
* `-L, --local-port=netdev`, Con este comando indicamos el puerto local que tendrá el switch el cual será la interfaz física o virtual, que se usará para el control in-band. Cuando está opción no está indicada, por defecto, se creará una interfaz de tipo tap, `tap0` o algo así, la cual se utilizará para el control del software switch. Si no se quiere dejar como responsabilidad al Kernel la de asignar un nombre a la interfaz tap, se puede indicar como `--local-port=tap:name`. Se crea [aquí](https://github.com/CPqD/ofsoftswitch13/blob/master/lib/netdev.c#L705). Para más información sobre las interfaces tun/tap, ver el anexo X.
* `--no-local-port`, se le indica al software switch que no va a utilizar un puerto local, ergo, no podremos trabajar en modo in-band.
* `--no-slicing`, se utiliza para deshabilitar la configuración de las colas asociadas a los puertos. Por ello, cadatendrá un total de 0 colas. Esta opción se suele utilizar cuando algunas de las configuraciones de colas (tc y kernel) no se encuentran disponibles. (Mininet y MIninet-wifi corre el BOFUSS con esta opción por defecto)
* `-d, --datapath-id=dpid`, Especifica el Datapath ID Openflow, conocido como `dpid`. Es un identificador del datapath de 16 digitos hexadecimales. Si no se especifica, el `ofdatapath` pilla uno aleatorio.

## Arqueología III :t-rex: : Debug al BOFUSS

Recordemos nuestro escenario. Vamos a trabajar con MIninet-Wifi, redes inlambricas, ergo, ya no podemos hacer como Boby de pillar shell scripts y ponernos hacer Network Namespaces y veths como enfermos... entonces, que nos toca? Trabajar codo con codo con Mininet-Wifi.

Ahora bien, puede complicarse bastante asi que vamos hacer una primera aproximación, vamos a ejecutar el código de una topología sencilla en modo debug para ver los comandos que se lanzan y despues ya vemos como pasarlo a un shell scripts. Nuestras herramientas de trabajo serán las siguientes:

* VS Code
* Mininet-WiFi
* WIreshark
* GDB

El script de topología de mininet-wifi a correr es el mismo que se indicó en la section anterior. A continuación se indica la traza.

*** errRun: ['grep', '-c', 'processor', '/proc/cpuinfo'] 
4
  0*** Setting resource limits
*** Creating nodes
*** Add Controller (Ryu) ***
*** errRun: ['which', 'mnexec'] 
/usr/bin/mnexec
  0*** errRun: ['which', 'ifconfig'] 
/usr/sbin/ifconfig
  0_popen ['mnexec', '-cd', 'env', 'PS1=\x7f', 'bash', '--norc', '--noediting', '-is', 'mininet:c0'] 43743*** c0 : ('unset HISTFILE; stty -echo; set +m',)
unset HISTFILE; stty -echo; set +m
*** c0 : ('echo A | telnet -e A localhost 6633',)
Telnet escape character is 'A'.
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Unable to contact the remote controller at localhost:6633
*** Add one UserAP ***
*** errRun: ['which', 'mnexec'] 
/usr/bin/mnexec
  0*** errRun: ['which', 'ip', 'addr'] 
/usr/sbin/ip
  1_popen ['mnexec', '-cd', 'env', 'PS1=\x7f', 'bash', '--norc', '--noediting', '-is', 'mininet:ap1'] 43749*** ap1 : ('unset HISTFILE; stty -echo; set +m',)
unset HISTFILE; stty -echo; set +m

added intf lo (0) to node ap1
*** ap1 : ('ifconfig', 'lo', 'up')
*** errRun: ['which', 'ofdatapath'] 
/usr/local/bin/ofdatapath
  0*** errRun: ['which', 'ofprotocol'] 
/usr/local/bin/ofprotocol
  0*** Add two WiFi stations ***
*** errRun: ['which', 'mnexec'] 
/usr/bin/mnexec
  0*** errRun: ['which', 'ip', 'addr'] 
/usr/sbin/ip
  1_popen ['mnexec', '-cdn', 'env', 'PS1=\x7f', 'bash', '--norc', '--noediting', '-is', 'mininet:sta1'] 43756*** sta1 : ('unset HISTFILE; stty -echo; set +m',)
unset HISTFILE; stty -echo; set +m
_popen ['mnexec', '-cdn', 'env', 'PS1=\x7f', 'bash', '--norc', '--noediting', '-is', 'mininet:sta2'] 43758*** sta2 : ('unset HISTFILE; stty -echo; set +m',)
unset HISTFILE; stty -echo; set +m
*** Configuring nodes
Loading 3 virtual wifi interfaces
Created mac80211_hwsim device with ID 0
Created mac80211_hwsim device with ID 1
Created mac80211_hwsim device with ID 2
rfkill unblock 2
*** sta1 : ('ip link set wlan0 down',)
*** sta1 : ('ip link set wlan0 name sta1-wlan0',)
rfkill unblock 3
*** sta2 : ('ip link set wlan1 down',)
*** sta2 : ('ip link set wlan1 name sta2-wlan0',)
*** ap1 : ('ip link set wlan2 down',)
*** ap1 : ('ip link set wlan2 name ap1-wlan1',)
*** ap1 : ('ip link set ap1-wlan1 up',)

added intf sta1-wlan0 (0) to node sta1
*** sta1 : ('ip link set', 'sta1-wlan0', 'down')
*** sta1 : ('ip link set', 'sta1-wlan0', 'address', '00:00:00:00:00:02')
*** sta1 : ('ip link set', 'sta1-wlan0', 'up')
*** sta1 : ('ip addr flush ', 'sta1-wlan0')
*** sta1 : ('ip addr add 10.0.0.1/8 brd + dev sta1-wlan0 && ip -6 addr add 2001:0:0:0:0:0:0:1/64 dev sta1-wlan0',)
*** sta1 : ('ip -6 addr flush ', 'sta1-wlan0')
*** sta1 : ('ip -6 addr add', '2001:0:0:0:0:0:0:1/64', 'dev', 'sta1-wlan0')
*** sta1 : ('ip link set lo up',)

added intf sta2-wlan0 (0) to node sta2
*** sta2 : ('ip link set', 'sta2-wlan0', 'down')
*** sta2 : ('ip link set', 'sta2-wlan0', 'address', '00:00:00:00:00:03')
*** sta2 : ('ip link set', 'sta2-wlan0', 'up')
*** sta2 : ('ip addr flush ', 'sta2-wlan0')
*** sta2 : ('ip addr add 10.0.0.2/8 brd + dev sta2-wlan0 && ip -6 addr add 2001:0:0:0:0:0:0:2/64 dev sta2-wlan0',)
*** sta2 : ('ip -6 addr flush ', 'sta2-wlan0')
*** sta2 : ('ip -6 addr add', '2001:0:0:0:0:0:0:2/64', 'dev', 'sta2-wlan0')
*** sta2 : ('ip link set lo up',)

added intf ap1-wlan1 (1) to node ap1
*** ap1 : ('ip link set', 'ap1-wlan1', 'up')
*** ap1 : ('ethtool -K', <WirelessLink ap1-wlan1>, 'gro', 'off')
*** ap1 : ('ip link set', 'ap1-wlan1', 'down')
*** ap1 : ('ip link set', 'ap1-wlan1', 'address', '00:00:00:00:00:01')
*** ap1 : ('ip link set', 'ap1-wlan1', 'up')
*** sta1 : ('iw dev', 'sta1-wlan0 set txpower fixed 100')
*** sta1-wlan0: the signal range should be changed to (at least) 116m
*** >>> See https://mininet-wifi.github.io/faq/#q7 for more information
*** sta2 : ('iw dev', 'sta2-wlan0 set txpower fixed 100')
*** sta2-wlan0: the signal range should be changed to (at least) 116m
*** >>> See https://mininet-wifi.github.io/faq/#q7 for more information
*** ap1 : ('iw dev', 'ap1-wlan1 set txpower fixed 100')
*** ap1-wlan1: the signal range should be changed to (at least) 116m
*** >>> See https://mininet-wifi.github.io/faq/#q7 for more information
*** ap1 : ("echo 'interface=ap1-wlan1\ndriver=nl80211\nssid=new-ssid\nwds_sta=1\nhw_mode=g\nchannel=1\nctrl_interface=/var/run/hostapd\nctrl_interface_group=0' > mn43736_ap1-wlan1.apconf",)
> > > > > > > *** ap1 : ('hostapd -B mn43736_ap1-wlan1.apconf ',)
ap1-wlan1: interface state UNINITIALIZED->ENABLED
ap1-wlan1: AP-ENABLED 
*** ap1 : ('ip link set', 'ap1-wlan1', 'down')
*** ap1 : ('ip link set', 'ap1-wlan1', 'address', '00:00:00:00:00:01')
*** ap1 : ('ip link set', 'ap1-wlan1', 'up')
_popen ['mnexec', '-da', '43749', 'tc', 'qdisc', 'replace', 'dev', 'ap1-wlan1', 'root', 'handle', '2:', 'netem', 'rate', '54.0000mbit', 'latency', '1.00ms'] 43921*** ap1 : ('tc qdisc add dev ap1-wlan1 parent 2:1 handle 10: pfifo limit 1000',)
*** sta1 : ('iw dev', 'sta1-wlan0 set txpower fixed 100')
*** sta2 : ('iw dev', 'sta2-wlan0 set txpower fixed 100')
*** ap1 : ('iw dev', 'ap1-wlan1 set txpower fixed 100')
*** Add links ***

added intf sta1-wlan0 (0) to node sta1
*** sta1 : ('ip link set', 'sta1-wlan0', 'up')
*** sta1 : ('ethtool -K', <WirelessLink sta1-wlan0>, 'gro', 'off')
 *** executing command: tc qdisc show dev sta1-wlan0
*** sta1 : ('tc qdisc show dev sta1-wlan0',)
qdisc mq 0: root 
qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
at map stage w/cmds: ['%s qdisc add dev %s root handle 5:0 htb default 1', '%s class add dev %s parent 5:0 classid 5:1 htb rate 11.000000Mbit burst 15k']
 *** executing command: tc qdisc add dev sta1-wlan0 root handle 5:0 htb default 1
*** sta1 : ('tc qdisc add dev sta1-wlan0 root handle 5:0 htb default 1',)
 *** executing command: tc class add dev sta1-wlan0 parent 5:0 classid 5:1 htb rate 11.000000Mbit burst 15k
*** sta1 : ('tc class add dev sta1-wlan0 parent 5:0 classid 5:1 htb rate 11.000000Mbit burst 15k',)
cmds: ['%s qdisc add dev %s root handle 5:0 htb default 1', '%s class add dev %s parent 5:0 classid 5:1 htb rate 11.000000Mbit burst 15k'] 
outputs: ['', ''] 
_popen ['mnexec', '-da', '43756', 'iwconfig', 'sta1-wlan0', 'essid', 'new-ssid', 'ap', '00:00:00:00:00:01'] 43933_popen ['mnexec', '-da', '43756', 'tc', 'qdisc', 'replace', 'dev', 'sta1-wlan0', 'root', 'handle', '2:', 'netem', 'rate', '8.0307mbit', 'latency', '1.58ms'] 43934
added intf sta2-wlan0 (0) to node sta2
*** sta2 : ('ip link set', 'sta2-wlan0', 'up')
*** sta2 : ('ethtool -K', <WirelessLink sta2-wlan0>, 'gro', 'off')
 *** executing command: tc qdisc show dev sta2-wlan0
*** sta2 : ('tc qdisc show dev sta2-wlan0',)
qdisc mq 0: root 
qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
at map stage w/cmds: ['%s qdisc add dev %s root handle 5:0 htb default 1', '%s class add dev %s parent 5:0 classid 5:1 htb rate 11.000000Mbit burst 15k']
 *** executing command: tc qdisc add dev sta2-wlan0 root handle 5:0 htb default 1
*** sta2 : ('tc qdisc add dev sta2-wlan0 root handle 5:0 htb default 1',)
 *** executing command: tc class add dev sta2-wlan0 parent 5:0 classid 5:1 htb rate 11.000000Mbit burst 15k
*** sta2 : ('tc class add dev sta2-wlan0 parent 5:0 classid 5:1 htb rate 11.000000Mbit burst 15k',)
cmds: ['%s qdisc add dev %s root handle 5:0 htb default 1', '%s class add dev %s parent 5:0 classid 5:1 htb rate 11.000000Mbit burst 15k'] 
outputs: ['', ''] 
_popen ['mnexec', '-da', '43758', 'iwconfig', 'sta2-wlan0', 'essid', 'new-ssid', 'ap', '00:00:00:00:00:01'] 43940_popen ['mnexec', '-da', '43758', 'tc', 'qdisc', 'replace', 'dev', 'sta2-wlan0', 'root', 'handle', '2:', 'netem', 'rate', '8.0307mbit', 'latency', '1.58ms'] 43941*** Plot he network ***

*** Build it ***
*** Configuring nodes
Enabling Graph...
_popen ['mnexec', '-da', '43756', 'tc', 'qdisc', 'replace', 'dev', 'sta1-wlan0', 'root', 'handle', '2:', 'netem', 'rate', '8.0307mbit', 'latency', '1.58ms'] 43943_popen ['mnexec', '-da', '43758', 'tc', 'qdisc', 'replace', 'dev', 'sta2-wlan0', 'root', 'handle', '2:', 'netem', 'rate', '8.0307mbit', 'latency', '1.58ms'] 43944
added intf sta1-wlan0 (0) to node sta1
*** sta1 : ('ip link set', 'sta1-wlan0', 'up')
*** sta1 : ('ethtool -K', <WirelessLink sta1-wlan0>, 'gro', 'off')

added intf sta2-wlan0 (0) to node sta2
*** sta2 : ('ip link set', 'sta2-wlan0', 'up')
*** sta2 : ('ethtool -K', <WirelessLink sta2-wlan0>, 'gro', 'off')
*** Start the controller ***
*** Set controllers ***
*** ap1 : ('ofdatapath -i ap1-wlan1 punix:/tmp/ap1 -d 100000000001 --no-slicing 1> /tmp/ap1-ofd.log 2> /tmp/ap1-ofd.log &',)
*** ap1 : ('ofprotocol unix:/tmp/ap1 tcp:localhost:6633 --fail=closed  --listen=punix:/tmp/ap1.listen 1> /tmp/ap1-ofp.log 2>/tmp/ap1-ofp.log &',)
*** RUN Mininet-Wifis CLI ***
*** Starting CLI:
*** errRun: ['stty', 'echo', 'sane', 'intr', '^C'] 

Podemos apreciar la topología generada es la siguiente:


Lo que vamos hacer es limpiar la traza para hacer un script sin comentarios y demás. Para el script de limpieza debería funcionar ejecutar un simple:

El script de `clean.sh`:

sudo mn -c

He estado haciendo pruebas lanzando los comandos a mano para levantar de forma individual la interfaz wireless para el ap1, y hemos visto que efectivamente, el comando anterior se encarga de limpiar todas las configuraciones que lanzamos con nuestro shell script. Por qué? En este caso hay que felicitar a Ramon fontes, lee del path:

/sys/kernel/debug/ieee80211

Listan todas las interfaces, y se las cargan :smile_cat:. Dejo por aquí el punto de mininet-wifi, donde gestión la limpieza de las interfaces.

* https://github.com/intrig-unicamp/mininet-wifi/blob/master/mn_wifi/clean.py#L77

Como se puede ver cuando se lanza el escenario `topo.py`, y nuestro script paralelo, al listar las interfaces podemos ver lo siguiente:


Como se puede ver con el comando que se lanza desde el modulo de limpieza de mininet-wifi lista nuestra phy, y por ende, será capaz de limpiarla a posteriori.

El script de `lauch.sh`:

Para el script de lanzamiento de nuestro UserAP, hemos ido investigando las trazas de ejecución de un software switch de UserAP, y desde ahí hemos aislado los comandos utilizados. Nos hemos fijado en las trazas que la creación de radios emuladas se gestionan llamando a la herramienta `hwsim_mgmt`. Desde Mininet-wifi, se crean en este punto del source code:

* https://github.com/intrig-unicamp/mininet-wifi/blob/master/mn_wifi/module.py

Hemos visto que para crear una radio emulada, se tiene que llamar a la herrmaienta de la siguiente forma:

sudo hwsim_mgmt -c -n [phy_name]

Para eliminarlas, se llama a la misma herramienta, de la siguiente manera:

sudo hwsim_mgmt -x [phy_name]

Es necesario que para trabajar con la herramienta, `hwsim_mgmt`, que el modulo del kernel `mac80211_hwsim` esté cargado, si no lo está, no podremos crear ninguna radio nueva. Pero como en nuestro caso, vamos a lanzar primero el script `topo.py` el cual ya cargará el modulo, no será necesario tener que cargarlo. Si creamos una interfaz con el modulo ya cargado podemos comprobar que se ha creado un nuevo radio de la siguiente forma:

iw dev

En nuestro caso:


Teniendo esto claro, podemos seguir con la creación del script de `launch.sh`.

#!/bin/bash

# Vars
AP_SSID='new-ssid'
AP_MAC='00:00:00:00:00:01'
STA_2_CONN=('sta1' 'sta2')

# Create UserAP
echo '[+] Lanch UserAP config'
hwsim_mgmt -c -n intfUserAP
ip link set wlan0 down
ip link set wlan0  name ap1-wlan1
ip link set ap1-wlan1 down 
ip link set ap1-wlan1 up
ethtool -K ap1-wlan1 gro off 
ip link set ap1-wlan1 down 
ip link set ap1-wlan1 address ${AP_MAC}
ip link set ap1-wlan1 up
iw ap1-wlan1 set txpower fixed 100
echo -e "interface=ap1-wlan1\ndriver=nl80211\nssid=${AP_SSID}\nwds_sta=1\nhw_mode=g\nchannel=1\nctrl_interface=/var/run/hostapd\nctrl_interface_group=0" > mn43736_ap1-wlan1.apconf
hostapd -B mn43736_ap1-wlan1.apconf
ip link set ap1-wlan1 down 
ip link set ap1-wlan1 address ${AP_MAC}
ip link set ap1-wlan1 up
tc qdisc replace dev ap1-wlan1 root handle 2: netem rate 54.0000mbit latency 1.00ms
tc qdisc add dev ap1-wlan1 parent 2:1 handle 10: pfifo limit 1000
iw dev ap1-wlan1 set txpower fixed 1400
ofdatapath -i ap1-wlan1 punix:/tmp/ap1 -d 100000000001 --no-slicing 1> /tmp/ap1-ofd.log 2> /tmp/ap1-ofd.log &
ofprotocol unix:/tmp/ap1 tcp:localhost:6633 --fail=closed  --listen=punix:/tmp/ap1.listen 1> /tmp/ap1-ofp.log 2>/tmp/ap1-ofp.log &

# Connect stations to AP
for sta in ${STA_2_CONN[@]}
do
    echo "[+] Connecting ${sta} to UserAP"
    PID_STA=$(ps aux | grep mininet | grep ${sta} | cut -d' ' -f7)
    echo "[+] ${sta} - Detected pid ${PID_STA}"
    nsenter --target ${PID_STA} --net iwconfig ${sta}-wlan0 essid ${AP_SSID} ap ${AP_MAC}
done

Como se puede ver, primero configuramos lo que viene a ser todos los parametros propios del userAP, y más adelante lo que hacemos es conectar las estaciones WiFi a la red creada por el punto de acceso. :smiling_face_with_smiling_eyes_and_hand_covering_mouth:.


En ocasiones, se bloquea la interfaz inalambrica, nos saca un warning de la siguiente manera, y no nos deja poner la interfaz `UP`.

Operation not possible due to RF-kill

Tenemos que hacer lo siguiente:

rfkill unblock all

Con esto ya somos capaces de lanzar un escenario, y en vuelo, lanzar un UserAP desde un shell script. Es decir, ahora tenemos que montar un JSON de vscode que llame a las dos ultimas lineas de `ofprotocol` y `ofdatapath` para debuggear los binarios. Por ello, tendremos que parametrizar las siguientes ordenes desde el JSON de debug:

ofdatapath -i ap1-wlan1 punix:/tmp/ap1 -d 100000000001 --no-slicing 1> /tmp/ap1-ofd.log 2> /tmp/ap1-ofd.log &
ofprotocol unix:/tmp/ap1 tcp:localhost:6633 --fail=closed  --listen=punix:/tmp/ap1.listen 1> /tmp/ap1-ofp.log 2>/tmp/ap1-ofp.log &

Una vez que nos hemos tenido que pegar con Vs code... ya tenemos el JSON de launch. Lo indicamos a continuación. Mencionar que gdb no soporta que corran con permisos de root. Hay que hacer una ñapa, adjunto links:

* https://github.com/microsoft/vscode-cmake-tools/issues/2463
* https://github.com/microsoft/vscode-cpptools/issues/861

Y despues parecía que no nos dejaban meter la contraseña dado que la entrada y salida se bloqueaba... el primer approach ha sido meter un visudo y a pastar... pero despues hemos visto como le podemos pasar la contraseña de forma única a sudo.

echo "pass" | sudo -S cmd

El JSON resultante es el siguiente:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(ap1)ofprotocol",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/secchan/ofprotocol",
            "args": [
                "unix:/tmp/ap1",
                "tcp:localhost:6653",
                "--fail=closed",
                "--listen=punix:/tmp/ap1.listen"
            ],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "text": "target-run",
                    "description": "Ofprotocol",
                    "ignoreFailures": true
                }
            ]
        },
        {
            "name": "(ap1)ofdatapath",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/udatapath/ofdatapath",
            "args": [
                "-i",
                "ap1-wlan1",
                "punix:/tmp/ap1",
                "-d",
                "000000000001",
                "--no-slicing"
            ],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "text": "target-run",
                    "description": "Ofdatapath",
                    "ignoreFailures": true
                }
            ]
        }
    ],
    "compounds": [
        {
            "name": "(ap1)ofprotocol/(ap1)ofdatapath",
            "configurations": [
                "(ap1)ofprotocol",
                "(ap1)ofdatapath"
            ],
            "preLaunchTask": "${defaultBuildTask}",
            "stopAll": true
        }
    ]
}

Lo tenemos :scream_cat: jajajaja ha costado pero si. Vamos a seguir con nuestra detectivación al switch :joy:.


La verdad que el setup configurado es bastante versatil. En una ventana tenemos a Mininet-Wifi, en la siguiente tenemos al controlador de Ryu, abajo, lanzamos el `lanch_dbg.sh` y despues cuando termina de converger el `ofdatapath`, lanzamos el `ofprotocol`.

## Arqueología IV :t-rex: : Una nueva esperanza (in-BOFUSS)

En este punto vamos a analizar los cambios inducidos por nuestro compañero bobys. El nuevo switch implementa de forma nativa el mecanimo In-band, con un pequeño matiz, es para redes cableadas. En neustro caso, tendremos que readaptar los cambios metidos por boby para nuestro TFM. Por ello, ese punto vamos a comparar la delta que hay entre el repositorio de:

* Switch de boby in-band, `a.k.a` **`in-BOFUSS`**: https://github.com/NETSERV-UAH/in-BOFUSS
* Basic OpenFlow Software Switch, `a.k.a` **`BOFUSS`**: https://github.com/CPqD/ofsoftswitch13

Para analizar las diferencias entre ambos repositiorios vamos a utilizar la herramienta llamada, [Meld](http://meldmerge.org/). Esta herramienta nos permite comparar diferencias y cambios entre dos directorios de forma gráfica. En este punto solo vamos a identificar los cambios inducidos en el nuevo repositorio de Boby, en el siguiente punto se buscará la explicación del cambio.

Podemos instalar Meld en Ubuntu 22.04 de la siguiente forma:

sudo apt install meld

Una vez que tenemos la herramienta instalada, deberiamos ver lo siguiente:


Despues de analizar el directorio principal, vemos que hay un **total** de **323 ficheros** en el switch:


A continuación, se indican los cambios inducidos por el repositorio de in-BOFUSS.

#### [F1.1] Fichero `include/openflow/openflow.h`


#### [F1.2] Fichero `include/openflow/openflow.h`


#### [F2.1] Fichero `lib/mac-learning.c`


#### [F3.1] Fichero `lib/mac-learning.h`


#### [F4.1] Fichero `lib/netdev.c`


#### [F4.2] Fichero `lib/netdev.c`


#### [F5.1] Fichero `lib/netdev.h`

#### [F6.1] Fichero `lib/ofp.c`

#### [F6.2] Fichero `lib/ofp.c`

#### [F6.3] Fichero `lib/ofp.c`

#### [F6.4] Fichero `lib/ofp.c`

#### [F6.5] Fichero `lib/ofp.c`

#### [F6.6] Fichero `lib/ofp.c`

#### [F6.7] Fichero `lib/ofp.c`

#### [F7.1] Fichero `lib/ofp.h`

#### [F7.2] Fichero `lib/ofp.h`

#### [F8.1] Fichero `lib/packets.h`

#### [F9.1] Fichero `lib/rconn.c`

#### [F9.2] Fichero `lib/rconn.c`

#### [F10.1] Fichero `lib/rconn.h`

#### [F11.1] Fichero `lib/vconn-stream.c`

#### [F12.1] Fichero `lib/vconn-stream.h`

#### [F13.1] Fichero `lib/vconn.c`

#### [F14.1] Fichero `nbee_link/nbee_link.cpp`

#### [F14.2] Fichero `nbee_link/nbee_link.cpp`

#### [F14.3] Fichero `nbee_link/nbee_link.cpp`

#### [F15.1] Fichero `oflib/ofl-messages-pack.c`

#### [F16.1] Fichero `oflib/ofl-packets.h`

#### [F17.1] Fichero `oflib/ofl-structs-pack.c`

#### [F18.1] Fichero `oflib/ofl-structs-print.c`

#### [F19.1] Fichero `oflib/ofl-structs-unpack.c`

#### [F19.2] Fichero `oflib/ofl-structs-unpack.c`

#### [F20.1] Fichero `oflib/ofl-structs.h`

#### [F21.1] Fichero `oflib/omx-match.c`

#### [F21.2] Fichero `oflib/omx-match.c`

#### [F21.3] Fichero `oflib/omx-match.c`

#### [F21.4] Fichero `oflib/omx-match.c`

#### [F21.5] Fichero `oflib/omx-match.c`

#### [F21.6] Fichero `oflib/omx-match.c`

#### [F21.7] Fichero `oflib/omx-match.c`

#### [F22.1] Fichero `oflib/omx-match.def`

#### [F22.2] Fichero `oflib/omx-match.def`

#### [F23.1] Fichero `oflib/omx-match.h`

#### [F24.1] Fichero `secchan/inband.c`

#### [F24.2] Fichero `secchan/inband.c`


#### [F24.3] Fichero `secchan/inband.c`


#### [F24.4] Fichero `secchan/inband.c`


#### [F24.5] Fichero `secchan/inband.c`


#### [F24.6] Fichero `secchan/inband.c`


#### [F25.1] Fichero `secchan/inband.h`

#### [F26.1] Fichero `secchan/port-watcher.c`

#### [F26.2] Fichero `secchan/port-watcher.c`

#### [F26.3] Fichero `secchan/port-watcher.c`

#### [F26.4] Fichero `secchan/port-watcher.c`

#### [F27.1] Fichero `secchan/port-watcher.h`

#### [F28.1] Fichero `secchan/secchan.c`

#### [F28.2] Fichero `secchan/secchan.c`


#### [F28.3] Fichero `secchan/secchan.c`

#### [F28.4] Fichero `secchan/secchan.c`

#### [F29.1] Fichero `secchan/secchan.h`

#### [F30.1] Fichero `udatapath/datapath.c`

#### [F31.1] Fichero `udatapath/datapath.h`

#### [F32.1] Fichero `udatapath/dp_actions.c`

#### [F33.1] Fichero `udatapath/dp_control.c`

#### [F33.2] Fichero `udatapath/dp_control.c`

#### [F34.1] Fichero `udatapath/dp_ports.c`

#### [F34.2] Fichero `udatapath/dp_ports.c`

#### [F34.3] Fichero `udatapath/dp_ports.c`

#### [F34.4] Fichero `udatapath/dp_ports.c`

#### [F34.5] Fichero `udatapath/dp_ports.c`

#### [F34.6] Fichero `udatapath/dp_ports.c`

#### [F34.7] Fichero `udatapath/dp_ports.c`

#### [F34.8] Fichero `udatapath/dp_ports.c`

#### [F34.9] Fichero `udatapath/dp_ports.c`

#### [F34.10] Fichero `udatapath/dp_ports.c`

#### [F34.11] Fichero `udatapath/dp_ports.c`

#### [F34.12] Fichero `udatapath/dp_ports.c`

#### [F34.13] Fichero `udatapath/dp_ports.c`

#### [F34.14] Fichero `udatapath/dp_ports.c`

#### [F34.15] Fichero `udatapath/dp_ports.c`

#### [F34.16] Fichero `udatapath/dp_ports.c`

#### [F35.1] Fichero `udatapath/dp_ports.h`

#### [F35.2] Fichero `udatapath/dp_ports.h`

#### [F36.1] Fichero `udatapath/flow_table.c`

#### [F37.1] Fichero `udatapath/match_std.c`

#### [F37.2] Fichero `udatapath/match_std.c`

#### [F37.3] Fichero `udatapath/match_std.c`

#### [F38.1] Fichero `udatapath/match_std.h`

#### [F39.1] Fichero `udatapath/packet.c`

#### [F40.1] Fichero `udatapath/packet.h`

#### [F41.1] Fichero `udatapath/packet_handle_std.c`

#### [F42.1] Fichero `udatapath/pipeline.c`

#### [F42.2] Fichero `udatapath/pipeline.c`

#### [F43.1] Fichero `udatapath/pipeline.h`

#### [F44.1] Fichero `udatapath/udatapath.c`

#### [F44.2] Fichero `udatapath/udatapath.c`

#### [F44.3] Fichero `udatapath/udatapath.c`

#### [F44.4] Fichero `udatapath/udatapath.c`

#### [F44.5] Fichero `udatapath/udatapath.c`

#### [F45.1] Fichero `utilities/dpctl.c`

#### [F46.1] Fichero `utilities/dpctl.h`

#### [F47.1] Fichero `customnetpdl.xml`

#### [F47.2] Fichero `customnetpdl.xml`

Como se ha podido ver despues de la indentificación de cambios introducidos por nuestro querido rumano de confianza Boby, hemos impactado sobre **47** ficheros distintos, con un total de **146** cambios. En el siguiente punto se irán analizando y describiendo cada cambio inducido, con la funcionalidad aparentemente, o motivación.

## Arqueología V :t-rex: : El BOFUSS contraataca

En esta section vamos a ir recolectando los cambios inducidos al BOFUSS. En el partado anterior ya se fueron identificando, en esta section vamos a llevar un seguimiento del funcionamiento intriseco de los mimsos. Empezamos :call_me_hand: :japanese_ogre: .

#### [F1.1] Fichero `include/openflow/openflow.h`

Vale según hemos visto, el enum que se utiliza aquí es para definir los puertos reservados de Openflow.


Como se pueden ver los puertos reservados especifican acciones genericas de forwarding. En este caso boby, añade una acción adicional, que al parecer, se utilizará para hacer una serie de peticiones.

OFPP_RANDOM = 0xfffffff7      /* Special value used in some requests when */

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/4ec746f46621f4ad4795d9f64c8bf947f1b0ae80/include/openflow/openflow.h#L102

Indagando más sobre este cambio vemos que es inutil y que es código muerto que se ha quedado sin uso. El id de `OFPP_RANDOM` aparece en los sisuientes puntos del repositorio:

* https://github.com/search?q=repo%3ANETSERV-UAH%2Fin-BOFUSS%20OFPP_RANDOM&type=code

Basicamente se le pasa siempre a la siguiente función:

void packet_Amaru_send(struct packet *pkt, uint32_t out_port)
{

    dp_ports_output_amaru(pkt->dp, pkt->buffer, pkt->in_port, out_port == OFPP_RANDOM, pkt);
}

El parametro de out_port siempre es el mismo. La macro que tenemos del puerto reservado, despues se compara siempre consigo misma, devolviendo un `true` o `false`, pero en todos los casos donde se llama a la función se le suministra el paremtro de de la macro. Por tanto, siempre llega un `true`. Además, donde llega ese `true` pues vamos a verlo:

int dp_ports_output_amaru(struct datapath *dp, struct ofpbuf *buffer UNUSED, uint32_t in_port, bool random UNUSED, struct packet *pkt)
{
    ***
}

En esta función llega el flag, pero no se usa para nada, donde se usaba ya está comentado.

##### Conclusión

Menos es más, en estos casos donde hay tanto código y se tiene que mantaner a la larga. Propongo este cambio para ser revertido y eliminar todos los vestigios de uso del puerto reservado.

#### [F1.2] Fichero `include/openflow/openflow.h`

En este caso, como se ha podido apreciar se añaden dos entradas más para añadir los campos de matching de Amaru. De esta forma se definen los campos de Matching del protocolo Amaru, por ello, este cambio aparentemente está bien hecho.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/include/openflow/openflow.h#L488

##### Conclusión

Este cambio no hay que revertirlo, solo tenemos que adaptar los nombre al nuevo protocolo. El cual por cierto aun no se ha decidido.

#### [F2.1] Fichero `lib/mac-learning.c`

Este cambio está bien hecho. Es más arregla un error de tipos que originalmente tienen el switch. Ya dentro de la función donde se modifica el valor de retorno, dentro se llama a otra función que devuelve un valor de tipo: `uint32_t`, y la función de afuera devuelve un valor de `uint16_t`. De esta forma poniendo ambos valores a 32 bits no se segmenta el valor de retorno.

##### Conclusión

Este cambio no hay que revertirlo.

#### [F3.1] Fichero `lib/mac-learning.h`

Este cambio lo único que hace es ajustar el tipo de retorno de la función que se ha modificado anteriormente en el cambio [F2.1].

##### Conclusión

Este cambio no hay que revertirlo.

#### [F4.1] Fichero `lib/netdev.c`

A continuación, se indica el cambio inducido. Lo he estado mirando y en verdad tiene sentido dado, que se utiliza una estructura para gestionar las interfaces de red de forma completamente agnostica... Y a la hora de la verdad utilizan un fd para las taps cuando en la propia interfaz tiene un fd para las itnerfaces genericas. Al final un file descriptor, aka, un descriptor de archivo es un valor de 32 bits para indentificar un socket.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/netdev.c#L1116

Boby se dio cuenta de esto y dijo... ey primo! Jajajaja si hasta aqui:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/netdev.c#L140

Nos dicen que son iguales, por que no ponerlo de forma generica?

##### Conclusión

Este cambio no hay que revertirlo.

#### [F4.2] Fichero `lib/netdev.c`

Este cambio unicamente se ha introducido para loggear los cambios de las flags en la interfaz. Se llama a la función `nd_to_iff_flags()` para consultarlos. A continuación, se indica la linua donde se ha introducido el cambio:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/netdev.c

##### Conclusión

Este cambio no hay que revertirlo.

#### [F5.1] Fichero `lib/netdev.h`

Declara fos funciones que se han añadido al final del fichero de `netdev.c`. A continuación, se indican las funciones que se han añadido, al parecer una es un mero wrapper de una que ya existe para restablecer las flags de la interfaz, y la otra consulta las Flags y poco más...

/*Modificaciones Boby UAH*/
int is_net_interface_running_UAH(const char *netdev_name)
{
    struct ifreq ifr;
    int sock;

    memset(&ifr, 0, sizeof(ifr));
    strncpy(ifr.ifr_name, netdev_name, sizeof ifr.ifr_name);
    sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_IP);
    if (ioctl(sock, SIOCGIFFLAGS, &ifr) < 0)
    {
        perror("SIOCGIFFLAGS");
    }
    close(sock);
    VLOG_WARN(LOG_MODULE, "[Is INTERFACE RUNNING UAH]: Flags de la interfaz --%s--: 0x%x\tValor devuelto:%d", netdev_name, ifr.ifr_flags, !!(ifr.ifr_flags & IFF_RUNNING));
    return !!(ifr.ifr_flags & IFF_UP); //Se utiliza !! para devolver 1 ó 0 cuando se opera con valores mayores que 1 (!!10 --> !10 = 0, !0 = 1)
}

void restore_flags_UAH(struct netdev *netdev)
{
    restore_flags(netdev);
}
/*+++FIN+++*/

##### Conclusión

Este cambio no hay que revertirlo, añade funcinalidad.

#### [F6.1] Fichero `lib/ofp.c`

Simplemente añade los archivos de cabacera necesarios, y declara una función que se definirá más abajo del fichero. Se me hace raro que defina ahí la función pudiendolo hacer perfectamente en el `*.h`. Dejo la modificación por aqui:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/ofp.c#L69

Más abajo se define la función, confirmado.

##### Conclusión

Modificaría la declaraciónb de la función al achivo de cabecera `ofp.h`.

#### [F6.2] Fichero `lib/ofp.c`

Entra a modificar, más bien completar la función anterior que se había quedado con un TODO pendiente para la instantación de un FLOWMOD.


* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/ofp.c#L207

##### Conclusión

Este cambio no hay que revertirlo.

#### [F6.3] Fichero `lib/ofp.c`

No tengo muy claro por que pone una estructura de if else, para droppear exlusivamente un flujo... Entiendo que su expliación tendrá. La expliación:


Entiendo que se boby ha incidido en la creación y modificación de estas funciones, vamos a respetarlas, ya veremos más adelante si hay que modificarlas o no.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/ofp.c#L240

##### Conclusión

Este cambio no hay que revertirlo.

#### [F6.4] Fichero `lib/ofp.c`

En esta función añade una lógica adicional para la eliminación de flujos.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/ofp.c#L275

##### Conclusión

Este cambio no hay que revertirlo.

#### [F6.5] Fichero `lib/ofp.c`

Se ha modificado para que se cree un paquete FLOW_MOD que instale una regla que encamine el tráfico, caracterizado por los campos de match, por un puerto concreto. Cuando el puerto de salida es 0, se crea un FLOW_MOD del
tipo DROP, es decir, una regla para descartar los paquetes del tráfico caracterizado por los campos de match.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/ofp.c#L304

##### Conclusión

Este cambio no hay que revertirlo.

#### [F6.6] Fichero `lib/ofp.c`

Este cambio unicamente propone una forma alternativa para calcular el tamaño de las actions propuetas.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/ofp.c#L369

Entiendo que boby lo modifico dado que el sizeof lo hace mal.

##### Conclusión

Este cambio no hay que revertirlo.

#### [F6.7] Fichero `lib/ofp.c`

Estas ultimas dos funciones lo que tratan de conseguir es generar a partir de una estructura de tipo, flow, una de tipo match. La otra función trata de generar un mensaje de tipo flow mod para modificar las reglas de in-band.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/ofp.c#L905

##### Conclusión

Este cambio no hay que revertirlo.

#### [F7.1] Fichero `lib/ofp.h`

Se puede ver como en las declaraciones de las funciones de manejo de flujos se les indica la prioridad. Es una mera actualización de la nueva definición de las funciones descritas anteriormente.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/ofp.h#LL77C1-L79C88

##### Conclusión

Este cambio no hay que revertirlo.

#### [F7.2] Fichero `lib/ofp.h`

Como vemos, se añade la declaración de la fgunción creada anteriormente. Será aqui donde tengamos que añadir la declaración que se hizo anteriormente en el `ofp.c`.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/ofp.h#L143

##### Conclusión

Este cambio no hay que revertirlo.

#### [F8.1] Fichero `lib/packets.h`

En este cambio se añade la estructura de la cabecera de AMARU, y añade macros para su correcta gestión a posteriori.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/packets.h#L420

##### Conclusión

Este cambio no hay que revertirlo.

#### [F9.1] Fichero `lib/rconn.c`

Añade el fichero de cabecera `vconn-stream.h` dado que quiere utilizar la función `modify_socket_options()`.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/vconn-stream.h#LL53C5-L53C26

##### Conclusión

Este cambio no hay que revertirlo.

#### [F9.2] Fichero `lib/rconn.c`

Define una función para modificar las opciones de una conexión de un socket TCP asociado a un puerto determinado. Dejamos la modificación por aquí:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/rconn.c#L1066

##### Conclusión

Este cambio no hay que revertirlo.

#### [F10.1] Fichero `lib/rconn.h`

Declara una función para modificar las opciones de una conexión de un socket TCP asociado a un puerto determinado (la función anterior). Dejamos la modificación por aquí:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/rconn.h#L102

##### Conclusión

Este cambio no hay que revertirlo.

#### [F11.1] Fichero `lib/vconn-stream.c`

La función que se defenía antes, y se declaraba claro, llamaba a su vez a esta función creada tambien por Boby para definir las opciones de un socket que gestiona una conexión TCP, entiendo que con el controlador por un puerto en particular. Dejo los cambios por aquí:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/vconn-stream.c#L400

##### Conclusión

Este cambio no hay que revertirlo.

#### [F12.1] Fichero `lib/vconn-stream.h`

Basicamente es la declaración de la función anterior. Dejo el cambio por aquí:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/vconn-stream.h#L53

##### Conclusión

Este cambio no hay que revertirlo.

#### [F13.1] Fichero `lib/vconn.c`

Solo se añade una nueva entrada de log para que lo saque tambien por el canal de warning además de por DBG.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/lib/vconn.c#L607

##### Conclusión

Este cambio no hay que revertirlo.

#### [F14.1] Fichero `nbee_link/nbee_link.cpp`

En esta modificacion se añaden las ceberas de control para gestionar los nuevos paquetes de control de amaru.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/nbee_link/nbee_link.cpp#L302C1-L317C33

##### Conclusión

Este cambio no hay que revertirlo.

#### [F14.2] Fichero `nbee_link/nbee_link.cpp`

En esta modificacion se parsea el paquete de amaru en función de la longitud de la cabecera, que en este caso es de 28 bytes.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/nbee_link/nbee_link.cpp#L375

##### Conclusión

Este cambio no hay que revertirlo. Habrá que modificarlo a la longitud de nuestra cabecera.

#### [F14.3] Fichero `nbee_link/nbee_link.cpp`

Este cambio hacemos el decode del paquete de Amaru, y lo metemos en la nueva estructura del paquete que se gestiona de cara hacia fuera del switch.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/nbee_link/nbee_link.cpp#L442C13-L442C13

##### Conclusión

Este cambio no hay que revertirlo.

#### [F15.1] Fichero `oflib/ofl-messages-pack.c`

En esta linea solo se añade un mensaje de log para indicar cuando se empaqueta un mensaje de FLOW MOD.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/ofl-messages-pack.c#L286

##### Conclusión

Este cambio no hay que revertirlo.

#### [F16.1] Fichero `oflib/ofl-packets.h`

Aqui lo unico que se hace es definir dos macros para gestionar la longitud de la cabecera de AMARU y ademas definir el ethertype.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/ofl-packets.h#L76

##### Conclusión

Este cambio no hay que revertirlo, solo habrá que ajustarlo al nuevo tamaño de la cabecera.

#### [F17.1] Fichero `oflib/ofl-structs-pack.c`

Esta modificación ajusta a mano a la hora de empequetar el paquete. No tengo muy claro por que lo ha modificado boby...

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/ofl-structs-pack.c#L936

##### Conclusión

Este cambio no hay que revertirlo, aparentemente.

#### [F18.1] Fichero `oflib/ofl-structs-print.c`

En esta modificacion solo se define el formato a la hora de hacer un print de la cabecera de AMARU.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/ofl-structs-print.c#L58

##### Conclusión

Este cambio no hay que revertirlo, solo habrá que ajustarlo a lo que necesitemos.

#### [F19.1] Fichero `oflib/ofl-structs-unpack.c`

En esta modificacion solo se añade una linea para loggear informacion a la hora de hacer un pack. Esta linea creo que la añadio boby para saber por donde iba el flujo de ejecucion del programa.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/ofl-structs-unpack.c#L299

##### Conclusión

Este cambio no hay que revertirlo.

#### [F19.2] Fichero `oflib/ofl-structs-unpack.c`

En esta modificacion solo se añade una linea para loggear informacion a la hora de hacer un pack. Esta linea creo que la añadio boby para saber por donde iba el flujo de ejecucion del programa.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/ofl-structs-unpack.c#L458

##### Conclusión

Este cambio no hay que revertirlo.

#### [F20.1] Fichero `oflib/ofl-structs.h`

Esta modificacion es para añadir la declaracion de las dos funciones para matchear la amac, y el nivel para el protocolo de amaru.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/ofl-structs.h#L454

##### Conclusión

Este cambio no hay que revertirlo.

#### [F21.1] Fichero `oflib/omx-match.c`

Esta linea la ha añadido boby para loggear el puerto de entrada :)

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/oxm-match.c#L301C16-L301C16

##### Conclusión

Este cambio no hay que revertirlo.

#### [F21.2] Fichero `oflib/omx-match.c`

Esta modificación se ha añadido para ver el ethertype loggeandolo.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/oxm-match.c#L342

##### Conclusión

Este cambio no hay que revertirlo.

#### [F21.3] Fichero `oflib/omx-match.c`

Este cambio boby ha añadido una logica para loggear info sobre los mensajes de Ethernet STA y TPA.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/oxm-match.c#L407

##### Conclusión

Este cambio no hay que revertirlo.

#### [F21.4] Fichero `oflib/omx-match.c`

En esta modificacion solo se añade información de log para ver la operación de ARP:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/oxm-match.c#L499

##### Conclusión

Este cambio no hay que revertirlo.

#### [F21.5] Fichero `oflib/omx-match.c`

En esta modificación solo se añaden dos case adicionales para gestionar los matches de level y amac de AMARU.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/oxm-match.c#L553

##### Conclusión

Este cambio no hay que revertirlo.

#### [F21.6] Fichero `oflib/omx-match.c`

En esta modificación se define una función para gestionar las AMACs de amaru. Se añade un offset al final de la cabecera.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/oxm-match.c#L793

##### Conclusión

Este cambio no hay que revertirlo.

#### [F21.7] Fichero `oflib/omx-match.c`

En este caso se añade la logica en caso de encontrar el offset mencionado anteriormente, se llama a la función de antes.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/oxm-match.c#L997

##### Conclusión

Este cambio no hay que revertirlo.

#### [F22.1] Fichero `oflib/omx-match.def`

En este fichero se definen estructuras y macros para cambiar las definiciones de los futuros matches:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/oxm-match.def#L56

##### Conclusión

Este cambio no hay que revertirlo.

#### [F22.2] Fichero `oflib/omx-match.def`

En esta modificacion se definen los nuevos matches del tipo AMARU, que pueden ser AMAC o level.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/oxm-match.def#L109

##### Conclusión

Este cambio no hay que revertirlo.

#### [F23.1] Fichero `oflib/omx-match.h`

Como hemos añadido dos nuevos campos hay que pasar de 56 fields, a 58, daod que hemos añadido las nuevas posibilidades de match ya sea por AMAC o por LEVEL.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/oflib/oxm-match.h#L72

##### Conclusión

Este cambio no hay que revertirlo.

#### [F24.1] Fichero `secchan/inband.c`

Aqui nuestro estimado compañero bobys nos define una serie de macros que entiendo que se utilizarán más abajo del codigo de inband. :smile_cat:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/in-band.c#L54

##### Conclusión

Este cambio no hay que revertirlo.

#### [F24.2] Fichero `secchan/inband.c`

Aqui se añade en la estructura cde inband data el port watcher para poder compartir información entre el puerto local y el puerto fisico.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/in-band.c#L82

##### Conclusión

Este cambio no hay que revertirlo.

#### [F24.3] Fichero `secchan/inband.c`

En esta función se gestiona toda la logica de la gestion de los pquetes de control inband, se intalan las reglas así como tambien las reglas inversas cuando llega un ARP :smile_cat:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/in-band.c#L167

##### Conclusión

Este cambio no hay que revertirlo, hasta donde he podido entender todos los cambios que ha hecho boby me valdrían.

#### [F24.4] Fichero `secchan/inband.c`

En esta función boby loggea para ver el tamaño de los mensajes de control inband (aparentemente solo del payload)

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/in-band.c#L343

##### Conclusión

Este cambio no hay que revertirlo.

#### [F24.5] Fichero `secchan/inband.c`

En esta función se gestionan la instalación de reglas de inband, en ella se instalan los flujos necesarios para gestionar los paquetes TCP y ARP de otros switches.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/in-band.c#L403

##### Conclusión

Este cambio no hay que revertirlo.

#### [F24.6] Fichero `secchan/inband.c`

Como vimos en un cambio de más arriba, donde se añadía a la esctrutura de inband data el port watcher, aquí se inicializa el pw con el punto que se pasa a la función de start.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/in-band.c#L500

##### Conclusión

Este cambio no hay que revertirlo.

#### [F25.1] Fichero `secchan/inband.h`

En esta modificación, se declaran las función que se han definido en el in-band.c para la instalación de las reglas de inband.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/in-band.h#L55

##### Conclusión

Este cambio no hay que revertirlo.

#### [F26.1] Fichero `secchan/port-watcher.c`

En esta modificacion se añade una macro para paear el puerto local a uno de 16 bits:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/port-watcher.c#L56

##### Conclusión

Este cambio no hay que revertirlo.

#### [F26.2] Fichero `secchan/port-watcher.c`

En esta función lo que se hace es mapear el puerto local al muerto de 16 bits auxiliar que se había definido antes.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/port-watcher.c#L148

##### Conclusión

Este cambio no hay que revertirlo.

#### [F26.3] Fichero `secchan/port-watcher.c`

En esta función se comprueba a la hora de actulizar los puertos localoes a los fisicos, si se trata del puerto local, en caso de que sea así lo que se hace es fixear el puerto local a la macro que se había definido antes.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/port-watcher.c#L201

##### Conclusión

Este cambio no hay que revertirlo.

#### [F26.4] Fichero `secchan/port-watcher.c`

Aqui lo que ha hecho boby es poner una linea para loggear, un port status cada vez que el datapath notifica a la capa de control un port status.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/port-watcher.c#L265

##### Conclusión

Este cambio no hay que revertirlo.

#### [F27.1] Fichero `secchan/port-watcher.h`

En esta modificación se declaran dos funciones que se van a utilizar más adelante al final del código del port-watcher. Son funciones para manipular el puerto local y el port watcher.

* (definición) https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/port-watcher.c#L265
* (declaración) https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/port-watcher.h#L78

##### Conclusión

Este cambio no hay que revertirlo.

#### [F28.1] Fichero `secchan/secchan.c`

En este caso se añaden archivos de cabecera necesarios, además de un flag sobre las reglas in band que al parecer se utiliza para gestionar la inicialización de las reglas inband.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/secchan.c#L71

##### Conclusión

Este cambio no hay que revertirlo.

#### [F28.2] Fichero `secchan/secchan.c`

En esta modificación se hace uso de la flag de que se ha definido antes para gestionar un arranque controlado de la logica de inband.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/secchan.c#L308

##### Conclusión

Este cambio no hay que revertirlo.

#### [F28.3] Fichero `secchan/secchan.c`

Aqui lo que se ha hecho es una refactorización de codigo y ya está :smile_cat: .

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/secchan.c#L386

##### Conclusión

Este cambio no hay que revertirlo.

#### [F28.4] Fichero `secchan/secchan.c`

En esta modificación se han añadido dos funciones para detectar el puerto local de los mensajes packet IN cuando quieran establecer una conexión con el controlador.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/secchan.c#L966

##### Conclusión

Este cambio no hay que revertirlo.

#### [F29.1] Fichero `secchan/secchan.h`

Se han declarado las función que anteriormente se han definido en el secchan.c.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/secchan/secchan.h#L131

##### Conclusión

Este cambio no hay que revertirlo.

#### [F30.1] Fichero `udatapath/datapath.c`

En esta función se añade una funcionalidad para sacar el numero de puerto, del puerto local.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/datapath.c#L682C1-L695C2

##### Conclusión

Este cambio no hay que revertirlo.

#### [F31.1] Fichero `udatapath/datapath.h`

En esta modificación se añade la declaración de la función definida anteriormente.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/datapath.h#L221

##### Conclusión

Este cambio no hay que revertirlo.

#### [F32.1] Fichero `udatapath/dp_actions.c`

Añade dos case más para gestionar los paquetes de LEVEL y de AMAC. Busca si hay un match con lo indicado en las tablas, y aplica el set field de la función para el caso de la level y amacs.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_actions.c#L478C1-L498C33

##### Conclusión

Este cambio no hay que revertirlo.

#### [F33.1] Fichero `udatapath/dp_control.c`

Añade un archivo de cabecera simplemente... entiendo que más abajo hará uso de el. Creo que esa librería es para loggear..

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_control.c#L47

##### Conclusión

Este cambio no hay que revertirlo.

#### [F33.2] Fichero `udatapath/dp_control.c`

Añade una linea de log para sacar un packet out de control.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_control.c#L139

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.1] Fichero `udatapath/dp_ports.c`

Aqui se definen dos variables globales para almacenar la antigua MAC del puerto que se configura como local para poder volver a asignarla en caso de que cambie el peurto local.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L58

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.2] Fichero `udatapath/dp_ports.c`

En esta modificación añaden funcionalidad adicional para ver cuando se ha caido una interfaz y se configura una nueva interfaz como puerto local.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L303

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.3] Fichero `udatapath/dp_ports.c`

Se comprueba si se ha recibido paquetes en la interfaz configurada como puerto local para poder dar por finalizada la configuración del puerto local.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L365

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.4] Fichero `udatapath/dp_ports.c`

Se comprueba si se ha recibido paquetes en la interfaz configurada como puerto local para poder dar por finalizada la configuración del puerto local.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L365

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.5] Fichero `udatapath/dp_ports.c`

Se añade funcionalidad para guardar la MAC oroginal del puerto que se va a configurar como local.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L450

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.6] Fichero `udatapath/dp_ports.c`

Se configura el bit OFPPC_NO_FWD para que no se use el puerto local con OFPP_FLOOD.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L559

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.7] Fichero `udatapath/dp_ports.c`

Añade una modificación a la función cuando añade un puerto local para evitar que asigne una nueva MAC a la interfaz :smile_cat:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L728

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.8] Fichero `udatapath/dp_ports.c`

Se añade funciones para crear una tabla, inicializarla, y otra función para añadir AMACs :smile: .

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L1402

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.9] Fichero `udatapath/dp_ports.c`

Añadimos dos funciones para gestionar el numero de AMACs en el swithc y además otra función para validarlas.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L1463

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.10] Fichero `udatapath/dp_ports.c`

Según he podido investigar en esta función se saca el paquete de AMARU por todos los puertos :smile: sin embargo la salida no tiene pinta que esté aleatoriazada.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L1512

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.11] Fichero `udatapath/dp_ports.c`

Aquí se añaden tres funcionaes para la visualización de AMACs, MACs y loggear de la uah... no añaden funcionalidad, pero si nos ayudarán a debuggear bien al switch en el desarrollo.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L1568

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.12] Fichero `udatapath/dp_ports.c`

En esta función se elimina el puerto local y lo limpia completamente :smiling_face_with_smiling_eyes_and_hand_covering_mouth: .

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L1687

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.13] Fichero `udatapath/dp_ports.c`

En este caso se añaden dos funciones para validar y para invalidar las AMACs validas o invalidas en su caso.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L1710

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.14] Fichero `udatapath/dp_ports.c`

En esta función se eliminan las AMACs invalidas y se ajusta la tabla cuando se elimina para guardar coherencia :smile_cat: .

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L1740

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.15] Fichero `udatapath/dp_ports.c`

Se añade una nueva función para configurar un nuevo puerto local de AMARU, en este caso se tienen que modificar tambien el ofprotocol... por tanto hay que enviarle un mensaje a través del socket unix.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L1773

##### Conclusión

Este cambio no hay que revertirlo.

#### [F34.16] Fichero `udatapath/dp_ports.c`

Crea una función para recorrer la lista de puertos y si el nombre de la interfaz es el mismo se devuelve el numero de puerto.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.c#L1809

##### Conclusión

Este cambio no hay que revertirlo.

#### [F35.1] Fichero `udatapath/dp_ports.h`

En este archivo de cabecera se definen todas las macros que se van a utilizar de aqui en adelante en la implementación del protocolo.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.h#L111

##### Conclusión

Este cambio no hay que revertirlo.

#### [F35.2] Fichero `udatapath/dp_ports.h`

Al final del archivo de cabecera se declaran todas las funciones que hemos ido viendo anteriormente :smiley_cat:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/dp_ports.h#L216

##### Conclusión

Este cambio no hay que revertirlo.

#### [F36.1] Fichero `udatapath/flow_table.c`

Se añaden dos nuevas campos de match a las flow tables :smile_cat: .

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/flow_table.c#L56

##### Conclusión

Este cambio no hay que revertirlo.

#### [F37.1] Fichero `udatapath/match_std.c`

Esto es puta mierda JAJAJAJAJAJA


##### Conclusión

Hay que ver si impacta o no las funciones tas de match... pero ya te digo que son puta mierda

#### [F37.2] Fichero `udatapath/match_std.c`

Sinceramente me da pánico esta funcion por que realmente se utiliza la puta mierda de las funciones de antyes en la etapa de matching .....

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/match_std.c#L207

##### Conclusión

Este cambio no hay que revertirlo.

#### [F37.3] Fichero `udatapath/match_std.c`

Hay que echarle un ojo a esto por que gestiona los matches en funcion de la longitud del paquete presupongo.... y utiliza las funciones mierdosas de antes.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/match_std.c#L469

##### Conclusión

Este cambio no hay que revertirlo.

#### [F38.1] Fichero `udatapath/match_std.h`

Se ha declarado la funcion mierdosa de antes :shit:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/match_std.h#L57

##### Conclusión

Este cambio no hay que revertirlo.

#### [F39.1] Fichero `udatapath/packet.c`

Se conforma el paquete de amaru :thinking_face: habrá que verlo con mas detenimiento. tambien tiene funciones para mandar el paquete amaru como root.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/packet.c#L151

##### Conclusión

Este cambio no hay que revertirlo.

#### [F40.1] Fichero `udatapath/packet.h`

Se decalran las funciones que se han comentado anteriormente :smile:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/packet.h#L83C1-L93C1

##### Conclusión

Este cambio no hay que revertirlo.

#### [F41.1] Fichero `udatapath/packet_handle_std.c`

Se añade una s para inclurir la string de amaru jajajaja poco más

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/packet_handle_std.c#L188C1-L188C63

##### Conclusión

Este cambio no hay que revertirlo.

#### [F42.1] Fichero `udatapath/pipeline.c`

Se loggea informacion que mandamos del switch al controller.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/pipeline.c#L97

##### Conclusión

Este cambio no hay que revertirlo.

#### [F42.2] Fichero `udatapath/pipeline.c`

Podriamos ver esta modificacion como una de las más importantes dado que es aqui donde se lleva a cabo la logica de AMARU haciendo uso de todas las funciones definidas anteriormente.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/pipeline.c#L161C3-L189C10

##### Conclusión

Este cambio no hay que revertirlo.

#### [F43.1] Fichero `udatapath/pipeline.h`

Es aqui donde se almacena la tabla de AMACs :smile_cat:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/pipeline.h#L42

##### Conclusión

Este cambio no hay que revertirlo.

#### [F44.1] Fichero `udatapath/udatapath.c`

Aqui se definen las variables globales que se van a utilizar como son la matriz aleatoria para realizar broacast y tambien la tabla de AMACs.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/udatapath.c#L85C1-L98C1

##### Conclusión

Este cambio no hay que revertirlo.

#### [F44.2] Fichero `udatapath/udatapath.c`

Aqui entramos en el main del datapath donde se inicializan los tiempos ademas de inicializar la tabla de AMACs.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/udatapath.c#L124C4-L138C33

##### Conclusión

Este cambio no hay que revertirlo.

#### [F44.3] Fichero `udatapath/udatapath.c`

En esta modficación añadimos el codigo para gestionar la inicialización de los paquetes de AMARU en cas ode ser el root.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/udatapath.c#L213C3-L236C10

##### Conclusión

Este cambio no hay que revertirlo.

#### [F44.4] Fichero `udatapath/udatapath.c`

En este caso se ha añadido la funcionalidad para gestionar el envio de paquetes en caso de que el switch sea el root, de forma periodica lanzamos el paquete de AMACs :smile_cat:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/udatapath.c#L249C4-L255C10

##### Conclusión

Este cambio no hay que revertirlo.

#### [F44.5] Fichero `udatapath/udatapath.c`

Se añade una función para aleatorizar el lanzamiento de paquetes de broadcast de las AMACs por los puertos del switch.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/udatapath/udatapath.c#L466

##### Conclusión

Este cambio no hay que revertirlo. Aunque se podría eliminar dado que aqui solo vamos a tener un puerto :smiley_cat:

#### [F45.1] Fichero `utilities/dpctl.c`

Se añade funcionalidad para gestionar el manejo de las AMACs desde la herramienta de dpctl :+1:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/utilities/dpctl.c#L1600C1-L1614C35

##### Conclusión

Este cambio no hay que revertirlo.

#### [F46.1] Fichero `utilities/dpctl.h`

Se añaden dos MACROS para guardar las strings que va a sacar la herramienta de dpctl :smile:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/utilities/dpctl.h#L219C1-L222C25

##### Conclusión

Este cambio no hay que revertirlo.

#### [F47.1] Fichero `customnetpdl.xml`

Se añade la posible encapsulación del protocolo de amaru :smile_cat:

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/customnetpdl.xml#L184C1-L184C88

##### Conclusión

Este cambio no hay que revertirlo.

#### [F47.2] Fichero `customnetpdl.xml`

En este punto se definen los campos del protocolo de AMARU.

* https://github.com/NETSERV-UAH/in-BOFUSS/blob/main/customnetpdl.xml#L184C1-L184C88

##### Conclusión

Este cambio no hay que revertirlo.

## Referencias chingonas

* https://opennetworking.org/wp-content/uploads/2014/10/openflow-spec-v1.3.0.pdf
* https://github.com/netgroup-polito/netbee
* https://staff.polito.it/mario.baldi/publications/2005ComNet_NetPDL.pdf
* https://wireless.wiki.kernel.org/en/users/documentation/iw