Struct OspfProtocol 

pub struct OspfProtocol;

OSPF protocol action handler

Implementations

impl OspfProtocol

pub fn new() -> Self

pub fn parse_lsa_headers(body: &[u8], max: usize) -> Vec<Value>

Parse the fixed 20-byte LSA headers that DD and LSAck packets carry, and that LSU packets carry ahead of each LSA body (RFC 2328 A.4.1).

Returns structured fields, never raw bytes - models cannot read a hex blob (see CLAUDE.md, action & event design rules). The shape is exactly what Self::build_link_state_ack_packet consumes, so the model can acknowledge an update by handing back the lsa_headers the event gave it.

Lives here rather than in the server loop because the OSPF client parses the same headers out of the Link State Updates it receives.

pub fn calculate_checksum(data: &[u8]) -> u16

Compute the OSPF packet checksum (RFC 2328 Section A.3.1).

This is the standard IP (one’s complement) checksum over the entire packet with the checksum field itself treated as zero and the 64-bit authentication field (header bytes 16..24) excluded. It is not the Fletcher checksum of Section D.4 — that one applies to LSA headers, not to packet headers. A previous implementation here used Fletcher, which meant every packet NetGet emitted failed the receiver’s validity check and was silently dropped by real routers (FRR/BIRD).

The defining property, and how a receiver validates: recomputing this sum over the packet with the checksum field left in place must yield 0.

That property is why this function does not special-case bytes 12..14. It sums the packet exactly as given, which makes one function serve both directions of the standard one’s-complement idiom:

• Sending — leave the checksum field zero, call this, store the result there. Every build_*_packet here does that, and their headers already lay the field down as [0, 0].
• Receiving — call this over the packet as it arrived. A valid packet yields 0.

Zeroing bytes 12..14 unconditionally, as an earlier version did, collapses those two into one: the receiver then recomputes the sender’s value instead of 0, so the validity check can never pass and a corrupted packet is indistinguishable from a good one. The doc comment claimed the property above while the code made it unsatisfiable.

pub fn build_hello_packet(action: &Value) -> Result<Vec<u8>>

Build OSPF Hello packet from action data

pub fn build_database_description_packet(action: &Value) -> Result<Vec<u8>>

Build OSPF Database Description packet from action data

pub fn build_link_state_request_packet(action: &Value) -> Result<Vec<u8>>

Build OSPF Link State Request packet from action data (RFC 2328 A.3.4).

Body is a repeating triple: LSType(4) | LinkStateID(4) | AdvertisingRouter(4), taken from the action’s requests array. The ospf_link_state_update event hands the model LSA headers carrying exactly those three fields, so a request can name real LSAs.

pub fn build_link_state_update_packet(action: &Value) -> Result<Vec<u8>>

Build OSPF Link State Update packet from action data

pub fn build_link_state_ack_packet(action: &Value) -> Result<Vec<u8>>

Build OSPF Link State Acknowledgment packet from action data (RFC 2328 A.3.6).

The body is the list of 20-byte LSA headers being acknowledged, taken from the action’s lsa_headers array in the shape Self::parse_lsa_headers emits — so the model acknowledges an update by handing back the lsa_headers the ospf_link_state_update event gave it.

An LSAck with an empty body is not a no-op: RFC 2328 13.7 matches an acknowledgement against the neighbour’s retransmission list header by header, so a body-less LSAck acknowledges nothing and the peer keeps retransmitting every LSA each RxmtInterval until the adjacency fails. That is what this used to emit.

Trait Implementations

impl Protocol for OspfProtocol

fn get_async_actions(&self, _state: &AppState) -> Vec<ActionDefinition>

Deliberately empty.

This used to advertise list_neighbors and list_lsdb, and execute_action had no arm for either — so the model was offered two verbs and rejected with “Unknown OSPF action type” whenever it chose one. They are removed rather than implemented because neither can be answered honestly: NetGet keeps no neighbour table and no link-state database, and the project rule is that protocols do not implement storage — the model tracks that state in its own memory, where it already has everything these would report.

fn get_sync_actions(&self) -> Vec<ActionDefinition>

Get sync actions available during network events

fn protocol_name(&self) -> &'static str

Get protocol name for debugging and identification

fn get_event_types(&self) -> Vec<EventType>

Get the event types that this protocol can emit

fn stack_name(&self) -> &'static str

Get the stack name (e.g., “ETH>IP>TCP>HTTP”)

fn keywords(&self) -> Vec<&'static str>

Get parsing keywords for protocol detection

fn metadata(&self) -> ProtocolMetadataV2

Get protocol metadata with implementation details

fn description(&self) -> &'static str

Get a short description of this protocol

fn example_prompt(&self) -> &'static str

Get an example prompt that would trigger this protocol

fn get_startup_parameters(&self) -> Vec<ParameterDefinition>

Get startup parameters that can be provided when starting this protocol

fn group_name(&self) -> &'static str

Get the group name for categorizing this protocol

fn get_startup_examples(&self) -> StartupExamples

Get startup examples for this protocol with different handler modes

fn default_binding(&self) -> Option<BindingDefaults>

Get default binding parameters for this protocol

fn get_dependencies(&self) -> Vec<ProtocolDependency>

Get runtime dependencies required for this protocol to function

fn startup_dependencies( &self, _startup_params: Option<&Value>, ) -> Vec<ProtocolDependency>

The runtime dependencies a start with these startup_params actually needs.

fn startup_privilege_requirement( &self, _startup_params: Option<&Value>, ) -> PrivilegeRequirement

The privilege this particular start needs, given its startup parameters.

impl Server for OspfProtocol

fn spawn( &self, ctx: SpawnContext, ) -> Pin<Box<dyn Future<Output = Result<SocketAddr>> + Send>>

Spawn a server instance for this protocol

fn execute_action(&self, action: Value) -> Result<ActionResult>

Execute a protocol-specific action

fn execute_action_with_state<'a>( &'a self, action: Value, state: AppState, server_id: Option<ServerId>, ) -> Pin<Box<dyn Future<Output = Result<ActionResult>> + Send + 'a>>

Execute a protocol-specific action with access to application state.