# Project Overview

This project is an OpenFlow agent written in C. It implements a subset of the OpenFlow 1.3 protocol to allow a remote controller to manage a network switch. The agent is designed to run on an ARM-based device.

The core logic resides in `main_user_openflow.c`, which handles various OpenFlow message types such as `HELLO`, `FEATURES_REQUEST`, `GET_CONFIG_REQUEST`, and `PACKET_OUT`. The agent responds to these messages by sending back appropriate replies, allowing the controller to inspect and manage the switch's state.

The project is built using a `Makefile` and links against several local libraries, including `libofp` (for OpenFlow protocol handling) and `libnet` (for network packet manipulation).

# Building and Running

## Building

To build the project, you can use the provided `Makefile`. The `Makefile` uses the `arm-linux-gnueabihf-gcc` cross-compiler, so you'll need to have that installed and in your `PATH`.

```bash
# To build the project
make
```

This will create an executable file named `user_openflow` in the project's root directory.

## Running

The `user_openflow` executable can only be run on the target ARM device. Based on the comment at the end of `main_user_openflow.c`, the following command can be used to run the agent:

```bash
sudo ./user_openflow -c eth0 -i obx0,obx1,obx2,obx3
```

*   `-c eth0`: Specifies the control interface.
*   `-i obx0,obx1,obx2,obx3`: Specifies the data plane interfaces.

The agent will then listen for incoming connections from an OpenFlow controller.

# Development Conventions

*   **Coding Style:** The code follows a C-style with a focus on clarity and modularity. Functions are well-documented with comments explaining their purpose, parameters, and return values.
*   **Testing:** There is a Python script `openflow_flow-test.py`, which suggests that testing is done using Python scripts.
*   **Dependencies:** The project relies on several pre-compiled libraries located in the `lib/` directory. Any new dependencies should be added there.
*   **Architecture:** The main application logic is event-driven, with a central callback function that dispatches OpenFlow messages to their respective handlers. This makes it easy to extend the agent by adding new handlers for additional OpenFlow message types.