A few times a minute, a host claiming to be ke6jjj-8 (44.4.39.8)
is sending an encapped packet that is peculiar: it is either 40 or 44
bytes long, but the length field in the IP header is set to a varying but
very large packetsize (for example, 61,683 bytes) and the Don'tFragment
bit is set so the amprgw IP kernel sending routine can't break it up
into MTU-sized fragments - thus it gets a transmit failure and isn't
sent anywhere.
The inner source is always 44.4.39.8, but the destination varies a lot.
I'm completely puzzled by this: I don't know how any common operating
system would be generating such a packet.
I can see how a naive IP implementation might have a problem when
receiving a packet that is relatively small but claims to be large.
Does anyone know: is this a deliberate attempt to sabotage the destination
host?
- Brian
> the rip sender;
Is there any tool for doing local Rip packet generation similar to the
main AMPRNet one? Perhaps Github or ?
I'd like to use it for testing and, prior to opening up with the
official system, building both local and community 44-net subnets.
73 and thanks..
Bill, WA7NWP
How do you add a subnet to a gateway? I have a /24 assigned to me and
I want to use a /32 of it with an IPIP gateway. I added the gateway in
the portal. Then when I went to add the network, the /24 is listed in
the dropdown but I can't figure out how to add the network with a
larger prefix. I don't want the whole /24 to route through this one
gateway.
Tom KD7LXL
> How do you add a subnet to a gateway? I have a /24 assigned to me and
> I want to use a /32 of it with an IPIP gateway. I added the gateway in
> the portal. Then when I went to add the network, the /24 is listed in
> the dropdown but I can't figure out how to add the network with a
> larger prefix. I don't want the whole /24 to route through this one
> gateway.
That cannot be done. You can only gateway registered subnets.
You would have to get the /32 assigned to you as well, and I think that will be
rejected when the /24 already is of the type "End user".
Maybe it can be done manually by one of the portal admins....
Rob
I just found and fixed another off-by-one error in the rip sender;
this one had the effect of omitting the last route in each sent
packet. Packets should hold up to 25 routes; they were being sent
one route short at 24.
Effectively, 25 subnets were missing from the rip transmissions.
Oops. Sorry folks.
- Brian
These are the rules that route AMPRNet traffic to and from the
ipip daemon (FreeBSD ipfw syntax):
#
# AMPR routing
#
# table(1) contains all registered/routable 44net addrs.
# table(2) contains all registered gateways.
# outbound encapsulated packets
# should go only to registered gateways
00100 allow ipencap from me to 'table(2)'
# inbound encapsulated packets
# should only come from registered gateways
00200 allow ipencap from 'table(2)' to me
# filter the 44net input side of things
# valid destination addresses go to the router socket: ipipd
00300 divert 4444 ip from any to 'table(1)' in not dst-port 111,135-139,445,1025-1028,1900,2323,5353,7547
# filter the 44net output side of things
00400 allow ip from 'table(1)' to any
Explanation:
Preliminary filtering of incoming packets is done by the BSD
ipfw firewall because it's easy to set up and very fast. Quite
a bit more filtering is done by the ipip router daemon.
Ipfw table 1 contains a list of the 44-net host addresses from
the AMPR.ORG DNS zone file that are routable according to the
encap file. Table 2 contains a list of the gateways from the
encap file.
Once an hour, the AMPR.ORG DNS zone file is fetched, normally at
10 minutes past the hour. Also hourly, the encap file is fetched
from the portal, normally at 20 minutes past the hour. Whenever
these files differ from their previous version, the ipfw tables are
flushed and reloaded. When the encap file changes, the ipipd
routing and the rip sender tables are also reloaded.
Rule 100 allows the encapped packets out to registered gateways.
Rule 200 allows encapped packets in only from registered gateway
source addresses.
Rule 300 diverts incoming IP to the ipipd encapsulating router
if the destination address is for a registered/routed address
and not for certain destination ports.
Rule 400 allows outgoing IP with source addresses from registered/routed
hosts.
That's about all the filtering that can be done without looking inside
the encapped packets, which the BSD firewall can't do. The ipipd daemon
handles that, and is much stricter.
- Brian
Hello,
Since the appearance of the 44.0.0.1 route in RIP, some of you using the
Mikrotik script may have noticed the disappearance of the RIP broadcasts
and missing updates.
This happens because of the creation of a alternative tunnel from your
router to ampr-gw (ampr-169.228.66.251), which highjacks the normal
ampr-gw tunnel.
To correct this, follow the following steps:
1. under routing->prefix list create the following rules in the given order:
chain ampr, prefix 44.0.0.1, prefix length 32 discard
chain ampr, prefix 44.0.0.0/8, prefix length 8-32 accept
chain ampr, prefix 0.0.0.0/0, prefix length 0-32 discard
2. under routing->rip->interfaces on your ucsd-gw set the 'ampr' prefix
list as 'In Prefix List'
3. under interfaces find and delete interface ampr-169.228.66.251
4. under ip->routes find and delete the route to 44.0.0.1 via unknown
5. Optional: if you like to have 44.0.0.1 routed via tunnel, add a
static route for 44.0.0.1 via interface ampr-gw.
Marius, YO2LOJ
> Belows IP's belong to SR3BBS gateway
> which _IS OFF LINE_ for a long time!
Then why is it in the table?
Maybe it should again be considered to add a mandatory field to a
gateway registration with a net-44 IP that should be pingable via the tunnel
(e.g. the IP of the gateway itself) and run some very infrequent ping
to that address from a monitoring system that is also on the tunnel network
(not amprgw as some people apparently choose not to tunnel to that system).
When e.g. one ping per hour is made and nothing is heard for 7 days or even more,
the gateway can be marked down and removed from the encap.txt and RIP broadcast.
The operator can then re-enable it via the portal.
Rob
Hi everybody,
Just to clarify the issues related to "strange routes" appearing during
the use of the rip daemons.
Together with Jann, DG8NGN, we devised a solution for interoperating BGP
announced 44 subnets with the current full mesh tunnel system.
Initially I implemented the system for testing and proof of concept in
the Mikrotik script v.3.0, and later in the ampr-ripd starting with
version 1.16 and amprd version 1.5.
Current versions are 1.16.3 for ampr-ripd (bug fixes and small
enhancements) and 1.6 (bug fixes), please use these.
Now to the idea behind it...
Directly BGP announced gateways need to be reached, well, directly, as
any other gateway.
If we have a default route by which we could reach the BGP announced
hosts (via your public IP, please don't use default routes via amprgw!),
on installing a subnet route via the RIP daemon, e.g. 44.130.121.0/24
(it is a working test host) then the endpint 44.130.121.2 will also be
routed via the tunnel, creating a loop, which is of course wrong.
So ampr-ripd will detect your default gateway on the system, and set
host routes for those direct gateways via the default gateway, if the
RIP announced gateway has a 44 address.
The detection of the default gateway is done by getting the route to
8.8.8.8 from your kernel tables.
So you will end up with 2 routes for that entry, like:
44.130.121.0/24 via 44.130.121.2 dev tunl0 proto 44 onlink
44.130.121.2 via 192.168.1.1 dev eth0 proto 44 onlink.
In this case, traffic for those subnets (in this case to
44.130.121.0/24) will be encapsulated and sent directly to 44.130.121.2,
which is reachable via internet.
It is expected that your system will nat those destinations to your
public IP (which probably happens).
If the detection of your default gateway is not correct, there is a
parameter '-g' by which you can set your gateway IP by hand.
Your internal addresses are not published, nor are the known to the
gateway. It is a local lookup performed by the daemons.
At the moment there are 4 functional gateways using this setup:
44.130.121.2, 44.130.122.2, 44.130.124.2 (as test systems) and
44.131.14.255 as a live setup.
Reachable tests hosts are: 44.130.121.3, 44.130.121.130, 44.130.122.3,
44.130.122.130, 44.130.124.3, 44.130.124.130, and of course the end points.
(44.130.121.2 runs amprd, 44.130.122.2 runs ampr-ripd and 44.130.124.2
runs the Mikrotik script).
I hope this clarifies some of the questions that may arise.
Have fun with the hobby,
Marius, YO2LOJ
amprgw has recently logged several discarded packets like the following:
Apr 24 18:44:03 <local0.info> amprgw ipipd[1518]: IBCAST: len 149, os 208.110.114.235, od 169.228.66.251, is 44.135.193.18, id 255.255.255.255, ttl 64, proto 17
encapped packets aren't supposed to send to the broadcast address (255.255.255.255).
Apr 24 18:44:05 <local0.info> amprgw ipipd[1518]: ISRC0: len 122, os 77.138.34.39, od 169.228.66.251, is 0.0.0.0, id 255.255.255.255, ttl 64, proto 17
encapped packets aren't supposed to come from address 0.0.0.0 and
encapped packets aren't supposed to send to the broadcast address (255.255.255.255).
Apr 24 18:44:06 <local0.info> amprgw ipipd[1518]: TIMXCEED: len 52, os 85.234.252.133, od 169.228.66.251, is 44.165.53.254, id 224.0.0.9, ttl 1, proto 17
Looks like a routing loop on RIP packets.
Ah well, variety is the spice of life...
- Brian
