44net

44net@mailman.ampr.org

3198 discussions

Re: [44net] Stats
by Rob Janssen 23 Oct '16

23 Oct '16

> Actually, Steve, because of the host-level filtering at amprgw, > only 17652 hosts addresses implied in the encap file go anywhere. > - Brian That is what I wanted to suggest as well. You cannot calculate the number of reachable hosts from the subnet sizes alone. Not even when you subtract two (network- and broadcast address) for every subnet you know about. And please do not try to resolve this puzzle by trying to ping every host... Rob

1 0

Re: [44net] Stats
by Steve L 23 Oct '16

23 Oct '16

Rob, Its a count of the number of routed hosts, taken from the encap file and the BGP announce list. Small math bug, but the number of hosts was right. So about 10% of the 44/8 allocation actually goes somewhere. 10/22/16 Routeable Ampr.org 44/8 Net Stats: ENCAP Total Hosts: 1224922 ENCAP Percent: 7 BGP Total Hosts: 581204 BGP Percent: 3

2 1

Re: [44net] Stats
by Rob Janssen 23 Oct '16

23 Oct '16

What do these numbers mean? Rob

1 0

Stats
by Steve L 22 Oct '16

22 Oct '16

I created a little script because I was curious, so I figured I'd share what it told me: 10/22/16 Routeable Ampr.org 44/8 Net Stats: ENCAP Total Hosts: 1224922 ENCAP Percent: 13 BGP Total Hosts: 581204 BGP Percent: 28

1 0

EdgeRouter/EdgeOS Wiki
by Rob Janssen 21 Oct '16

21 Oct '16

> Quick question, is the EdgeRouter wiki page outdated? Just did it by the > letter, but I got no outside ping to my router's IP. Well, what is described there does not constitute a proper AMPRnet gateway, i.e. with such a setup you can only communicate between your own subnet and internet via the amprgw at UCSD, *not* with other users of the AMPRnet network! When you cannot ping from addresses outside 44.0.0.0/8, check: - is your router IP (and other IPs you want to use) registered in DNS for .ampr.org? - is protocol-4 traffic being passed to your EdgeRouter? (not filtered by some other modem/router you may have in front of it) Rob

2 2

EdgeRouter/EdgeOS Wiki
by Miguel Rodriguez 21 Oct '16

21 Oct '16

Hey folks! Quick question, is the EdgeRouter wiki page outdated? Just did it by the letter, but I got no outside ping to my router's IP. -- Miguel Rodriguez 12th Grade Student miguemely101(a)gmail.com Tel: *561-758-0631* *Accredited District Since 2008; Re-certification - January 2013* Home of Florida's first LEED Gold Certified School *Disclaimer*: Under Florida law, e-mail addresses are *public records*. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing.

1 0

Re: [44net] Dynamic IPENCAP Filtering on OpenWRT/iptables-based devices
by Rob Janssen 21 Oct '16

21 Oct '16

> I have implemented the dynamic IPENCAP firewall script in OpenWRT; and > it works! I did not mention in the mail that I had to resolve those catch-22 effects as well... In my system, I initialize the firewall using a shell script that has a long list of iptables commands in it. I prefer that over manipulating it ad-hoc and then saving it using iptables-save, because I can put comments in the script, use variables to hold values like the external and internal IP addresses, etc. Inside this script, after the commands to erase any existing rules, I first call the update script I posted that populates the ipipfilter so I can add that in the rule for incoming -p 4 traffic without getting a nonexisting chain error. (it is not possible to forward-reference chains in iptables) For other purposes I now use "ipset" to hold such lists of addresses instead of a long list of rules that matches them one by one. Is more efficient as well, but in my Linux version it is not possible to keep hit counters for ipset members, which I would like to do (to occasionally check which gateways actually send traffic to us). Using an ipset could resolve the issues that you have been facing, as one can create the empty ipset before setting up the iptables, put the public address of amprgw in it (hardwired), then start ampr-ripd and let it receive the tunnel information and put it in the ipset. You never have unresolved values while doing that. You can use ipset like this: ipset create gateways hash:ip ipset add gateways 169.228.66.251 and then in the firewall: iptables -A INPUT -p 4 -m set --match-set gateways src -j ACCEPT The script called from ampr-ripd would then use "ipset add", "ipset del" and "ipset list" commands to manipulate the set similar to what I did with iptables. Rob

1 0

Re: [44net] Information - Traffic Attempt to Route Through my Node
by Rob Janssen 20 Oct '16

20 Oct '16

> Rob, > You stated: > "When you are worried about intrusions it is probably more effective to > block IPIP packets from sources that are not in the gateway list. I do > that as well (via ampr-ripd)." > What command/script do you use to add the endpoints to iptables? I have posted it before on this mailinglist: http://hamradio.ucsd.edu/mailman/private/44net/2014-November/003577.html This script manipulates an iptables chain. It would be possible to do a similar thing with the "ipset" command to manipulate an address list when you are familiar with that (I wasn't when I wrote this script). Advantage of using iptables is you have statistics per rule in the table so you can see which IPIP peers are sending traffic to you. New versions of ipset support counters but the one I am running doesn't. With a command like this you get a quick overview of your active IPIP peers: iptables -L ipipfilter -vn | grep -v ' 0 ACCE' Rob

2 1

Re: [44net] test ping
by Rob Janssen 18 Oct '16

18 Oct '16

> For years, my node had similar behavior, causing various kinds of > intermittent issues. The problem was solved when I added an iptables > rule permitting inbound IPENCAP: Ok in your case it was a configuration error? Of course we should make sure that there is no error outside the router, e.g. by using wireshark to confirm that IPIP packets are not arriving when the source is new. Well, it will be a tricky investigation especially when we have to instruct those that are not so proficient in networking to determine the cause of the problem. (gateway system, internet router, maybe ISP filters or cgNAT) Rob

1 0

Re: [44net] test ping
by Rob Janssen 18 Oct '16

18 Oct '16

> No, it is not ok. > It is working because of connection tracking if YOU access the page. > Here the output ofhttp://yo2tm.ampr.org/nettools.php ping: > Ping Output: > PING 44.153.32.97 (44.153.32.97) 56(84) bytes of data. > --- 44.153.32.97 ping statistics --- > 4 packets transmitted, 0 received, 100% packet loss, time 2999ms Indeed, it is not working correctly. He sent me a mail telling me that he could ping me at 44.137.41.97 and I happened to be at the computer when it came in, I immediatelu tried to ping back and it worked. Then I waited an hour, tried again, and again it did not work. So all symptoms point to a stateful firewall of IPIP traffic, probably in his ISP router. I suspect that some NAT routers do a connection tracking firewall even when the DMZ HOST is set in the config. The DMZ HOST only receives all TCP and UDP traffic, but not protocol-4. However, just like all other hosts on the LAN, it can send out protocol-4 traffic and receive the "reply" traffic. So doing outbound connections works, but inbound on an idle tunnel is not working. It would be interesting to investigate which routers suffer from this bug, so a list can be made on the WiKi page. I think quite some gateway stations have this fault. The operator believes he has a working gateway because he can connect whatever other gateway station he tries, but incoming connects do not work when there has been no prior traffic. (of course the same thing happens when DMZ HOST is not set at all, so this has to be properly investigated) Rob

4 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net