AX25RTD.CONF(5)

🌸 NAME 🌸

okay so bestie, this is ax25rtd.conf — like, literally the configuration file for the ax25 routing daemon 💖 it lives in the Linux Programmer's Manual corner of the world and yes it's AX25RTD.CONF(5), we're fancy like that 💅

---

✨ SYNOPSIS ✨

/etc/ax25/ax25rtd.conf

---

🎀 DESCRIPTION 🎀

so the file /etc/ax25/ax25rtd.conf is the configuration file for ax25rtd. every parameter you're about to see is showing you its default value — unless it's marked with (example), in which case it's just a lil demo, not the default, got it? 🫶

• ax25-maxroutes 4096
• ip-maxroutes 4096

these two set the maximum size of the three lists / caches. and when they overflow? ax25rtd just substitutes the oldest entry with the new one — out with the old, in with the new, iconic behavior honestly ✨

• iproute2-table radio — the name ("radio") of the kernel routing table. this is an advanced routing feature; if you don't need it, literally just leave this setting as is, no thoughts head empty 💅

the current implementation depends on iproute2 (anyone like to code it directly? 👀 ngl that's a real question from the original authors, I'm just the messenger).

if it's not set or it's empty, routes get set in the normal, default manner. but if you <em>are</em> using it, please configure /etc/iproute2/rt_protos with

44      ax25rtd

and /etc/iproute2/rt_tables with

210     radio

where "radio" is the name of the table (for the configuration example above, iykyk).

heads up bestie: this option is disabled by default.

• ip-encaps-dev ipax0 — this one was for a patched kernel of the 2.2.x series. multiple interfaces were aggregated to one interface when sending IP frames. it's disabled by default 🦋
• [1k2] — this marks the beginning of the per-port definitions 🎀 and okay, important: you have to use port names as defined in axports(5) here. anywhere else you may use the port <em>or</em> the device name. don't mix it up bestie, it's giving "read the room" energy.
• ax25-learn-routes no — set this to "yes" and ax25rtd will add the routing information for every heard frame (with complete digipeater path) to the kernel AX.25 routing table. note that ax25rtd's internal cache will be updated anyway, regardless of this option. so like, the cache is always getting fed, this option is just about the kernel table 💅
• ax25-learn-only-mine no — set it to "yes" and only frames sent to (1) the interface callsign, (2) any of the listeners on this device, or (3) the callsigns specified by ax25-more-mycalls will be used to update the internal cache and (depending on ax25-learn-routes) the kernel routing table. so basically: only my people ✨
• ax25-add-path db0ach (example) — this is useful on DAMA digipeaters. in that case, the DAMA master has to be used for <em>every</em> AX.25 connection, so ax25rtd will add this digipeater(s) to every target we learn that has no digipeater path (yet). "db0ach" is just an example here, don't come for me 🙈
• ax25-more-mycalls dl1bke dl1bke-8 (example) — you can specify more calls as calls here that belong to this interface... "dl1bke" and "dl1bke-8" are examples. main character callsigns only, periodt 👑
• ip-learn-routes no — if you set it to "yes", ax25rtd will modify the IP routing table if it receives an IP frame (directed to us). this is dangerous! 💀

it should not screw up your routing table, though. ax25rtd recognizes the netmask of the device and will adjust the route only if it fits the netmask and the old route points to one of the devices ax25rtd knows about (hence an AX.25 device). so like, it's checking the vibe first 🧚

the problems begin if you have more than one port and a user is able to hear your outgoing traffic on at least two of them. due to technical reasons ax25rtd adjusts the route <em>after</em> the kernel has sent the reply to the received TCP frame already. this has technical reasons.

if the remote does the same, both are switching between the two ports. 😭 chaos.

don't use this feature unless you know what you are doing.

it <em>should</em> be safe to enable this on one-port machines, although I strongly recommend to set a network route instead, i.e.:

route add -net 44.0.0.0 scc3

note that ax25rtd's internal cache will be updated anyway, regardless of this option. again. always. the cache does not care about your flags 💅

• irtt <irtt> — if ip-learn-routes is enabled, this will assign newly added routes an initial round trip time (IRTT) for TCP. <irtt> is measured in msec, hence

irtt 10000

sets the irtt to 10 seconds. a value of 0 disables this feature (default). math is mathing 🌈

• ip-adjust-mode no — set this option to "yes" and ax25rtd will change the IP encapsulation mode according to the last received IP frame.

the problem with this option is that the kernel AX.25 sends a received IP frame to the IP layer regardless if it was sent in UI frame encapsulation "mode datagram (dg)" or in I frame encaps, hence in an AX.25 connection, "mode virtual connect (vc)". the Linux kernel will respond to this frame <em>before</em> ax25rtd can adjust the mode. if the remote does the same... you get the picture. 🙈

don't use this feature unless you know what you are doing.

• arp-add no — this option, if set to "yes", changes the ARP table to the source callsign of the received frame. it should be harmless, it just has the effect that if it is a new entry, the Linux ARP code will send one ARP request before ax25rtd has adjusted the ARP table. if there was already an existing ARP entry for this IP route, one IP datagram will be sent to the old address. not really a problem, I hope. 🫶 (that "I hope" is the original author's energy and honestly? relatable.)

---

🔥 SEE ALSO 🔥

• ax25rtd(8)
• ax25rtctl(8)

---

👑 AUTHORS 👑

• Joerg Reuter <jreuter@poboxes.com>
• Llaus Kudielka OE1KIB

---

and that's the whole thing bestie, slay 💖 this page came out of the Linux manual on 11 November 2003, filed under AX25RTD.CONF(5) — go forth and configure responsibly, no cap 🌸✨