- 44net - mailman.ardc.net

by Rob Janssen

> Subject: > Re: [44net] ampr-ripd update 1.14 > From: > Marius Petrescu <marius(a)yo2loj.ro> > Date: > 09/21/2016 06:59 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu>, "Ana C. Custura" <ana(a)netstat.org.uk> > > > On my server running Debian 8 with kernel 3.16.0-4-amd64 it works > without the '-r' flag. > > I actually wanted to remove that flag, but then it will break the > scripts using it. > > I will make a new release that ignores that flag but still accepts it as > parameter, but runs always in raw mode. > > I think this would be the proper approach. Ok, the multicast mode of course is a good thing, but it has caused some strange behaviour in the past. You could of course keep the old code in there using some #ifdef option for those that want to try it. Or introduce a new flag that switches from raw to multicast mode. Raw mode always works, but in some cases may have some more CPU overhead. Not sure if it is a noticable difference... Rob

9 years

3
4
0 0

ampr-ripd 1.15

by Marius Petrescu

Hello, Another update... To keep everything as simple as possible and since this seem to work on all systems, only raw socket mode is used (parameter -r is ignored, so you don't have to change anything in your startup scripts). Please note that no functionality has actually changed compared to 1.13, so if you are happy with your current setup, no change is needed. These changes are basically aimed to newcomers and will bring nothing new to existing users. Internet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.15.tgz 44Net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.15.tgz or from GitHub: git clone https://github.com/yo2loj/ampr-ripd.git Have fun, Marius, YO2LOJ

9 years

1
0
0 0

Re: [44net] ampr-ripd update 1.14

by Rob Janssen

I think it is a good idea! The password has often confused newcomers and made it harder to debug an intial setup. How about the -r flag? Some time ago it became necessary for me to use it, apparently due to changes in the kernel around multicasting. Is this still the current situation on the latest Debian release? Or can ampr-ripd again work without -r? Depending on this, it may be good to make some change in that default too. Rob

9 years

2
1
0 0

Greetings from Poland!

by Jakub Kramarz

Dear 44net group subscribers, My name is Jakub Kramarz (SP0NGE) and I'm writting on behalf of Hackerspace Kraków foundation (callsign SP9HACK) in Poland and I'd like to say hello to this community :-) We're a group of Linux and networking professionals, web and embedded developers, security researchers and finally radioamatours who has recently started our small, personal war to bring HAM radio back to young people in our country. In recent time, we've successfully: - in cooperation with SP9KGP club, we held 3 comprehensive HAM radio courses in Kraków, converting 40 enthusiasts to fully-fledged radio operators (~ the number of Polish Amateur Radio Union's new members in whole country), - held an important role in securing radio communication during World Youth Day 2016, - operated multiple occasional stations (supporting Great Orchestra of Christmas Charity, promoting Woodstock Festival Poland, ...), - supported Radioreaktywacja (Radio Reactivation) initiative, who "infects" the youngest with our hobby, by sharing hardware and knowledge, - and, finally, contributed to numerous open source and open hardware radio-related projects, eg. mcHF QRP firmware I hope we'll be able also take a part in AMPRNet project and contribute to digital communications over radio. Serdecznie pozdrawiam / Best regards, Jakub Kramarz http://about.me/jkramarz Sent from Makita TD090DWE impact driver

9 years

1
0
0 0

Posting from HamWAN Tampa @ DCC

by Bryan Fields

I'm on the 15th floor, 17 Miles from Tampa in St Petersburg, getting 20mbit/s with some refraction through glass in the club here. 73's -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

9 years

1
0
0 0

rip down ?

by Maiko Langelaar

Did we loose the rip broadcast ? Maiko

9 years

5
5
0 0

Re: [44net] getting rip data fron the non ampr address of ucsd gw?

by Rob Janssen

> Please be aware the protocol is RIP44, **NOT** RIPv2. You must install > and run a daemon that processes RIP44 (e.g. ampr-ripd and rip44d). He uses a solution devised by Marius to work around that problem on a MikroTik router. Rob

9 years, 1 month

1
0
0 0

Re: [44net] getting rip data fron the non ampr address of ucsd gw?

by lleachii＠aol.com

Ronen, Please be aware the protocol is RIP44, **NOT** RIPv2. You must install and run a daemon that processes RIP44 (e.g. ampr-ripd and rip44d). See: http://wiki.ampr.org/wiki/RIP 73, -Lynwood KB3VWG

9 years, 1 month

1
0
0 0

cant get rip in MicroTik

by R P

I tried to follows the instructions that written here http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt www.yo2loj.ro<http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt> www.yo2loj.ro Setup example - please adapt ===== (ASSUMPTIONS: public ip is 89.122.215.236, router's ampr ip 44.182.21.254, WAN interface is PPPoE-In): You ... I have a working tunnel on the router called UCSD (the tunnel interface have no IP adress) my router is in bridge mode because it connect to cable modem before of it and sit on a DMZ address of the cable modem It uses ether1-gateway interface as the 44 net address (4.138.1.1) it uses ether2-master-local as the ip connected to the Cable modem (it uses 192.168.1.180 and default gateway to the cable modem ip which is 192.168.1.1) I have no firewall working and i get no RIP routes I have changed the tunnel interface name in the instructions to meet my interface name .. on the VRF if i chose the tunnel interface the routes (or maybe the tunnel) stop and i cant access anymore the 44 net hosts from the outside world and i see no rip info when i change the interface to the ether1-gateways (the one that have the 44 net address) the routes are ok the hosts are accessible from the outside world but i still not seeing any rip info what is wrong ? how can I debug it ? if needed i can provide password to the router since it is accessible from the outside world Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

9 years, 1 month

2
2
0 0

Re: [44net] getting rip data fron the non ampr address of ucsd gw?

by Rob Janssen

> Let's not forget... > If you are unable to get RIP broadcasts for any reason, you can get the > encap data from the portal as a json file via its API. Sure, but please note that this does not solve the underlying problem of not being able to receive unsolicited IPIP traffic I mentioned. When that is the reason (rather than inability to follow installation and debugging instructions), the result will be a partially-working gateway. That gateway will be usable to contact other stations on the AMPRnet, but those other stations will not be able to contact your systems. Outgoing connects are OK, incoming connects are not. While some people my consider that a usable system, it is not a desirable situation. The AMPRnet is more peer-to-peer than the internet in general, in that anyone is expected to be both a participant and a consumer, not only a consumer as is usual on the internet. Rob

9 years, 1 month

1
0
0 0

Re: [44net] getting rip data fron the non ampr address of ucsd gw?

by Rob Janssen

> So the password is sent from UCSD and compered with the password i put locally and if they identical then the data is processed ? > one more thing i understand the data is sent from UCSD ... how often is it sent ? > I dont see any advertisement here do i need to define something in the portal ? > normal tunneling work well Of course you need to have a gateway entry in the Portal. I.e. you need to have a subnet, and a gateway with external address and that subnet defined. The RIP packets are sent every 5 minutes. When you can manually make a tunnel and ping the remote, but you do not receive anything including RIP broadcasts, the cause often is a stateful firewall inside your internet modem/router. It accepts replies to outgoing packets, but it does not accept unsolicited incoming packets. This is designed as a security feature. To use IPIP tunneling, your modem/router must be able to unconditionally forward protocol-4 traffic to your gateway system. In advanced modem/routers you can forward a protocol, but usually it is only possible to forward TCP and UDP ports. That is something different. It is useless to forward port 4, you have to forward protocol 4. When that cannot be done you can often set a "DMZ host" that is said to get all incoming traffic, however there are examples of modem/routers where this does not work correctly. The DMZ host receives all TCP and UDP traffic but not all other traffic (including IPIP). It does receive (like any host) replies on its own IPIP traffic, but not the unsolicited incoming traffic. When you have such a modem/router, and when it cannot be replaced (e.g. because your provider requires you to use this modem/router), you cannot use IPIP tunnels. Rob

9 years, 1 month

3
2
0 0

getting rip data fron the non ampr address of ucsd gw?

by R P

Hi there can i get the ripv2 data from ucsd gateway by connecting to its non ampr address ? what about from connecting it from my internet (non ampr) adress as well ? any info welcome Thanks forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

9 years, 1 month

3
3
0 0

Re: [44net] ip44 argentina

by Rob Janssen

> Subject: > [44net] ip44 argentina > From: > Eduardo Castillo <lu9dce(a)gmail.com> > Date: > 09/07/2016 06:10 PM > > To: > 44net-owner(a)hamradio.ucsd.edu > > > Hello !! > > we are trying to set up a debian linux pc > > and we fail to find settings > > ip we have is 44.153.32.97 > > PC IP is 192.168.0.50 > > and dynamic IP Internet > lu9dce.dynu.com > > how to make a script > to a ip44 You can find directions on the WiKi: http://wiki.ampr.org/wiki/Setting_up_a_gateway_on_Linux

9 years, 1 month

1
0
0 0

ip44 argentina

by Eduardo Castillo

Hello !! we are trying to set up a debian linux pc and we fail to find settings ip we have is 44.153.32.97 PC IP is 192.168.0.50 and dynamic IP Internet lu9dce.dynu.com how to make a script to a ip44 73 --------- Hola !! estamos tratando de configurar un pc con linux debian y no logramos dar con la configuracion la ip que tenemos es 44.153.32.97 la ip del pc es 192.168.0.50 y la ip de internet dinamica a lu9dce.dynu.com como hacer un script para poder unas ip44 73 -- ====================================================================== Yo, el solitario, soy siempre el más rico y el más envidiado porque os he poseído y vosotros me poseéis aún. Friedrich Nietzsche, "Así habló Zaratustra". ====================================================================== __ __ __ __ | / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz |__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300 == power by linux === NODO LU9DCE.DYNU.COM PORT 3694 *** https://www.facebook.com/groups/newpacketradio/ /EX

9 years, 1 month

1
0
0 0

Routing

by Paul Middlehurst

I have configured a Cisco router, duel Ethernet interfaces on on of my static Internet addresses. The IPIP tunnel comes up and with wireshark I can see traffic in both directions to 169.228.66.251 pinging devices in the wider 44. network I never see anything being returned. Does the gateway router automatically have the reciprocal return tunnel / routes added (as per the Encap file) or is this something that needs requesting? Is there a good 44.131.x.x address to test against? 73 Paul - G1DVA

9 years, 1 month

3
2
0 0

Re: [44net] DGN2200 ADSL router and IPIP

by lleachii＠aol.com

Ronen, Most consumer routers only pass TCP and UDP without customized firmware. If you have the Version 1 device, it is compatible with OpenWRT, see: https://wiki.openwrt.org/toh/netgear/dgn2200 I suggest using devices known to pass IPENCAP traffic. 73, Lynwood KB3VWG

9 years, 1 month

3
3
0 0

using first and last IP of AMPR subnet for networking

by R P

hi there One of our gateway got 8 IP ADDRESSES 44.138.0.8/39 Can the first address 44.238.0.8 be used ? or it reserved for networking only ? and i have to choose ip address only in the range of the 9-14 ? if the answer is that it can not be used how the main router at UCSD treat for ping attempts coming for 44.138.0.8 ? does it pass it ? or ignore it ? all is assured that the IP is defined at the AMPR DNS... What about the tunnel itself doesit have any connection to what ip the gateway have ? or it exist anyway and has no meaning for the ip of the gateway ? (because the tunnel defined with only Commercial IP one is local and other is the AMPRGW commercial ip) Its the first time i play with so small network and its not clear to me how its done at the AMPR system I know that on ampr /24 network we didnt use the first and last .. dont know if it was necessary or not but that was the fact Thank for any clarification Regards Ronen-4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

9 years, 1 month

5
5
0 0

DGN2200 ADSL router and IPIP

by R P

Hi there Does anyone know if netgear DGN220 router may pass IPIP to its DMZ ? the router have a fire wall that ca not turned off and one rule in it that can not be deleted as follows any any drop always 10.0.0.20 never log i have placed before it rule as follows any any always pass 10.0.0.20 always log i suspect it know only TCP and UDP and not recognize IPIP on the log there is no sign of AMPRGW IP does anyone have experience with it ? Thanks for any help Regards Ronen - 4Z4ZQ http://www.ronen.org

9 years, 1 month

1
0
0 0

ipip tunnel problem for new gateway

by Rob Janssen

> sorry this is the correct config I think we have explained you many times that this is NOT a correct config. People have helped you with setting up working alternatives, someone has even gone all the way to write software for a commercial router to work as an AMPRnet tunnel router. All that effort seems to have gone to waste. You are still deploying those Cisco routers with only a default route. It's a shame. Rob

9 years, 1 month

2
1
0 0

Re: [44net] ipip tunnel problem for new gateway

by R P

________________________________ Its cisco i tried to send print screen of th show interface tunnel0 but the message didnt go with it ... config is as follows the cisco sit on the DMZ of the DSL router the relevant part of the config is as follows this router was working t my home and only the fellow changes his IP to meet his network the router can ping the 169.228.66.251 interface Tunnel0 ip unnumbered Ethernet0 tunnel source Ethernet0 tunnel destination 169.228.66.251 tunnel mode ipip ! interface Ethernet0 ip address 44.138.1.1 255.255.255.0 secondary ip address 44.138.0.8 255.255.255.0 secondary ip address 10.0.0.20 255.255.255.0 secondary ip address 192.168.2.140 255.255.255.0 ip route-cache flow ip tcp adjust-mss 1360 hold-queue 100 out ! ! ip classless ip route 0.0.0.0 0.0.0.0 Tunnel0 169.228.66.251 ip route 8.8.8.8 255.255.255.255 Ethernet0 10.0.0.138 ip route 169.228.66.251 255.255.255.255 Ethernet0 10.0.0.138 ! ________________________________ From: 44Net <44net-bounces+ronenp=hotmail.com(a)hamradio.ucsd.edu> on behalf of Todor Kandev <todor(a)kandev.com> Sent: Tuesday, August 23, 2016 11:28 PM To: AMPRNet working group Subject: Re: [44net] ipip tunnel problem for new gateway (Please trim inclusions from previous messages) _______________________________________________ Having issues with my crystal ball this morning... :D What is your friend using (openwrt, mikrotik, cisco, linux, washing machine, toaster...?) and how it's configured? 73, LZ1ETE On Wed, Aug 24, 2016 at 9:23 AM, R P <ronenp(a)hotmail.com> wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > > > > ________________________________ > > > ________________________________ > > > Hi there > > im helping a local ham to set up a gateway and i get strange behave > > the amprgw is accessible from his router the ipip table at the portal > POINTfor the correct ip > > the router accessible from the outside world > > the tunnell interface according to the cisco is up but it look like that > no data flow to the income > > how can i track where the problem is ? > > any help is appreciated > > thanks forward > > Ronen - 4Z4ZQ > > http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com > > Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> > www.ronen.org<http://www.ronen.org> > ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com > > > >

9 years, 1 month

1
1
0 0

ipip tunnel problem for new gateway

by R P

________________________________ ________________________________ Hi there im helping a local ham to set up a gateway and i get strange behave the amprgw is accessible from his router the ipip table at the portal POINTfor the correct ip the router accessible from the outside world the tunnell interface according to the cisco is up but it look like that no data flow to the income how can i track where the problem is ? any help is appreciated thanks forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

9 years, 1 month

2
1
0 0

missing packets in to AMPRGW ?

by R P

Hi can anyone explain why i get every second ping missing packets from AMPRGW ? it happen not only from my PC also from other places ... Regards Ronen-4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com C:\Documents and Settings\customer>ping 169.228.66.251 Pinging 169.228.66.251 with 32 bytes of data: Request timed out. Reply from 169.228.66.251: bytes=32 time=336ms TTL=40 Request timed out. Reply from 169.228.66.251: bytes=32 time=286ms TTL=40 Ping statistics for 169.228.66.251: Packets: Sent = 4, Received = 2, Lost = 2 (50% loss), Approximate round trip times in milli-seconds: Minimum = 286ms, Maximum = 336ms, Average = 311ms C:\Documents and Settings\customer>

9 years, 1 month

4
7
0 0

Use of 44.128.0.0/16

by DaKnOb

Hello, as far as I know, 44.128.0.0/16 is reserved for testing and experimentation and should be treated much like an RFC1918 subnet. That means it will not be routable to anyone (although it is advertised on BGP). So I have a few questions about its use: 1. Can an AMPRNet member use 44.128.0.0/16 in their home instead of, let’s say, 192.168.1.0/24? Note that I am not talking about routing these addresses, just use them in a non-connected place. 2. Can a non-ham use 44.128.0.0/16 in their home instead of, let’s say, 192.168.1.0/24? 3. Can a company use 44.128.0.0/16 for their intranet, instead of, let’s say, 10.0.0.0/8? Note than in all three cases, nobody is connected to 44net gateways and just use the network like any other private address. I am aware that there’s no technical limitation in doing this and there are hardly any benefits from doing this, however I am asking for informational purposes. Thanks!

9 years, 1 month

5
4
0 0

Re: [44net] Use of 44.128.0.0/16

by Rob Janssen

Bogon filter in use on our gateway (all packets with these source addresses are dropped): # ipset list Bogons Name: Bogons Type: hash:net Header: family inet hashsize 1024 maxelem 65536 Size in memory: 17208 References: 6 Members: 10.0.0.0/8 169.254.0.0/16 172.16.0.0/12 198.51.100.0/24 127.0.0.0/8 192.0.2.0/24 213.222.29.194 224.0.0.0/4 100.64.0.0/10 203.0.113.0/24 240.0.0.0/4 0.0.0.0/8 192.168.0.0/16 44.128.0.0/16

9 years, 1 month

1
0
0 0

Re: [44net] Problem with drop non 44/8 trafic via tunnel

by lleachii＠aol.com

Waldek, Have you enabled connection tracking for the relevant bridge/VLANs/tunnels, etc. that pass traffic (as this is disabled by default on some systems for non-masqueraded traffic)? In addition, is your default iptables forwarding policy REJECT or DROP, instead of ACCEPT? 73, Lynwood KB3VWG

9 years, 1 month

3
5
0 0

Re: [44net] Security/Wiki Question - Requesting a Block

by Rob Janssen

That "Requesting a Block" page has a lot of personal opinion it and also contains directives that may be valid for some regions but not for others. This already starts with the first line. Here in the Netherlands we don't use the portal for requesting blocks, only for registering blocks that are to be used for IPIP tunnels. So requesting a block does not start with the portal, but with mailing a request for a block to me and allocation of the block in the hostsfile for 44.137.0.0/16 followed by updating the DNS via the robot. Once that is done, it can optionally be registered in the portal. I recommend users not to do this unless they want to setup a gateway, because registered subnets that are not claimed by a gateway are up for grabs by other gateway operators, and given that we have widely varying skills among out users it has repeatedly happened that users (who often not even understand what it means and requires to run an IPIP gateway) create a gateway entry and add someone else's subnet to it by mistake. This then cannot be corrected by either the owner of the subnet or the coordinator of the IP space. It requires a "contact the portal admin" form entry to correct it and that may take a long time to be acted upon. (I still have two open requests of that type) I also don't agree with the "don't waste space" adagium. I allocate whatever is required for the experiment, and now that we are using BGP internally on the radio network, that also includes /30 and /29 networks for point-to-point links (/30 for links with only a router at each end, /29 when it is desired to have AP managment addresses). Unlike on the internet, we have no lack of IPv4 space on AMPRnet! There is no point in using RFC1918 addresses for this, and it causes problems with ICMP messages returned from those routers, e.g. when using traceroute. I also don't agree with "an ISP uses unroutable addresses for routers". Maybe some ISPs do that, but probably most do not. About RFC1918 filtering: YES, everyone should filter RFC1918 addresses at every entry and exit into the network. There are many configuration mistakes in ham networks, and I often see log results on those filters (which I have configured with logging on our gateway). RFC1918 addresses come in via IPIP tunnels from all over the world and also from radio. Of course it requires detailed knowledge of networking, policy routing, and NAT rules to get a mixed net44/rfc1918 LAN correctly connected to AMPRnet (with NAT or blocking for the RFC1918 systems) and let's face it: many users simply don't have that knowledge and are just trying. So, everyone else should filter that traffic so that at least it does not get propagated far. I sometimes send mail to repeat offenders and they often promise me that they will look at it, but it rarely stops completely. Rob

9 years, 1 month

1
0
0 0

Re: [44net] Problem with drop non 44/8 trafic via tunnel

by Rob Janssen

> I have use tcpdump to check how working iptables > I have try block this traffic by > but not working for me Again: you can NOT test it this way! tcpdump will show you all packets even when you are dropping them in the filter. I know this is sometimes a nuisance. It is difficult to test if your filters are working. When your filter has the structure of: - some packets dropped - some other packets dropped - more packets dropped - all remaining packets accepted (note that this is normally not a preferred structure of your blocklist) you can work around it by inserting a rule like this just before the last ACCEPT rule (or at the end of the table when the default setting is ACCEPT, again not a preferred situation): iptables -A INPUT -i tunl0 -j NFLOG --nflog-group 44 This will send the packets to a "netfilter logging" interface where you can trace it with: tshark -i nflog:44 (I don't think tcpdump supports dumping nflog interfaces but this may depend on version) The result of this is that all packets that have already been dropped above that rule will not reach the NFLOG target and will not be traced when you trace nflog:44. However, it is normally preferred to work with a "default drop" setup. You accept all packets that you know you want to accept, and drop everything else at the end of the table. This makes it less likely that things pass by that you did not think about, like other protocols than TCP and UDP. It is still possible to have NFLOG logging of everything that is accepted, by first creating a helper table like this: iptables -N NFLOGACCEPT iptables -A NFLOGACCEPT -j NFLOG --nflog-group 44 iptables -A NFLOGACCEPT -j ACCEPT Then you setup your filter table like this: iptables -A INPUT -i tunl0 -..... -j NFLOGACCEPT iptables -A INPUT -i tunl0 -..... -j NFLOGACCEPT iptables -A INPUT -i tunl0 -j DROP Rob

9 years, 1 month

1
0
0 0

Re: [44net] Problem with drop non 44/8 trafic via tunnel

by Rob Janssen

> I have try block non 44/8 traffic via tunnel IPIP with iptables but without > success > I have use ampr-ripd to create port 'tunl0' > I have add to firewall rule: > iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP > iptables -A FORWARD -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP > but I have still a lot of traffic via tunl0 non 44/8 ip address and it is > look like this not working for me How did you validate that you still have the traffic? Does such traffic still reach an open port on your system or a system behind it? E.g. when you have telnet or ssh running, can you still telnet or ssh from internet? Note that using a trace tool like "tcpdump" or "tshark/wireshark" is NOT a valid way of testing of those filters work! When you do "tshark -i tunl0" with the above filters in place, you will still see the traffic. This is because tshark and tcpdump trace the real traffic on those interfaces BEFORE the filters have been applied. Rob

9 years, 1 month

1
0
0 0

Problem with drop non 44/8 trafic via tunnel

by Waldek Waldek

Hi I have try block non 44/8 traffic via tunnel IPIP with iptables but without success I have use ampr-ripd to create port 'tunl0' I have add to firewall rule: iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP iptables -A FORWARD -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP but I have still a lot of traffic via tunl0 non 44/8 ip address and it is look like this not working for me I have add one more rule like where eth0 is my internet port iptables -A OUTPUT -o eth0 -s 44.0.0.0/8 -j DROP and it is help me to not send to internet 44/8 ip traffic but I would like block incoming non 44/8 IP address via tunnel -- Waldek sp2ong

9 years, 1 month

1
0
0 0

Re: [44net] iptables

by lleachii＠aol.com

It appears the the iptables rule is incorrect. In my previous configuration I had a border device NATing to a downstream device running as my AMPRNet Gateway. When I first set it up, I had THE EXACT SAME ISSUE YOU ARE EXPERIENCING. I could only receive packets after first initiating them. When asking for advice, I continued to receive information that the iptables rules were correct... THEY WERE NOT!!! Why??? As you are receiving this traffic the router interface, IT IS CONSIDERED INPUT since there are no routing rule to forward the packet (this is only done the subsequent DNAT rule added to the iptables firewall). This is an example from my DD-WRT device when I DNATed to a IPIP gateway downstream (so, this is a known working configuration): # iptables -t filter -I INPUT -p 4 -i eth0.1 -j ACCEPT # iptables -t nat -I PREROUTING -p 4 -i eth0.1 -j DNAT --to-destination 192.168.0.11 Further, on the INPUT rule, you could use the -d argument and the IP address if your WAN interface has a static address. Also, after I added this rule to my device, the issue Rob describes doesn't occur (except when I explicitly added a rule to block Pings). 73, - Lynwood KB3VWG

9 years, 2 months

2
1
0 0

Re: [44net] iptables

by Rob Janssen

> It is behind my ISP cable modem, I had to get it setup in bridging mode > after the last time they upgraded it. My router is showing all the > tunnel traffic (via tcpdump) so I'm fairly certain the modem isn't the > issue. Ok. I heard before from other members of this group that they had a similar setup, yet I was never able to ping them unless they first pinged me. > Central to my confusion at the moment is the rule in the nat PREROUTING > isn't counting packets. Remember that iptables NAT processing in Linux is stateful. It only sees "new" traffic for a connection. Once a connection is in the NAT table, the traffic goes "around" those rules much like Established/Related traffic in the filter tables, but without an explicit visible rule for that purpose. So, when you ping outward over a tunnel, you will not see those rules matching yet the traffic is forwarded as reply to your outgoing pings. Only when you ping from somewhere else, those rules are going to be of influence. But of course they only see traffic when it actually arrives on your router. Rob

9 years, 2 months

2
1
0 0

Re: [44net] iptables

by Rob Janssen

> The latest reboot had me digging deeper to try to find the real problem > and I have discovered that only the rule in FORWARD chain of the filter > table is firing, not the DNAT in the nat table. I suspect the firewall > is only working when some connection (outgoing ?) wakes up the > masquerade rules but haven't actually found the rule that is active. Are you sure the OpenWRT box is actually seeing the incoming packets? Is it directly on the internet, or is there another box before it, e.g. an ISP provided modem/router? Even though you might have forwarded the protocol or even set the OpenWRT box as the "DMZ device", it may still do stateful firewalling on non-TCP/UDP protocols. That is a known problem with NAT routers. Try to run a trace on the OpenWRT box to verify that you can receive IPIP traffic from sources that you have not recently contacted with outgoing traffic. Rob

9 years, 2 months

2
1
0 0

Re: [44net] TAPR DCC 2016 - anyone going?

by Rob Janssen

> I think with much larger address space and the availability of /56 or > larger spaces for many connections means many of us already have excess, > the second approach is worth investigating. Come up with DNS management > and a system for automatically configuring AMPRNET6 routers to share > trust information to tie the network together securely. As I said > before, I could easily allocate part of my /56 to this project. I'm > using less than 1% of my address range (1/256th to be exact :) ). Address space is not an issue with IPv6. Everyone here gets a /48 with their home internet connection. I use only 3/65536 of mine :-) For a "global IPv6 space for amprnet" we would get a /32 and map it 1:1 with the existing net-44 addresses. That will give every net-44 IP user a /56 network on IPv6. However, I too don't think is the way to go. Just use the space you get on your own internet connection for your own purposes on AMPRnet (and nag the ISP when they don't provide IPv6, give you only a /128 or /64, or assign dynamic prefixes - bad concepts in IPv6 rollout!). Extend the current DNS server and robot with AAAA records, and find or design some method of sharing the prefix list. Could be done using a BGP server. (not the internet BGP but a server on AMPRnet that distributes prefixes) Then we can interconnect on internet without the hassle we have now, and still are able to route the same addresses over wireless networks. Rob

9 years, 2 months

2
1
0 0

iptables

by Niall Parker

Hello, I seem to have something broken on my firewall for redirecting incoming ipip packets to my gateway box. It appears to work fine at times but fails periodically, typically after a reset/power failure. Usually it comes back after several reboots of firewall and router but this process is inconsistent. The latest reboot had me digging deeper to try to find the real problem and I have discovered that only the rule in FORWARD chain of the filter table is firing, not the DNAT in the nat table. I suspect the firewall is only working when some connection (outgoing ?) wakes up the masquerade rules but haven't actually found the rule that is active. The firewall is running on OpenWRT using iptables (old version 1.3.8) and the rules as I think they should work are ## for ampr.org tunnels iptables -t nat -I PREROUTING -p 4 -i eth0.1 -j DNAT \ --to-destination 192.168.99.66 iptables -t filter -I FORWARD -p 4 -i eth0.1 -j ACCEPT As I understand it, the first re-writes the destination for ipip packets to my gateway and the second allows them to be forwarded however the counter on first stays stuck at 0. A reference to what sounds like a similar problem: https://sourceforge.net/p/ipcop/mailman/message/17780204/ It would be really nice to get this sorted properly, any debugging hints appreciated. In particular, am I correct in expecting both rule counters to match ? thx ... ... Niall

9 years, 2 months

1
0
0 0

Connecting to amprnet

by Jon A

Hi folks, I have a /29 subnet allocated and have been with interconnecting a few systems but want to expand that connectivity to other systems round the world. Last time I experimented with amprnet was 15 years ago and I had a ipip tunnel to a packet node that also had amprnet connectivity. That node is long gone so looking for something else to use. Reading info on the wiki, it sounds like I can now use rip and connect via the UCSD router. Have I under stood this correctly? Any idiot guides out there on how to do this or any suggestions on other ways I can connect to a gateway? Thanks Jon M1CQO

9 years, 2 months

4
4
0 0

TAPR DCC 2016 - anyone going?

by Brian Kantor

I'm unable to attend the 2016 TAPR DCC next month in St Petersburg Florida. If anyone on this mailing list is going to be there, could you please let us know the substance of any discussions relevant to the AMPRNet. Thank you. - Brian

9 years, 2 months

8
13
0 0

IPv6 trust model

by Dean Hall

Hello, I know the people on this maillist work on the real internet infrastructure types of networks, but I was wondering if anyone thought an overlay network, such as CJDNS [1], that uses cryptographic-generated addressing to ensure an FC::/8 address corresponds to a public certificate. would be more practical for everyday hams who only have a behind-the-ISP or dynamic IP connection to the internet. [1] https://en.wikipedia.org/wiki/Cjdns !!Dean KC4KSU

9 years, 2 months

1
0
0 0

Re: [44net] TAPR DCC 2016 - anyone going?

by Rob Janssen

> It's frustrating when one has deployed IPv6 and has to keep battling > with the evils of NAT. :/ But we have a large IPv4 space available so why would we battle with NAT??? It should not be a problem to get an IPv4 address from net-44 for any of your experiments and not have to use NAT. Not that I am against experimenting with IPv6, but I am not sure which way that should go: - somehow get an "own" IPv6 range that we can manage in a similar way as the net-44 space - just use the IPv6 space everyone can get from their local provider and have only DNS support for it in ampr.org and maybe some service for listing of prefixes in use on ampr hosts to be used in firewall address lists. Having an own range appears nice, but it means we will again have the problems with internet tunneling and BGP routing that we are having now. Rob

9 years, 2 months

2
1
0 0

time sync in mikrotik

by R P

I have replaced my cisco with mikrotik the ipip works ok i have two questions (for time being) 1) how do i synchronize the time ? do i need to install ntp client ? i see no ntp under the system in the gui window 2) i want to run the routing script that Marius wrote but it say it need a password ? what is the password for ? how do i get it ? Thanks forward Ronen 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

9 years, 2 months

2
2
0 0

Connecting amprnet via openvpn

by R P

Hi there when Connecting amprnet via openvpn is it limited to USA only users ? what is the IP the one that connect get ? is it a special IP assigned for the vpn server ? or the user get his country IP allocation ...and can a block of ip pass ? or only single ip ? What PC software can be used ? or only linux supported ? thanks forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

9 years, 2 months

2
1
0 0

TCP networking code scores own goal

by Brian Kantor

Because many of the people on this list run Linux, I mention the following article: http://www.theregister.co.uk/2016/08/10/linux_tor_users_open_corrupted_comm… "Linux security backfires: Flaw lets hackers inject malware into downloads, disrupt Tor users, etc" If you're running Linux kernel 3.6 or later and your system is exposed to the internet, this is something you should consider taking care of. - Brian

9 years, 2 months

1
0
0 0

requesting an allocation block problem

by Marcel Neupauer

Hello, I have some problem with requesting an alocatation block. I sent two alocation request on portal.ampr.org on 44.181.0.0/16 (Slovakia) one week ago. My requests are still in "waiting for coordinator" status. I tried to send "Contact us" message to portal two day ago, but my request is without changes. I am not sure that my coordinator is active on portal. Please, Who can help me with this issue, or give advice, or some mail contact. Is possible to activate some subregion block witout my inactive coordinator to me ? Thanks. 73, Marcel OM0ATE

9 years, 2 months

2
1
0 0

ipencap via oprnwrt

by lz4ny＠mail.bg

Hello, I had a problem to let rip44d after an OpenWrt Chaos Calmer 15.05, but was dropped dmz traffic ipencap 169.228.66.251 not passed to the second router. In openwrt menu: Network -> Firewall -> Custom Rules I add: --- iptables -A INPUT -p 4 -j ACCEPT iptables -A INPUT -p udp --dport 520 -j ACCEPT iptables -t nat -A PREROUTING -p 4 -j DNAT --to 192.168.1.2 --- 192.168.1.2 is ip of second router or 44 gateway with rip44d After adding these lines and reboot the router all problems are corrected. Let's hope it will be useful. 73, Miro, LZ4NY ------------------------------------- P.S Вместо да разпитваш приятели и познати как се прави онлайн магазин, тествай безплатно 14 дни Shopiko – за да започнеш да продаваш. https://www.superhosting.bg/web-hosting-compare-shop-plans.php?utm_source=M…

9 years, 2 months

3
6
0 0

Re: [44net] Help setting up a BSD-based gateway?

by Dan Cross

[Apologies for the repost: I meant to have a useful Subject: header and accidentally omitted that earlier.] [Forgive the top-posting: I include the full text of what I'd written several weeks ago below for refresher and reference.] To recap, I've set up IPENCAP tunnels to AMPRNet networks on a Ubiquiti EdgeRouter Lite running OpenBSD: there is one gif(4) interface per tunnel and routes are kept in a dedicated routing table (like Linux, OpenBSD supports multiple routing domains on a single system); firewall rules are used to go from one routing domain to another. The biggest piece missing was a daemon to handle receiving 44net RIP packets and use that data to maintain tunnels and routes. I thought about porting one, but decided of write my own instead. It has been running for a few weeks now on my node and while it's still not quite "done" it seems to work well enough that I decided it was time to cast a somewhat a wider net and push it up to GitHub for comment from others. A couple of quick notes on implementation: 1. The program maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree). Routes are expired after receiving a RIP packet. 2. A similar table of tunnels is maintained. 3. Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained. 4. The program is completely self-contained in the sense that I do not fork/exec external commands to e.g. configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket. There is more to do; I'm sure there are a few bugs. I'd also like to query the system state at startup to initialize the routing and tunnel tables. Exporting and/or parsing an encap file would be nice. Logging and error checking can, I'm sure, be improved. It's about 1200 lines of non-comment code, compiles down to a 28K MIPS64 executable (stripped). The code is at https://github.com/dancrossnyc/44ripd Please have a look and let me know what you think! - Dan C. On Fri, Jun 17, 2016 at 5:46 PM, Dan Cross <crossd(a)gmail.com> wrote: > On Tue, Jun 14, 2016 at 12:51 PM, Dan Cross <crossd(a)gmail.com> wrote: > > I'm trying to set up an AMPRNet gateway at home and am running into > > some problems. Has anyone successfully configured a BSD-based gateway > > that would be willing to give me some pointers? > > > > [snip] > > > > It seems like what I want to do is configure a gif(4) interface > > for tunnel traffic, but my attempts at doing so all seem to fail, > > and documentation for setting up an IPENCAP tunnel is related to > > setting up IPsec gateways; my attempts at transliterating from the > > examples for e.g. Linux and Cisco et al have failed. > > > > If someone has gone down this road before and has a working > > setup, that would be tremendously helpful. If someone could send > > me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and > > possibly some 'tcpdump' output, I could probably muddle through the > > rest. If there are any caveats in setting up a 'pf' based firewall, > > that would be helpful as well. If not, I suppose my next step will > > be to reinstall RouterOS on the ERL, try and get everything configured, > > and then see if I can replicate under BSD. > > Folks, > > I just wanted to do a quick followup to this for the archives. > I am now successfully transferring traffic between my 44net subnet > (44.44.107.0/24) and the rest of the world using my OpenBSD-based > router. > > A quick recap of my setup: > 1. I have a Comcast business class circuit. > 2. I have a dedicated static IP address to use as an endpoint for > 44net traffic. > 3. My comcast router is just a router; no NATing, no firewalling. > 4. My (non-comcast) edge router is a Ubiquiti EdgeRouter Lite > running OpenBSD 5.9. It has three ethernet interfaces: > a. cnmac0 is the external interface connected to Comcast's network > b. cnmac1 connects to my internal network > c. cnmac2 is my internal gateway to 44.44.107.0/24. > > On OpenBSD, tunneling interfaces for IPENCAP are provided by > 'gif' pseudo-devices. Unlike Linux, it appears that one creates a > separate 'gif' interface for each tunnel, but one seems able to > create an arbitrary number of such interfaces: I created a thousand > as a test. I'm sure there is a limit but it seems sufficiently > high that practically routing AMPRNet traffic won't run up against > it. (Again, if someone knows of a different way to configure a > single 'gif' interface so that it could support multiple tunnels, > I'd be happy to know about it). In other words, don't worry about > scalability because you are creating a separate 'gif' interface for > each tunnel to another AMPRNet site. > > On AMPRNet, the UCSD gateway *will not* pass traffic for an > IP address that does not have a corresponding entry in the AMPR.ORG > domain. Also, 44.0.0.1 does not respond to 'ping' from 44/8 IP's. > Caveat emptor as one tries to test: make sure you have DNS entries > for your addresses and try pinging something other than 44.0.0.1 > or you'll suffer contusions banging your head against a desk trying > to figure out why nothing appears to work.... > > Once I had a tunnel up to UCSD, I found that I could ping my > 44.44.107.1 machine from a host on my internal network, but not > from arbitrary machines. This was interesting; it turns out that > hosts on my internal network get NAT'ed to another IP address on > the small subnet I got from Comcast (through another, completely > separate router -- not comcast's router but another ERL). What was > happening was that as I ping'ed 44.44.107.1 from e.g. my laptop, > ICMP echo request packets got NAT'ed to this other address and > routed over to amprgw.sysnet.ucsd.edu and tunneled back to the > external interface of my AMPRNet gateway. The gateway accepted the > encapsulated ICMP echo requests (I have a PF rule that explicitly > allows ping) and forwarded them across the tunnel interface where > they were unencapsulated; the IP stack saw that the result was > addressed to an IP address on a local interface (i.e., they were > for the router) and generated an ICMP echo response packet with a > *source* address of 44.44.107.1 and a *destination* address of the > external address of my other router (that is, the address the ICMP > echo request was NAT'ed to). This matched the network route for > my local Comcats subnet and so my AMPRNet router realized it could > pass the packet back to my other router directly. It did so and > the other router happily took the packet, matched it back through > the NAT back to the original requesting machine (my laptop) and > forwarded it: hence, I got my ping responses back. But note that > the response was not going through the tunnel back to UCSD: it was > being routed directly through the external interface. > > Now consider what happens when I tried to ping 44.44.107.1 from > a different machine on some other network. The ICMP echo request > packet gets routed through the UCSD gateway and tunneled back to > my gateway as before, but since responses don't go through back > through the tunnel, the response packet matches the default route > of my gateway and get's forwarded to comcast's router. Comcast > would look at it, see that 44.44.107.1 wasn't on one of it's known > networks that it would route floor, and discard the response. Oops. > > The solution was to set up a separate routing table in a different > routing domain specifically for AMPRNet traffic, and tie the two > together using firewall rules. In the AMPRNet routing table, I > could set my default route to point to the UCSD gateway, so any > traffic sent from one of my 44.44.107.0/24 addresses that doesn't > match a route to a known tunnel gets forwarded through > amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway > from random machines. This must seem obvious to a lot of folks > here, but it took me a little while to figure out what was going > on. Things are working now, however. > > So far I have encountered two other caveats: I decided to > configure two tunnel interfaces statically at boot time: 'gif0' > goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for > his 44.88 net. Under OpenBSD, I assumed that the natural way to > do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1 > files and this does in fact create the tunnels at boot time. However, > traffic going out from my gateway doesn't seem to get sent through > the tunnels; I did not bother to track down exactly why, but I > believe it has to do with some kind of implicit ordering dependency > when initializing PF. When I set up the separate routing domain, > it struck me that the language accepted by /etc/netstart in an > /etc/hostname.if file was not sufficiently rich to set up tunnels > in a routing domain, so I capitulated and just set up the static > interfaces from /etc/rc.local; imperfect but it works. > > The second caveat is that I seem to have tickled a kernel error > trying to set up an alias of a second IP address on my 44.44.107.1 > NIC; I get a kernel panic due to an assertion failure. It looks a > bug to me, but I haven't had the bandwidth to track it down. In > the meanwhile, simply don't add aliases to interfaces in non-default > routing domains. > > I'll try to go through my notes and type up something for the > wiki. > > The next step is to write a modified version of rip44d for BSD. > I may take a stab at that this weekend if I can get some time. As > near as I can tell, the wire format of the protocol is strictly > RIPv2; the difference is what the gateway does with the data in the > RIP packet (it sets up tunnels in addition to maintaining routes). > > Anyway, I hope this can be of some small help to someone else > who wants to run an OpenBSD-based gateway!

9 years, 2 months

1
0
0 0

(no subject)

by Dan Cross

[Forgive the top-posting: I include the full text of what I'd written several weeks ago below for refresher and reference.] To recap, I've set up IPENCAP tunnels to AMPRNet networks on a Ubiquiti EdgeRouter Lite running OpenBSD: there is one gif(4) interface per tunnel and routes are kept in a dedicated routing table (like Linux, OpenBSD supports multiple routing domains on a single system); firewall rules are used to go from one routing domain to another. The biggest piece missing was a daemon to handle receiving 44net RIP packets and use that data to maintain tunnels and routes. I thought about porting one, but decided of write my own instead. It has been running for a few weeks now on my node and while it's still not quite "done" it seems to work well enough that I decided it was time to cast a somewhat a wider net and push it up to GitHub for comment from others. A couple of quick notes on implementation: 1. The program maintains a copy of the AMPRNet routing table in a modified PATRICIA trie (really a compressed radix tree). Routes are expired after receiving a RIP packet. 2. A similar table of tunnels is maintained. 3. Tunnel interfaces are reference counted and garbage collected. A bitmap indicating which tunnels are in use is maintained. 4. The program is completely self-contained in the sense that I do not fork/exec external commands to e.g. configure tunnels or manipulate routes. That is all done via ioctls or writing messages to a routing socket. There is more to do; I'm sure there are a few bugs. I'd also like to query the system state at startup to initialize the routing and tunnel tables. Exporting and/or parsing an encap file would be nice. Logging and error checking can, I'm sure, be improved. It's about 1200 lines of non-comment code, compiles down to a 28K MIPS64 executable (stripped). The code is at https://github.com/dancrossnyc/44ripd Please have a look and let me know what you think! - Dan C. On Fri, Jun 17, 2016 at 5:46 PM, Dan Cross <crossd(a)gmail.com> wrote: > On Tue, Jun 14, 2016 at 12:51 PM, Dan Cross <crossd(a)gmail.com> wrote: > > I'm trying to set up an AMPRNet gateway at home and am running into > > some problems. Has anyone successfully configured a BSD-based gateway > > that would be willing to give me some pointers? > > > > [snip] > > > > It seems like what I want to do is configure a gif(4) interface > > for tunnel traffic, but my attempts at doing so all seem to fail, > > and documentation for setting up an IPENCAP tunnel is related to > > setting up IPsec gateways; my attempts at transliterating from the > > examples for e.g. Linux and Cisco et al have failed. > > > > If someone has gone down this road before and has a working > > setup, that would be tremendously helpful. If someone could send > > me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and > > possibly some 'tcpdump' output, I could probably muddle through the > > rest. If there are any caveats in setting up a 'pf' based firewall, > > that would be helpful as well. If not, I suppose my next step will > > be to reinstall RouterOS on the ERL, try and get everything configured, > > and then see if I can replicate under BSD. > > Folks, > > I just wanted to do a quick followup to this for the archives. > I am now successfully transferring traffic between my 44net subnet > (44.44.107.0/24) and the rest of the world using my OpenBSD-based > router. > > A quick recap of my setup: > 1. I have a Comcast business class circuit. > 2. I have a dedicated static IP address to use as an endpoint for > 44net traffic. > 3. My comcast router is just a router; no NATing, no firewalling. > 4. My (non-comcast) edge router is a Ubiquiti EdgeRouter Lite > running OpenBSD 5.9. It has three ethernet interfaces: > a. cnmac0 is the external interface connected to Comcast's network > b. cnmac1 connects to my internal network > c. cnmac2 is my internal gateway to 44.44.107.0/24. > > On OpenBSD, tunneling interfaces for IPENCAP are provided by > 'gif' pseudo-devices. Unlike Linux, it appears that one creates a > separate 'gif' interface for each tunnel, but one seems able to > create an arbitrary number of such interfaces: I created a thousand > as a test. I'm sure there is a limit but it seems sufficiently > high that practically routing AMPRNet traffic won't run up against > it. (Again, if someone knows of a different way to configure a > single 'gif' interface so that it could support multiple tunnels, > I'd be happy to know about it). In other words, don't worry about > scalability because you are creating a separate 'gif' interface for > each tunnel to another AMPRNet site. > > On AMPRNet, the UCSD gateway *will not* pass traffic for an > IP address that does not have a corresponding entry in the AMPR.ORG > domain. Also, 44.0.0.1 does not respond to 'ping' from 44/8 IP's. > Caveat emptor as one tries to test: make sure you have DNS entries > for your addresses and try pinging something other than 44.0.0.1 > or you'll suffer contusions banging your head against a desk trying > to figure out why nothing appears to work.... > > Once I had a tunnel up to UCSD, I found that I could ping my > 44.44.107.1 machine from a host on my internal network, but not > from arbitrary machines. This was interesting; it turns out that > hosts on my internal network get NAT'ed to another IP address on > the small subnet I got from Comcast (through another, completely > separate router -- not comcast's router but another ERL). What was > happening was that as I ping'ed 44.44.107.1 from e.g. my laptop, > ICMP echo request packets got NAT'ed to this other address and > routed over to amprgw.sysnet.ucsd.edu and tunneled back to the > external interface of my AMPRNet gateway. The gateway accepted the > encapsulated ICMP echo requests (I have a PF rule that explicitly > allows ping) and forwarded them across the tunnel interface where > they were unencapsulated; the IP stack saw that the result was > addressed to an IP address on a local interface (i.e., they were > for the router) and generated an ICMP echo response packet with a > *source* address of 44.44.107.1 and a *destination* address of the > external address of my other router (that is, the address the ICMP > echo request was NAT'ed to). This matched the network route for > my local Comcats subnet and so my AMPRNet router realized it could > pass the packet back to my other router directly. It did so and > the other router happily took the packet, matched it back through > the NAT back to the original requesting machine (my laptop) and > forwarded it: hence, I got my ping responses back. But note that > the response was not going through the tunnel back to UCSD: it was > being routed directly through the external interface. > > Now consider what happens when I tried to ping 44.44.107.1 from > a different machine on some other network. The ICMP echo request > packet gets routed through the UCSD gateway and tunneled back to > my gateway as before, but since responses don't go through back > through the tunnel, the response packet matches the default route > of my gateway and get's forwarded to comcast's router. Comcast > would look at it, see that 44.44.107.1 wasn't on one of it's known > networks that it would route floor, and discard the response. Oops. > > The solution was to set up a separate routing table in a different > routing domain specifically for AMPRNet traffic, and tie the two > together using firewall rules. In the AMPRNet routing table, I > could set my default route to point to the UCSD gateway, so any > traffic sent from one of my 44.44.107.0/24 addresses that doesn't > match a route to a known tunnel gets forwarded through > amprgw.sysnet.ucsd.edu. With that in place, I could ping my gateway > from random machines. This must seem obvious to a lot of folks > here, but it took me a little while to figure out what was going > on. Things are working now, however. > > So far I have encountered two other caveats: I decided to > configure two tunnel interfaces statically at boot time: 'gif0' > goes to the UCSD tunnel, and 'gif1' sets up a tunnel to N1URO for > his 44.88 net. Under OpenBSD, I assumed that the natural way to > do this would be to add /etc/hostname.gif0 and /etc/hostname.gif1 > files and this does in fact create the tunnels at boot time. However, > traffic going out from my gateway doesn't seem to get sent through > the tunnels; I did not bother to track down exactly why, but I > believe it has to do with some kind of implicit ordering dependency > when initializing PF. When I set up the separate routing domain, > it struck me that the language accepted by /etc/netstart in an > /etc/hostname.if file was not sufficiently rich to set up tunnels > in a routing domain, so I capitulated and just set up the static > interfaces from /etc/rc.local; imperfect but it works. > > The second caveat is that I seem to have tickled a kernel error > trying to set up an alias of a second IP address on my 44.44.107.1 > NIC; I get a kernel panic due to an assertion failure. It looks a > bug to me, but I haven't had the bandwidth to track it down. In > the meanwhile, simply don't add aliases to interfaces in non-default > routing domains. > > I'll try to go through my notes and type up something for the > wiki. > > The next step is to write a modified version of rip44d for BSD. > I may take a stab at that this weekend if I can get some time. As > near as I can tell, the wire format of the protocol is strictly > RIPv2; the difference is what the gateway does with the data in the > RIP packet (it sets up tunnels in addition to maintaining routes). > > Anyway, I hope this can be of some small help to someone else > who wants to run an OpenBSD-based gateway!

9 years, 2 months

1
0
0 0

Ampr Wiki

by Brian

Can the person who maintains the "Services" page contact me offlist please? Thanks much. -- I was going to go see a Guns 'n' Roses concert... until the liberals took away ALL the guns. Now I'm only going to see Roses *sigh* ----- 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, New Jersey, Pennsylvania, Rhode Island, and Vermont.

9 years, 2 months

1
0
0 0

Running a Binary copy of RIPD on PI ?

by Rob Janssen

> That is when all work fine without errors > but before you have to grab all the gcc enviourment into the PI That is done with this single command: apt-get install build-essential Maybe you need to type: sudo apt-get install build-essential (when you are logged in as user pi) > I know how hard it was to More experts from me to compile for me the Firmware for the arduino Sometimes these things are hard, but not in the case of ampr-ripd. And when you don't try, you'll never learn... Rob

9 years, 3 months

1
0
0 0

Running a Binary copy of RIPD on PI ?

by R P

Hi Fellows Since compiling is hard task for me Is it possible to take from a working PI the RipD and run it on my pi ? or the only solution is to compile ? I know on Unix some programs can run when taken from another systems ... If that can be done where can I get the RIPD executable ? Thanks Forward Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

9 years, 3 months

2
8
0 0

Re: [44net] Running a Binary copy of RIPD on PI ?

by Rob Janssen

> Hi Fellows > Since compiling is hard task for me Incredible... To compile it, you only need to type: make To install it, you only need to type: make install Rob

9 years, 3 months

2
1
0 0

Making Gateway with PI ? and TNC as well ?

by R P

Hi there Since yesterday I have a Raspberry Pi unit connected to Arduino doing MMDVM (a project that allow making digital repeater from two analog radios) I know that a Gateway can be done with raspberry Pi 1) What exactly needed to be done (some software to add to what i have now ?) in order to deal with IPIP and make a gateway ? can it run on RASPIAN ? 2) what about making TNC from Raspberry ? i know thare is a board that stick to it and make TNC ... Or (preferred) using the Internal sound card for making TNC ? can this be done on Raspian ? and where can i get info how to do it ? Thanks For any Info Regards Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

9 years, 3 months

6
7
0 0

IP allocation in Australia

by Tony Langdon

Hi, I'm trying to get an allocation of IPs (a /28) for some projects here. The /28 is to be split between the LAN (and perhaps HSMM type wifi), and more traditional low speed RF (i.e. 2 /29s). Looking through the Australian lists, there were no existing regions within VHF range of here that I could see (I'm in Bendigo, central Victoria). Anyway, I applied over 2 weeks ago and haven't heard anything, just wondering what the normal wait time is. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com

9 years, 3 months

3
5
0 0

wat to do now?

by on4hu

think the English language is not a problem for the Belgian coordinator but that person is too busy it seems to me it is what emerges from the last conversation that date two year with him what to do to restore our 44net now ??? vy73s André ON4HU http://on4hu.dyndns.org:81/ http://www.on4hu.com/ http://www.on4hu.eu ftp://ftp.on4hu.be/ ou ftp://on4hu.dyndns.org/ http://on4hu.eu/ COMPUTERS ARE LIKE AIR-CONDITIONERS THEY STOP WORKING PROPERLY AS SOON AS YOU OPEN WINDOWS.

9 years, 3 months

1
0
0 0

44NET

by on4hu

Coordinateurr for Bekgium NEVER answer deAR Ludovic, i have no contact wIth 44net from more than one year now, our Begium Coordinateur answer ONLY with Flemich people and never with French and do not understood our language André ON4HU http://on4hu.dyndns.org:81/ http://www.on4hu.com/ http://www.on4hu.eu ftp://ftp.on4hu.be/ ou ftp://on4hu.dyndns.org/ http://on4hu.eu/ COMPUTERS ARE LIKE AIR-CONDITIONERS THEY STOP WORKING PROPERLY AS SOON AS YOU OPEN WINDOWS.

9 years, 3 months

1
0
0 0

Re: [44net] IP address allocation in Belgium

by Rob Janssen

> I try to contact him before i create the "44.151belgium subnet" and no > anwer. > ON3LA, ON3LX and ON2CQ had no answer too... O dear... my fears I would get in a similar situation as with PJ2 are becoming true... Yesterday I sent an e-mail in Dutch (should be close enough to Flemish) to the address Brian mentioned, but I have heard nothing yet. I'll try to contact someone who knows people active in the network there (which is quite widely deployed). Rob

9 years, 3 months

2
1
0 0

IP address allocation in Belgium

by Rob Janssen

Is anyone aware of the procedure to allocate addresses in Belgium? I entered a request on the Portal a month ago, but got no reply. Is there some website that explains a local procedure? (like my site for the Netherlands) Rob

9 years, 3 months

4
5
0 0

Re: [44net] IP address allocation in Belgium

by Rob Janssen

> Your portal request should have gone to Robbie,on4sax at on4sax.be <http://hamradio.ucsd.edu/mailman/listinfo/44net> > Perhaps you could write to him and see what's going on. > - Brian Yes I saw he is the contact for that range, but obviously he got my request by e-mail on that same address. So I wonder if there is another method in use there. (e.g. I still process IP allocation requests on my amsat.org mail, and in other countries in EU it is sometimes done via hamnetdb.net) Any users from ON on the list? Hopefully the situation does not turn out to be similar as in PJ2 :-) (but that one is now allocated and working well) Rob

9 years, 3 months

3
2
0 0

44/8 routing problem at UCSD

by Brian Kantor

There appears to be a routing problem with the path to the amprgw router at UCSD. I'm investigating. - Brian

9 years, 3 months

3
3
0 0

Help setting up a BSD-based gateway?

by Dan Cross

Dear Folks, I'm trying to set up an AMPRnet gateway at home and am running into some problems. Has anyone successfully configured a BSD-based gateway that would be willing to give me some pointers? Some details of my setup: * I have a comcast business-class circuit with a static IP address that I've dedicated to 44net traffic (23.30.150.141). * I have an AMPRnet network allocation (44.44.107.0/24). * The Comcast router is configured as simply a router: all NATing and firewalling is disabled and I can see tunneled traffic arriving at the external NIC of my (non-comcast) router (specifically, I see RIPv2 packets with 44net routing information in them). * My "real" router is a Ubiquiti EdgeRouter Lite running OpenBSD 5.9. I have the three ethernet interfaces on the ERL configured as follows: cnmac0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500 lladdr 44:d9:e7:9f:a7:64 priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143 cnmac1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 44:d9:e7:9f:a7:65 priority: 0 media: Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.129.4 netmask 0xffffff00 broadcast 192.168.129.255 cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 44:d9:e7:9f:a7:66 priority: 0 media: Ethernet autoselect (none) status: no carrier inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255 Where I'm getting tripped up is in figuring out where to go from here. It seems like what I want to do is configure a gif(4) interface for tunnel traffic, but my attempts at doing so all seem to fail, and documentation for setting up an IPENCAP tunnel is related to setting up IPsec gateways; my attempts at transliterating from the examples for e.g. Linux and Cisco et al have failed. If someone has gone down this road before and has a working setup, that would be tremendously helpful. If someone could send me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and possibly some 'tcpdump' output, I could probably muddle through the rest. If there are any caveats in setting up a 'pf' based firewall, that would be helpful as well. If not, I suppose my next step will be to reinstall RouterOS on the ERL, try and get everything configured, and then see if I can replicate under BSD. Much thanks in advance! 73 de AC2OI, - Dan C.

9 years, 4 months

7
18
0 0

Re: [44net] disappearing ip alias ?

by Rob Janssen

> Has anyone else noted problems with the ethernet alias functionality in > recent Linux kernels ? I've just done an update on my tunnel server > (pogoplug E02 running Debian 8 with kernel 4.4.0-kirkwood) and within a > day or so the 44net alias disappears. Nothing I can see in any of the > logs. Replacing the alias via 'ip addr add 44.135.190.17/32 dev eth0:1' > is enough to fix it, might have to hack into a cron job :-/R Why are you still using ethernet aliases? This was originally a hack to be able to have multiple IP addresses on a single interface (using ifconfig) but since the introduction of the iproute2 package (which you apparently use, as it provides the "ip" command) this is really not required anymore. You can add addresses to eth0 without making an eth0:1 alias first. Rob

9 years, 4 months

3
3
0 0

Re: [44net] block allocation

by Rob Janssen

> In any case, your subnet will be connected to the Internet by at most > ONE method: Radio, Tunnel, or Direct, and might not be connected at all, > so select at most ONE of the connection method boxes in the allocation > request. (I have asked that these selections be changed to a pulldown > list or radio buttons so that it is impossible to select more than one; > until that happens, requests having more than one box checked are likely > to be rejected.) > - Brian Why is that?? We have been happily connected on both BGP and Tunnel for some time. The gateways that are part of the tunnel mesh route to us by Tunnel and the remainder of internet routes directly. What is wrong with that? Some gateways do not want to route directly ("only AMPRnet") so it is preferred when they can use the Tunnel to the same network. Rob

9 years, 4 months

8
9
0 0

Re: [44net] block allocation

by Rob Janssen

> The idea here is to support IPIP and BGP concurrently while preferring IPIP. Additionally we also > run BGP over other tunnel protocols ( GRE, SSTP, etc) with more specific preferences depending on the > agreement between the Ops. AFAICT this setup is the only way wich allows both the IPIP-only and the BGP-only > sites to reach our networks. > vy 73 de Marc, LX1DUC I agree, that is the way it works best. We do that here as well, however now we just have a single routing table where routes of different origin are stored at a different metric, so there is no fixed priority between protocols anymore. The first decision is always made on subnet size (smaller subnet has preference), the metric only comes into play when for some reason there are routes over two different protocols for the same subnet, and then the metric decides what path to take (e.g. there is both an IPIP tunnel and a a route announced with internal BGP on HAMNET). Normally these are error conditions. The difference between those methods becomes important when e.g. a /20 subnet is IPIP tunneled and out of that a /28 subnet is routed another way, e.g. over a GRE tunnel. This works without problem for us now. (on systems that are both on the normal internet and on the IPIP mesh reachable from the entire internet, with source address filtering at the provider, I normally have at least two different routing tables and policy routing, but on a directly routed system this is not required) Rob

9 years, 4 months

1
0
0 0

Re: [44net] block allocation

by Rob Janssen

> On Wed, Jun 15, 2016 at 11:46:30PM +0200, Rob Janssen wrote: > >/A quick check returns the following subnets being both BGP and Tunnel routed: / > I stand corrected. > - Brian Well, before I made that list I hoped that it would be much longer... Maybe I made a mistake, it was quick cut-and-paste followed by edit and comm of the list of bgp routed subnets and the routes in my personal gateway. Anyone with a BGP subnet who has a full-featured system as a router should consider to announce the same subnet on the IPIP mesh, I think. (with a tunnel endpoint address outside net-44, certainly outside the subnet) Rob

9 years, 4 months

1
0
0 0

Re: [44net] block allocation

by Rob Janssen

> I'm not saying you can't be connected in more than one way, I'm saying > that it's a special case that is unusual enough that it ought not to be > easy to mistakenly claim you're going to do. As far as I know, Rob, at > the current moment you're the only one doing this. Hmm... disappointing. I would hope everyone who is BGP routing would be doing that. I am not the only one, your gateway is doing the same thing :-) A quick check returns the following subnets being both BGP and Tunnel routed: 44.135.193.0/24 44.136.227.0/24 44.137.0.0/16 44.161.230.0/24 44.161.252.0/22 44.188.128.0/20 44.208.0.0/16 44.48.16.0/24 > Two or three times a week I get applications which have simplemindedly > checked all three boxes. Most of these people have no idea what they're > asking for Most applications of portal registrations I get are wrong or strange. It appears that the thing is confusing to newcomers. > I'm open to any suggestion that will keep me from having to go through > this process over and over again. Perhaps making 'Direct' a link which > brings up an intermediate page which presents a blurb about what checking > Direct actually means and demands that they confirm that they're really > going to get a BGP announcement from their ISP? Other ideas? It could be done with a simple Javascript on the page that presents a pop-up or reveals some explanation on the page when the checkmark is set ON.

9 years, 4 months

3
2
0 0

block allocation

by Pierre-Philippe F4MZI

Hi there, I actually have a /32 IP. I plan to connect a few new machines to the network. So, I would need 3 or 4 new adresses. I went to the web page, the the network tab, and click on 44.0.0.0 / 8 <https://portal.ampr.org/networks.php?a=request&id=1> Global link. the smallest block that I can request through this link is a /24. but I don't need a /24, only a /29 how can I send my request directly from the web site ? thank you -- 73, Pierre-Philippe F4MZI

9 years, 4 months

3
11
0 0

Re: [44net] block allocation

by Rob Janssen

> Subject: > Re: [44net] block allocation > From: > "Bill Buhler - AF7SJ" <af7sj(a)buhlerfamily.org> > Date: > 06/15/2016 06:47 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > > Sorry if I'm unclear, so what I'm envisioning is setting up tunnels to the > other participants of the 44 net who aren't directly internet routed and > using RIP advertisement for them. Then traffic between me and them can > bypass the main AMPR 44 net router, reducing latency and reducing bandwidth > requirements at the root node. > > In other words, if anyone on my subnets access the internet it would route > through our BGP connected uplink. If they were communicating with another > subnet on the AMPRNet it would tunnel directly to them. > > What do you think? > > Bill Buhler > AF7SJ > Indeed that is how we route here as well. Please don't remove that from the Portal! Rob

9 years, 4 months

1
0
0 0

Re: [44net] Help MBOX flood

by lleachii＠aol.com

Pedro, I use the following iptables rules on my router (this will work for any console-based connection using TCP): # DROPS MULTIPLE SSH CONNECTIONS FROM SAME IP iptables -t filter -I FORWARD -p tcp --syn --dport 22 -i tunl0 -m connlimit --connlimit-above 5 -j DROP # DROPS MULTIPLE SSH ATTEMPTS FROM SAME IP WITHIN FIVE MINUTES iptables -t filter -I FORWARD -p tcp --dport 22 -i tunl0 -m state --state NEW -m recent --name sshconnect --update --seconds 300 --hitcount 5 -j DROP iptables -t filter -I FORWARD -p tcp --dport 22 -i tunl0 -m state --state NEW -m recent --name sshconnect --set The first rule drops any connections greater then five. The last two rules mark and drop more than five attempts from the same IP, for a period of five minutes. You may wish to increase the time frame. I've also added rules to block IPs that attempt to connect (or portscan) on certain TCP and UDP ports (3389/tcp, 123/udp and 161/udp are common, for example) for which I not post services as available to the AMPR Community or the Public Internet connection. In essence, even if an unauthorized person discovered the the port without being firewalled by the portscan rule, they only get 5 chances, with up to 5 concurrent connections at any given 5 minute interval (the amount of attempts vary by implementation of server and client; but once portscanned or disconnected from a given series of attempts, it counts at one connection). Each reattempt after 5, restarts the 5 minute clock. I also block Bogon IP addresses from entering tunl0: # DROPS BOGONS ENTERING AMPRNet # SEE http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt iptables -t raw -I PREROUTING -s 0.0.0.0/8 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 10.0.0.0/8 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 100.64.0.0/10 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 127.0.0.0/8 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 169.254.0.0/16 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 172.16.0.0/12 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 192.0.0.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 192.0.2.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 192.168.0.0/16 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 198.18.0.0/15 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 198.51.100.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 203.0.113.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 224.0.0.0/4 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 240.0.0.0/4 -i tunl0 -j DROP I should note that in addition to this, console-based connections that I use for administration only are moved to non-standard ports. So I added another layer of protection with Security Through Obscurity (hence a portscan rule). 73, Lynwood KB3VWG

9 years, 4 months

3
4
0 0

Re: [44net] Help MBOX flood

by William Lewis

Pedro: I use Fail2Ban as well, and created my own Jail to help with this. First, you will need to created jail. In the Fail2Ban directory "filter.d" create a new text file called "jnos.conf" In the file called "jnos.conf" place the following text. _____________________________________ # Fail2Ban configuration file # # Author: Wm Lewis - KG6BAJ # # $Revision$ # [Definition] # Option: failregex # Notes.: regex to match the password failures messages in the logfile. The # host must be matched by a group named "host". The tag "<HOST>" can # be used for standard IP/hostname matching and is only an alias for # (?:::f{4,6}:)?(?P<host>[\w\-.^_]+) # Values: TEXT # # # # # failregex = ^.* <HOST>:.*bad login.*$ # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # # ignoreregex = ___________________________________ Next, after creating this file, in the main Fail2Ban directory, add the following to your "jail.local" file. ______________________________ # # Custom Made Bans # [jnos] enabled = true port = anyport filter = jnos logpath = /jnos/logs/nos.log banaction = shorewall action = %(action_mwl)s maxretry = 2 ______________________________ *** Note #1 : Your BANACTION may be different, depending on what your box is using as a default ban method. Look at some of the other jail entries, ( like [postfix] ). You may need to change the BANACTION to match the others. If your other jails are working with Fail2Bans default settings, you could comment out the "banaction = shorewall" with a hash so it reads "#banaction = shorewall" Obviously I use shorewall for my firewall. Your system may be using something else. Note #2 : Your path to your jnos log file may have to be tweaked to something like "/jnos/logs/filename.extension" I am using a version of jnos where I can specify that jnos logs are called "nos.log" and rotated every 24 hours. Your jnos may be custom built to call the logs something else. After you've install the "jnos.conf" jail file, and added the jnos jail settings, then restart Fail2Ban. Assuming you've made any appropriate directory tweaks needed to what I supplied, and assuming you've also adjusted your "jail.local" files email address to be your own, you should start getting emails telling you when Fail2Ban bans an IP address from the jnos logs for a bad login attempt. Note, I put MAXRETRY = 2. This tells the jail to allow 2 bad login tries, and then ban on the third bad attempt. Hope this helps. I currently show over 1300 banned IP addresses from jnos using this method. 73 Bill Lewis / KG6BAJ At 11:39 AM 6/12/2016, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >Hello, > >Since last months my JNOS MBOX is being attacked: > >15:24:59 94.53.236.39:55248 - MBOX (supervisor) bad login >15:25:07 113.162.86.77:35247 - MBOX (support) bad login >15:25:09 190.140.17.22:53348 - MBOX (root) bad login >15:25:14 92.27.102.224:38887 - MBOX (support) bad login >15:25:14 114.109.125.48:42069 - MBOX (administrator) bad login >15:25:35 190.140.17.22:54146 - MBOX (root) bad login >15:25:50 92.27.102.224:40191 - MBOX (support) bad login >15:26:33 182.184.71.162:41259 - MBOX (root) bad login >15:26:49 182.184.71.162:41259 - MBOX (sh) bad login >15:26:50 89.22.213.165:33979 - MBOX (root) bad login >15:27:52 89.22.213.165:34979 - MBOX (root) bad login > >None of the users tried have granted permit. > >Installed fail2ban but not avail. >Attacking IPs change continuosly, routing to loopback no help >Due heavy load jnos eventually hangs. > >Is it there any way/suggestion to stop this ? > >Appreciate any help. >73, lu7abf, Pedro Converso >44.153.0.1 or conversoft.com.ar >pconver(a)gmail.com >_________________________________________ >44Net mailing list >44Net(a)hamradio.ucsd.edu >http://hamradio.ucsd.edu/mailman/listinfo/44net --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

9 years, 4 months

1
0
0 0

Help MBOX flood

by Pedro Converso

Hello, Since last months my JNOS MBOX is being attacked: 15:24:59 94.53.236.39:55248 - MBOX (supervisor) bad login 15:25:07 113.162.86.77:35247 - MBOX (support) bad login 15:25:09 190.140.17.22:53348 - MBOX (root) bad login 15:25:14 92.27.102.224:38887 - MBOX (support) bad login 15:25:14 114.109.125.48:42069 - MBOX (administrator) bad login 15:25:35 190.140.17.22:54146 - MBOX (root) bad login 15:25:50 92.27.102.224:40191 - MBOX (support) bad login 15:26:33 182.184.71.162:41259 - MBOX (root) bad login 15:26:49 182.184.71.162:41259 - MBOX (sh) bad login 15:26:50 89.22.213.165:33979 - MBOX (root) bad login 15:27:52 89.22.213.165:34979 - MBOX (root) bad login None of the users tried have granted permit. Installed fail2ban but not avail. Attacking IPs change continuosly, routing to loopback no help Due heavy load jnos eventually hangs. Is it there any way/suggestion to stop this ? Appreciate any help. 73, lu7abf, Pedro Converso 44.153.0.1 or conversoft.com.ar pconver(a)gmail.com

9 years, 4 months

4
3
0 0

Raspberry Pi 3 image

by Brian

I'm in the process of uploading an image of jessie for the RPI 3 to https://sourceforge.net/projects/uronode/files/?source=navbar If you wish to give it a go, that's where it'll be in approximately an hour from this post. It's made from the kit sold near the TAPR booth at this year's Hamvention at Dayton. You'll need to edit files in /etc/ax25, /etc/postfix, and the file /usr/local/bin/ax25 other than that it should be ready to go. I did notice the main repositories that came with it failed but an apt-get update fixed those issues. It was made using the uronode-pi.tgz script available in the tools section of the same sf.net site. -- <rhetorical> Why is it linux users can install and operate *any* version of M$ Windoze but the same can't be said in reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

9 years, 4 months

1
0
0 0

Banana Pi

by Brian

Greetings; Is it me or does the Jessie version of the Banana Pi OS fail to include kernel modules for the ax25 stack?.. and if so would a custom compile of the kernel work? Curious as if anyone else has gone through this one before. I know it's fine with the Raspberry Pi but I'm not that familiar with a Banana Pi. -- <rhetorical> Why is it linux users can install and operate *any* version of M$ Windoze but the same can't be said in reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

9 years, 4 months

3
4
0 0

Fwd: [Uronode] FCC serves Comcast

by Boudewijn (Bob) Tenty

Repeat (sorry about the formatting in my previous reposting) -------- Forwarded Message -------- Subject: [Uronode] FCC serves Comcast Date: Tue, 07 Jun 2016 13:19:12 -0400 From: Brian <n1uro(a)n1uro.ampr.org> Reply-To: n1uro(a)n1uro.ampr.org Organization: Amateur Radio Services To: uronode(a)tapr.org, eastnet(a)n1uro.ampr.org With regards to my dealings with Comcast and the faulty firmware installed in their CPE devices, the FCC has informed me that they've officially served Comcast with a direct order to resolve this problem or respond to the complaint within 30 days of receipt of the complaint. Since Comcast has admitted to me about their firmware bugs it'll be interesting to see how this is accomplished and if it's within their 30 day window. A copy of their communication is included below. " Your Ticket No. 950514 was served on Comcast Cable Communications on Jun 7 for its review and response. Comcast Cable Communications will likely contact you in an effort to resolve your issue. A response is due to the FCC no later than 30 days from today. Comcast Cable Communications will respond to you directly by postal mail. You can view a list of frequently asked questions at: https://consumercomplaints.fcc.gov/hc/en-us/articles/205082880. We appreciate your submission and help in furthering the FCC’s mission on behalf of consumers. This email is a service from FCC Complaints. Delivered by Zendesk [NKGKWV-K6P1] " This is somewhat positive news for us on the amprnet. -- <rhetorical> Why is it linux users can install and operate *any* version of M$ Windoze but the same can't be said in reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

9 years, 4 months

1
0
0 0

Fwd: [Uronode] FCC serves Comcast

by Boudewijn (Bob) Tenty

I repost this from the UroNode list with permission from the author. -------- Forwarded Message -------- Subject: [Uronode] FCC serves Comcast Date: Tue, 07 Jun 2016 13:19:12 -0400 From: Brian <n1uro(a)n1uro.ampr.org> n1uro(a)n1uro.ampr.org With regards to my dealings with Comcast and the faulty firmware installed in their CPE devices, the FCC has informed me that they've officially served Comcast with a direct order to resolve this problem or respond to the complaint within 30 days of receipt of the complaint. Since Comcast has admitted to me about their firmware bugs it'll be interesting to see how this is accomplished and if it's within their 30 day window. A copy of their communication is included below. " Your Ticket No. 950514 was served on Comcast Cable Communications on Jun 7 for its review and response. Comcast Cable Communications will likely contact you in an effort to resolve your issue. A response is due to the FCC no later than 30 days from today. Comcast Cable Communications will respond to you directly by postal mail. You can view a list of frequently asked questions at: https://consumercomplaints.fcc.gov/hc/en-us/articles/205082880. We appreciate your submission and help in furthering the FCC’s mission on behalf of consumers. This email is a service from FCC Complaints. Delivered by Zendesk [NKGKWV-K6P1] " This is somewhat positive news for us on the amprnet. -- <rhetorical> Why is it linux users can install and operate *any* version of M$ Windoze but the same can't be said in reverse?</rhetorical> 73 de Brian - N1URO email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

9 years, 4 months

1
0
0 0

Re: [44net] Unable to Receive rip44 Datagram

by Rob Janssen

> On Tue, 2016-06-07 at 13:25 -0400, James Sharp wrote: > >/I haven't run in to 443 "filtering", but I have run into instances where /> >/the ISP will drop TCP connections that are active for more than a few /> >/minutes, forcing openvpn to restart the connection. / > Chances are your issue is the same as mine was. The CPE (router) has a > built in watchdog timer that cuts all sockets after a few minutes. Using > port 443 wouldn't make any difference. To the average web user this > isn't an issue because each time a page is opened/refreshed a new socket > is created, thus a new timer engages. The same may be said for services > such as pop3/smtp/etc. where you're engaging a new socket each time you > pop or send email. As long as the attachments aren't that big where you > may exceed the watchdog's timer you'll never notice this. So you can never download a file that takes more than a few minutes to complete? Terrible! Now I understand why some companies try to enforce a "download manager" to download a file of a measly 30 MB. So I can continue where I left off, yeah sure. Well it is clear that everyone should devise their own solution for tunneling and we should not change the global system to cater for limits that certain users encounter. There will always be a more severe limitation found by someone. It is better to solve these issues locally, where you have fellow users (victims) that can understand what is and what isn't possible. Colocated (virtual) servers with small storage capacity are very cheap today. Usually they are the entry level of server location, the hoster advertises their $3.99/mo server and knows that "everyone" will upgrade to more storage and pay a lot extra. But for a gateway these are perfectly usable, you can perfectly run it with 512MB RAM and 8GB disk. Put it in the IPIP mesh with the usual tunl0 and ampr-ripd, and then everyone in the area can make their VPN connection to there. Without NAT problems, and working round nasty ISPs. (you can make a VPN over almost anything if you wish) Rob

9 years, 4 months

2
1
0 0

Re: [44net] Unable to Receive rip44 Datagram

by Rob Janssen

> Ok... all important points to understand and we absolutely rely and > appreciate all your help on running the current AMPRGW solution. Before > even jumping to conclusion, we'd need to know if GRE really would be > more successful than IPIP. In Brian, N1URO's situation, I'm curious if > a Comcast "Business" class service would remove some of these > intentional filtering issues. I don't think it will be an appreciable improvement. I have experimented with GRE as the tunneling protocol (chosen exactly for this reason) to connect local stations to our Dutch gateway, and at first the results looked promising, but it did not take long before I got to the first case where plain GRE would not work over a consumer NAT router. I think it is (at least here) never caused by intentional ISP filtering, it is just caused by limitations of NAT routers that were only designed for typical outgoing TCP and UDP connections only. In the mentioned case the router was not even provided by the ISP, making malice even less likely. I then changed setup to GRE over IPsec which works fine until now when in NAT-T mode, but of course this is only suitable for use in a star configuration with connections initiated from the users to some gateway. Not a replacement for the tunnel mesh. I heard in Germany L2TP is used, I'm not sure if it is over IPsec or not. Anyway, I use L2TP over IPsec (sometimes over NAT-T) at work, it works over any connection but here as well it is a star topology. We also offer OpenVPN connectivity at our gateway, in UDP mode only, and this too is problem-free w.r.t. ISP routers. I don't believe a provider would (or even can?) filter OpenVPN, certainly not when it would be run in TCP mode on port 443. However, what is common in all these solutions is the star topology where the user behind the crippled router connects outward to a well-connected system. Of course we don't want to make the entire network into a star, but it could be an idea to deploy more regional gateways like our national gateway, that are interconnected by IPIP tunnels and optionally are BGP-routed on internet, and that offer services like mentioned above and discussed before in this thread to regional users who for some reason cannot run IPIP. It works well here. It is possible to deploy these on virtual servers that are quite inexpensive these days, certainly when not doing BGP (not all those hosters will offer BGP of a /16 or similar network via their routers, at an affordable price) In my experience it is possible (although not for "I am not a programmer" types) to get this working well on a Linux box. Setting up the VPN services and routing is quite well described. Setting up a firewall requires some thought and monitoring, see the recent incident with portmap. But this list is available for exchange of such information. Rob

9 years, 4 months

5
4
0 0

Suggestions for the portal and the wiki

by Miguel Bahi

Thanks Brian, for your update. Yes, the Portugese hamnet site is still under construcction. I notice you when this is up and running for update the link. 73’s EB5JEQ Message: 5 Date: Mon, 6 Jun 2016 09:22:08 -0700 From: Brian Kantor <Brian(a)UCSD.Edu> To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Suggestions for the portal and the wiki Message-ID: <20160606162208.GA28893(a)UCSD.Edu> Content-Type: text/plain; charset=us-ascii On Mon, Jun 06, 2016 at 02:31:39PM +0200, Miguel Bahi wrote: > Please , I suggest add in this paragraf > http://www.ampr.org/publications/ > add : Spanish hamnet www.hamnet.es I have added the Spanish HAMNET to the list of links on the publications page of www.ampr.org. There is a link on the Spanish hamnet page to the Portuguese hamnet page, but that site is still under construction so I did not add that link to the link list on www.ampr.org. - Brian

9 years, 4 months

1
0
0 0

Re: [44net] Unable to Receive rip44 Datagram

by Rob Janssen

> A possible option could be SSTP, which works over regular TCP connections > on port 443. But this is not well supported by the Linux world. > Marius, YO2LOJ SSTP is a star as well. In the open world there is OpenVPN over TCP port 443 when you want to run a VPN over TCP (I would not want that, but that is another topic). However what it seems to come down to is that these issues can be solved locally. A local Linux server or (e.g. MikroTik) router can be configured to be part of the IPIP mesh and possibly be BGP routed, and then it can serve as a VPN server for local users using whatever protocol(s) is or are locally preferred due to local situation w.r.t. internet routers and/or filtering. Rob

9 years, 4 months

1
0
0 0

Re: [44net] Unable to Receive rip44 Datagram

by lleachii＠aol.com

I concur with Bob. I've had Comcast before (though, I always used my own device - connecting to a DOCSIS-to-Ethernet bridge/Cable Modem). I've never had success using a consumer-grade router, unless it had DD-WRT or OpenWRT installed, or I used a Linux server. Some D-Link devices permit forwarding of protocols other than TCP/UDP, select the 'Other' option, and place the number 4 in the box for IPENCAP. Otherwise, most DMZ settings on consumer routers only forward TCP and UDP traffic. Since 44net (including RIP44) packets are encapsulated within IPENCAP (IP Protocol No. 4), you must forward that protocol. The Iptables Firewall is the same as on other *nix devices. If you are NATing to a device inside your LAN, the commands are similar to: # iptables -t filter -I INPUT -p 4 -i eth0 -j ACCEPT # iptables -t nat -I PREROUTING -p 4 -j DNAT --to-destination 192.0.2.8 Ensure that you are in fact seeing IPENCAP traffic entering your Local Network at your device (e.g. the to-destination address specified). Within the IPENCAP packets, you should see the password. I should also note, that I currently use Verizon FiOS; and I noticed when using their router as my border gateway, that the IPENCAP entry I make is administratively removed (Verizon has a back-door into their routers on tcp/4567) from upstream at intermittent times (I've been told this is because it's 'hard' for the carrier to track and/or rate-limit non TCP/UDP traffic). So be certain that your carrier it not removing firewall entires, especially if you were successful in the past. 73, - Lynwood KB3VWG

9 years, 4 months

5
11
0 0

Re: [44net] Unable to Receive rip44d Datagram

by Rob Janssen

> Subject: > Re: [44net] Unable to Receive rip44d Datagram > From: > "Boudewijn (Bob) Tenty" <bobtenty(a)gmail.com> > Date: > 06/06/2016 08:23 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > He can check or dd-wrt or OpenWrt firmware is available for his router as these > can forward ipip or can can be set in bridge mode (dd-wrt and OpenWrt are linux based) > and much more. Well, dd-wrt is available for some commercial ethernet/wifi routers but I don't think it exists for any combo-modem-router as is normally used by cable or dsl providers. The dd-wrt people don't have the drivers/software for the modem chips used in those modem-routers. So in this case (a DOCSIS cable provider) it can only be done when he is already using a separate modem and router. > > Some firmwares in these consumer routers even don't allow to be put in bridge mode at > all. The tabs for it are just missing or they don't have an option for it in their menu. Sometimes the ISP can switch the modem-router into modem mode (bridge) from their central management system on user request. It will probably have some strings attached like "no helpdesk support for network problems". After the switchover, the internal ethernet interface will be plain ethernet or PPPoE or PPTP. So you will need an extra router that indeed can be running dd-wrt. However, with today's internet speeds on cable and dsl you also have to consider the router performance. The typical WRT54 routers from the days dd-wrt was created cannot keep up with the internet speeds of today. Rob

9 years, 4 months

1
0
0 0

Re: [44net] Unable to Receive rip44d Datagram

by Rob Janssen

> I have a strong suspicion that my ISP (Charter Communications) has implemented > some kind of filtering on my home cable-based (DOCSIS) internet connection. My > reception of the RIP44d table broadcase has all but ceased. ip-ip tunnel > communication to a friend's machine in a neighboring county only seems to work > for a limited time, and only AFTER I initiate a connection from my end. It's > as if they're using some kind of NAT or port knocking filter, and only opening > the gate for incoming proto 4 traffic for a limited time after I initiate an > outgoing request to a specific host. It is, as Brian N1URO also wrote, an issue in your home router. Other routers have shown this phenomenon for some time. Even when you set a "DMZ" (meaning: forward all unknown traffic to this host), there still is a stateful firewall in place for all protocols except TCP and UDP, requiring you to send outgoing traffic before incoming traffic is accepted. You will need to have the router put in bridge mode (making it only a modem) and install a better router in front of that. With a suitable router, it can also do the IPIP encapsulation. A Linux system of course is a suitable router as well. Rob

9 years, 4 months

2
1
0 0

Unable to Receive rip44d Datagram

by kd4cbm＠charter.net

Good Morning Guys: I have been working to get my chunk of .44 active for a little while now. I've become quite familiar with the concepts of how the network is set up etc. That being said, no matter what I do I cannot seem to get the RIP password that is supposed to be broadcasted from 44.0.0.1. I have go as far as to monitor, log, and filter every packet coming in the cable modem from anything AMPRNet to verify it is arriving. It just seems like the packet is never making it to my public IP. I've gone through all the basics - protocol 4(IPIP) forwarding, UDP port 520 forwarding etc. Like I said, I've even captured all packets pre firewall and I'm not seeing anything AMPRNet. Is it possible that even though my gateway/public IP is registered, the packets aren't being sent out? The last portion of getting this going is that elusive RIP pass. Any suggestions? Thanks, Jason - KD4CBM '73

9 years, 4 months

4
3
0 0

disappearing ip alias ?

by Niall Parker

Has anyone else noted problems with the ethernet alias functionality in recent Linux kernels ? I've just done an update on my tunnel server (pogoplug E02 running Debian 8 with kernel 4.4.0-kirkwood) and within a day or so the 44net alias disappears. Nothing I can see in any of the logs. Replacing the alias via 'ip addr add 44.135.190.17/32 dev eth0:1' is enough to fix it, might have to hack into a cron job :-/ 44 net tunnels are being setup via a script from KB3VNW/LX1DUC, I suspect a few people out there would be using it ... Ideas ? ... Niall

9 years, 4 months

1
0
0 0

Suggestions for the portal and the wiki

by Miguel Bahi

Please , I suggest add in this paragraf http://www.ampr.org/publications/ add : Spanish hamnet www.hamnet.es and for the wiki http://wiki.ampr.org/wiki/Main_Page in the “how to connect to amprnet” title it would be interesting add one easy guide like “ setting up a Jnos Linux gateway” 73’s ------------------------------------------------------ Miguel Bahi Cruz EB5JEQ Amateur Radio Station www.eb5jeq.es ECB03KBQ "galaxia5" CB RADIO STATION Elche Alicante Spain email y skype : miguelbahi_cruz(a)hotmail.com LOCAL VHF : 144.550mhz / UHF : 436.300mhz Echolink: Conference **ESPAÑA** AX25 Packed VHF 144.950mhz AX25mail eb5jeq#ea5dv.eaa.esp.eu APRS chat: 144.800 mhz, monitoring CQ group WWconv ampr.org **Elche_ES** BPQ32net conv **GENERAL** http://www.hamnet.es eb5jeq(a)piserver.eb5jeq.es.ampr.org http://piserver.eb5jeq.es.ampr.org email/forum/wiki/conference XMPP Sysop of EB5JEQ-1:BPQELX AX25 Node BPQnet BPQ32 144.825MHZ EB5JEQ-6:ELXMPR TCPIP Node Ampr.org Net JNOS, 144.825MHZ ( in test ) QRUEB5JEQ Aprs QRUserver ( APRSIS32 ) EB5JEQ-24/ELXNOD24 node HSMM-mesh 2,4 ghz in test EB5JEQ-50/ELXNOD5 nodo HSMM hamnet.es 5 ghz in test

9 years, 4 months

2
1
0 0

Re: [44net] Exploitable portmapper service

by Rob Janssen

> Same here as there is just too much garbage coming in and it is very > labour intensive, I just block it. > Bob Well, here there is a lot more garbage coming in on other ports like 22 and 23 but I don't block that as there might be the occasional user who actually uses it. For the listed completely-blocked ports there appears to be no valid use from internet to amprnet. Internal to amprnet we are a lot more transparent, but at the gateway I do block all traffic to/from addresses without a registration within 44.137.0.0/16. This cuts the noise as well because currently about 2.8% of the addresses is registered. (after the big cleanup) Rob

9 years, 4 months

1
0
0 0

Re: [44net] Exploitable portmapper service

by Rob Janssen

Thanks Brian, I was already filtering that port for traffic outside AMPRnet. It would not have affected us much because we forward new incoming traffic from internet only to users who have explicitly requested this. This list now includes 10 /28 subnets and 29 individual hosts. (189 addresses out of the 65536 address network) All other users receive new traffic only from 44.0.0.0/8, and replies to their own outgoing traffic. I added this after the SNMP DDOS incident.... in case there are other problems like this. Ports filtered here on input from internet are: 135:139,445,1025:1028 TCP and UDP (SMB) 53 TCP and UDP (DNS) 111 UDP (portmap) 161 UDP (SNMP) 1900 (SSDP) Rob

9 years, 4 months

2
1
0 0

Looking for assistance setting up IP Ham system

by Arnold＠rogers

Can someone please direct me to the right place where I can purchase a complete kit so that I can setup an IP Ham network system. I would like to experiment with using using the 44Net as a fall back network in times of disaster. Any assistance / direction will be very appreciated as I am new at this. Thanks Arnold Villeneuve www.networkologist.com <http://www.networkologist.com> Change is the end result of all true learning.- Leo Buscaglia

9 years, 4 months

11
19
0 0

Re: [44net] OVA for ESXi?

by Rod Ekholm

Thanks Marius. It looks like the instruction are jumbled up a bit to me, and don't include the creation syntax for the tunnel interface, on the Wiki. Maybe someone could make an edit to that?? I will try this when I get home later, and see if I can get it to play!! More to come after that! -- Rod Ekholm kc7aad(a)gmail.com

9 years, 4 months

1
0
0 0

Exploitable portmapper service

by Brian Kantor

Folks, I have begun blocking the portmapper port (UDP 111) at the UCSD amprgw gateway. This is to mitigate a new DDOS exploit that is taking place on the Internet. This would prevent the use of various RPC services across the amprgw gateway, but I don't think anyone is currently using NFS, NIS, or the like in that context. The performance would be very poor in any case. You might consider blocking this port in your firewalls. I recommend that everyone running their own BGP'd subnet insert a blocking filter rule for this port as well. More information: http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-… Thanks. - Brian

9 years, 4 months

4
4
0 0

Re: [44net] Looking for assistance setting up IP Ham system

by Rob Janssen

Where are you located? Most important (unless you want to build a set of portable nodes that you can all deploy yourself during an emergency) is to have others to link to. So you need to check what others are doing in your area, to be compatible with the systems they use. In the old days, everyone built their own modems and sometimes even radios, and connected them to general purpose computers running special software. However, today you can buy ready wireless link and routing equipment from manufacturers like MikroTik and Ubiquiti for prices much below what we spent on homebrew equipment, and if you wish you can build an IP network by just plugging those together and do basic routing and linking configuration. Others have taken existing hardware from Linksys and those same two and replaced the firmware with own developments that e.g. go beyond the point-to-point linking by offering automatic routing in a mesh configuration. This may be more convenient in a temporary deployment during an emergency, but the point-to-point range of such a system is less than with directed links using dish antennas. Rob

9 years, 4 months

3
3
0 0

Re: [44net] OVA for ESXi?

by Rod Ekholm

I get all the way to the section where it says I need to run 'sudo ./findpass.sh', and it gives me output of 'Tunnel Socket: Setting SO_BINDTODEVICE: No suck device'. The instructions I am following are at: http://wiki.ampr.org/wiki/Ubuntu_Linux_Gateway_Example#Setting_up_the_Tunne… And I am to the section of ' Finding the password for AMPR-RIPD" The only section that had an issue during this process is the isc-dhcp-server will not start. I don't believe this should make any difference, other than if I have a client on my Ham Network that needs DHCP, but I plan to statically assign those devices.. so I believe that point should be moot. My installation is Ubuntu 14.04.4 LTS I only have 2 interface.. eth0 (outside WAN address from ISP. One of my /29 allocations) and eth1 (inside 192.168.44.0/24) I know enough to make my way around, but am not normally a linux guy!! Let me know what other info would be helpful to share out, so we can get this one going. Thanks guys!! -- Rod Ekholm kc7aad(a)gmail.com

9 years, 4 months

2
1
0 0

OVA for ESXi?

by Rod Ekholm

Thanks for the reply's guys. Lynnwood.. I have Ubuntu installed and working on my network (outside address as to not have anything blocking right now!!), but when it came time for the box to listen to the AMPR RIP broadcasts, I never did see anything. The notes say to let it sit for a little bit.. I let it sit for two days before I got back to it! :) So.. I haven't been diligently working on it, that's on me. But something seemed to go awry. Dangit. That's on me toooooo!! :( I'll try and get back to it over the next few days, and report back again. But if there are any ideas off the tops of ones heads.. Hit me with your best shot.. Fire Away!! Thanks. -- Rod Ekholm kc7aad(a)gmail.com

9 years, 4 months

1
0
0 0

Re: [44net] OVA for ESXi?

by lleachii＠aol.com

Yes, but since the machine is a standard Ubuntu Linux Server machine, I'm not sure how an OVA will help you. You still have to assign your IP addresses, turn on routing, etc. per the instructions in the Wiki. In the time it would take you to transfer it the file, you could simply have the same thing by running the ISO on a fresh VM. Are you having issues with setup? 73, Lynwood KB3VWG

9 years, 4 months

1
0
0 0

OVA for ESXi?

by Rod Ekholm

Has anyone built an OVA of a VM used for an AMPR Gateway yet? Or has anyone Exported their local VM that they would be willing to share? *Disclaimer:* Yes.. I realize it is easy to build a host(though my attempt so far has failed). But If someone has already put in the work to build a VM, I'm willing to piggyback in their expertise in what they've built. Thank you!! -- Rod Ekholm kc7aad(a)gmail.com

9 years, 4 months

2
1
0 0

Re: [44net] AMPRNET latency in VOIP connections ?

by Rob Janssen

> two ways to solve this as well. > 1. NAT the 44. address out the public internet. That is what I am doing > here. That only works when you have made special arrangements (policy routing) to make sure the Echolink traffic is ALWAYS sent to the NAT device and never routed directly. See what I explained to Gustavo. > 2. have the server have two NIC cards. One with a 44 address and the > other a local non-routable which is then NATed ouot your public internet IP. That does not require 2 cards (you can put 2 addresses on 1 card), and it is basically the same as the policy routing method, in this case using the IP address as the base for the policy routing. In practice it can be more difficult to implement because you need to force the Echolink application to bind to the correct card address. Fortunately Svxlink can do that, but many other programs cannot. Rob

9 years, 4 months

1
0
0 0

Re: [44net] AMPRNET katency in VOIP connections ?

by Rob Janssen

> The fact is that, actually the repeater is networked to the EchoLink > server and this can be obtained ONLY by using the commercial > IP number, i.e. IP address 79.47.199.234. Look at our repeaters, e.g. PI2NOS It is registered on the Echolink system using its own address 44.137.72.130 (pi2nos.ampr.org). Therefore this problem does not occur here. > the incoming IP results 44.137.41.97; so I understand that the > internet server act as the real gateway in a similar way as our > ampr.org gateways. It function very OK! Yes, for "normal traffic" it works OK. But not for Echolink. This is because Echolink has a directory server that registers your repeater by IP address, and this address does not match the actual address. When you get connected by someone from plain internet, it works OK because the route back is through the same NAT router, where you have defined port forwarding for the 5198 and 5199 ports, and the users sees the same translated address as the Echolink system registered. However, when I connect from my address 44.137.41.97, the repeater or another part of the system thinks it is being clever and routes the traffic through a IPIP tunnel, the address does not get translated, and the connection fails. The quick way to solve it is to give your repeater some RFC1918 address (10.x.x.x, 192.168.x.x) so its traffic is always forced through the NAT router. Alternatively, you can setup some policy routing so the Echolink traffic is always sent to the NAT router, not routed directly. Then you can still use AMPRnet on the same computer for other things. The way we solved it here is by applying for BGP routing of our subnet, so our net-44 traffic is routed directly on internet and it is no problem to run an Echolink repeater on it. (the subject of this thread: will routing through UCSD cause problems with VoIP. yes it will, but we don't route through UCSD so we don't have that problem) Rob

9 years, 4 months

4
5
0 0

smtp (port 25) filter ?

by Niall Parker

Is port 25 now being filtered within the tunnel network ? Submission (587), ssh (22) and http (80) appear to be OK (Internet -> 44 net) ... Niall

9 years, 4 months

2
4
0 0

Re: [44net] AMPRNET katency in VOIP connections ?

by Rob Janssen

> Subject: > Re: [44net] AMPRNET katency in VOIP connections ? > From: > "'Gustavo Ponza'" <g.ponza(a)tin.it> > Date: > 05/30/2016 07:12 PM > > To: > 44net(a)hamradio.ucsd.edu > > > On 05/30/2016 05:55 PM, Rob Janssen wrote: >> (Please trim inclusions from previous messages) >> _______________________________________________ >>> I don't know how they do the job... but as all of you can see, >>> also iPAD/iPhone can do it by using my small ampr.org facility :) >> >>> 73, gus >> >> Which repeater is this log from? It is on an AMPRnet address? > > It is from IR0AAB (ER-IR0AAB). It is on (or better, it should be on) > 44.134.32.240/44.208.58.1 Ok but it registers on Echolink using IP address 79.47.199.234 So there is some NAT between its 44-address and internet! This is no problem as long as the repeater always routes its traffic via that NAT, but in practice those operators often route 44-net traffic directly and then it does not work. I have tried to connect it from my 44-address and indeed it fails! I connect to the node on address 79.47.199.234 as directed by the Echolink server, and I get replies from 44.134.32.240: Spurious audio packet received from 44.134.32.240 So I cannot connect that repeater from AMPRnet. Rob

9 years, 4 months

2
1
0 0

Re: [44net] AMPRNET katency in VOIP connections ?

by Rob Janssen

> Subject: > Re: [44net] AMPRNET katency in VOIP connections ? > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 05/30/2016 06:25 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > As far as I know there are no active AMPRNet users in Asia. > - Brian > > On Mon, May 30, 2016 at 05:55:47PM +0200, Rob Janssen wrote: >> >It would be welcome when a volunteer a lot more east (near Japan/Korea/Thailand) >> >could setup another set of Echolink relays. This requires a Linux machine >> >with 5-10 IP addresses available to it, either plain internet or BGP-routed AMPRnet. A host somewhere in a datacenter with a /28../24 subnet would be OK as well. There are a couple of Echolink proxies in the far east, e.g. from JH1PGO but I have been unable to contact the operator. Rob

9 years, 4 months

1
0
0 0

Re: [44net] AMPRNET katency in VOIP connections ?

by Rob Janssen

> I don't know how they do the job... but as all of you can see, > also iPAD/iPhone can do it by using my small ampr.org facility :) > 73, gus Which repeater is this log from? It is on an AMPRnet address? Those 44.137.75.24x addresses are our Echolink relays that serve the mobile users in this part of the world. It would be welcome when a volunteer a lot more east (near Japan/Korea/Thailand) could setup another set of Echolink relays. This requires a Linux machine with 5-10 IP addresses available to it, either plain internet or BGP-routed AMPRnet. When some 20-200 addresses are available, it can also run Echolink proxies. A combined proxy/relay server written in C (1000 times more efficient than the echolink.org Java version) is available on my site: http://pe1chl.nl.eu.org/Softw/elproxy.tar.gz Bonus points when you find the race condition that makes it sometimes leak proxy instances when it is rapidly scanned by a web proxy scanner :-) Rob

9 years, 4 months

3
2
0 0

Re: [44net] AMPRNET katency in VOIP connections ?

by Rob Janssen

> The easiest way would be to put an Echolink system server on a 44.x.y.z > IP... > Anybody working on this? > This will avoid NAT and proxies, but problem with bandwith and latency > staies the same if serveral "44 islands" are connected via tunnels. > You then have to consider the bandwith of the tunnels and the > performance of the peers. > Micha, DD2MIC The main issue is that many users of the system are on plain internet and so the Echolink repeater has to be on a BGP-routed subnet or the users will all enter via the UCSD router. When you are not on a BGP-routed subnet I think it is better to use a proxy to register using the plain internet address, so at least the user traffic remains local and does not all go via UCSD. Rob

9 years, 4 months

1
0
0 0

Re: [44net] AMPRNET katency in VOIP connections ?

by Rob Janssen

> The basic idea would be that AMPR to AMPR traffic is a go since it is > tunneled directly. > Public IP to AMPR is a no-go for tunneled networks. > They have a public Gateway IP anyway, so you should use that one for access > from the internet. > Marius, YO2LOJ When you use Echolink from within AMPRnet but want to use a public IP you should be very careful how to implement it. Some people configure an Echolink repeater on an AMPRnet address and then route the traffic to some gateway where this address is translated using NAT. However, this does not work correctly! The Echolink repeater will register itself with the Echolink system server which is on public internet, so the registration address in the Echolink system is the address of your NAT router. But internally, the repeater has a 44.x.x.x address so when someone from a 44.x.x.x address connects the reply will come from the wrong address and the connection does not go through. This manifests itself when some other systems are natively on AMPRnet not using NAT. For example, here in the Netherlands we have several repeaters with a true AMPRnet address that is BGP routed, and we also run several Echolink proxies and relays on AMPRnet addresses. In neighboring Germany, the NAT method is often used, where the repeaters have a 44.x.x.x address but connect to the Echolink server via NAT. As a result, no connections between the repeaters in these two areas are possible, and worse: people using our Echolink proxies and relays cannot connect to German repeaters or users. It can be solved by not using NAT to translate the Echolink traffic to public addresses, but instead run an Echolink proxy on the gateway system which converts the internal AMPRnet address of the Echolink repeater to the public address of the gateway. Unfortunately only a single proxy can be run per public IP address, so a "normal" gateway with a single external address can only host a single repeater. To solve this, a number of proxies can be run e.g. in a datacenter where an IPv4 subnet is available for them (more and more difficult, of course!). This has now been done in Germany. The disadvantage of this solution is that all users that are on AMPRnet still connect to the outside address. On a BGP routed AMPRnet network where no proxies or translations are used, local users can connect the repeater directly. Rob

9 years, 4 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net