I'm been seeing rather a storm of incoming packets to the amprgw gateway;
there are six times as many inbound packets to routable AMPRNet addresses
as outbound. The firewall is doing its duty: in the last about 24 hours
it's discarded 9,905,154,331 incoming packets as being from bad guys,
and of the packets that did get past the badguy list, 24,974,234,978
were discarded. It's running around 30 MB/s, at about 20 million packets
a minute.
Looking at the incoming traffic, it appears to be mostly TCP connection
requests with large window sizes to varying 44.x.x.x addresses, with lots
of different destination port numbers but many are to port 23 (TELNET)
and port 80 (HTTP). There's a goodly number of UDP requests to port 53
(DNS) too.
The system seems to be about 85% idle.
- Brian
I just found and fixed a bug in the router where it would occasionally
reject a valid destination as being an encap-to-encap route and discard
the packet.
Detail: Rob's address-mask-and-index scheme with the huge global
addresses array only works if you FIRST check that the address
is on network 44. Oops.
Anyway, I restarted the packet errors tallys so they won't show the
erroneous results of this bug.
- Brian
I have also noticed that traceroutes through the amprgw router
don't seem to work, although the destination host is reachable.
I have yet to spend much time on figuring out why this is.
- Brian
On Fri, May 05, 2017 at 11:35:40PM +0100, M6XCV (Mike) wrote:
> I think this is because you are trying to send via the gateway.
>
> I am not sure why, but I have tried using the gateway to access the
> internet and my packets go missing. I assumed it should work, however the
> fact that it did not was not something I thought it was worth investigating
> as I am BGP routed. If are trying to reach me through the main gateway then
> perhaps it is worth asking Brian to look in to it?
>
> For the record, I attempted to ping you and my outbound seems fine.
> https://u4477715.ct.sendgrid.net/wf/click?upn=MJaTQVDJZogYIZySndf7y-2BCWLgZ…
> 668edee920.pcap
>
> I can ping 44.0.0.1. Traceroutes also show my packets reach the gateway but
> go no further. I added a static route for 8.8.8.8 encapped via the gateway
> and it gave me this.
>
> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> 1 onsite.notmike.uk (44.131.14.129) 0.412 ms 0.392 ms 0.382 ms
> 2 Gateway.AS206671 (44.131.14.254) 9.972 ms 9.989 ms 9.988 ms
> 3 amprgw.sysnet.ucsd.edu (169.228.66.251) 158.942 ms 158.981 ms
> 159.397 ms
> 4 * * *
> 5 * * *
>
> I suspect a firewall rule, however there are A records under ampr.org for
> all of my IP addresses.
>
> Thanks,
> Mike, M6XCV
Hello All,
I've just implemented the newest version of Marius' Mikrotik script
which enables accessing 44net IPs using a gateway in 44 address space,
and was wondering if there is an IP which uses this configuration I can
test my setup against. The network which Marius was originally tested
with (44.130.120.0/24) seems to no longer be present in my routing table.
Cheers!
Chris
VE7ALB
The top 5 misconfigured gateways: These account for more dropped packets
than all the rest of them.
These are stats from midnight local to about 20 hours later.
The fifth entry is kind of interesting; it has an inner source address
of amprgw itself, which is clearly wrong. I don't quite see how that
could be happening.
These AREN'T causing any noticeable problems for amprgw or anyone else,
but a lot of things must not be working properly for those gateway operators.
I mention them here because the gateway operators may be scratching
their heads over why some connections don't seem to be working.
- Brian
Last update at Thu May 4 20:15:01 2017
gateway inner src #errs indx error type
---------------- ---------------- ----- ---- -------------------------------
77.138.34.39 192.168.1.180 26168 [19] dropped: non-44 inner source address
174.97.179.219 44.92.21.35 24627 [ 8] dropped: encap to encap
23.30.150.141 23.30.150.141 17839 [19] dropped: non-44 inner source address
59.167.198.158 44.225.125.2 8137 [ 8] dropped: encap to encap
85.234.252.133 169.228.66.251 6361 [19] dropped: non-44 inner source address
[etc]
> Oops; 23.30.150.141 is me. I think I've mitigated it via firewall rules now.
It is often caused by traffic from the gateway system itself where the system has
decided to use the internet source address rather than the desired 44-net address.
On your system this is more likely to happen because your internet address is lower
than 44. (when there is a complete tie on what address to use one of the last decisions
sometimes is to use the lowest address)
You can often this by setting a preferred source address on some route(s), in this
case probably a default route in the AMPRnet-specific route table pointing to amprgw.
Rob
On Wed, 26 Apr 2017, Brian Kantor wrote:
> 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.
I think I'm closer to finding out why this happens. I use a firewall rule
(using FreeBSD ipf(8)) to make sure that traffic leaving my network with a
source of 44.0/8 is redirected to the tunneling interface:
# Make certain AMPR/44 hosts reaching outwards will tunnel through AMPR
# gate
pass out quick on vlan0 to gif0:44.0.0.1 from 44/8 to any
I believe, however, that in picking up and relocating the packet this way, I am
perhaps taking a packet that was destined for some interface acceleration (such
as offlined checksumming and the like) and placing it on an interface queue
that has no such optimizations.
Still more research required, but I see the problem now.
-J
Hi there
Long ago the AMPRNET was defined that both IP PID 94 and 4 was working ?
What is situation today ? will it work with PID94 ?
if possible may someone explain why we moved to PID4 ? as at this period I wasnt active with the AMPRNet
Thanks for any info
Ronen - 4Z4ZQ
http://www.ronen.org
2) Why there is no option to add attachment (or graphics ) to the list ? is it because of Disk space ? etc ?
from time to time it is usefull to have a screen capture of log of network related issues
Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
www.ronen.orgronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
The ipip router at UCSD is not very busy (99% idle), but I am surprised
at the number of dropped packets. It's higher than I would have hoped,
suggesting there are a significant number of misconfigured routers on
the network.
- Brian
------------------------------------------------------------------
started at Tue May 2 20:49:25 2017
snapshot at Tue May 2 22:00:00 2017
uptime: 0+01:10:35 (4235 seconds)
idle: 4194.615196 secs (99%)
packets/bytes
---------/---------
181908/50252930 ipip encapped input
170575/45757610 forwarded out unencapsulated
1/56 dropped: no source gateway
1666210/125325363 unencapsulated input
1666196/125324029 encapped out
0/0 dropped: no destination gateway
5994/447291 dropped: encap to encap
0/0 ttl exceeded
0/0 icmp sent
0/0 dropped: packet too large
0/0 dropped: zero outer source address
0/0 dropped: broadcast outer destination address
0/0 dropped: packet too short
0/0 dropped: zero inner source address
481/66757 dropped: broadcast inner destination address
13/676 dropped: multicast inner destination address
4781/337160 dropped: non-44 inner source address
0/0 dropped: embedded encap protocol
35/1400 dropped: ip_len > MTU and DF
0/0 dropped: ip_len != packet size
0/0 dropped: output packet too short
0/0 dropped: output packet too long
4181/347878 dropped: output blocked by firewall
1/40 dropped: kernel send error
0/0 dropped: multicast inner source address
1171/1756463 outgoing encapped IPIP packet will be fragmented by kernel
2019413 route lookups took 1782499 microseconds (0.88 usec/lookup)
2 route table updates took 0.008852 seconds (4 msec each avg)
> - Are you saying that some AMPRNet OPs simply forward packets to their
> WAN interface...WITH INVALID SRC IPs from their 44.0.0.0/8 RANGE?!?!
Some do that, yes. The SRC IPs are not invalid but they are not their allocated IP from their ISP.
Some poor ISPs allow that (lack of BCP38 source address filtering)
However, the reason we are on the IPIP network is to allow others that are there to communicate
with us without doing that. They can send their traffic in a proper IPIP tunnel. That would not
be possible when we were only on BGP.
Rob
