- 44net - mailman.ardc.net

by M6XCV (Mike)

Hi, I wouldn't normally post here about this, but I see a couple of others seem to have gotten a response from doing so. I am new to amatuer radio and while I was getting my license someone told me about APRMnet, so I decided to join. I put in a network request back in november and got a response from the coordinator G1FEF asking for clarification on my request. I responded via the portal, however that has been the last I have heard. I sent a follow-up email directly at the beginning of January, however I haven't had any further response. What should I do next? Thanks, - Mike, M6XCV

8 years, 3 months

3
3
0 0

Tunnel on Cisco Router

by Bill Atkinson

Greetings! I have a /22 block of AMPRNet space. I've configured it for tunnel access, and defined the gateway in my portal. Following the instructions on the wiki, here is my router config: interface GigabitEthernet0/0 ip address 44.48.8.1 255.255.252.0 secondary ip address 96.82.54.108 255.255.255.240 duplex auto speed auto media-type rj45 end interface Tunnel0 no ip address tunnel source 96.82.54.108 tunnel mode ipip tunnel destination 169.228.66.251 end results of 'sh int tunnel0' amprnet-router#sh int tunnel0 Tunnel0 is up, line protocol is up Hardware is Tunnel MTU 17920 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 96.82.54.108, destination 169.228.66.251 Tunnel protocol/transport IP/IP Tunnel TTL 255, Fast tunneling enabled Tunnel transport MTU 1480 bytes Tunnel transmit bandwidth 8000 (kbps) Tunnel receive bandwidth 8000 (kbps) Last input 00:02:16, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 7024 packets input, 3500920 bytes, 0 no buffer Received 0 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 unknown protocol drops 0 output buffer failures, 0 output buffers swapped out At this point, I believe I need to get RIP running with the right options. However, this is where the wiki falls short. The only rip configs examples are for the linux daemons. Here is the output of 'sh ip prot' amprnet-router#sh ip protocols *** IP Routing is NSF aware *** Routing Protocol is "rip" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Sending updates every 30 seconds, next due in 13 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip Neighbor(s): 169.228.66.251 Default version control: send version 2, receive version 2 Automatic network summarization is in effect Maximum path: 4 Routing for Networks: 44.0.0.0 Passive Interface(s): GigabitEthernet0/0 GigabitEthernet0/1 VoIP-Null0 Routing Information Sources: Gateway Distance Last Update Distance: (default is 120) As is standard practice, I've put all interfaces in passive-default, and then explicitly defined tunnel0 as non-passive. I have not been able to establish any sort of RIP adjacency: amprnet-router#sh ip route rip Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP + - replicated route, % - next hop override Gateway of last resort is not set amprnet-router#sh ip rip database 44.0.0.0/8 auto-summary 44.48.8.0/22 directly connected, GigabitEthernet0/0 Thanks in advance to anyone who can offer any guidance. --- 73, Bill Atkinson, NF9K ARRL Technical Specialist ARRL VE/OO Laurel VE PODXS 070 Club #1595 30MDG #6014 www.nf9k.net www.crossroadsdmr.org

8 years, 3 months

2
1
0 0

Re: [44net] BGPed Gateway

by Rob Janssen

> I received a 44 net allocation and am successfully advertising it to the internet via my ISP. > I have been reading on the AMPRNet Wiki about IPIP tunnelling and Startampr. Are there best practices or anything else I need to be aware of before venturing into building the gateway? It is advisable to make your system an IPIP tunnel gateway for the same subnet as you advertise via BGP. Make sure you use a non-44 public IP for the tunnel. > On a related note, I have been using OpenVPN to provide publicly routable /32 IP addresses to individual Windows PC. I don’t see support for IPIP on Windows, are there any other tunnelling methods worth looking at, for Windows7 specifically, or is OpenVPN my best bet? We offer OpenVPN but beware: it allows an easy entry into the AMPRnet that has nothing to do with amateur radio anymore. You just become a VPN provider like there already are so many on internet. To do something amateur-radio related with AMPRnet you really should offer radio access and encourage the users to use it, and OpenVPN works counter-productive in that regard. Rob

8 years, 3 months

2
1
0 0

44net Direct Allocation

by Adi Linden

Hi, I am interested in accessing 44 Net number via BGP. What would be the best avenue to discuss this? I already sent a message using the “Contact Us” link on the portal. How would I go about it? Thanks, Adi VA3ADI

8 years, 3 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 6, Issue 8

by kd6oat

On 1/12/17 1:19 PM, Jonathan Smith wrote: > Anyone have the UT coordinator email, or know where I can find it? I am the Utah coordinator. Based on the inquiry I checked my spam mail and found what I believe is the subject request. This will be processed shortly. Sorry for any inconvenience. Ken - KD6OAT On Thu, Jan 12, 2017 at 1:00 PM, <44net-request(a)hamradio.ucsd.edu> wrote: > Send 44Net mailing list submissions to > 44net(a)hamradio.ucsd.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://hamradio.ucsd.edu/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)hamradio.ucsd.edu > > You can reach the person managing the list at > 44net-owner(a)hamradio.ucsd.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > > > Today's Topics: > > 1. TrivnetDB (Brian) > 2. Re: Allocation time (Jonathan Smith) > 3. Re: Allocation time (Bryan Fields) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 12 Jan 2017 12:15:22 -0500 > From: Brian <n1uro(a)n1uro.ampr.org> > To: 44net(a)hamradio.ucsd.edu > Subject: [44net] TrivnetDB > Message-ID: <1484241322.23614.13.camel@n1uro> > Content-Type: text/plain; charset="utf-8" > > Is there someone from there on this list? If so please contact me > offlist. Thanks. > -- > I don't have to worry about body fitness in 2017. All I do is > show my body to itself in the mirror and it throws plenty of > fits. > -------- > 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. > > >

8 years, 3 months

1
0
0 0

Allocation time

by Jonathan Smith

How long does it usually take for the coordinator to approve requests? I know the holidays will get in the way. I'm just wondering. I'm looking for some space in Utah. Thanks.

8 years, 3 months

5
6
0 0

TrivnetDB

by Brian

Is there someone from there on this list? If so please contact me offlist. Thanks. -- I don't have to worry about body fitness in 2017. All I do is show my body to itself in the mirror and it throws plenty of fits. -------- 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.

8 years, 3 months

1
0
0 0

IPv6 talk from the DCC

by Steve L

I found the talk that was just released, by Brian, W9CR very informative. Very good historical overview of IPv4 as well, highly recommend watching it. https://www.youtube.com/watch?v=mkKOX5q1XJ4#t=04m20s Steve, KB9MWR

8 years, 3 months

1
0
0 0

Contact...

by SP2L Tom

Hello Paul G4APL. Could you please contact me off the list as I lost your e-mail address. Weird... Thank you very much in advance. Best regards. --- Tom - SP2L Sent from Xperia Z1 with AquaMail http://www.aqua-mail.com

8 years, 3 months

1
0
0 0

Re: [44net] Coordinator bug?

by Rob Janssen

> If I don't hear from them in a week or two, I put a comment "awaiting > response to email" in their coordination request and return it to them. > Returned requests will expire in 3 months if no further action is taken > and do not generate coordinator reminders. In that case it is not so bad. However, my experience is that most users who do not understand the portal (and of course there are more of those in my country, because they have the language barrier in addition to the already complicated matter) and get a request returned to them (previously this was called rejected, now it is called returned) will always manage to click on the re-submit link. So the ball is again in my park, and when I don't play it back to them, I get the reminders. I have once got it returned 3 times this way. Normally it is not a real problem when a requester does not come back after requesting additional information, because (here) the original request usually wasn't what they wanted anyway (we use the portal only for IPIP gateways). Rob

8 years, 3 months

1
0
0 0

Re: [44net] Coordinator bug?

by Rob Janssen

> You're welcome. Yes, I don't get many requests during a year and I go > through a learning curve every time I use the portal site. I still have the problem that users (who have to use a non-native language) do not understand the portal, make a request for something they do not want, and when I reject it with an explanation what the need to do next (read our website, mail me) they just click on all links in that reply mail causing the request to be re-submitted with the comments that I have put in there myself. We really need some button to just delete a request without notification to the submitter, so that I can contact them out-of-band. When I just leave the bad requests there will be "reminder" mails from the portal later. Rob

8 years, 3 months

3
2
0 0

Coordinator bug?

by Pedja YT9TP

I am country coordinator. I have administrative options meant for coordinator, but I lost options ordinary user has: for example I cannot apply for an IP allocation. Is this a bug, or I am missing to find this option in portal menu? 73 Pedja YT9TP --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

8 years, 3 months

3
4
0 0

System patch to pass 44net protocols through pfSense

by Luzemário Dantas

Hi guys, Anyone of you do use pfSense? I want a clue about forwarding 44net protocols on it without manual editing. It is FreeBSD based, but I want to get the webConfigurator way to get 44net trafic forwarded to my Linux Debian box. PfSense allows NATting 44net protocols to a Linux box. But it's webConfigurator does not show all protocols to be listed in the NAT configuration page. Despite all IP protocols being supported in "/etc/protocols", only the most common protocols are listed in the protocols drop-down of NAT configuration page (it is a webConfigurator limitation). There is a workaround by editing system files, but I am wondering if someone already have a system patch handy to add the needed protocols without manual editing, by using only the "System Patches" package. I don't like the idea of myself editing system files, since I don't know too much PHP programming. PfSense has a System Patches package wich makes easy to change system components (easy for the ones that understand it). Can someone help me to build a system patch to show 44net protocols in the NAT protocol drop-down menu? There are some comments on the link below, but I could not figure out how to do so by making a system patch, so anyone could apply the patch without manual editing. Thanks for your comments. https://forum.pfsense.org/index.php?topic=64060.msg346690#msg346690 73 de PT2LDR Luzemario

8 years, 3 months

3
2
0 0

Re: [44net] mikrotik

by Rob Janssen

Chris, Did you go to the http://www.yo2loj.ro/ site and go to the Ham projects subpage? It has a newer version of the script than what is mentioned on the Wiki (Wiki has to be updated) Rob

8 years, 3 months

1
0
0 0

mikrotik

by Chris McCune

Hi, I followed the wiki on using a Mikrotik as a gateway to the 44 net but I seem to be stuck. I watch the tunnel go up and down but I never get any farther. Does anyone have a little more complete setup procedure? Thanks, Chris --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

8 years, 3 months

1
0
0 0

Re: [44net] direction request

by Alessandro Spinella

hello everybody, i greet you all (Ronen included) for your kind answers; Brian : <<...have to get your connectivity via one of the commercial or government satellite services...>> Feel it the more suitable solution. <<....you can find a charity that will fund or donate the necessary equipment or service....>> just 2 words about: have distance-adopted a daughter, if I need charity the whole question become a nonsense.... it is my duty and pleasure to get rid of matter. Michael : <<...it would not be a legal solution.>> hahaha! thank you for the adivce, but will not encrypt anything and care not so much about what U.S.A. laws states; just like to reach a daughter and feel nobody can dislike it. <<...amateur radio is probably not a viable solution for your application...>> I agree, will move to satellite equipment & services Bill : <<...this is a fit for Outernet...>> maybe, but file transfer lead to a "misuse" of resources even if will be able to fool the content constraints (no personal messages are allowed); feel it can't fit requirements. anyway: thank you very much for your time and suggestions, my research is now better directed. wish you all great day. Alessandro

8 years, 4 months

2
1
0 0

Re: [44net] direction request

by Bill Vodall

Perhaps this is a fit for Outernet ? On Jan 3, 2017 8:48 AM, "Brian Kantor" <Brian(a)ucsd.edu> wrote: (Please trim inclusions from previous messages) _______________________________________________ Hello Alessandro, To the best of my knowledge, there is no AMPRNet infrastructure in Bangladesh, so there is nothing for you to connect to using network 44. While it is true that amateur radio can communicate over long distances, it can only do so at extremely slow data rates, far too slow for internet use. The only way I can think of for you to accomplish the connection you seek is to use satellite communications. There are indeed amateur radio satellites, but none of them handle the kind of data that would be needed for internet use. I believe you will have to get your connectivity via one of the commercial or government satellite services. In the USA, this is not expensive, but I have no idea how much it would cost for Bangladesh. Perhaps you can find a charity that will fund or donate the necessary equipment or service. I wish you the best of luck. - Brian On Tue, Jan 03, 2017 at 12:39:28PM +0100, Alessandro Spinella wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > hello everybody, > > let me shortly present myself and the matter: working in IT for more than 30 years, experienced with network devices (switch, routers, firewalls, IDS/IPS), programming (C and some others), good knowledge on protocols and RFCs; hosts under my control are not allowed to run anything else than FreeBSD. > > but absolutely not experienced about radio transmission/devices/requirements so had carefully read http://wiki.ampr.org/wiki/Quickstart and feel it is not suitable for my problem: I am looking how to arrange for an internet-connected PC located somewhere in a remote village of Bangladesh with no local power source. > > while it seem almost easy to power the PC with solar-cells battery is it not clear for me: > > - if and how is possible to use 44net to internet-connect the remote site via RF, feel it just a matter to have sufficient "radio power" to reach a 44net bridge, a PC/router and some radio devices but unsure. > - what kind of radio devices are suitable for that use (or: how far can radio waves go with a "poor" power source?) > - locations (if any) of local-radio-amateur joined in 44net that can bridge some internet traffic from/to such a "leaf-site" > > moreover my limit are: > > - money: while it's a personal initiative have no founding except my incoming and thus cheap is a must > - reliability: can't be on site to fix any possible problem as them arise, so "good" devices are required > > as stated in RFC1925 : <<good, fast, cheap: choose two, you can't have all three>> implies that am aware that "fast" can't be get; just need directions and some "good" reference for the HW where I can learn details as power requirements and for the SW (but I guess 44net is the right place). > > wish you nice day > > > $witch > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

8 years, 4 months

1
0
0 0

direction request

by Alessandro Spinella

hello everybody, let me shortly present myself and the matter: working in IT for more than 30 years, experienced with network devices (switch, routers, firewalls, IDS/IPS), programming (C and some others), good knowledge on protocols and RFCs; hosts under my control are not allowed to run anything else than FreeBSD. but absolutely not experienced about radio transmission/devices/requirements so had carefully read http://wiki.ampr.org/wiki/Quickstart and feel it is not suitable for my problem: I am looking how to arrange for an internet-connected PC located somewhere in a remote village of Bangladesh with no local power source. while it seem almost easy to power the PC with solar-cells battery is it not clear for me: - if and how is possible to use 44net to internet-connect the remote site via RF, feel it just a matter to have sufficient "radio power" to reach a 44net bridge, a PC/router and some radio devices but unsure. - what kind of radio devices are suitable for that use (or: how far can radio waves go with a "poor" power source?) - locations (if any) of local-radio-amateur joined in 44net that can bridge some internet traffic from/to such a "leaf-site" moreover my limit are: - money: while it's a personal initiative have no founding except my incoming and thus cheap is a must - reliability: can't be on site to fix any possible problem as them arise, so "good" devices are required as stated in RFC1925 : <<good, fast, cheap: choose two, you can't have all three>> implies that am aware that "fast" can't be get; just need directions and some "good" reference for the HW where I can learn details as power requirements and for the SW (but I guess 44net is the right place). wish you nice day $witch

8 years, 4 months

4
4
0 0

AXIP/UDP links in Australia request

by vk1kw

Hello All, Looks like I have lost all of my AXIP/UDP links in Australia over the years and would like to try and configure a couple again within Australia and New Zealand please? I am Rob VK1KW 44.136.3.92 Canberra A.C.T. local area 44.136.0.0/21 Vk1kw.dyndns.org EMAIL Vk1kw(a)netspace.net.au BBS Vk1kw(a)vk1kw.act.aus.oc JNOS APRS BPQ & FBB Best wishes for the New Year Rob

8 years, 4 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 5, Issue 193

by lleachii＠aol.com

Miguel, - The remote IP should be blank, you have to use the tunl0 to connect to all endpoints - You must be able to access the underlying Debian system in order to install ampr-ripd (I haven't seen instructions on how to do this since it was called Vyatta) - You cannot use RIPv2, you must use a RIP44 daemon (e.g. ampr-ripd) 73, Lynwood KB3VWG On 12/27/2016 03:00 PM, 44net-request(a)hamradio.ucsd.edu wrote: > Send 44Net mailing list submissions to > 44net(a)hamradio.ucsd.edu > > To subscribe or unsubscribe via the World Wide Web, visit > http://hamradio.ucsd.edu/mailman/listinfo/44net > or, via email, send a message with subject or body 'help' to > 44net-request(a)hamradio.ucsd.edu > > You can reach the person managing the list at > 44net-owner(a)hamradio.ucsd.edu > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of 44Net digest..." > > > Today's Topics: > > 1. AMPR + VyOS (Miguel Rodriguez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Dec 2016 13:40:14 -0500 > From: Miguel Rodriguez <miguemely101(a)gmail.com> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: [44net] AMPR + VyOS > Message-ID: > <CANvo9Dh7iDAS5JTnTrohNtnSbJuzJjPX5-aFFTgZ8E5pHtUrjQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello everyone! > > Does anyone have any experience setting up VyOS for use on the AMPR > network? I have the IPIP tunnel to UCSD set up, however, I don't know how > to proceed from there in terms of RIP. > > This is what I did so far: > set interfaces tunnel tun0 > set interfaces tunnel tun0 local-ip 'wanip' > set interfaces tunnel tun0 remote-ip 169.228.66.251 > set interfaces tunnel tun0 encap ipip > set interfaces tunnel tun0 descr "Tunnel to AMPR Gateway" > set interfaces tunnel tun0 multicast enable > set protocols static table 1 interface-route 0.0.0.0/0 next-hop-interface > tun0 > set policy route SOURCE_ROUTE rule 10 set table 1 > set policy route SOURCE_ROUTE rule 10 source address 44.0.0.0/16 > set interfaces ethernet eth1 vif 44 policy route SOURCE_ROUTE > set protocols rip interface eth1.44 > set interfaces ethernet eth1 vif 44 ip rip authentication > plaintext-password [therippass] > > >

8 years, 4 months

2
3
0 0

Re: [44net] AMPR + VyOS

by Rob Janssen

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] AMPR + VyOS > From: > Miguel Rodriguez <miguemely101(a)gmail.com> > Date: > 12/27/2016 07:40 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hello everyone! > > Does anyone have any experience setting up VyOS for use on the AMPR > network? I have the IPIP tunnel to UCSD set up, however, I don't know how > to proceed from there in terms of RIP. I have no experience with that, but I would guess that the easiest way is to use ampr-ripd for that. Is is possible to compile and install it on your system? Check the generic installation instructions on the WiKi. Rob

8 years, 4 months

2
1
0 0

Mikrotik firewall rules for 44net?

by Nick G4IRX

I've recently installed Marius YO2LOJ's RIPv2 AMPR Gateway Setup Script 2.2 on a Mikrotik RB450G. RouterOS is version 6.37.3, I have 44.131.56.241 configured on the ucsd-gw interface and 44.131.56.9/29 on ether5 for my LAN. It seems to work well and I can access 44net hosts from a 44net machine on the LAN. I'm filtering traffic on the WAN interface of the router to only permit ipip traffic, however I still see traffic from outside 44/8 - mainly tcp syn packets to port 23 appearing on the LAN. These must be coming down via a tunnel and I'd like to filter them out. I've implemented an output rule to permit traffic from 44/8 to 44/8 and drop everything else, applied this to ether5. Is there a better way to implement this? I would like to filter on the WAN side but that would mean a firewall input rule on every tunnel. Thanks, -- Nick G4IRX

8 years, 4 months

2
2
0 0

Re: [44net] Telnet To JNOS From Public IP Users Not Working

by Rob Janssen

> i was able to telnet in from here and got a login prompt from > wa4zlw.ampr.org Yes, from .ampr.org hosts it works OK. But the question was about "Public IP" users (he means users on the normal internet). That does not work, at least not here. When JNOS is running on Linux it is best to do the tunneling in Linux and have JNOS on a local subnet behind that. When running on another OS, it will be required to put a decent router inbetween. Rob

8 years, 4 months

1
0
0 0

Re: [44net] Telnet To JNOS From Public IP Users Not Working

by Rob Janssen

> Your JNOS is trying to respond directly to the incoming connections rather > than traversing an encap tunnel. This will not work as the upstream > hardware does not know about you and your 44net allocation. You receive > packets over the encap bridge but you respond back directly. > As for how to fix it? Dunno. We need to somehow encap your outgoing default > route for your 44 IP address so that packet response is along the same path > that it came in. Is that the issue? When I telnet to him from internet I do get "established" suggesting that something gets back... But when it is as you write, what you need is "policy routing". that means, the capability to select a (default) route based on criteria like the source address (your 44-net address or your public IP address). The first has to go to amprgw, the second has to go to your ISP. Does JNOS even offer that? It can be solved with Linux or a sophisticated router like MikroTik or OpenWRT, but I am not sure a bare JNOS system can do this. Rob

8 years, 4 months

2
1
0 0

Re: [44net] Telnet To JNOS From Public IP Users Not Working

by Rob Janssen

> Subject: > [44net] Telnet To JNOS From Public IP Users Not Working > From: > "Charles Hargrove" <n2nov(a)n2nov.net> > Date: > 12/09/2016 07:13 PM > > To: > 44net(a)hamradio.ucsd.edu > > > I am having trouble getting users to telnet from their homes to my JNOS box > located at 44.68.41.1 on port 2300. Their seems to be an asynchronous > connections as they try to transverse the UCSD portal. I see my responses > going back to them, but they are just hanging on their side. I have in my > autoexec.nos file "route add default tun1 44.0.0.1" as their is a tunnel > interface between the JNOS and the linux box that it is running on. Does > anyone have any ideas? Thanks. I get a connect but no text. Normally this means there is an MTU issue somewhere, but in this case (trying from net-44) the welcome text appears to be too smal for that kind of problem. it could be a firewall issue as well. Why do you set the default route to 44.0.0.1 instead of 169.228.66.251 ? Is that normal for JNOS? Rob

8 years, 4 months

4
3
0 0

Telnet To JNOS From Public IP Users Not Working

by Charles Hargrove

I am having trouble getting users to telnet from their homes to my JNOS box located at 44.68.41.1 on port 2300. Their seems to be an asynchronous connections as they try to transverse the UCSD portal. I see my responses going back to them, but they are just hanging on their side. I have in my autoexec.nos file "route add default tun1 44.0.0.1" as their is a tunnel interface between the JNOS and the linux box that it is running on. Does anyone have any ideas? Thanks. -- Charles J. Hargrove - N2NOV NYC ARECS/RACES Citywide Radio Officer/Skywarn Coord. NYC-ARECS/RACES Net Mon. @ 8:30PM 449.025/123.0 PL http://www.nyc-arecs.org and http://www.nyc-skywarn.org NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM on 7.036 Mhz USB/1500 hz waterfall spot; Olivia 8/500 check-ins "Information is the oxygen of the modern age. It seeps through the walls topped by barbed wire, it wafts across the electrified borders." - Ronald Reagan "The more corrupt the state, the more it legislates." - Tacitus "Molann an obair an fear" - Irish Saying (The work praises the man.) "No matter how big and powerful government gets, and the many services it provides, it can never take the place of volunteers." - Ronald Reagan "We are fast approaching the stage of ultimate inversion: the stage where the government is free to do anything it pleases, while the citizens may act only by permission." - Ayn Rand

8 years, 4 months

1
0
0 0

Re: [44net] LoRa

by Steve L

>Are hams allowed to use spread spectrum modes in USA? Yes. Speaking of rules... I once asked about data data rates and bandwidth rules for ham radio in other countries. I am interested in learning about spread spectrum rules, and encryption rules for the hobby in other areas for anyone who cares to share. Steve KB9MWR

8 years, 5 months

2
1
0 0

Re: [44net] LoRa

by Steve L

Dean, Thanks for sharing. Range will be the big thing at least for me, so if you get around to testing that, I hope you'll share your results. Though I am really leaning toward the 400 MHz modules. If there continues to be hold up on the MMDVM boards, then I'll likely order some LoRa modules for my winter project instead.

8 years, 5 months

1
0
0 0

LoRa

by Steve L

Since we really need some other data radio options in the hobby, I wanted to mention LoRa. It's a chirped spread spectrum technology used for low power WAN applications, with air transfer rates: 300bps-31.2Kbps. There are 433 MHz modules, as well as 900 MHz and 2.4 GHz. As a staring place, WA2KWR has some code here: https://github.com/fcolumbu/LoRa_Projects/wiki Steve, KB9MWR

8 years, 5 months

2
1
0 0

Re: [44net] LoRa

by Rob Janssen

> Since we really need some other data radio options in the hobby, I > wanted to mention LoRa. > It's a chirped spread spectrum technology used for low power WAN > applications, with air transfer rates: 300bps-31.2Kbps. There are 433 > MHz modules, as well as 900 MHz and 2.4 GHz. Indeed it is interesting, I have looked at it as well when a local telecom company recently announced it has deployed a country-covering network. (by mounting LoRa equipment at all cell towers and locations) They use 900 MHz, which is not a ham band here. But 433 could be useful. It is unfortunate that the datarate is too low for many applications. It could be interesting for APRS-like mobile datacomm or other telemetry, which is also what the commercial network is for. Rob

8 years, 5 months

2
1
0 0

postfix/smtp/smtpd flood...

by SP2L

Greetings. Lately my small amateur server been severely flooded with similar activities: Nov 21 22:54:01 linux postfix/smtp/smtpd[26048]: connect from unknown[200.7.249.218] Nov 21 22:54:02 linux postfix/smtp/smtpd[26048]: disconnect from unknown[200.7.249.218] Nov 21 22:55:01 linux postfix/smtp/smtpd[26048]: connect from unknown[83.70.149.33] Nov 21 22:55:04 linux postfix/smtp/smtpd[26048]: disconnect from unknown[83.70.149.33] Nov 21 22:56:59 linux postfix/smtp/smtpd[26066]: connect from mail.devaney.net[96.91.214.49] Nov 21 22:57:00 linux postfix/smtp/smtpd[26066]: disconnect from mail.devaney.net[96.91.214.49] Nov 21 23:00:11 linux postfix/smtp/smtpd[26161]: connect from unknown[83.70.149.33] Nov 21 23:00:11 linux postfix/smtp/smtpd[26161]: disconnect from unknown[83.70.149.33] Nov 21 23:02:27 linux postfix/smtp/smtpd[26203]: connect from unknown[186.33.182.12] Nov 21 23:02:28 linux postfix/smtp/smtpd[26203]: disconnect from unknown[186.33.182.12] Nov 21 23:02:31 linux postfix/smtp/smtpd[26203]: connect from unknown[unknown] Nov 21 23:02:31 linux postfix/smtp/smtpd[26203]: disconnect from unknown[unknown] Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: connect from unknown[50.126.82.18] Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: lost connection after HELO from unknown[50.126.82.18] Nov 21 23:04:32 linux postfix/smtp/smtpd[26205]: disconnect from unknown[50.126.82.18] System logs were building up very fast! Created new entries for fail2ban porogram and got rid of this in a few minutes time! In jail.local file added: [postfix-auth] enabled = true filter = postfix.auth action = iptables-multiport[name=postfix, port="http,https,smtp,submission,pop3,pop3s,imap,imaps,sieve", protocol=tcp] logpath = /var/log/mail.log In filter.d folder added new filter postfix.auth.conf with regex: # failregex = ^%(__prefix_line)slost connection after (AUTH|UNKNOWN|EHLO) from (.*)\[<HOST>\].* ^%(__prefix_line)sconnect from unknown\[<HOST>\].* ^%(__prefix_line)swarning: hostname.* ignoreregex = # >From now on NO MORE such crap!!! Best regards. Tom - SP2L

8 years, 5 months

1
0
0 0

Re: [44net] Wikipedia article on AMPRNet

by Steve L

Speaking of documentation... Every once and a while I get an email from someone, and it's not clear to them how the IP space is useful, "since everyone on the internet already has a publicly routeable address." Maybe that can be made clearer some where? Just a suggestion.

8 years, 6 months

1
0
0 0

Re: [44net] Wikipedia article on AMPRNet

by Rob Janssen

> Ah, I stand corrected; I've updated the entry. The section on 44.128/16 was > pointing to an obsolete article that incorrectly gave the impression that > that subnet was unroutable like an RFC1918 network, whereas it's really just > reserved for testing. > Unfortunately, there's an article on www.eastnetpacket.net that incorrectly > states that it *IS* an RFC1918-style network and people outside the AMPRNet > are quoting it as justification for using the network AS an unrouted network. Well, that amprnets.txt file of course has existed and has been maintained on hamradio.ucsd.edu for many many years. I have 3 old copies and all of them mention that it may be assumed that any packets with 44.128 addresses are bogons, so this text has probably been there for at least a decade if not much more. Currently this file does not exist anymore at hamradio.ucsd.edu, I presume its function has been taken over by the "networks" menu item at portal.ampr.org. However, that listing does not mention 44.128.0.0/16 at all. When it is desired to change the definition of this subnet, it may be better to provide an explicit new definition, instead of trying to remove the old definition from internet without providing a new one. I think that is not going to work well, given the way information is stored, copied and archived on the web. Also note that this information on portal.ampr.org is only available to registered users, so it would be wise to put some information on a publicly available site as well (maybe a description of the subnetting of net 44 at the top level without all that country-specific info). That could be on the www.ampr.org site. Rob

8 years, 6 months

2
1
0 0

Wikipedia article on AMPRNet

by Brian Kantor

There are some rather troublesome inaccuracies in the Wikipedia article on the AMPRNet. Does anyone on this list have edit privileges on this page so those could be corrected? - Brian

8 years, 6 months

3
5
0 0

44.127/16

by Assi Friedman

Quick question: why is 44.127/16 listed as "No Country" on the portal? How are the subnet allocations different from allocations that belong under a specific country? Thanks, Assi

8 years, 6 months

2
1
0 0

Missing RIP broadcasts

by Boudewijn (Bob) Tenty

Hi Brian, I don't see the rip broadcasts from ucsd to my gateway at 69.165.175.62 since a couple days. I'm still in the encap.txt and I still see the regular packets routed by ucsd.edu addressed to my subnets coming in. Something wrong at that end? Bob (Boudewijn) VE3TOK -- There is nothing permanent except change Heraclitus

8 years, 6 months

6
7
0 0

Re: [44net] EdgeRouter/EdgeOS Wiki

by Rob Janssen

> I've tried a few other things with no avail at this point. Put a monitoring device at the outside port, or start a data capture in the router itself when EdgeOS can do that, and then check what is arriving when you do the outside ping. When you see packets coming from 169.228.66.251 addressed to your external IP with protocol field 4 you at least know the external causes are covered. You can then concentrate on the setup of your router. When no such packets appear, the problem is in your gateway setup at portal.ampr.org or your DNS entry. As I don't see your callsign or AMPRnet IP anywhere in your message I can't do much research... Rob

8 years, 6 months

5
10
0 0

tunl0 and ax0

by Eduardo Castillo

Hi a question tunl0 tunnel is my ip 44.153.32.97 and my radio ax0 44.153.35.100 as I can do to make 44.153.35.0/24 out by ax0 and not tunl0 my local colleagues via radio frequency use 44.153.35 0/24 regards -- __ __ __ __ | / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz |__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300 == power by linux === NODO LU9DCE.DYNU.COM PORT 3694 ## AMPR NET 44 // LU9DCE.AMPR.ORG // 44.153.32.97 ## *** https://www.facebook.com/groups/newpacketradio/ GRUPO DE PACKET WHATSAPP https://chat.whatsapp.com/Id3cEQjDdXl8BL0Sik4lGQ

8 years, 6 months

2
1
0 0

system 'hamradio' offline Monday

by brian

The host 'hamradio.ucsd.edu' will be offline some of Monday to upgrade its operating system. Services such as this mailing list and the DNS robot will be unavailable during that time. - Brian

8 years, 6 months

2
3
0 0

Re: [44net] EdgeRouter/EdgeOS Wiki

by Rob Janssen

> Any ideas? I feel like I did configure the tunnel correctly, but I don't > see anything on the LAN. Will post config if needed. Your gateway config looks OK to me. Your route entry appears in our gateway: 44.98.17.32/27 via 73.1.142.180 dev tunl0 proto ampr-ripd metric 4 onlink (of course useless for us, because the method described on the WiKi does not provide connectivity for gateway stations other than amprgw) I can ping your external address. Maybe Comcast or the modem is filtering IPIP? Rob

8 years, 6 months

2
2
0 0

Re: [44net] Stats

by Steve L

Its not perfect. I was just curious as to the shift now being done direct with BGP. Probably the most useful information for many would be to correlate gateways or network space with a rough location. One might like to coordinate some coordinate some tunneled activities/traffic with someone in a geographic area for instance. I for one, would like to know who else in my state is reachable over 44net. But I don't see an easy way to do that.

8 years, 6 months

1
0
0 0

Re: [44net] Stats

by Rob Janssen

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

8 years, 6 months

1
0
0 0

Re: [44net] Stats

by Steve L

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

8 years, 6 months

2
1
0 0

Re: [44net] Stats

by Rob Janssen

What do these numbers mean? Rob

8 years, 6 months

1
0
0 0

Stats

by Steve L

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

8 years, 6 months

1
0
0 0

EdgeRouter/EdgeOS Wiki

by Rob Janssen

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

8 years, 6 months

2
2
0 0

EdgeRouter/EdgeOS Wiki

by Miguel Rodriguez

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

8 years, 6 months

1
0
0 0

Re: [44net] Dynamic IPENCAP Filtering on OpenWRT/iptables-based devices

by Rob Janssen

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

8 years, 6 months

1
0
0 0

Re: [44net] Information - Traffic Attempt to Route Through my Node

by Rob Janssen

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

8 years, 6 months

2
1
0 0

Re: [44net] test ping

by Rob Janssen

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

8 years, 6 months

1
0
0 0

Re: [44net] test ping

by Rob Janssen

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

8 years, 6 months

4
3
0 0

test ping

by Eduardo Castillo

Hello !! as I can test the ping to my ip .. my route in dmz activated addressed to my pc I tried the page http://yo2tm.ampr.org/nettools.php and it's OK ! my ip is 44.153.32.97 --------- Hola !! como puedo testear el ping hacia mi ip .. mi route en dmz activado dirigido a mi pc yo probe la pagina http://yo2tm.ampr.org/nettools.php y esta bien ! mi ip es 44.153.32.97 -- ====================================================================== La vida nunca nos depara lo que queremos en el momento apropiado. Las aventuras ocurren, pero no puntualmente. -- Edward Morgan Foster. ====================================================================== __ __ __ __ | / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz |__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300 == power by linux === NODO LU9DCE.DYNU.COM PORT 3694 ## AMPR NET 44 // LU9DCE.AMPR.ORG // 44.153.32.97 ## *** https://www.facebook.com/groups/newpacketradio/

8 years, 6 months

5
4
0 0

fwd linfbb

by Eduardo Castillo

Hello everyone I have a running FBB baires I would like to have a fwd with a colleague europe or usa network by 44 if there is any colleague who could - I would appreciate I leave my email lu9dce(a)gmail.com regards 73 -- ====================================================================== El joven conoce las reglas, el viejo las excepciones. ====================================================================== __ __ __ __ | / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz |__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300 == power by linux === NODO LU9DCE.DYNU.COM PORT 3694 ## AMPR NET 44 // LU9DCE.AMPR.ORG // 44.153.32.97 ## *** https://www.facebook.com/groups/newpacketradio/

8 years, 6 months

1
0
0 0

Re: [44net] test ampr bbs

by Rob Janssen

> Subject: > [44net] test ampr bbs > From: > Eduardo Castillo <lu9dce(a)gmail.com> > Date: > 10/12/2016 06:46 PM > > To: > 44net(a)hamradio.ucsd.edu > > > pls test bbs 44.153.32.97 port 6300 !! > > send report !! my mail lu9dce(a)gmail.com !! tks !! I can't connect it. There appears to be a tunnel route to 44.153.32.97 via 181.192.58.28 but I can't even ping 44.153.32.97 so probably there is some issue, maybe the wellknown NAT DMZ issue? Rob

8 years, 6 months

5
4
0 0

Re: [44net] test ampr bbs

by Rob Janssen

> I can ping 44.153.32.97 from here and connect to his port 6300. > - Brian When I ping from a public IP it works, the traffic will then be routed over internet to amprgw and then tunneled to him. He probably has reverse traffic via amprgw so there is an open "session" in his router. When he pings me, he gets replies. But when I later (or before) ping him, I only see the traffic departing at our GW (properly encapsulated and sent to 181.192.58.28) but nothing is returned. I suspect it is the problem of being behind a stateful firewall in a NAT router. This sometimes cannot be disabled for other protocols than TCP/UDP even when defining the host as "DMZ Host". But I don't know if he has already tried that. Rob

8 years, 6 months

1
0
0 0

test ampr bbs

by Eduardo Castillo

pls test bbs 44.153.32.97 port 6300 !! send report !! my mail lu9dce(a)gmail.com !! tks !! -- ====================================================================== Hombre invisible busca mujer transparente para hacer lo nunca visto. -- Stepi taglines. ====================================================================== __ __ __ __ | / \(__\| \/ |_ BBS GF05OM TORTUGUITAS 145010Mhz |__\__/ __/|__/\__|__ TELNET LU9DCE.DYNU.COM PORT 6300 == power by linux === NODO LU9DCE.DYNU.COM PORT 3694 ## AMPR NET 44 // LU9DCE.AMPR.ORG // 44.153.32.97 ## *** https://www.facebook.com/groups/newpacketradio/

8 years, 6 months

1
0
0 0

Information - Traffic Attempt to Route Through my Node

by lleachii＠aol.com

All, FYI, I have recorded NetFlow on my tunl0 interface that appears to be NESTED IPENENCAP packets. I have also seen these previously. This is similar to a vector I described in my 20AUG remarks in "Security/Wiki Question - Requesting a Block." Because the source and destination IP addresses recorded could be spoofed (or the result of a misconfigured AMPR router), I do not want to alarm anyone by giving the specific address. I will note the packets contained the source address of an AMPR node and the destination of AMPRGW (i.e. another nested packet or a packet that would be de-encapsulated by AMPRGW); and were recorded over 60 seconds in a window of 24 hours. I have added the following rule to my firewall, to appear in iptables before my bogons: # THIS PREVENTS NESTED IPENCAP iptables -t raw -I PREROUTING -p 4 -i tunl0 -j DROP To add: a source IP iptables rule (based on BCP 38) had prevented these packets from forwarding. 73, - Lynwood KB3VWG /"//Archives of security comments in this forum from others suggest proper firewalling is necessary in environments running IPENCAP-enabled routers, ESPECIALLY BECAUSE of the presence of NAT/masquerade co-existing in some AMPRNet nodes..."/

8 years, 6 months

2
3
0 0

Re: [44net] Information - Traffic Attempt to Route Through my Node

by Rob Janssen

> FYI, I have recorded NetFlow on my tunl0 interface that appears to be > NESTED IPENENCAP packets. I have also seen these previously. I have had a rule in place to log and drop these for ages, and I have not seen them recently at our gateway. As pointed out, they are configuration errors, e.g. because people put 44net addresses as tunnel endpoint address and policy routing is sending the traffic into a tunnel instead of direct on the interface. Other misconfigurations can result in recursive encapsulation. I believe I added the rule when there was an incident resulting in many-level encapsulated IPIP packets that only were limited by the MTU. When you are worried about intrusions it is probably more effective to block IPIP packets from sources that are not in the gateway list. I do that as well (via ampr-ripd). Rob

8 years, 6 months

1
0
0 0

Re: [44net] Issue routing multiple IPs to Mikrotik

by Rob Janssen

> So in my opinion the best approach would be to send only traffic with 44 > origin and 44 destination not in other routes via ampr-gw, to preserve > your original 44 IP. > All the rest should be NAT-ed to your public gateway IP, not your > gateway's 44 net, in order to circumvent the whole 44net completely. > This will give you better speed, better response times and will ease the > work of the ampr gateway. I agree that there are situations where you better NAT the traffic than send it via amprgw. E.g. you are running Windows or Linux systems on 44-net addresses and you want to fetch operating system- or virus signature updates from an internet source, and you do not want to needlessly load amprgw with that traffic. (over here that does not really matter, we have our own gw and it can easily handle that load for the subnet of users that are in 44.137.0.0/16) Unfortunately, there are also situations where that NAT is really undesirable. The best example is Echolink. It simply will not work correctly when your system partly communicates directly (to other 44net systems) and partly uses NAT to communicate to internet systems. Of course it is also possible to use advanced techniques like the packet- and connection marking that you already mentioned to run a mix between direct and NAT. For a while I had a connection mark in the gateway that was set for certain host/port combinations and forced the use of srcnat in the POSTROUTING table. This was an attempt to work around issues like Echolink and also reachability of a system that is also running partly with NAT. I have dropped it some time ago as it was not easy to maintain it. Rob

8 years, 7 months

1
0
0 0

Issue routing multiple IPs to Mikrotik

by Christopher S. Munz-Michielin

Hey all, I've been trying to configure a Mikrotik router to allow devices connectivity to the Amprnet and have been running into a bit of a snag. First off here's what my architecture looks like: Internet------------->Edge Router------------>AMPR Mikrotik------------->Devices I have a public IP on the edge router and a static /29 of public IPs between the Edge router and the AMPRNet router. I have confirmed I have external access to the AMPRNet router's public IP. I followed the guide outlined by Marius here: http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt and have the following WORKING as expected: 1) connectivity from the Internet to my router's 44 IP (44.135.193.129) 2) connectivity to/from the AMPRNet to my router's 44 IP 3) connectivity to/from the AMPRNet to devices behind my router (44.135.193.18) What is not working is connectivity from the Internet to devices behind the router; i.e. I am unable to PING these devices from the Internet and am unable to access any Internet resources from these devices. If I add a layer of NAT at the AMPR router, the end devices CAN access the Internet, as the source IP is concealed and appears to UCSD to be that of the 44 IP of my router (44.135.193.129). I have also tried to add an additional 44 IP to my ampr-gw IPIP interface (44.135.219.130/8) but am also unable to PING that IP from the Internet. When I look at a packet capture on the router I do not see any packets destined for this second IP making it to the router at all. Is there something special that needs to be done in order to facilitate routing to more then one 44 IP via the UCSD tunnel? Cheers, Chris

8 years, 7 months

4
7
0 0

Re: [44net] Issue routing multiple IPs to Mikrotik

by Rob Janssen

> if you want to go to the internet from 44net you need to NAT. you should > also have a firewall to deal with those issues as well > also you want to NAT if you go from a non-routable to 44net This is of course incorrect. The whole point of having amprgw is to be able to communicate between 44net and internet without having to use NAT. But indeed it is true that for amprgw and some other gateways to transport your traffic between internet and 44net you need to have a DNS entry for each of your addresses. And it is also true that you should have a careful look at your firewall when you are not used to having systems "directly on the internet" without the implicit firewalling provided by a NAT router. Rob

8 years, 7 months

1
0
0 0

Re: [44net] IPv6

by Rob Janssen

> Perhaps someone would like to know not only what are the callsigns under > which both endpoints of the RF are operating, but also who is the > Amateur that originated the message and which Amateur is the final > recipient. I can imagine several reasons to want to know these. In the packet radio days, our license conditions explicitly included this requirement. It was fulfilled by ordinary digipeating, but not by NET/ROM. I added support to my version of NET to make NET/ROM nodes operate as a virtual digipeater, so the outgoing connect of a NET/ROM on behalf of a user was not made under the USERCALL-(15-SSID) call, but as "user via node". (a packet that was transmitted by the node as if it had been digipeated by the node) IP was a problem under those regulations, however an arrangement was made with the authorities that source and destination of the traffic were sufficiently identified when there was an accessible list of IP addresses and corresponding callsigns. The hosts files provided that information. (I doubt that the authorities ever listened in on amateur IP over AX.25 traffic and tried to identify the endpoints, I heard that the only AX.25 equipment available at the monitoring station was a PK-232) However, since then we have lost our "license" and now operate under a "unlicensed station with mandatory registration" regime here, with usage conditions that are far less detailed. Operating modes are no longer specified, only identification modes. As long as you ID your station in one of a specified set of modes, they no longer care what you transmit and what its source is. This also makes it legal to forward internet content, something that was not allowed under our old license conditions (that explicitly prohibited 3rd party content and connections with external networks). But of course it can still be useful to have identification information in IPv6 addresses, if only because of the general lack of reverse-DNS information in the IPv6 network. Rob

8 years, 7 months

2
1
0 0

Re: [44net] IPv6

by Rob Janssen

> I don't see why anyone would want to encode information about the > country in the first 64 bits, especially since you can use compound > callsigns such as PA/EA4GPZ if you're operating abroad. > Perhaps it would be interesting to have the information about the > Maidenhead locator or GPS coordinates of a subnet (where this makes > sense). Someone could use this info to make a geographical map of the > network. However, I think that this info should belong to an external > database (whois maybe) and not be encoded in the IPv6's. I also don't think it should be done that way, especially because we seem to agree on the idea that we do not want to have a large IPv6 network for amprnet (which we could subnet in creative ways), but rather use the IPv6 addresses provided by a local ISP. We don't have control over the numbering and network size of those addresses, and especially during the initial phase of the rollout there will always be ISPs that do not understand IPv6 and give a customer only a single /64 or even less. Hopefully that will change later, but we cannot wait for that forever. So, keep all special handling in the last 64 bits and treat the first 64 as random. I think a special handling of the address should not even be mandatory, only a good suggestion that may help others to determine the source of traffic easily. It should still be possible to send traffic from addresses not conforming to this methid, at most risking that it will be dropped at an internet-radio gateway when prior arrangements have not been made. Probably a next step would be to standardize a method to distribute information about valid IPv6 AMPRnet networks (that can be somewhat trusted in access lists). E.g. use BGP, downloadable textfiles, (ampr-)RIPv6, etc. It may not be possible to standardize a single method due to limitations of used software and hardware, although this probably is less important than with the current gateway list. (where we need to remain compatible with very old software that cannot do IPv6 anyway) Rob

8 years, 7 months

4
3
0 0

Re: [44net] IPv6

by Rob Janssen

> Hmm.. Do you have any examples of such ISPs? I’ve only seen them give out a /64 to the PPPoE / WAN interface and then also have a routable /56 or /48 which is almost always available using DHCPv6-PD. The /64 is only used for communication with the ISP (can also be a /126) while everything else if up to the router to manage. Although I do get a /48 from my ISP there is nothing I can manage about the subnetting. The 16 bits between my prefix and my networks are assigned by my router using DHCPv6-PD and there is nothing I can do to set these bits. They are assigned to my networks sequentially. I don't think it is feasible to use those bits with a special meaning. Rob

8 years, 7 months

3
2
0 0

Re: [44net] IPv6

by Rob Janssen

> I'm using this proposal in my systems: >https://github.com/darconeous/ham-addr/blob/master/ham-addr.txt.md Maybe it is useful to develop a simple tool, e.g. a webpage with some javascript, that allows input of a callsign in a field and converts the input to the HAM-64, EUI-48 and EUI-64 forms as far as possible. A similar tool could work the other way around. This allows some experimentation. Rob

8 years, 7 months

2
1
0 0

Re: [44net] IPv6

by Rob Janssen

> Currently many routers (I’ve tested and written a tutorial on Ubiquiti, and OpenWRT) allow you to set the subnet you want. In addition to that, some ISPs have pages that have details on how to do this in FreeBSD, OpenBSD, Gentoo, Windows, Cisco, etc. Of course, the modem / router / switch / access point provided by the ISPs may not allow you this, but it’s certainly possible. In the MikroTik routers quite popular in amateur networking, and also in the AVM Fritz!box routers that my ISP provides, it is not possible to do this when DHCPv6-PD is used. (it is possible when static IPv6 addresses are used as is done by some ISPs) There is an open feature request at MikroTik to implement something like you depict in your tutorial, but currently it is not there. Rob

8 years, 7 months

2
1
0 0

Re: [44net] IPv6

by Rob Janssen

> The good thing about IPv6 is that due to the large address space it's > possible to make it mandatory to encode the callsign in the last 64 bits > of the address. This eliminates the problem that we have in IPv4 of > trying to trace back which callsign is behind an IP. I think it basically is a good idea, but it needs to be more flexible. We would like to be able to derive the callsign from the IP, but there should be no 1:1 mapping between callsign and IP, because that would mean only a single system can be online for each callsign. The standard should leave some bits (at least 8) available for use as "SSID" as we had in the packet days (callsign-1 callsign-2 etc), maybe also with some encoding of alphanumeric values. Rob

8 years, 7 months

4
5
0 0

IPv6

by Dani EA4GPZ

Hi all, Sorry for the slight off-topic. I'm testing in my systems the idea of using IPv6 for Amateur Radio. My idea is to use some way of encoding the callsign in the IPv6 address. I'm using this proposal in my systems: https://github.com/darconeous/ham-addr/blob/master/ham-addr.txt.md Certainly, there are several other proposals that could be used. The good thing about IPv6 is that due to the large address space it's possible to make it mandatory to encode the callsign in the last 64 bits of the address. This eliminates the problem that we have in IPv4 of trying to trace back which callsign is behind an IP. The idea is to make some sort of whitelist of globally routable subnets that are using some way of encoding the callsign into the IPv6 (I would like to allow for the admin of a net to choose the encoding he wants to use). This whitelist can then be used in a firewall for several things: allowing access to some services to Amateurs only or deciding if a packet is fit to be routed by an RF link (for instance, one could require that the source and destination have both their callsigns encoded in their IPv6's). I'm using the subnet 2001:470:6915:8000::/49 for these tests. If someone has IPv6 connectivity and wants to try, there's a mumble server and a DX cluster (telnet port 7300) at ea4gpz.destevez.net (its IPv6 has the callsign EA4GPZ-Z encoded). The long term goal would be to have something similar to the 44net but where each user is using subnets allocated directly from their ISP instead of having a large block for amateurs (like the 44.0.0.0/8). Connectivity between different amateur subnets would run over the IPv6 internet instead of using a mesh VPN (as the IPIP mesh of 44net). The whitelist could be used to decide which IPv6's are amateur and get "special treatment". I have a longer text describing these ideas, but it's in Spanish. I'll translate it and put it somewhere, but I want to keep this email short enough. So, is anyone doing something similar already? I would like to get some subnets into the whitelist, so I can test how well this works. Questions, suggestions, comments? Anyone interested in joining these tests? 73, Dani EA4GPZ.

8 years, 7 months

1
0
0 0

Re: [44net] Security - Telnet (port tcp/23)

by Rob Janssen

> the "Iot" is quite a culprit..I am constantly probed and attacked by > routers, refrigerators, and many, many so-called "smart > TV's"...sometimes, when I'm bored, I shut them off...it gives me a > tickle to think of someone botting away and abruptly being shut > down...but the poor, unknowing customer is the one who suffers...I've > got to wonder if they even notice their appliance is acting strangely, > or laggy, and why... > this would best be fixed at the manufacturers end.. At least half of the problem is the refusal of ISPs in general to implement BCP38. When there would be source address filtering, we would not see all the backscatter (DNS replies mainly). Then there are shodan.io and a lot of other "research" systems. I keep a blacklist to drop all their traffic, but of course it still arrives at the router. They usually offer unlisting the network, but at least in the case of shodan.io this is completely fake. A day or a week later they just resume. Finally we all know about the cheap virtual Linux cloudhosting companies like AWS, Linode, etc. Probably half blackhats, half sincere users don't even know that they got hacked. After all, Linux is secure so you don't have to think about that. Rob

8 years, 7 months

1
0
0 0

Re: [44net] Security - Telnet (port tcp/23)

by Rob Janssen

> The unanswered SYN traffic to port 23 is much, much more. Especially before the "allow only > registered hosts" filter. We are dropping around 80 Mbyte/day of traffic for our /16 subnet due > to the address not being registered, so that would be about 20 GByte/day for amprgw.... Of course it is way more than that. I forgot that the about count is only for the subnets within our /16 that are actually routed. That is about 1/5 of our space. So the total "noise" traffic is more like 400 MB/day and would be like 100 GB/day for the entire AMPRnet. Rob

8 years, 7 months

4
4
0 0

Re: [44net] Security - Telnet (port tcp/23)

by Rob Janssen

> I usually allow remote access (SSH, RDP, etc...) through VPN only. > When access from Internet is absolutely required (because it's not > possible to have a VPN), then I usually add a firewall rule to allow > access only from a list of known WAN IP addresses. That is certainly the best approach! Also, whenever possible, I run those protocols on IPv6 only, preferably on an address that is not as well in DNS for other services on the host. They cannot viably scan the IPv6 range so this obscurity hides the remote access quite well. Rob

8 years, 7 months

2
1
0 0

Re: [44net] Security - Telnet (port tcp/23)

by Rob Janssen

> >/When I had SSH open to the world, I saw similar usernames in the failure log as I now /> >/see on this telnet honeypot. / > If your connectivity to the world is via a tunnel from amprgw, please > resist the temptation to run a honeypot - we're trying to reduce the > amount of bandwidth, not increase it. Although a honeypot isn't > necessarily a big bandwidth consumer, every bit helps. > - Brian It is on our BGP-routed subnet so the traffic is via our own gateway through a direct IPIP tunnel to that system. However, it is not really something to worry about. It attracts about 10-20 kbytes of internet->host traffic per day (the usernames and passwords that I log). Those attackers are trying maybe 10-15 different logons then move on. It is not like they try a list of 100,000 most often use passwords, they probably have the default passwords for some commonly used routers and other IoT devices, in some cases probably only a single one. (the worms that infect one particular device) The unanswered SYN traffic to port 23 is much, much more. Especially before the "allow only registered hosts" filter. We are dropping around 80 Mbyte/day of traffic for our /16 subnet due to the address not being registered, so that would be about 20 GByte/day for amprgw.... Rob

8 years, 7 months

1
0
0 0

Re: [44net] Security - Telnet (port tcp/23)

by Rob Janssen

> As always, the best practice recommendation is to disable telnet logins > entirely as it represents a security issue because passwords pass over > the connection in clear plaintext. > - Brian Well, the issue is not really the passwords being in plaintext. The issue is the availability of a remote login feature with possibly weak passwords. It affects SSH just as much as it affects telnet. The malvolents are scanning the IPv4 space and when they can connect to a remote logon service (telnet, SSH, RDP, VNC) they try a number of common usernames and passwords. They are not listening in on your traffic. While it is clear that telnet is not the most secure login service, it really doesn't make a difference. I have a fake telnetd running on one of my systems that simply presents the user with a login prompt and logs what is being typed, and it shows endless connections trying things like root/12345 root/password admin/admin etc. They probably get into certain routers or other systems like that, then install some trojan that does further scanning. This is also indicated by certain loggings where they apparently believe they got logged in and then send a long string like "wget something; chmod a+x something; ./something" or similar. Rob

8 years, 7 months

5
4
0 0

Re: [44net] Security - Telnet (port tcp/23)

by Rob Janssen

> The term to search for is 'honeypot'. There are many such scripts out there > on github and on the web in general. That is correct. In my case I quickly hacked something together but there are lots of examples to be found that are probably much more advanced. When I had SSH open to the world, I saw similar usernames in the failure log as I now see on this telnet honeypot. Rob

8 years, 7 months

2
1
0 0

Re: [44net] Security - Telnet (port tcp/23)

by Gabriel Medinas

Hello Lynwood, I had in my JNOS virtually a lot of attempts connections to port 23 from all part of the world, to achieve forwarding to other BBS had change the telnet port to 2323 and substantially lower these attempts. When I speak attempts to port 23 are evidence of brute force, it is almost impossible to have open this port, also same the 20, 21, 443, etc. 73 Gabriel YV5KXE. Venezuela AmprNet Coordinator yv5kxe.ampr.org Date: Thu, 29 Sep 2016 12:15:57 -0400 From: lleachii(a)aol.com To: 44net(a)hamradio.ucsd.edu Subject:Date: Thu, 29 Sep 2016 12:15:57 -0400 From: lleachii(a)aol.com To: 44net(a)hamradio.ucsd.edu Subject: [44net] Security - Telnet (port tcp/23) Message-ID: <8c28faa2-76ff-45a9-06c6-1705433cf307(a)aol.com> Content-Type: text/plain; charset=windows-1252; format=flowed All, In June, we discussed a topic entitled: "Odd Username attempts at login" where Bill, KG6BAJ noticed odd connection attempts to his JNOS system via Telnet. I have recently been working on my SNMP and NetFlow servers, and noticed quite a bit of Telnet connection attempts from Asia, Europe and South America. While I have also seen SSH, RDP, NTP, ICMP and VNC, by far the largest amount of traffic reaching my border interface is Telnet. Doing some research, I discovered that NIC.CZ <http://nic.cz/> has been operating the Turris Project. They have determined that these attempts are coming from a botnet of embedded devices that have Telnet vulnerabilities. I have provided a link to those findings here: https://en.blog.nic.cz/2016/09/01/telnet-is-not-dead-at- least-not-on-smart-devices/ 09-28 19:57:36 0.000 TCP 60.189.137.98:28940 -> 44.60.44.128:2323 09-28 19:57:55 0.000 TCP 115.219.124.37:49067 -> 44.60.44.133:23 09-28 19:57:55 0.000 TCP 222.124.85.17:34905 -> 44.60.44.133:23 09-28 19:57:52 5.552 TCP 190.67.215.114:29593 -> 44.60.44.6:23 09-28 19:58:03 0.123 TCP 115.219.124.37:21070 -> 44.60.44.133:23 09-28 19:58:54 0.000 TCP 116.102.62.182:37311 -> 44.60.44.135:23 Please be mindful. 73, - Lynwood KB3VWG

8 years, 7 months

1
0
0 0

Security - Telnet (port tcp/23)

by lleachii＠aol.com

All, In June, we discussed a topic entitled: "Odd Username attempts at login" where Bill, KG6BAJ noticed odd connection attempts to his JNOS system via Telnet. I have recently been working on my SNMP and NetFlow servers, and noticed quite a bit of Telnet connection attempts from Asia, Europe and South America. While I have also seen SSH, RDP, NTP, ICMP and VNC, by far the largest amount of traffic reaching my border interface is Telnet. Doing some research, I discovered that NIC.CZ has been operating the Turris Project. They have determined that these attempts are coming from a botnet of embedded devices that have Telnet vulnerabilities. I have provided a link to those findings here: https://en.blog.nic.cz/2016/09/01/telnet-is-not-dead-at-least-not-on-smart-… 09-28 19:57:36 0.000 TCP 60.189.137.98:28940 -> 44.60.44.128:2323 09-28 19:57:55 0.000 TCP 115.219.124.37:49067 -> 44.60.44.133:23 09-28 19:57:55 0.000 TCP 222.124.85.17:34905 -> 44.60.44.133:23 09-28 19:57:52 5.552 TCP 190.67.215.114:29593 -> 44.60.44.6:23 09-28 19:58:03 0.123 TCP 115.219.124.37:21070 -> 44.60.44.133:23 09-28 19:58:54 0.000 TCP 116.102.62.182:37311 -> 44.60.44.135:23 Please be mindful. 73, - Lynwood KB3VWG

8 years, 7 months

2
1
0 0

Re: [44net] Fwd: MicroTik and Dumb Questions

by Rob Janssen

> You need to use mangle rules in firewall to mark the incoming packets from the gateway interface and then using route marking route them back out the way they came. That is another approach, but you will have to handle outgoing connections as well. Rob

8 years, 7 months

3
4
0 0

Fwd: MicroTik and Dumb Questions

by Miguel Rodriguez

Good evening/morning folks! I have some dumb questions about setting up the MicroTik. I currently have everything set(I got all the RIP records and routes created), however, it can't talk to the internet. I'm trying to figure out, would this be a firewall issue? Do I need to create a whole new NIC just for the 44net? Basically, where should I go from here? Thanks, Miguel Rodriguez 12th Grade Student miguemely101(a)gmail.com <javascript:_e(%7B%7D,'cvml','miguemely101(a)gmail.com');> Tel: *561-758-0631* *Accredited District Since 2008; Re-certification - January 2013* Home of Florida's first LEED Gold Certified School *Disclaimer*: Under Florida law, e-mail addresses are *public records*. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing. -- Miguel Rodriguez 12th Grade Student miguemely101(a)gmail.com Tel: *561-758-0631* *Accredited District Since 2008; Re-certification - January 2013* Home of Florida's first LEED Gold Certified School *Disclaimer*: Under Florida law, e-mail addresses are *public records*. If you do not want your e-mail address released in response to a public records request, do not send electronic mail to this entity. Instead, contact this office by phone or in writing.

8 years, 7 months

4
4
0 0

Re: [44net] Fwd: MicroTik and Dumb Questions

by Rob Janssen

> Rob, > I thought the script took care of routing. So I would have to create new routes for 44net to go to the IPIP tunnel? It should not be required for 44net, but only for internet. I.e. for communication between your 44net hosts and systems on internet outside 44net. That traffic has to be forced through the IPIP tunnel to UCSD (169.228.66.251) instead of directly to your ISP, which will drop it. This can be achieved by creating the 44net routes in a different routing table, I'll wait to see if Marius joins the discussion to find how this is best achieved when using his script. I am not using IPIP myself on my MikroTik, I have a VPN to another system and use BGP. There I have configured the BGP to put the routes in a separate routing table named amprnet and configured some IP Route Rules so that this table is used for amprnet traffic only. Rob

8 years, 7 months

2
2
0 0

Re: [44net] Fwd: MicroTik and Dumb Questions

by Rob Janssen

> I have some dumb questions about setting up the MicroTik. I currently have > everything set(I got all the RIP records and routes created), however, it > can't talk to the internet. I'm trying to figure out, would this be a > firewall issue? Do I need to create a whole new NIC just for the 44net? When you want to route from net-44 addresses to internet (non-net-44), and your ISP implements source address filtering (BCP38) you need to setup policy routing, because you need a separate default route for traffic from your public internet address (pointing to your ISP) and for traffic from your net-44 systems (pointing to the IPIP tunnel to UCSD). Rob

8 years, 7 months

2
1
0 0

Allocation of addresses

by John Ricketts

Thank you to all that responded to my email, I made my request through the portal. I would like to provide free tunnel services to any amateur that applies and issue 44net addresses to those who qualify. I also will be experimenting locally with RF. I am currently connected to AT&T at 10gbits/sec, should be snappy. Thanks! John KD5ZZH

8 years, 7 months

1
0
0 0

Re: [44net] Co-located point of presence for 44net

by Rob Janssen

> So my question is this: Is what I want to do feasable as a way to get a > static address and act as an AMPR gateway? Yes, this works quite well. I have the same setup here. I have a colocated Raspberry Pi that is on the IPIP mesh using ampr-ripd in the standard setup that is described on the WiKi, and it serves my subnet and a couple of /32 addresses. My subnet is tunneled to my home using IPsec in AH/Tunnel mode. Using AH instead of ESP (as is usually used) reduces CPU usage, and encryption is not required for this purpose anyway. At home I have a MikroTik router. I do have a fixed IP at home so IPsec is easy, when you don't have that it may be easier to use a VPN that does not care about addresses, e.g. OpenVPN. I also run a couple of applications locally on the Pi, hence the /32 addresses. Today, thanks to Marius' work, it is also possible to use a MikroTik router instead of the Raspberry Pi. It may be easier to configure and is available in rackmount formfactor. Rob

8 years, 7 months

1
0
0 0

Co-located point of presence for 44net

by Tom C

Greetings. I'm somewhat new to the list and would like to join the network. I am not able to get a static address from my ISP, well I could, but I'd have to get a business account and my speeds would be a lot slower than they are now. I'm considering getting a VPS or a colocated raspberry pi to act as a vpn server and my point of presence to connect to my network via a tunnel. A rough ASCII diagram follows: (^^^^^^^^^^^^^^^^^^^^^^^^^^^^) ( IPIP/Tun0/VPN Svr <<--- ) ( Ieth0 RasPi in DATA CENTER) (vvIvvvvvvvvvvvvvvvvvvvvvvvvv) I (^^I^^^^^^^^^^) (^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^) ( Internet )====(>LinuxRouter/VPN/Tun0/eth2-->>44.98.63.0/29) (vvIvvvvvvvvvv) (vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv) I (^^I^^^^^^^^) (IPIP @ SDSU) ( 44/8 ) (vvvvvvvvvvv) My intent is to initilly have connectivity for a small LAN and then build it out over AX25 for my local area. I've run linux as my router/firewall (iptables and ipset) since 2012, but have not done much with "ip route" or "route", tunneling or anything with bridging but I did play a little with GRE and OpenSwan a couple of years ago. My thinking is building tun0/eth0 bridge and feeding that through the VPN to the distant RasPi which would vbidge the other end of the connection to the IPIP tunnel. So my question is this: Is what I want to do feasable as a way to get a static address and act as an AMPR gateway? Any suggestions, hints or approaches to prod me in the right direction to get me going would be appreciated. -- tom 73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified

8 years, 7 months

1
0
0 0

New 44.0.0.0 /24 request

by John Ricketts

All, KD5ZZH here. I currently run an ISP (AS 62744) and I would like to provide an exit bridge to the public internet and link the Tom Green<x-apple-data-detectors://0> County, TX area as well. How does one go about getting a /24 out of the block? John Ricketts, PhD Quintex Alliance Consulting (325) 263-3488<tel:(325)%20263-3488>

8 years, 7 months

3
3
0 0

ampr-ripd update 1.14

by Marius Petrescu

Hello all, It seems that the ampr-ripd daemon will be included into Debian by the DebianHams group. To be able to fit into an easy setup for all fellow hams, after discussions with Brian Kantor and Ana C. Custura taking care of packackaging it, we reached the following conclusions: - The RIP password was never actually meant as a security feature, more a validation mechanism - Everyone having access to the RIP data can actually extract the password by sniffing the stream - Since access to the network implies a gateway registration, and the RIP sources are well defined and restricted, the password could be ignored. Now, as a result of these discussions, I made some changes to the ampr-ripd daemon: - the RIP password is now included into the source file. The RIP data will continue to be validated against this password. - the password option can be omitted, but is still there for compatibility reasons and if it would be necessary to change the password at a later time - password discovery via debug mode still works - a man page for ampr-ripd was added (Tnx. Ana) You can get the updated ampr-ripd from: Internet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.14.tgz 44Net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.14.tgz or from GitHub: git clone https://github.com/yo2loj/ampr-ripd.git Have fun, Marius, YO2LOJ

8 years, 7 months

5
5
0 0

Re: [44net] RIPv4 security

by Brian Kantor

Gentlemen, if we cannot discuss a matter calmly and rationally, we should not discuss it at all. What we are after here is light, not heat. Incendiary comments are not welcome on this mailing list. Control yourselves. - Brian

8 years, 7 months

4
3
0 0

Portal (was: RIPv4 security)

by Rob Janssen

It would still be an option to merge the portal and hamnetdb... Hamnetdb is much more capable when managing subnets, and it is open. There is an issue with scalability (it always shows you all the data it has when first opening a page, before you have applied a search filter, which really loads older computers), so there may be surprises when all of the world's data is loaded into it. The "gateways" functionality is not yet there, so it would have to be implemented. But issues like the one that started this discussion are easier to resolve in hamnetdb because every object has a list of maintainers, which the owner or a sufficiently privileged person can modify. So you can easily hand over control over your subnet (e.g. to include it in a gateway) to someone else without sysop involvement. Rob

8 years, 7 months

2
1
0 0

RIPv4 security

by Rob Janssen

> That's fine for YOUR users because you keep a separate database of what > is allocated and what is not in your country's subnet, but I and many of > the other coordinators use the subnet allocations in the portal as the > authority for what is allocated and what is available. It is essential > that all subnets be registered in the portal in order for me to do my job. For me, the portal is not usable as the only registry of information, because it does not do DNS and DNS is essential for the functioning of the network. (not only because you want to name your system, but also because being in DNS is used as a filter to allow traffic through the gateway) So I need to keep two different registries anyway, and it does not matter how much of the information is in the portal and how much is in my own database. Furthermore, for allocating subnets and addresses I need an easily browsable view on the existing allocations including comments like regional names, to be able to decide where to put the new entry. To me, a simple "hosts" file edited in vi gives more overview than most point and click interfaces, including even that of the hamnetdb (which is way better than the portal in this regard). This solution also reduces the effort when making bulk changes like moving an entire subnet, doing cleanups like I did some time ago, or even transfer of the existing allocations into the portal. Sure they would be possible with a tool like this but it would either need a lot more features (and thus coding) or it would have to offer direct access to the database for queries. Rob

8 years, 7 months

2
1
0 0

Re: [44net] RIPv4 security

by Bryan Fields

On 9/23/16 2:59 AM, G1FEF wrote: > I get very fed up with folk like yourself making assumptions. There is a simple way to shut me up. > The reasons > why the code is not yet open has nothing to do with me or my ego, there are > other factors which you are not aware of that keep it like it is for now at > least. State them. > I am an advocate of open source, I have, and do, contribute to open > source. So please stop being so rude and obnoxious to me when a) you don’t > know me and b) you do not know the full circumstance. I see the evidence as presented. What is presented is you have some "mystical" reason you refuse to be open with your code. This is unacceptable. Can you logically argue it is not? > Just take the time to > look at life from someone else’s perspective for a change, how would you > feel if people like yourselves were being so rude to you for trying to help > out without being paid? Having 44net over a barrel with code which we cannot audit or extend is not helping; It's holding us back. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net

8 years, 7 months

1
0
0 0

Re: [44net] RIPv4 security

by Rob Janssen

>>/Furthermore, portal.ampr.org allows anybody with valid email address to />>/route any 44/8 subnet through any IP address, not only subnets assigned to />>/account in use. There're no restrictions to do so and it will stay there />>/and get broadcasted until somebody notice. />This is not true. By registering a gateway, you can use your assigned >subnet through your registered gateway. But if that subnet is already >assigned to a gateway, you can not assign it to your own gateway without >deassigning it from the old gateway first.So this is a non-issue unless >there are unassigned subnets floating around in the portal for people to >grab. But these are mostly the result of misconfiguration and lack of >knowledge, not the work of an attacker. And it will disrupt only that >specific subnet. Well, this issue is really there! Recently I found that two users from the Netherlands had setup completely bogus gateway entries, both stealing subnets belonging to others and routing them to the 44.137.x.x address I have them as "the gateway external address". Those were probably not malicious, they just did not understand the portal and fiddled around a bit, and left it as it is once they did not understand anymore what is happening. I think the portal should not allow to route other people's subnets through your own gateway without some consent from the subnet's owner, I think for some time it was impossible to setup such entries, and people complained that they needed this to route for others, and the check was removed again. >So here we may need some improvement tot to allow e.g. assignements of >national or regional subnets assigned to administrators to regular >users, which are the most likely to float since they are not bound to >any gateway. Administering national and regional subnets is a real pain, as it is impossible to manipulate the subnet structure without deleting it first, and ownership of an entry cannot be transferred. We all know how hard it is to get anything improved in the portal. For now, I advise users to not register their subnets unless they want to do IPIP tunneling. W.r.t. the processing of RIP and IPIP traffic, you can do a lot with a properly designed firewall. On my systems I accept only IPIP traffic from gateways that I received before via RIP, and I accept RIP only from 44.0.0.1 on the IPIP interface. Maybe it would be possible to also check if the traffic came from UCSD, I'll have to see how to check that in iptables. (probably can be done with marking packets when they come in from UCSD, then check the mark when they arrive on tunl0) Rob

8 years, 7 months

5
5
0 0

RIPv4 security

by Jakub Kramarz

I hope that I'm not breaking thread continuity, but I've subscribed requesting daily batches and don't know how to change it. > > As it is UDP based and relies on source of UDP packets, which is easy to > > spoof, current routing infrastructure is vulnerable to unrestricted > > injecting of 44/8 routes to it's gateways - anybody can send forged RIP > > updates to them. > Here I don't think the situation is that critical. The RIP updates are > sent via tunnel, and should be accepted only from the ampr-gw tunnel > interface. The attacker needs actually to block out original IPIP > traffic and spoof the IPIP tunnel to get fake RIP data into the network. > This is a little harder than just sending a bunch of UDP packets to a host. It's just as hard as decapsulating these packages in ampr-ripd. There's no need to disturb communication, as IPIP tunnel is not being established - it's just another IP header one can easily spoof, there's no authenticity control. This kind of DoS attack on AMPRnet won't be very interesting, but may be quite annoying to gateway operators. On the other side, it may result in sending unsolicited IPIP traffic to random hosts. Firewalling (by restricting pool of destination hosts for protocol 4) would do the job of limiting such activity, but on the other hand would be one step back, as list of gateways would need maintenance by hand. > I really don't see the point of doing that. Crackers want benefits from > their work: e-mail collecting, snmp access, spamming, not the glory of > sending data to a compromised system to which they are the only ones > having access. And creating a DOS attack like this on an APMPR host is > nothing interesting. So I do. Can't find any other use than a bit creepy SMURF-like DDoS. > So this is a non-issue unless > there are unassigned subnets floating around in the portal for people to > grab. There's a lot of such subnets. I just got banned for routing one of them through 192.168.0.1.

8 years, 7 months

1
0
0 0

RIPv4 security

by Jakub Kramarz

Password authentication mechanism in RIPv2 is meant to protect against accidental misconfigurations and is the only way of configuring ampr-ripd routing. As it is UDP based and relies on source of UDP packets, which is easy to spoof, current routing infrastructure is vulnerable to unrestricted injecting of 44/8 routes to it's gateways - anybody can send forged RIP updates to them. Furthermore, portal.ampr.org allows anybody with valid email address to route any 44/8 subnet through any IP address, not only subnets assigned to account in use. There're no restrictions to do so and it will stay there and get broadcasted until somebody notice. So, there're at last two ways of disrupting whole AMPRnet network topology and both will make nodes send traffic to any hosts. Is it really the way it should be? If changing RIP to some more secure protocol is not an option, maybe at last implementing RFC4822 would do the job?

8 years, 7 months

2
1
0 0

Re: [44net] ampr-ripd update 1.14

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

8 years, 7 months

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

8 years, 7 months

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

8 years, 7 months

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

8 years, 7 months

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

8 years, 7 months

1
0
0 0

rip down ?

by Maiko Langelaar

Did we loose the rip broadcast ? Maiko

8 years, 7 months

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

8 years, 7 months

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

8 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net