xeiaso.net / ircd.rs
Proof of concept mechanical port of ircnet/ircd to Rust as part of a bit about C being insecure for network services
0
Fork 0

Configure Feed

Select the types of activity you want to include in your feed.

ircd.rs / docs / claude-memory / leveva-s2s-port-based-routing.md
2.3 kB

name: leveva-s2s-port-based-routing description: "leveva routes client-vs-server by the listener server-only flag, NOT by the PASS/SERVER handshake — deliberate, keep it" metadata: node_type: memory type: project originSessionId: c7dc8be3-7986-4f0d-b05d-122c8e8737d7#

leveva decides whether an accepted connection is a client (serve_client) or a server link (serve_server) by the listener's server-only flag, set in main.rs::handle. It does NOT sniff the PASS/SERVER handshake to detect a peer on a shared port. So a server linking to a normal client port (e.g. 6667) is treated as a client and its SERVER line gets 451 You have not registered; a peer must connect to a server-only listener.

Why: the maintainer chose this (2026-06-09) over content-based routing. It diverges from the IRCnet 2.11 oracle (which accepts both on one port, dispatching SERVER→m_server vs NICK→m_nick by content) but is a cleaner separation. Do not "fix" it to content-based routing without being asked again — it was an explicit, considered decision.

How to apply: if asked why a peer can't link on the client port, the answer is "use a server-only listener" (see s2s.kdl / the examples/simple.kdl 6067 port), not a leveva bug. A connect{} block alone does not open a port. Related: [[leveva-command-folder]] (the s2s/ modtree), the S2S slice in docs/progress-log/p11.md.

HARD RULE (maintainer, 2026-06-12): leveva MUST NOT support S2S commands on client connections. S2S verbs — ENCAP, UNICK, NJOIN, SAVE, EOB, EOBACK, SERVER, SMASK, SDIE, etc. — sent on a client port MUST return 421 ERR_UNKNOWNCOMMAND ("invalid command"), NOT be interpreted. This overrides THE STANDING RULE ([[leveva-native-oracle-harness]]) for S2S commands: the IRCnet oracle routes e.g. ENCAP/ HAZH/DNS from a registered client to m_nop/m_nopriv/handler by status column, but leveva does not — on a client port these are simply unknown commands. So do NOT "close" an oracle-supports-but-leveva-doesn't divergence by adding an S2S verb to the client dispatch; the correct leveva behavior is 421. S2S verbs are only valid on a server-only listener (the serve_server path).