axports

axports file

# /etc/ax25/axports
#
# The format of this file is:
#
# name  callsign        speed   paclen  window  description
# ----- -----------     ------- ------- ------- ---------------------------
ax0     PI1LAP-1        9600    128     4       144.850Mhz 1k2
ax1     PI1LAP-2        9600    128     4       430.950Mhz 9k6
ax2     PI1LAP-3        19200   256     4       Link local BBS pi8lap
ax3     PI1LAP-6        19200   256     4       Link local Dx pi1lap-4
ax4     PI1LAP-8        19200   256     2       AX25/udp via pi1lap-8
ax5     PI1LAP-9        19200   256     2       AX25/ip via pi1lap-9
ax6     PD9Q-7          19200   256     2       Link local Jnos pd9q
rose0   PI1LAP-11       9600    128     4       Rose port

 

Linfbb port.sys

Voorbeeld van port.sys die ik gebruik voor pi8lap

# BBS port.sys
#
# Number of Com Ports (not including Com 0) and TNCs
  3      10
#
# Interface 7 = TCPIP
# Interface 9 = LINUX
#
#Com Interface Adress (Hex)  Baud
 1   9           0       115200
 2   9        189C         0
 3   9        189D:189E:77       0
#
# Maxframe: The maximum number of frames the TNC will send at a time.
# NbFwd   : Number of channels for OUTGOING forward at the same time.
# MxBloc  : Size of forward-block in Kb.
#
# M/P-Fwd : Minute of the hour for start of forward, and period
#           (how many minutes between each forward-start).
# Mode    : One of these:
#           B : BBS-mode.
#           G : "Guest"-mode.
#           U : Normal-mode.
# Type host-mode, one of these:
#           D : WA8DED
#           K : KAM hostmode.
#           M : Telephone-modem.
#           P : PK-232
#           Q : BPQ v 4.x
# Addition: One of these letters can be used too:
#           L : Send unproto beacon after each arriving mail.
#           Y : Yapp allowed on this QRG.
#           W : Gateway allowed TO this QRG.
#           R : Read-Only acces.
#           E : Recommanded by JP F6FBB
#
# Freq.   : Text to describe this port (max 9 characters, no space)
# Same number of lines as number of TNCs.
#
#TNC NbCh Com MultCh   Pacln Maxfr NbFwd MxBloc M/P-Fwd  Mode  Freq
  0   0    0   0        0     0     0     0      00/01   ----  File-fwd.
  1   4    1   ax0      128   4     2     10     15/60   XULWY 144.850
  2   4    1   ax1      128   4     2     10     15/60   XULWY 430.950
  3   4    1   ax2      128   4     2     10     15/60   XULWY Node
  4   10   2   0        250   7     4     10     15/15   TUY   Telnet
  5   10   1   nr1      250   4     2     10     30/15   XUWY  NetRom
  6   10   3   0        250   7     4     10     00/10   SU    Pop/smtp
  7   10   1   rose0    250   4     4     10     30/15   XUWY  Rose
  8   10   1   ax4      250   4     4     10     30/15   XUWY  Axudp
  9   10   1   ax5      250   4     4     10     30/15   XUWY  Axip
 10   10   1   ax6      250   4     4     10     30/15   XUWY  Jnos
#
# Special callsigns and modes for some channels
# TNC Nbs Callsign-SSID Mode
# 1    2   XXXXX-1       B
#
# End of file

 

Allowing traceroutes to succeed with iptables

Traceroute from Windows machines typically uses ICMP Type 8 packets.  Traceroute from Unixlike machines typically uses UDP packets with sequentially increasing destination ports, from 33434 to 33534.  So your server (the traceroute destination) must not drop incoming ICMP Type 8 or UDP 33434:33534.

Here’s where it gets tricky: it really doesn’t need to accept those packets either, which the vast majority of sites addressing this issue recommends.  It just needs to be able to reject them, which won’t happen if they’re being dropped.  If you implement the typical advice – accepting those packets – traceroute basically ends up sort of working by accident: those ports shouldn’t be in use by any running applications, and since nothing is monitoring them, the server will issue an ICMP Type 3 response (destination unreachable).  However, if you’re accepting packets to these ports, then a rogue application listening on those ports also becomes reachable – which is the sort of thing your firewall should be preventing in the first place.

The good news is, DROP and ACCEPT aren’t your only options – you can REJECT these packets instead, which will do exactly what we want here: allow traceroutes to work properly without also potentially enabling some rogue application to listen on those UDP ports.

So all you really need on your server to allow incoming traceroutes to work properly is:

# allow ICMP Type 8 (ping, ICMP traceroute)
-A INPUT -p icmp --icmp-type 8 -j ACCEPT
# enable UDP traceroute rejections to get sent out
-A INPUT -p udp --dport 33434:33523 -j REJECT