- 44net - mailman.ardc.net

by lleachii＠aol.com

All, I noticed that all of my DNS A records recently dissappeared. Has this occured to anyone else? At this time, my AMPR services are only rechable by IP address. The CNAME records in the DNS still exist; but most point to the missing ampr.org. A records: kb3vwg-001.ampr.org (44.60.44.1) kb3vwg-002.ampr.org (.2) kb3vwg-003.ampr.org (.3) kb3vwg-006.ampr.org (.6) kb3vwg-007.ampr.org (.7) kb3vwg-010.ampr.org (.10) kb3vwg-011.ampr.org (.11) kb3vwg-012.ampr.org (.12) -Lynwood KB3VWG

11 years, 6 months

2
2
0 0

Re: [44net] Raspberry Pi

by kb9mwr＠gmail.com

It's funny how you though going away from a moving disk hard-drive would be a good thing. Anyway here are my experiences. I have several Pi's in use. I have had a lot of head aches with PNY SD Cards. They go bad in rather short order. I have had a few Sandisk cards that have been in use just over a year. I have yet to have a problem with Sandisk.

11 years, 6 months

1
0
0 0

Portal

by Brian Rogers

Can anyone else get to the portal? It isn't coming up for me. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

11 years, 6 months

12
19
0 0

net-44 source address spoofing?

by Rob Janssen

Recently I have been tracing the tunnel traffic a bit to investigate a strange situation. Sometimes I got unsolicited ping replies on the NET screen. It appears that sometimes a ping reply is received without any ping having been sent. Users of Windows or Linux ping will never notice this, because there is a special application that sends a ping with unique ID and then listens for replies with the same ID and prints them. However, NET (written in the days when the network still was a friendly place) just uses a timestamp as the ID, sends the ping, and forgets about it. It continously listens for incoming ping replies and when one arrives, it prints it to the console with a roundtriptime calculated from the current timestamp and whatever happens to be in the ID field of the reply. Thus nonsense ping replies are printed. This happened here one to several times a day. So I put a statefull firewall (Linux iptables) in front of NET, and studied the logs a bit. The firewall is (partly) like this: iptables -A netwall -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A netwall -p icmp --icmp-type 8 -j ACCEPT iptables -A netwall -p icmp -j LOGDROP So it accepts all icmp related to ongoing traffic, it accepts incoming ping requests and logs and drops everything else (LOGDROP is a target that does a LOG and a DROP) Now it becomes apparent that the bogus ping replies are not the only thing that is going on. There is a regular flow if incoming "destination unreachable" ICMP replies that refer to connections that I never made. I also enabled some logging for unsolicited TCP replies and there are SYN ACK and RST replies as well. Apparently my 44-addresses are used as spoofed source addresses by other people. Do other users notice this? I presume it is done by a DDOS tool or similar, but the rate at which I receive this traffic (maybe 10 packets an hour) does not make it likely that they use only my address. However, I have not seen this effect on my public addresses, so probably they don't use random addresses. Maybe they use the entire net-44 space? In that case there should be an awful amount of ICMP type 3 and TCP RST traffice coming in at amprgw... (my space is only one millionth of the total) Another unrelated question: a lot of you likely have an amsat.org address. Do you also see the endless stream of Korean spam? From the headers it looks like it is sent to many different amsat.org users. It has been ongoing here for many years, some 20 messages a day. These guys are very persistent. (of course it is easily filtered) Rob

11 years, 6 months

3
2
0 0

Re: [44net] net-44 source address spoofing?

by Bryan Fields

On 10/13/13 5:10 PM, Brian Kantor wrote: > The background noise is one of the reasons why amprgw only lets traffic through > for hosts registered in the AMPR.ORG DNS. People with directly-connected > subnets will have to deal with it on their own; background noise is one of > the facts of Internet life. > - Brian Really everyone should run a firewall or at least some ACL's regardless. Leaving yourself open to 44/8 is not a good idea. However if your OS is well written and secure there is not any risk to the background noise hurting it. If it's a win2k box that's not been patched, god help you :) -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

11 years, 6 months

1
0
0 0

Re: [44net] net-44 source address spoofing?

by Rob Janssen

> Subject: > Re: [44net] net-44 source address spoofing? > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 10/13/2013 08:20 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Rob, > > I also get a some strange unrelated traffic: ping replies, SYN-ACK on > various ports, pings and SYN targeted to random IPs on my subnets. > So nothing new here. > I studied the source addresses for some time: china, russia, and alot of > "this IP range is really wold wide" according to RIPE. > Since they achieve nothing, I choose to ignore them, along with some tight > stateful firewall rules. > > Marius, YO2LOJ > Yes, it is required to have a firewall in front of everything these days... Of course I always firewalled malicious attempts to make incoming connects to my systems, this unrelated traffic usually does no real harm. It was only the ping replies that triggered me to look what was really happening. It is unfortunate that the amprgw has to carry all that unnecessary traffic... (and the amsat.org mailserver as well. the vast majority of what I receive is discarded immediately as spam, mostly Korean. And I cannot even read Korean) Rob

11 years, 6 months

2
1
0 0

Re: [44net] net-44 source address spoofing?

by lleachii＠aol.com

I've also noticed the strange traffic and am working on discovering its origins. This is common and should be expected on any public IP address. It's mostly pings and attempts to seek vunerable machines accessable by Remote Desktop Protocol. 73, -Lynwood KB3VWG

11 years, 6 months

1
0
0 0

Fwd: [nos-bbs] encap.txt

by Don Moore

---------- Forwarded message ---------- From: Don Moore <ve3zda(a)gmail.com> Date: Sat, Oct 12, 2013 at 4:20 PM Subject: Fwd: [nos-bbs] encap.txt To: gw <gateways(a)ampr-gateways.org>, gateways(a)ampr.org ---------- Forwarded message ---------- From: Don Moore <ve3zda(a)gmail.com> Date: Sat, Oct 12, 2013 at 4:14 PM Subject: Re: [nos-bbs] encap.txt To: TAPR xNOS Mailing List <nos-bbs(a)tapr.org> Hi Dave, let me know what the address is and I can input it into jnos for now.. 73, Don On Sat, Oct 12, 2013 at 2:41 PM, Michael E. Fox - N6MEF <n6mef(a)mefox.org>wrote: > I certainly hope so. There are a bunch of us that use encap.txt instead > of the RIP process.**** > > ** ** > > M**** > > ** ** > > *From:* nos-bbs-bounces(a)tapr.org [mailto:nos-bbs-bounces@tapr.org] *On > Behalf Of *Wars > *Sent:* Saturday, October 12, 2013 11:14 AM > > *To:* TAPR xNOS Mailing List > *Subject:* Re: [nos-bbs] encap.txt**** > > ** ** > > Hi Don,**** > > I do not know if anyone is going to fix the encap.txt file. **** > > My IP address changed and without a new encap.txt file I can only use the > RF with my JNOS. **** > > ** ** > > 73 Dave wa8rsa**** > > ** ** > > ** ** > > > > **** > > ** ** > > Dave**** > > Cell : 616-836-1214**** > > Sent from my iPhone**** > > > On Oct 12, 2013, at 2:01 PM, Don Moore <ve3zda(a)gmail.com> wrote:**** > > thanks for the info, do you know if it's being fixed?**** > > ** ** > > On Sat, Oct 12, 2013 at 11:54 AM, wa8rsa <wa8rsa(a)charter.net> wrote:**** > > Don,**** > > **** > > You are correct. The encap.txt file is out of date.**** > > **** > > 73 Dave wa8rsa**** > > **** > ------------------------------ > > *From:* nos-bbs-bounces(a)tapr.org [mailto:nos-bbs-bounces@tapr.org] *On > Behalf Of *Don Moore > *Sent:* Saturday, October 12, 2013 7:03 AM > *To:* TAPR xNOS Mailing List > *Subject:* [nos-bbs] encap.txt**** > > **** > > Have those of us not using the RIP process noticed that the encap.txt file > is not updating or is it my problem?**** > > I went so far as to check the gateway file and it too appears to be out of > date...**** > > 73, Don - ve3zda**** > > > > > > > ======= > Email scanned by PC Tools - No viruses or spyware found. > (Email Guard: 9.1.0.2900, Virus/Spyware Database: 6.21600) > http://www.pctools.com<http://www.pctools.com/?cclick=EmailFooterClean_51> > ======= **** > > > > > > > ======= > Email scanned by PC Tools - No viruses or spyware found. > (Email Guard: 9.1.0.2900, Virus/Spyware Database: 6.21600) > http://www.pctools.com<http://www.pctools.com/?cclick=EmailFooterClean_51> > ======= **** > > > _______________________________________________ > nos-bbs mailing list > nos-bbs(a)tapr.org > http://www.tapr.org/mailman/listinfo/nos-bbs**** > > ** ** > > _______________________________________________ > nos-bbs mailing list > nos-bbs(a)tapr.org > http://www.tapr.org/mailman/listinfo/nos-bbs**** > > > _______________________________________________ > nos-bbs mailing list > nos-bbs(a)tapr.org > http://www.tapr.org/mailman/listinfo/nos-bbs > >

11 years, 6 months

2
1
0 0

Re: [44net] Announcement: ampr-ripd new version 1.6

by Rob Janssen

> Subject: > [44net] Announcement: ampr-ripd new version 1.6 > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 10/10/2013 09:22 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello XYLs and OMs, > > The modified version of ampr-ripd according to Rob's sugestion to use > MCAST_JOIN_GROUP and be interface specific is available for download at > atwww.yo2loj.ro under hamprojects. > > Direct links: > http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.6.tgz > http://www.yo2loj.ro/hamprojects/ampr-ripd-1.6.tgz > > Download, compile and have fun. > > Marius, YO2LOJ Thank you Marius! I compiled and installed it, and it works OK in my environment even when I have two interfaces with the same address. It assigned the multicast group to the correct interface and it receives the multicast OK. Finally this hair-pulling about "why doesn't this work???" is finished! Rob

11 years, 6 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 162

by Rob Janssen

> Subject: > Re: [44net] 44Net Digest, Vol 2, Issue 159 > From: > sp2lob <sp2lob(a)tlen.pl> > Date: > 10/07/2013 09:49 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hello Rob et al, > > Quote: > "...by default mcast routes will be associated with an interface > the kernel picks (usually the first to come up)." > > There is something what you're looking for, I believe. > Small, nifty & powerfull program to install: *smcroute* > > The *smcroute* <http://www.cschill.de/smcroute/> utility provides a command line interface to manipulate > the multicast routing tables via a method other than *mrouted*. Tom, I looked in the source and this tool is not going to fix it. It uses exactly the same setsockopt call that ampr-ripd is already using to join the multicast group. The problem is that this setsockopt has 2 IP address parameters, one is the address of the local interface and the other is the multicast group to join. This is of course wrong. The first should not be an IP address but an interface name. But this kernel interface appears to be very old, dating back from BSD Unix. Given is situation, there is no way to uniquely identify the interface where the multicast group has to be joined, and the problem cannot be solved. Either all interfaces have to use a different address, or the multicast group must be joined before a duplicate address is created (I do that now). Or, when you don't mind using undefined implementation details, it will probably also work when tunl0 is created as the last interface. (because it appears the kernel has preference for the last interface in the list when a duplicate is found) W.r.t. multicast routing not being enabled: that does not appear to matter. Probably this is only required when you want the Pi to do actual forwarding of multicast traffic, not for just receiving it. Rob

11 years, 6 months

3
4
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 159

by Rob Janssen

> Subject: > Re: [44net] 44Net Digest, Vol 2, Issue 159 > From: > sp2lob <sp2lob(a)tlen.pl> > Date: > 10/06/2013 12:43 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hello Rob et al, > > In my system I've similar setup. > > 1. tun0 - tunnel to my JNOS > 2. tunl0 - tunnel to AMPRNet > > Both have assigned same IP - 44.165.2.2 > I do not observe anything suspicious. > > What kind of issue do you encounter, please? > > Best regards. > Tom - sp2lob Tom, Check this: cat /proc/net/igmp Idx Device : Count Querier Group Users Timer Reporter 1 lo : 1 V3 010000E0 1 0:00000000 0 2 eth0 : 1 V3 010000E0 1 0:00000000 0 3 tunl0 : 2 V3 090000E0 1 0:00000000 0 010000E0 1 0:00000000 0 4 net0 : 1 V3 010000E0 1 0:00000000 0 As you can see, the 224.0.0.9 address is at the tunl0 interface. When I start the daemon after the net0 interface is created (tun0 in your case) the address gets added to net0 only, and not to tunl0. Therefore the daemon does not receive the 224.0.0.9 multicasts (only 224.0.0.1 which everyone gets). I don't know what the algorithm is to select the interface when there are multiple interfaces with the same address. It looks like it picks the one with the highest index. The function to add a multicast address cannot specify the interface directly. Rob

11 years, 6 months

4
6
0 0

Re: [44net] no more 44-net routing through amprgw?

by Rob Janssen

> Subject: > Re: [44net] no more 44-net routing through amprgw? > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 10/06/2013 05:31 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Ron, > > Ampr-gw doesn't route anything to other ampr hosts. It allows only the > routing to internet hosts. > To reach ampr hosts you need to have a tunnel established with each host... > So the behavior is as expected. > > Marius, YO2LOJ Ok, I think in the past it worked when used as a default route. Maybe too many users made a lazy setup that routed everything through amprgw and did not setup the tunnel mesh, thus overloading amprgw. Anyway it is not a real problem as the multicasting is now working and the RIP daemon adds the routes. Rob

11 years, 7 months

1
0
0 0

no more 44-net routing through amprgw?

by Rob Janssen

During my tests yesterday (to get RIP working with a multicast socket) there was an extended period where there was only a default route in my table 44 which is used to send network-44 traffic. This default route sends the traffic to amprgw as tunneled traffic (ipip). This route is normally used only for traffic leaving net 44 to the internet, and more specific tunnels are used for all gateway stations. But this temporarily did not work while I was debugging and the RIP packets were not being processed. What I noticed was that I lost connectivity to the other network-44 stations during that interval. I would expect that amprgw would forward the traffic to the other stations. Of course this is not a desirable permanent situation, but I think it worked in the past. Has this forwarding been blocked in amprgw? Or is this something that must be caused by a local configurarion error here? (like a firewall issue) Rob

11 years, 7 months

3
2
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 159

by Rob Janssen

> Subject: > Re: [44net] 44Net Digest, Vol 2, Issue 158 > From: > <sp2lob(a)tlen.pl> > Date: > 10/04/2013 10:32 PM > > To: > "AMPRNet working group" <44net(a)hamradio.ucsd.edu> > > > Hello Rob et al, > > What Brian just suggested is EXACTLY what I've in my startup scripts, Hi! > > # > modprobe ipip > ifconfig tunl0 44.165.2.2 netmask 255.255.255.248 multicast up > # > > Best regards. > Tom - sp2lob Well, after a long debugging session I finally found what is going wrong! It is not this multicast bit. In fact, ampr-ripd sets it while initializing in multicast mode. The cause of my problems was that the same IP address is used on different interfaces. I have my address 44.137.40.2 on tunl0 but also on a tun interface that provides a tunnel to locally running KA9Q software, which uses address 44.137.40.1 When initializing, ampr-ripd joins multicast group 224.0.0.9 with address 44.137.40.2, but I finally found that this is happening on the tun interface and not on the ipip tunl0. This can be seen using "cat /proc/net/igmp". When I start ampr-ripd after creating tunl0 and before the tun is brought up, it works OK. The 44.137.40.2 address still is unique at that point, and the group is joined on the correct interface. I still have to decide what permanent strategy to use. Maybe I need to allocate another address... Rob

11 years, 7 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 156

by Rob Janssen

> > From: > Heikki Hannikainen <hessu(a)hes.iki.fi> > Date: > 10/01/2013 10:01 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > I think I have found and fixed a problem which caused rip44d multicast > reception to mysteriously fail on some systems. Interesting story. I thought it might be the reason for my battle with the multicast socket on the Raspberry Pi, and I have checked the setting of rp_filter on it, but when I do: cat /proc/sys/net/ipv4/conf/*/rp_filter I get: 0 0 0 0 0 0 So it looks like the rp_filter is off for all interfaces on this system. It could be a good idea indeed to turn it on, although I have some DROP rules for obviously spoofed traffic in my firewall, but that is not going to help solving the multicast problem. Apparently there is more than one reason why it could fail... still have not found what is going wrong here. Rob

11 years, 7 months

3
3
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 158

by Rob Janssen

> Subject: > Re: [44net] 44Net Digest, Vol 2, Issue 157 > From: > sp2lob <sp2lob(a)tlen.pl> > Date: > 10/03/2013 11:03 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Rob, > > I have already answer for you. > > Yes, my Pi is running Raspbian 3.6.11+ #538 > PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l > updated&upgraded as often as possible. > > Line from config.gz file you're asking about is as follow: > #CONFIG_IP_MROUTE is not set > > But here is my AMPRNet tunnel interface: > > tunl0 Link encap:UNSPEC > inet addr: 44.165.2.2 Mask: 255.255.255.248 > UP RUNNING NOARP MULTICAST MTU:1480 Metric:1 > > I've also 3 ax ifces, 3 nr ifces, 1 rose ifce and tun0 ifce from linux to my JNOS. > > Traffic flows in both directions IN&OUT just fine. > > Best regards. > Tom - sp2lob Hi Tom, Well, that is the same as what I have here except there is no MULTICAST on my tunl0 interface. The flag is only there on my eth0 interface. The kernel is the same version, config of that MROUTE option is also the same. Did you issue a command to get that MULTICAST on tunl0 switched on? Or is that supposed to be enabled by the application, rip44d in this case? I use this: ip addr add 44.137.40.2/32 dev tunl0 ip link set dev tunl0 up maybe I need "ip link set dev tunl0 multicast on"? That could be something to try... tomorrow I will add that command and change the ampr-ripd to use multicast socket instead of raw, and reboot to see what happens. Rob

11 years, 7 months

3
2
0 0

Re: [44net] DMZ

by lleachii＠aol.com

All, Many stations are suggesting that those with devices behind firewalls simply add the device to the DMZ. This is an unsafe suggestion. I worked on this issue for many months and discovered how to route traffic through Linux Kernel, DD-WRT, OpenWRT and most D-Link based routers. IP Protocol Number Four (4 - IPENCAP) must be allowed. **In DD-WRT 1.) Browse to Administration > Commands 2.) Enter the commands either for either static or dynamic IP configuration 3.) Click "Save Firewall" **OpenWRT CLI 1.) Edit firewall "vi /etc/firewall.user" 2.) Enter the commands either for either static or dynamic IP configuration 3.) Save file and quit vi editor 4.) Reboot Device **OpenWRT LuCI GUI Option #1 (Recmmonded) 1.) Browse to: Network > Firewall > Port Forwards > New Port forward 2.) Enter the following information: - Name:<enter name> - Protocol:<select "other"> - External Port <leave blank, IPENCAP protocol does not use port numbers> - Internal Zone <lan> - Internal IP address <IP of you 44GW Device> - Internal Port <leave blank, IPENCAP protocol does not use port numbers> 3.) Click "Add" 4.) Browse to: Network > Firewall > Port Forwards 5.) Click "edit" on the new entry 6.) Change "protocol" to --custom-- 7.) The protocol dropdown will change to a textbox, enter "4" in the box 8.) Click "Save & Apply" **OpenWRT LuCI GUI Option #2 1.) Browse to: Network > Firewall > Custom Rules 2.) Enter the commands either for either static or dynamic IP configuration 3.) Click "Save & Apply" **On D-Link 1.) Browse to Network Settings > Advanced > Virtual Server 2.) Add name and IP address of 44GW, or select IP from the list and click the "<<" button 3.) Change Protocol to "Other" and enter "4" in the box under Protocol 4.) Click "Save Settings" **Command for Static IP (tested on DD-WRT and OpenWRT): iptables -t nat -I PREROUTING -p ipencap -d <GW Public IP> -j DNAT --to-destination <GW LAN IP> iptables -t filter -I FORWARD -p ipencap -d <GW LAN IP> -j ACCEPT **Command for Dynamic IP - (WAN is vlan1 in DD-WRT in OpenWRT it is usually eth0.1): iptables -t nat -I PREROUTING -p ipencap -i vlan1 -j DNAT --to-destination <GW LAN IP> iptables -t filter -I FORWARD -p ipencap -d <GW LAN IP> -j ACCEPT 73, Lynwood KB3VWG

11 years, 7 months

3
2
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 157

by sp2lob

Rob, I have already answer for you. Yes, my Pi is running Raspbian 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l updated&upgraded as often as possible. Line from config.gz file you're asking about is as follow: #CONFIG_IP_MROUTE is not set But here is my AMPRNet tunnel interface: tunl0 Link encap:UNSPEC inet addr: 44.165.2.2 Mask: 255.255.255.248 UP RUNNING NOARP MULTICAST MTU:1480 Metric:1 I've also 3 ax ifces, 3 nr ifces, 1 rose ifce and tun0 ifce from linux to my JNOS. Traffic flows in both directions IN&OUT just fine. Best regards. Tom - sp2lob

11 years, 7 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 157

by Rob Janssen

> Subject: > Re: [44net] 44Net Digest, Vol 2, Issue 156 > From: > <sp2lob(a)tlen.pl> > Date: > 10/03/2013 07:53 AM > > To: > "AMPRNet working group" <44net(a)hamradio.ucsd.edu> > > > Hello Rob et al, > > My Raspberry Pi is behing own TL-MR3420 router. > When I ran ripd44 for the very first time it didn't worked. > Following suggestion by one of U.S. hams, > I put Pi into DMZ zone - ripd44d automagically revived! Ok, but as I explained before, my Raspberry Pi is directly on the internet. I don't have problems with routers, NAT, DMZ zones or whatever. I have the issue that Hessu explains (Multicast socket not working; raw socket OK) but in my case it must be caused by something different than rp_filter. Is your Pi running Raspbian? What does it say when you enter: zgrep CONFIG_IP_MROUTE /proc/config.gz Rob

11 years, 7 months

2
1
0 0

RIP question

by Lakenet

I run JNOS 2.0i with Ubuntu Linux 12.04. I am set up to receive RIP broadcasts and they are working fine. Along with the encapsulated RIP broadcast is coming non encapsulated data and JNOS is responding Unreachable Port Returned. Is this non encapsulated data something that I asked for in AmperNet registration or does it just come along or have to come along with the encap data? Jerry, N0MR

11 years, 7 months

2
1
0 0

Attempting to contact 4Z4ZQ

by Assi Friedman

Folks: Apologies for the note, but I am trying to get in touch directly with Ronen Pinchook 4Z4ZQ, who is a member here. Ronen: do you mind contact me directly at assi(a)kiloxray.com regarding amprnet business. Thank folks, over and out. Assi KK7KX/4X1KX P.S: Brian, if you want to beat me over the head for this, you know where to find me :)

11 years, 7 months

1
0
0 0

rip44d rp_filter problem fixed

by Heikki Hannikainen

I think I have found and fixed a problem which caused rip44d multicast reception to mysteriously fail on some systems. The workaround is present in rip44d version 1.4, which is available at: https://raw.github.com/hessu/rip44d/master/rip44d I just upgraded the Linux distribution on my gateway, and rip44d stopped working. After some slight hair-pulling I figured it out. The same thing will affect the C implementation, and doing the same workaround will remove the need to use a raw socket instead of the more optimal multicast socket. Some distributions/kernels (some of the new ones, and maybe some old ones too?) enable strict reverse path verification (rp_filter) by default. Reverse Path filtering looks at the source IP address of packets coming in on an interface, and checks that an outgoing packet destined to that same address would be routed out on that same interface according to your routing table. That's a nice feature as such - it drops spoofed packets, which is good for security. If someone on the Internet sends packets to you, and fakes the source address to be one of your internal addresses, it could save your day. Or, if a client/user on your network tries to send packets to the Internet with a fake source address (typically his computer is infected with a bot, and the bot is taking part in a DDOS attack), rp_filter will drop those packets with invalid source addresses. However, it affects multicast packets too. Our RIP packets come in on tunl0, with a source address of 44.0.0.1. Before your tunnel routing table is populated with RIP, there is no route to 44.0.0.1 pointing to tunl0. The RIP announcements do contain a route for 44.0.0.1, but we need to have it there to be able to receive any RIP packets. There are a couple of alternative workarounds to this: 1) Disable rp_filter on the tunl0 interface. sudo sysctl net.ipv4.conf.tunl0.rp_filter=0 (and put net.ipv4.conf.tunl0.rp_filter=0 in /etc/sysctl.conf) *or* 2) Set up a dummy route for 44.0.0.1/32 pointing to the tunl0 interface. It'll be replaced by the real one once the first RIP packets come in. I opted for option 2, rip44d 1.4 does that when starting up. If you have an asymmetric routing setup, rp_filter might cause some other surprises too. Good to keep it in mind. - Hessu, OH7LZB

11 years, 7 months

1
0
0 0

Re: [44net] How to use my IP 44.xx.xx.xx

by Robbie De Lise

Andre, Please register a new subnet or ip at the portal first. If you like you can connect your new subnet/ip to the internet through hamnetbe vpn or 5ghz wifi link if a node is available in your area. We are currently not yet linked to the rest of ampr but are looking into it. https://portal.ampr.org/networks.php?a=region&id=304 Thank you Robbie ON4SAX 44.144 Coordinator Op 15 sep. 2013 12:58 schreef "on4hu" <on4hu.0(a)gmail.com> het volgende:

11 years, 7 months

4
13
0 0

community-wide networking discussion group

by Brian Kantor

Projects such as HAMWan are community-wide networking. Are there any mailing lists where people who are actively working on or planning to construct such networks, or should I start one such? - Brian

11 years, 7 months

3
2
0 0

Portal

by Brian Rogers

Is the portal offline? I don't appear to get a connect to it. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

11 years, 7 months

2
2
0 0

DNS

by ian

Hello, I am new to this and would like to ask the following question : - What is considered a reasonable time for a response to change/add a DNS ?? Ian..

11 years, 7 months

1
0
0 0

(no subject)

by Robbie De Lise

44.144.123.7 add a ups.on3dga 44.144.123.11 add a bi.on3dga 44.144.123.12 add a voipserver.on3dga 44.144.123.2 add a coreswitch.on3dga

11 years, 7 months

1
1
0 0

TAPR/ARRL DCC 2013

by Brian Kantor

I'll be at the TAPR/ARRL DCC 2013 is this Friday-Sunday in Seattle. I'd be happy to get together with any of the AMPRNet folks; I'll be at both of the lunches, the Friday night social event, and the banquet. Perhaps we can find some place to gather and chat about what's going on and what's in the future for network 44. At this point there is only a preliminary schedule posted on the TAPR web site so I don't know exactly when and where we will meet, but feel free to stop me and chat. - Brian

11 years, 7 months

3
2
0 0

Att: Chris G1FEF

by Brian Rogers

Chris; I sent you an email as per your request, but no reply. Just want to insure you received this one ok. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

11 years, 7 months

3
3
0 0

(no subject)

by Robbie De Lise

on0ck del

11 years, 7 months

2
1
0 0

Re: [44net] 44Net Reboot (DNS)

by Rob Janssen

> Subject: > Re: [44net] Reboot (DNS) > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 09/13/2013 01:59 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > The goal is to have every DNS entry belong to someone who is registered > with the portal, so that when that person becomes inactive (defined > as no longer keeping their portal registration current despite annual > reminders), the DNS entry will also become inactive, and after a year > or so, be expunged. That way we can reclaim addresses and also prevent > the DNS from being full of obsolete data. > > What we have to work with is a database that has only the DNS information > for the vast majority of its entries. For the past few years, it has > also been recording the timestamp and author of the entry. So the plan > in general (details are still to be worked out) is to convert entries > which match registered portal users either in the hostname or in the > author field. That will have the effect of leaving out most of the > obsolete entries but should retain most relevant (active) ones. What we have (again) learned from the first step, the migration of the gateway entries, is that the method of matching and validating the existing entries with the new portal users cannot be "send an e-mail to a single person who will handle it". I tried to convince a couple of operators to refresh their info in the portal but when they can only create a new entry and cannot move their existing info into it, and have no reply to their mail after a month, they lose interest and won't be pursuing this anymore. And I am not going to ask them over and over again. When the same has to be done for all the end-user registrations, it will be a nightmare to get it completed. But of course *some* validation has to be done. Rob

11 years, 7 months

9
9
0 0

Re: [44net] 44Net Reboot (DNS)

by Rob Janssen

> Subject: > Re: [44net] 44Net Reboot (DNS) > From: > Neil Johnson <neil.johnson(a)erudicon.com> > Date: > 09/15/2013 12:51 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > So what do you propose ? > > -Neil We need to have a system where multiple persons can handle the task in case the one originally assigned to it gets overloaded or otherwise not available. Or maybe we could use the login credentials of another system within the amateur radio world (qrz.com? eqsl?) and trust a user immediately. (so they can reconfirm their IP addresses without manual confirmation by the coordinator) Rob

11 years, 7 months

2
1
0 0

Re: [44net] 44Net Reboot (DNS)

by Rob Janssen

> Subject: > Re: [44net] 44Net Reboot (DNS) > From: > Chris <chris(a)g1fef.co.uk> > Date: > 09/15/2013 09:56 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > The migration of the gateway entries has gone quite well, we matched up a good proportion of the old entries. If anyone still has a gateway entry they need to claim, they only have to ask - as far as I am aware all such requests have been processed. If anyone is aware of any "gateway claim" emails that have gone unanswered please let me know. > > Thanks, > Chris When I login to the portal and get a list of registered gateways, I see several IP addresses for which there are two entries, usually one of them with only a description and no subnets. I presume that those are the ones that correspond to currently open claims for the gateway entry. (for a new portal user it is possible to setup a new gateway entry, including external IP address and description, but once they try to enter their subnets they get stuck because the subnets are already in use on their old entry) A friend tried to e-mail you several times, but did not get a reply. Then he tried to guess his old password for the mail robot and after several tries he got a mail from Maiko who then fixed the situation. Probably not everyone got that far. Rob

11 years, 7 months

1
0
0 0

Re: [44net] Reboot (DNS)

by kb9mwr＠gmail.com

Thomas, In lue of an email robot, what if you could submit data using curl? I understand the you need, but I also understand how complex it could be two run to update mechanisms On Fri, Sep 13, 2013 at 02:28:08PM +0200, Thomas Osterried wrote: > We need the bot. We can't live with a web frontend.

11 years, 7 months

7
8
0 0

More fun with DNS

by Blaine Forbort

Just curious, has anyone played with the more oddball things that can be done using DNS servers? I'm aware that DNS requests can be used to tunnel traffic (often used to get around governmental censorship in some countries), and that E.164 can be used to route VoIP calls, but how about some REAL fringe stuff? I was just thinking that, we're ham radio guys, and we don't really have a standardized way to do something like call CQ and have keyboard-to-keyboard or voice chats! Maybe something can be done using DNS that hasn't really been done before. Anyone have ideas? Blaine, K1QV Sent from my iPhone

11 years, 7 months

1
0
0 0

How to use my IP 44.xx.xx.xx

by on4hu

I would use my IP 44.144.195.1 via Internet to my JNOS how to use this IP is there a gateway? a special procedure is it required? it's been decades that I find space this procedure? or find the information? Vy73s ON4HU -- http://on4hu.be/ ftp://ftp.on4hu.be http://on4hu.be:81 COMPUTER ARE LIKE AIR-CONDITIONNERS THE STOP WORKING AS SOON YOU OPEN WINDOWS

11 years, 7 months

1
0
0 0

Reboot

by Kutche, Jerry (Mitchell) USA

Hi guys.. IP Coordinator for Indiana... Most of the assignments in our 44.48.x.x range are nolonger in operation... I know we were planning something to address this... what was that plan? 73 jerry Jerry Kutche Electrical Supervisor Lehigh Cement Company LLC 180 N. Meridian Road Mitchell, IN 47446 Phone: (812) 849-2191 ext. 251 Fax: (812) 849-5007 Cell: (812) 583-0445 jkutche(a)lehighcement.com<mailto:jkutche@lehighcement.com> www.lehighcement.com<file:///C:\Documents%20and%20Settings\kmundy\Application%20Data\Microsoft\S…> This e-mail may contain confidential and/or legally privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

11 years, 7 months

5
5
0 0

Re: [44net] IP Gateway

by Jerry

Yes 44.48.0.46 encap 69.27.54.92 Have you seen the aprs group. AMPRNet working group (44net(a)hamradio.ucsd.edu) I can email Brian and see if you can get added to the group.. I need to also get you the link to the amprnet webportal... 73 -----Original Message----- From: John Wiseman [mailto:john.wiseman@cantab.net] Sent: Thursday, September 12, 2013 2:30 PM To: n9lya(a)blueriver.net Subject: IP Gateway Jerry, The IPGateway code in LinBPQ seems be to working ok. It switches packets between BPQ Ports. Config is simply IPGATEWAY IPPorts 2,4 # List of Ports to be used for IP **** https://dl.dropboxusercontent.com/u/31910649/linbpq Do you have an allocation in the 44 network? I'm thinking of trying to add the amprnet tunnelling code to LinBPQ. 73, John

11 years, 7 months

3
7
0 0

Radio-based networking

by Brian Kantor

I'm in the process of preparing a new document on the AMPRNet. I'd like to include a section on the radio-based portions of the network. Is anyone actually using the network over radio at this point? Could you supply some details? (All the discussions of the landline-based portions of the network are well and good but this network is supposed to be about radio-based networking and that seems to be falling by the wayside.) - Brian

11 years, 7 months

13
14
0 0

IPV6 Rumors

by Daniel Curry

I am starting to hear from folks in my area that we are starting to allocate IPV6 addresses? From what I have read on the reflector that is not true. There were some testing from limited folks, but that is all. As far as I can tell there is really no need to start issuing IPv6 addresses since we have not dish out all of the current available IPv4 addresses. K6DLC -- Daniel Curry IPV6 Sage Certified PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92 San Francisco/Silicon Valley AmprNet Co-coordinator [44.4.0.0/16]

11 years, 7 months

6
5
0 0

Off Topic.. NOSview

by Jerry

Anyone have a copy of NOSview I could get.. I have googled it and tried to extract all I get is !WELCOME.TXT no files.. Thanks 73 Jerry N9LYA 44.48.0.46 N9LYA/K9BBS <http://w9bbs.no-ip.org:8080/> http://w9bbs.no-ip.org:8080 Linbpq 6.0.3.20 Debian Linux 7.0.0 Dell_Server_2600_4GBRAM_73GBHD_Dual_Dual_Core_CPU_1.8Ghz W9HU <http://w9bbs.no-ip.org:8081/> http://w9bbs.no-ip.org:8081 PilinBPQ 6.0.3.14 Raspbian-wheezy-7_Rpi_B_700MHz_256MBram_128GB-SD-class10 N9LYA-5 JNOS 2.0j Debian Linux 6.0.6 HP 3.4Ghz 2GB Ram 2TB Hard drive W9OTR-8 XR32 201b Windows XP SP3 Dell Optiplex GX240 Pentium 4 1.70GHz 768MB Ram 40 GB Harddrive <http://www.mitchellwx.com/> http://www.mitchellwx.com <http://www.n9lya.com/> http://www.n9lya.com <http://www.kutche.net/> http://www.kutche.net <http://www.hfskipnet.net/> http://www.hfskipnet.net

11 years, 7 months

5
6
0 0

From Scratch

by Rosalio Salas

I need some help with where to download jnos from. Seems all the websites I find to download JNOS are offline. I have Debian loaded on computer and working, but JNOS software is eluding me. Thanks & 73s -- Leo Salas PO Box 6103 Paris, TX 75461-6103 972-510-5157 n5jep1(a)gmail.com

11 years, 7 months

4
9
0 0

NetScreen NS-25 IPSEC Devices

by William Bressette

Hey all I have to older but still working fine still. These devices have been upgraded to Advanced edition and will support 500 IPSEC tunnels each They do BGP, OSPF, RIP, GRE Tunnels etc. I was thinking with all of the VPN talk on here do we want to use these to setup either 2 highly available IPSEC termination point or 2 one in NA and 1 in Europe so that we have to concentration points. If anyone has a 1 or 2 U rack space in a data center which can host these devices please let me know and we can try and set something up. Note Devices cost 0$

11 years, 7 months

1
0
0 0

amprnet routing made simple

by Brian Rogers

http://n1uro.ampr.org/cgi-bin/safe-config.cgi will set up a *very* basic system for amprnet ipencap routing pending you have a tunnel interface already configured. Field 1: 169.228.66.251 <- ucsd Field 2: 44.0.0.1 <- ucsd Field 3: 44.x.x.x <- your amprnet gw IP Field 4: eth0/wlan0/wifi0/etc The rest gives you basic IPTable rules to allow IPEncap and ax25 frames through your firewall, route rules, and a basic route table. Load your favorite ripv2-daemon and configure it to populate "table 1" and you'll be off and running within the first rip broadcast (faster if you run the munge script - no need to wait for a broadcast). Mine looks exactly as the cgi prints: Add this to your rc.local, or whatever init script you wish to make: # allow IPEncapsulation and ax25 frames to gate through... iptables -I INPUT 1 -j ACCEPT --proto 4 iptables -I INPUT 1 -j ACCEPT --proto 93 iptables -I OUTPUT 1 -j ACCEPT --proto 4 iptables -I OUTPUT 1 -j ACCEPT --proto 93 iptables -I FORWARD 1 -j ACCEPT --proto 4 iptables -I FORWARD 1 -j ACCEPT --proto 93 # Create a policy to encap forward to your host... ip rule add from 44/8 pref 1 table 1 ip rule add to 44/8 pref 1 table 1 # Now let's set the routing accordingly... ip route add 44/8 via 169.228.66.251 dev tunl0 onlink src 44.88.0.9 table 1 ip route add default via 169.228.66.251 dev tunl0 onlink table 1 *Whether or not you're SAFed (source address filtered) this should work for you. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

11 years, 8 months

3
5
0 0

BGP on commercial ISP lines

by Assi Friedman

So how are people dealing with running BGP over home class internet service? With ISPs becoming more and more restrictive, I can't see any ISP in the US allowing this. While not 100% sure, I believe running BGP would be in violation of the garden variety usage agreement that is tailored towards "home use" and prohibits any service that falls into the business class traffic. Also, how does BGP interoperate with the current default route of non 44 op to mirrorshades? Did Brian remove any BGP advertised subdomain from the default route? Assi KK7KX/4X1KX (www.kiloxray.com) -----Original Message----- > > I don't agree with that. > People who want to experiment with BGP are free and welcome to do > that, but there is no and there should not be any "deprecating IPIP > tunnels".

11 years, 8 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 139

by Rob Janssen

> Subject: > Re: [44net] amprnet routing made simple > From: > K7VE - John <k7ve(a)k7ve.org> > Date: > 09/06/2013 06:58 PM > > To: > n1uro(a)n1uro.ampr.org, AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > This may be a stop gap for low traffic sites, but I think the goal is to > avoid sending everything through 44.0.0.1. This solution is not sending "everything through 44.0.0.1" Only traffic incoming from non-44 internet addresses to your net-44 station is replied via that path. All other traffic is going via direct tunnels. > We should be working toward deprecating hacked solutions, like the IPIP > tunnel set. I don't agree with that. People who want to experiment with BGP are free and welcome to do that, but there is no and there should not be any "deprecating IPIP tunnels". Rob

11 years, 8 months

2
1
0 0

Routing and encap minor issue in JNOS

by Mark Phillips

Hi all, Firstly, if this has been done to death before please forgive me. I could not find anything in the archive. Secondly, I have noticed an "issue" with the routing and encap within JNOS. It would seem that if a 44 station tries to contact me all works fine. For example I can communicate with N2NOV and GB7CIP exactly how you would expect. However, if a "public" address contacts me, I get their connect requests in encap format via uscd but then I send them my response directly rather than back the same way it came. This means that there can be no public access to my system via the Internet. What have I missed? JNOS will not allow me to set the default route via encap/uscd and I don't really want to send all my traffic (eg DNS lookups) via there anyway. How can I respond to connections in the same way that I received them? Thinking about it, it makes sense that JNOS replies directly. Once it unpacks the packet and discovers an encap'd one inside it will work on that one exclusively. Thanks Mark

11 years, 8 months

4
9
0 0

jnos

by Eric Fort

Does a version of jnos exist that is stripped of all it's networking code thus just offering the the bbs parts? AF6EP

11 years, 8 months

2
2
0 0

Something simple

by Rod Ekholm

I am interested in something simple. I am not interested in creating a Linux box to do my routing, as I see no need for it. It's almost worse than having a network that is vendor specific!! I don't tell you how to run your internet.. you don't tell me what router I have to use. I use Mikrotik for my edge technology, just because it's what I am familiar with. For me it's easy enough. I am interested in creating some links with others, hopefully in the NW towards the Seattle area. I have my own system design that I am planning on implementing starting early this fall. I have no interest however in trying to use some script (nice work on it though..) to make it work, but would rather have some common assembly of networks that can connect to each other. Unfortunatley, until this is done in a large enough fashion, it looks like i am talking static routes to and from some other networks. My intention is not to rock the boat of what has been done here, but it seem like there is little direction of how the network is assembled and coming to a common point of presence. until one person or gorup comes up and offers some stability of how to route the network accordingly, I fear my use of AMPR is only for some of it's tunneling ability with the use of our 44/8 addressing. I had no intentions of it before, so if I end up not using them later, now loss on my end. Let me know if anyone is interested in creating some more static links, and / or trying to do some sort of edge router that can have an open communications standard, and not a customized (could otherwise spelled proprietary) protocol in the middle. Thanks to you all and have a great day! -- Rod Ekholm KC7AAD kc7aad(a)gmail.com Spokane, WA (509) 435-3400

11 years, 8 months

8
23
0 0

Chris Smith G1FEF?

by Brian Kantor

Has anyone heard from Chris Smith, G1FEF in the past few months? All my email to him has gone unanswered so I'm worried that he might be ill. - Brian

11 years, 8 months

4
3
0 0

Re: [44net] ripv2

by Rob Janssen

> Subject: > [44net] ripv2 > From: > Brian Rogers <n1uro(a)n1uro.ampr.org> > Date: > 09/01/2013 12:12 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > There appears to be at least one valid route missing in the rip > broadcasts. aa6hf is not received via rip however it is using the munge > script... is there an issue in the portal? I receive the routes from RIP and his route is OK. 44.17.0.128/31 via 67.49.91.65 dev tunl0 proto ampr-ripd onlink

11 years, 8 months

5
5
0 0

AMPRNet-config

by Willie Hein WJ3G

Greetings, I'm again planning the setup of a gateway here at the Balogna Capitol, much to the wonderment of a few. Prelim's are done, ie: static ip, registering in the portal, etc. Now I'm back to a place I've been before, automating the startup, and configuration. Something I'm surprised we haven't overcome with a gui by now, and unfortunately way above my pay scale.:) I did have this working before, so I'm hoping with little changes I'll have the init.d scripts and all updated. I'll certainly make them available, maybe on the wiki when I'm done. I realize that it will take changes to make them work on other distros. Maybe it's time to see what the commonalities are, in hopes of developing a standard config tool. I'd certainly like to take this off list till there is something worth showing. Anyone interested? Best regards, Willie, WJ3G

11 years, 8 months

1
0
0 0

Microtik is Broadcasting

by Michael E. Fox - N6MEF

Someone with a Microtik is evidently broadcasting on the AMPRnet tunnels. Dest address 255.255.255.255 Source address 0.0.0.0 UDP port 5678 Please stop! Michael

11 years, 8 months

1
0
0 0

Re: [44net] Off Topic.. NOSview

by kb9mwr＠gmail.com

I'd like a copy too. Is there anyway we have have a centralized place for stuff like this? I have to admit that wiki's aren't really for me. Editing them I find painful. And there are a number of scripts and software packages that I have been trying to archive. -- And a couple messages ago the question was asked "Has anyone tried to use transverters from 2.4GHz to 432 Mhz?" Does such a transverter exist? A $40 Ubiquiti 2 GHz bullet coupled with a few watt (2.4 Ghz to 432 MHz) transverter might work better than a $170 mini PCI radio card combined with a $85 router board and all that. http://www.xagyl.com/store_us/product.php?productid=31 There are some impressive 802.11 networks being built by European amateurs. There also seems to be quite a lot of talent with microwave design over there.

11 years, 8 months

1
0
0 0

rip44d

by Rob Janssen

Hi Hessu, I am trying to get rip44d working on my Raspberry Pi. For some reason, I cannot get it to receive the 44.0.0.1 -> 224.0.0.9 transmissions. The socket is listening on port 520, when I trace tunl0 I see the packets arriving every 5 minutes, but the rip44d (running with -v) remains absolutely silent. Any idea what that can be? I saw that there is a 2nd set of transmissions, from 169.228.66.251 to my internet address, oddly from port 520 to port 34348. With some small changes to rip44d, to change the source address check and the port number, and to remove the multicast handling, it receives those packets perfectly and the routes are added. Do you have any idea what this can be? The Pi is running Linux 3.6.11+ (raspbian wheezy), and I installed the perl modules just as you explain on the wiki. Of course I could make my changes conditional and add a flag to listen to this alternate transmission, but I don't know about the status (maybe they will stop sometime?). It could be better to fix the problem, if I knew how... 73, Rob PE1CHL

11 years, 8 months

4
3
0 0

Re: [44net] 44Net Digest, rip44d

by Rob Janssen

> Subject: > Re: [44net] rip44d > From: > "Kutche, Jerry (Mitchell) USA" <JKutche(a)lehighcement.com> > Date: > 08/30/2013 12:40 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu>, Heikki Hannikainen <hessu(a)hes.iki.fi> > > > Is your pi in the DMZ? I had to do that with HP Linux BOX a non-pi.... Might try that? > > Jerry Kutche > Electrical Supervisor My Pi is in a datacenter, directly connected to Internet. Not behind a NAT router, that is. I have not further researched the matter, as I have solved it by using ampr-ripd and not using multicast. I think there is something missing or not configured that is related to multicast. The kernel config is: CONFIG_IP_MULTICAST=y # CONFIG_IP_MROUTE is not set Multicast routing is not enabled. On my home PC (SuSE Linux), it is enabled. Maybe this is a requirement even for the reception of multicast datagrams. Rob

11 years, 8 months

1
0
0 0

Anyone tried to use transverters from 2.4GHz to 432 Mhz?

by YT9TP Pedja

I noticed that there are some ham projects of developing transverters from 2.4 GHz to lower ham radio bands. I wonder if anyone tried something like this to convert WiFi devices to 70 cm band? Could that work? Pedja YT9TP

11 years, 8 months

1
0
0 0

Re: [44net] (no subject)

by kb9mwr＠gmail.com

The tunnel interface is a gateway to the rest of the class A network. You have to allow this by setting a netmask of netmask 255.0.0.0 An your second ethernet interface to your radio LAN, you may set a smaller netmask. Steve

11 years, 8 months

3
3
0 0

Re: [44net] Multiple gateways for same route

by Michael E Fox - N6MEF

Eric, Today, the list of tunnels, whether distributed by the encaps file or via RIP, are really just a list of whatever is configured in the portal. Even though they may be distributed by RIP, RIP is being used merely as a distribution mechanism. The existence of an entry in the list tells you nothing about whether that tunnel is actually up or not -- only that it has been configured in the portal. So, even if there were multiple RIP speakers, you'd get the same info except for the main gateway/default route. What I think you're describing is more like a route reflector such as are used in Internet BGP networks. The clients would identify themselves to the main gateway, and the main gateway would reflect that info back to all other clients. That would provide the dynamic routing that would be helpful. And, if the clients could announce additional routes to the server, we could have dynamic alternate routes. Couple that with regional reflectors and the option to listen to more than one reflector so you can get dynamic default route, and I think we've got something. The code for BGP route reflectors is public domain, so I wonder if it makes sense to adapt it to RIP. Michael N6MEF Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: Eric Fort <eric.fort(a)gmail.com> Date: 08/27/2013 1:33 AM (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Multiple gateways for same route (Please trim inclusions from previous messages) _______________________________________________ ok, multiple static routes to the same place I can see why not. We do have dynamic routing available to us though via RIP. Would RIP or another routing protocol not handle this in the case of the route being unreliable and drop that route? Why must routes be persistent rather than dynamic? In a larger sense and I realize we're not there yet it would seem that rather than having to know the routes to all other 44net hosts from boot it would be much easier to have each area (for instance each /16 or maybe in some cases each /24) to have a designated router (say at .1) or possibly use multicast to discover one's local router. thus the initial config is simplified as it has a single route to the 44net gateway for it's area from which it may discover via dynamic routing other routes. no more need to manually distribute and update a routing table. This seems to be something to work towards. On Thu, Aug 15, 2013 at 7:55 AM, <Bob(a)qbjnet.com> wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > No they shouldn't both be allowed. There isn't a way to dynamically choose > the > route based on whether one or the other connection is up. Packets sent to > the > down route are simply lost. > > Regards, > Bob > > > "Eric Fort <eric.fort(a)gmail.com> says:" > > (Please trim inclusions from previous messages) > > _______________________________________________ > > are these 2 entries for a single route or 2 separate routes to a single > > destination? It seems to me they are actually separate redundant routes > to > > the same /21. should redundant routes not be allowed? It would seem > quite > > the reverse that redundancy being useful and importaint these ought to be > > allowed to stand so long as they are valid routes to the specified /21. > > > > Eric > > AF6EP > > > > On Thu, Aug 15, 2013 at 2:54 AM, G1FEF <chris(a)g1fef.co.uk> wrote: > > > > > (Please trim inclusions from previous messages) > > > _______________________________________________ > > > Hi Marc, > > > > > > No, there should not be two entries for one route and the portal should > > > not allow this to happen, so I will look into how it occurred and > amend the > > > code as necessary. > > > > > > Thanks, > > > Chris > > -- > /~\ The ASCII | Bob Brose N0QBJ > \ / Ribbon Campaign | http://www.qbjnet.com/ > X Help cure | mailto:bob@qbjnet.com > / \ HTML Email | public key at http://www.qbjnet.com/key.html > > There are only 10 types of people in the world: Those who understand > binary, and those who don't > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net > http://www.ampr.org/donate.html >

11 years, 8 months

4
3
0 0

Re: [44net] Multiple gateways for same route

by Rob Janssen

> Subject: > Re: [44net] Multiple gateways for same route > From: > Eric Fort <eric.fort(a)gmail.com> > Date: > 08/27/2013 10:33 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > ok, multiple static routes to the same place I can see why not. We do have > dynamic routing available to us though via RIP. Would RIP or another > routing protocol not handle this in the case of the route being unreliable > and drop that route? This has been discussed many times here. Maybe you need to have a look at the archive. There are many existing solutions for this problem, of course. They all have their advantages and disadvantages, when seen from an amateur viewpoint. However you need to understand that the sending system has no information about "the route being unreliable" and the receiving system has no way of making the sending system try other routings. That is why a working automatic routing protocol is always much more complex than RIP (which works like the method used by NET/ROM) There is little point in rehashing time after time how much better everything could be, when there is not going to be a change anyway. Rob

11 years, 8 months

1
0
0 0

Multiple gateways for same route

by Marc, LX1DUC

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, while analyzing the routing table on my Mikrotik router, I noticed that there are 2 gateways for 44.136.0.0/21: 114.198.116.219 203.5.58.162 The encap file has both as well: route addprivate 44.136/21 encap 203.5.58.162 route addprivate 44.136/21 encap 114.198.116.219 I have tried to create 2 routes for some of my networks via the portal, but the portal complains with the words "The network overlaps an existing entry". I'm now interested to know, if these 2 routes are intended to co-exist? If yes, how can one create those entries via the portal. If no, which one is correct and why are there 2 entries? 73 de Marc, LX1DUC - -- http://lx1duc.mcs.tel -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSDJ/oAAoJEHFIN1T8ZA8v8EoP/0HHZn+S4SB0EiqJKjZR8gJG GL7imNQ0sTZUBE6QMQzXs5+Dr6D++jEYyO36AlqgR0Z2SABs/HFhbuHYV+9Bvb+n m01m8eKDFJam3uqXGQjsvV5gH/nC8nVJ0hgdsMolatu8B8WBUR02QQDkgq2u11pP GLwffzANg4/FPLLShYZKk2IL6unh0GFqvW2bePQUZ+8OQv2X1UyDR2jWg4gi7sOO 6imU3CVfKfc53SfPox2De7nLGxsKZsk2O/RCxHEom0MKYCdWtNmoszOTDpxNmkPd cVJfEZ7zOIBHW+ZYFtsCy1GfoanDlel0jOMm5zNe4WkxeCjPtvD/46vxpPOAh2xk 84lDA3oWY2LYKny6c6YD7zFEcHcX84gR+6gdFFvuaiKU99RizFK0XORJxdVqU4tT TSBCCt+oW6sPCAJe2vuorA9TyqLMwc6RDg98ZdoEEAYQJke7/CgTBkP+A6EY/U15 HCWk6cXIvHsu2j33K4HoqoaJa74yZMctTnumMu+E4x2Kw+OtCFJfsNt3dTAqeWkr uuKpeqnjWqPAnT6l3uQOTknwfara79Cw9zWfaG2nnRS8gcIki+Voe+gWAOdiObbF m0dcmsCBqcyFaRtBHyR0N4BuQC/o5H6rQBgzNFDW54EKraRPLokuM9fW6PF1YJ1l +TItkIm+J2u9xwlSJbXq =invI -----END PGP SIGNATURE-----

11 years, 8 months

9
9
0 0

Re: [44net] Routing Tables

by William Lewis

Your routes look correct. Traffic will follow the most 'precise' given route. For example, lets first use a made-up route to 44.2.12.75. Since your table does not show a 'specific' subnet, it will use your rule of "44.0.0.0 169.228.66.251 255.0.0.0" But, if you use a route to 44.2.14.3, your tables show a more precise route to that address, so your traffic will use your route rule of "44.2.14.0 50.79.156.221 255.255.255.248" The only thing I see in your route that may or may not be of concern, is the third line. Not sure what your interface "rose0" goes too, but I see a possible conflict with the route right above it. You basically have two (2) routes listed for traffic to 44.0.0.0/8 Other than that, that looks good. As everyone's setups are custom, I don't know what that interface "rose0" does for your system. Bill At 03:32 PM 8/24/2013, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >Hi all, > >My routing table after my AMPRnet GATEWAY has got all the routes via >RIPv2 using rip44d, looks like this: >------------------------------------------------------------------------------------------------------- >Kernel IP routing table >Destination Gateway Genmask Flags Metric Ref Use Iface >0.0.0.0 192.168.15.1 0.0.0.0 UG 0 0 0 eth0 >44.0.0.0 169.228.66.251 255.0.0.0 UG 0 0 0 tunl0 >44.0.0.0 0.0.0.0 255.0.0.0 U 30 0 0 rose0 >44.0.0.1 169.228.66.251 255.255.255.255 UGH 0 0 0 tunl0 >44.2.1.32 76.14.161.185 255.255.255.248 UG 0 0 0 tunl0 >44.2.10.0 71.130.72.52 255.255.255.248 UG 0 0 0 tunl0 >44.2.11.1 71.130.72.52 255.255.255.255 UGH 0 0 0 tunl0 >44.2.14.0 50.79.156.221 255.255.255.248 UG 0 0 0 tunl0 >44.2.14.100 50.79.156.221 255.255.255.255 UGH 0 0 0 tunl0 >44.2.50.0 68.189.32.222 255.255.255.248 UG 0 0 0 tunl0 >44.2.50.0 208.74.106.137 255.255.255.0 UG 0 0 0 tunl0 >44.4.2.152 173.167.109.217 255.255.255.255 UGH 0 0 0 tunl0 >44.4.2.153 173.167.109.217 255.255.255.255 UGH 0 0 0 tunl0 >.... >More routes >------------------------------------------------------------------------------------------------------------- > >Is this correct or am I dending all AMPRnet traffic through UCSD.EDU ? > >-- >73 de SV1UY >Demetre Ch. Valaris >e-mail: demetre.sv1uy(a)gmail.com >Radio e-mail: sv1uy(a)winlink.org >(to use my radio e-mail put //WL2K in the beginning of the subject line) >http://www.qsl.net/sv1uy >_________________________________________ >44Net mailing list >44Net(a)hamradio.ucsd.edu >http://hamradio.ucsd.edu/mailman/listinfo/44net >http://www.ampr.org/donate.html

11 years, 8 months

4
5
0 0

Re: [44net] ipip tunnel

by lleachii＠aol.com

Marius, 172.31.255.254 is merely my tunl0 IP address, it's a Private IP in the Class B range, using a /32 (a single host on the network), nothing works using that IP address but ping from my 44LAN. 44.60.44.1 is the IP of my eth1 interface, everything is handled on my device via IP forwarding. I have my tunnel isolated from my 44LAN and Local/WAN network for testing and troubleshooting purposes. This ensures that I'm in fact routing if a packet moves from one network to another. My eth0 is my public facing LAN - which has a 192.168 IP scheme, IP-in-IP is passed to that network from my Public IP address by my Router. eth1 is my 44LAN with the IP address of 44.60.44.1/24. my setup script can be seen at http://44.60.44.13/startampr 73, Lynwood KB3VWG

11 years, 8 months

9
24
0 0

Re: [44net] 44Net Routing tables

by Rob Janssen

> Subject: > Re: [44net] Routing Tables > From: > Bob Tenty <bobtenty(a)gmail.com> > Date: > 08/26/2013 08:23 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > The default route to 169.228.66.251 is in most munge scripts I have seen. > The motivation was that you are reachable in that way if a new gateway > pops up and you don't refresh your ipip routes at a regular basis. > > 73, > > VE3TOK I also need it for the return route to sources outside net 44. That is why I have it as a default route in table 44. When someone outside net 44 connects me, I need to return the packets encapsulated to amprgw where they are decapsulated and returned to the internet. (every responsible ISP has source address filtering these days) Rob

11 years, 8 months

1
0
0 0

Re: [44net] 44Net (no subject)

by Rob Janssen

> Subject: > Re: [44net] (no subject) > From: > kb9mwr(a)gmail.com > Date: > 08/24/2013 10:06 PM > > To: > "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > > > The tunnel interface is a gateway to the rest of the class A network. > You have to allow this by setting a netmask of netmask 255.0.0.0 > > An your second ethernet interface to your radio LAN, you may set a > smaller netmask. > > Steve > > > Subject: > Re: [44net] 44Net (no subject) > From: > "Marc, LX1DUC" <lx1duc(a)rlx.lu> > Date: > 08/24/2013 10:12 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Netmask surely has a relation to broadcast packets, but not multicast. > > Several user on this list use /32 (255.255.255.255) netmask on their > tunl0 interface. > > 73 de Marc It is not completely clear to me what the netmask on tunl0 really does. I understand what it does on a local network, but not for tunl0. For the routing, it does not appear to influence anything. And at least by setting it this way, I avoid having that unclear route for 44.0.0.0/8 that is added when tunl0 is created. Maybe it breaks multicast, but I don't know how. The non-working multicast could as well be the result of something else, e.g. the limited config included with the Raspberry Pi that is not really intended to be a complex router (but quite capable of it). With the -r option to ampr-ripd things appear to work OK. I use the policy-routing configuration, not a flat routing table. There is a main routing table with routes for the local network (at the datacenter), and the default gateway. There is a separate route table 44, with the default route to amprgw, the specific route for my subnet at home and the local running NET, and the ampr-ripd also adds all the specific tunnel routes in that table. There are policy routing rules that select this routing table when the source or the destination of the packet is in network 44: 44: from 44.0.0.0/8 lookup 44 45: from all to 44.0.0.0/8 lookup 44 Rob

11 years, 8 months

2
1
0 0

Portal Feature Request

by Neil Johnson

Can I request a feature for the portal ? It would be nice for a co-ordinator to have the ability to add an IP address allocation on the behalf of someone else. I'm in the process of cleaning up the database for the US State of Iowa, and some users are e-mailing me directly to keep their allocations rather than registering it via the portal. I suspect that explaining how to register through the portal might be confusing or they don't feel comfortable registering on the portal. Thanks. -Neil -- Neil Johnson -N0SFH http://erudicon.com

11 years, 8 months

2
1
0 0

Routing Tables

by Demetre SV1UY

Hi all, My routing table after my AMPRnet GATEWAY has got all the routes via RIPv2 using rip44d, looks like this: ------------------------------------------------------------------------------------------------------- Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.15.1 0.0.0.0 UG 0 0 0 eth0 44.0.0.0 169.228.66.251 255.0.0.0 UG 0 0 0 tunl0 44.0.0.0 0.0.0.0 255.0.0.0 U 30 0 0 rose0 44.0.0.1 169.228.66.251 255.255.255.255 UGH 0 0 0 tunl0 44.2.1.32 76.14.161.185 255.255.255.248 UG 0 0 0 tunl0 44.2.10.0 71.130.72.52 255.255.255.248 UG 0 0 0 tunl0 44.2.11.1 71.130.72.52 255.255.255.255 UGH 0 0 0 tunl0 44.2.14.0 50.79.156.221 255.255.255.248 UG 0 0 0 tunl0 44.2.14.100 50.79.156.221 255.255.255.255 UGH 0 0 0 tunl0 44.2.50.0 68.189.32.222 255.255.255.248 UG 0 0 0 tunl0 44.2.50.0 208.74.106.137 255.255.255.0 UG 0 0 0 tunl0 44.4.2.152 173.167.109.217 255.255.255.255 UGH 0 0 0 tunl0 44.4.2.153 173.167.109.217 255.255.255.255 UGH 0 0 0 tunl0 .... More routes ------------------------------------------------------------------------------------------------------------- Is this correct or am I dending all AMPRnet traffic through UCSD.EDU ? -- 73 de SV1UY Demetre Ch. Valaris e-mail: demetre.sv1uy(a)gmail.com Radio e-mail: sv1uy(a)winlink.org (to use my radio e-mail put //WL2K in the beginning of the subject line) http://www.qsl.net/sv1uy

11 years, 8 months

2
1
0 0

FW: RIP from teqsys.net

by Hugh Golding

Hi Guys, Sorry about the RIP routes. After some work on my router the RIP was turned on for all interfaces. I have now rectified this and all should have stopped. Apologies. Best Regards, Hugh G7UOD ) +44 7841 749345 * g7uod(a)onlineham.net

11 years, 8 months

3
3
0 0

Re: [44net] 44Net (no subject)

by Rob Janssen

> Subject: > [44net] (no subject) > From: > kb9mwr(a)gmail.com > Date: > 08/24/2013 02:59 AM > > To: > "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> > > > --- Quote --- > > For some reason, I cannot get it to receive the 44.0.0.1 -> 224.0.0.9 > transmissions. > The socket is listening on port 520, when I trace tunl0 I see the > packets arriving > every 5 minutes, but the rip44d (running with -v) remains absolutely silent. > Any idea what that can be? > ------ > > The first thing that comes to mind is something wrong with the tunl0 netmask. > Ah is that the reason? The netmask on tunl0 is 255.255.255.255. I have only a single address on my tunnel endpoint. Is that not allowed? What should it be instead? In the meantime I have solved it by using ampr-ripd instead of rip44d. It has the -r option to use a raw socket to receive everything on tunl0 and picking out the RIP datagrams itself. That works OK. I have a Rasperry Pi that is located in a datacenter. It is directly on Internet. Now I am running the net-44 tunnel stuff on it, it acts as my gateway for two single addresses and a subnet. There is a local copy of NETCHL running there as well, on 44.137.40.1. I can access the different amprnet systems from there. It is running under "screen" so I can take over the console from where I like. My subnet is routed to my home system via an IPsec tunnel, where I still run some services that I want to move there. The default route for net-44 traffic at home is now to my Pi. It runs beautifully. Now my system at home is a lot less complicated, and I can more easily upgrade to a newer Linux version without disturbing all the special networking stuff. Rob

11 years, 8 months

2
1
0 0

Dynamic Routing: LISP

by Jim Alles

In another thread, it was said: >> everyone in the mesh ought to be running a dynamic routing protocol thus >> increasing redundancy and reliability. >This is a good idea. I'm not up on the latest RFCs concerning routing in >tunneled (VPN, GRE, etc) networks. Do you have a recommendation? I am not an expert to answer this question, but I have stumbled on an emerging method for routing that has remarkable similarities to threads here. Along with the connections/associations I list below, it is experimental communications, and I believe we (Hams) have something to contribute. RFC 6830, LISP (Locator/ID Separation Protocol - see [http://www.lisp4.net/] ) decouples Location from unique IDentifier in IP addressing. I first saw the need for this concept with APRS messaging, but that is for another group. "LISP follows a network-based map-and-encapsulate scheme ... both identifiers and locators can be IP addresses or arbitrary elements like a set of GPS coordinates or a Mac address." {or call sign?} The LISP Papers at [http://blog.pattincon.com/lisp-papers/] seems to be a good place for me to start to understand the application of this protocol. It is implemented in recent versions of Cisco IOS/NX-OS (out of my reach at this time) and LISPmob (Mobile Node) at [http://lispmob.org/] runs on OpenWRT/Linux. I am working on experimenting with something from here. Peace, Jim A. KB3TBX

11 years, 8 months

2
1
0 0

(no subject)

by kb9mwr＠gmail.com

--- Quote --- For some reason, I cannot get it to receive the 44.0.0.1 -> 224.0.0.9 transmissions. The socket is listening on port 520, when I trace tunl0 I see the packets arriving every 5 minutes, but the rip44d (running with -v) remains absolutely silent. Any idea what that can be? ------ The first thing that comes to mind is something wrong with the tunl0 netmask.

11 years, 8 months

1
0
0 0

Re: [44net] Something simple

by Rod Ekholm

Pedja, If I add the encap.txt file you provided (realizing is is truncated..) and adding it to my files list in my router, and running the txt file you provided as a scipt in my MT, it does nothing. Is this the intended method of your files? i see the script count increment, but I don't see any routes get added. In the first line of the script file, I edited the IP Address to be my local (inside address). Should it be the inside address, my outside WAN address or my AMPR address? Thanks for clarifying, and great job, if this works! -- Rod Ekholm KC7AAD

11 years, 8 months

2
1
0 0

Re: [44net] Who is teqsys.net and why is he sending me RIP?

by Heikki Hannikainen

On Sun, Aug 18, 2013 at 5:54 PM, David Ranch <amprgw(a)trinnet.net> wrote: > Going to www.teqsys.net and looking at the Orange tab, there is the callsign > G7UOD for "Hugh Golding". There is an email address for him on QRZ too. I sent an email to Hugh, he confirmed he has removed his RIP transmit configuration now, and teqsys.net should not be sending those packets any more. - Hessu

11 years, 8 months

1
0
0 0

Re: [44net] Radio-based networking

by Paul Delaney - K6HR

Same here, all dressed up with nowhere to go! I maintained 6 radio ports for quite a long time utilizing HF/VHF/UHF 1200/9600/PACTOR3, even satellite. No users. No more fun. I eventually reinvested that money in other areas of the hobby. Judging by the replies so far I think it's fairly safe to say there is little to no tcp/ip over radio in use anymore. Paul Delaney - K6HR http://k6hr.dyndns.org:8080 On 08/21/13, JJ wrote: (Please trim inclusions from previous messages) _______________________________________________ On 13-08-21 11:19 AM, Brian Kantor wrote: > > Is anyone actually using the network over radio at this point? > Could you supply some details? > I have 4 RF ports, 2 hf, 2 vhf, all ip capable, but there's no-one in my area to route to over the air...and forget trying tcipip @ 300 baud hf, lol, that wud be painful...but I cud turn the beam and route to ka0mos over vhf... prolly not very helpful, but yes, I use/would use ip over RF, I have b4, and I will again! _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

11 years, 8 months

1
0
0 0

Re: [44net] Radio-based networking

by Paul Delaney - K6HR

An HTML attachment was scrubbed... URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20130821/7ee0c10…>

11 years, 8 months

1
0
0 0

Re: [44net] Radio-based networking

by kb9mwr＠gmail.com

------ Quote ------ Is anyone actually using the network over radio at this point? Could you supply some details? We had been using the 44 net space and TCP/IP over radio (1200/9600) for many years here in Wisconsin. We even ran Webservers on those links. This made the 1999 CQ and CQ-VHF magazine. Our original packet organization's (WAPR) webpage was accessible via radio. http://www.qsl.net/kb9mwr/wapr/ Now most of the 1200 baud portions of the network are dead, and only a few have moved on to 802.11 options. I and four others in Green Bay have been mostly doing remote backups using rsync over 802.11 for several years now. A few years back I ran a PBX with a 802.11 trunk to my friends house.

11 years, 8 months

1
0
0 0

Re: [44net] Radio-based networking

by Brian Rogers

Hello Brian et al; > I'm in the process of preparing a new document on the AMPRNet. > I'd like to include a section on the radio-based portions of the > network. > > Is anyone actually using the network over radio at this point? > Could you supply some details? You may be interested in this link: http://bythebays.net/neflexnet/howtotcp.htm It's a document I drafted with k2mf a few years back. ********************** 73 de Brian N1URO ********************** Spam {n}: an entity using smtp via internet to force humans to revert back to paper, pencil, and postage for mail communications.

11 years, 8 months

1
0
0 0

Re: [44net] Something simple

by kb9mwr＠gmail.com

>> Well seems every platform is a bit different. The ip route command >> works a bit different from Debian to Redhat. Here are the errors when >> I tried to run rip44d on CentOS platform: >> >> route del failed: 'LANG=C /sbin/ip route del 44.183.0.0/255.255.0.0': >> Error: an >> inet prefix is expected rather than "44.183.0.0/255.255.0.0". > >This looks really odd. rip44d runs ip route commands with a prefix >length, not a netmask. Was that with a current, unmodified version of >rip44d (https://raw.github.com/hessu/rip44d/master/rip44d) ? > >- Hessu That was an older version. I just tried it again, using CentOS 5.5 and it works as expected. Which is great

11 years, 8 months

1
0
0 0

IP Protocol 4 in DD-WRT and rip44d script

by Demetre SV1UY

Hi all, Is anyone using a DD-WRT router (I use a TL-WR1043ND with DD-WRT) for his/her AMPRnet GATEWAY 44.154.0.1? I have the following problem here. I have included support in my DD-WRT Router's IPTABLES for IPIP (IP Protocol 4) with the command "iptables -t nat -A PREROUTING -p 4 -j DNAT --to 192.168.250.66" in it's Firewall, but this does not seem to work. I wonder if I need to also port forward UDP port 520 to the same IP, but I don't think so because I think rip44d uses UDP port 520 for outgoing packets only. When I put my GATEWAY's ethernet IP (192.168.250.66) in DMZ then rip44d works fine, but then my AMPRnet GATEWAY is really exposed and I need to write an extensive IPTABLES SCRIPT. Is there a way for rip44d to work behind NAT? Is my "iptables -t nat -A PREROUTING -p 4 -j DNAT --to 192.168.250.66" command enough for my DD-WRT or am I wrong? Could anyone help please? 73 de Demetre SV1UY IP coordinator for AMPRnet in Greece e-mail demetre.sv1uy(a)gmail.com

11 years, 8 months

8
21
0 0

Re: [44net] Something simple

by kb9mwr＠gmail.com

Well seems every platform is a bit different. The ip route command works a bit different from Debian to Redhat. Here are the errors when I tried to run rip44d on CentOS platform: route del failed: 'LANG=C /sbin/ip route del 44.183.0.0/255.255.0.0': Error: an inet prefix is expected rather than "44.183.0.0/255.255.0.0". route add failed: 'LANG=C /sbin/ip route add 44.183.0.0/255.255.0.0 via 130.208.168.63 dev tunl0 window 840 onlink': Error: an inet prefix is expected rather than "44.183.0.0/255.255.0.0". route del failed: 'LANG=C /sbin/ip route del 44.208.0.0/255.255.0.0': Error: an inet prefix is expected rather than "44.208.0.0/255.255.0.0". route add failed: 'LANG=C /sbin/ip route add 44.208.0.0/255.255.0.0 via 94.101.48.134 dev tunl0 window 840 onlink': Error: an inet prefix is expected rather than "44.208.0.0/255.255.0.0". route del failed: 'LANG=C /sbin/ip route del 44.142.0.0/255.254.0.0': Error: an inet prefix is expected rather than "44.142.0.0/255.254.0.0". route add failed: 'LANG=C /sbin/ip route add 44.142.0.0/255.254.0.0 via

11 years, 8 months

2
1
0 0

re: Something simple

by Rod Ekholm

Single point of presence only for vast connectivity. I have read others ideas about having multiple GP hosts.. That is a great concept. As for vendor non-specific.. I think just about any common platform of routing will do. What I hate to see is something that has to be run on a certain box. Whether it be RIP44d, or any other specifically modified routing protocol. You don't see Cisco's specific standards being used across platforms, because they can only be used with other Cisco boxes. While I am stating all this all to obvious information, i do realize there have been some very long nights and likely some personal sacrifices that folks have made to have 44Net what it is today. i just think there needs to be a road map developed like any project, to make sure everyone that has the common interest be allowed to play, and not be locked down to what flavor they have to have. Be it PPP, VPN, BGP with some redundancy, vanilla, chocolate... I don't have the answer, because it's too big to wrap my head around this early in my game. I'd be willing to be part of something that can define and help others though. -- Rod Ekholm

11 years, 8 months

1
0
0 0

Re: [44net] Something simple

by kb9mwr＠gmail.com

Rod, I can't speak for everyone. What do you propose that isn't vendor specific? There was some talk about http://en.wikipedia.org/wiki/Dynamic_Multipoint_Virtual_Private_Network And there seems to be an open source compatibility here: http://sourceforge.net/projects/opennhrp/ I'd be willing to dabble with this, if someone else wants to. The common point of presence idea, might make things simpler, but then that is a possible point of failure.

11 years, 8 months

1
0
0 0

Who is teqsys.net and why is he sending me RIP?

by Mark Phillips

All, Like the subject says. I've noticed I'm getting a RIP update from 81.174.253.193 which contains only a few of the major subnets in our nework. Anyone got a clue as to whom this is and why they are sending them? Thanks Mark

11 years, 8 months

4
4
0 0

Dynamic IP Gateway problem.

by Demetre SV1UY

Hi all, I have setup, after many years of absence, our AMPRnet GATEWAY in Athens, running in a LINUX BOX. I have a dynamic IP here which rarely changes and up to now I had access to several AMPRnet hosts. Yesterday I had to reset my router (TL-WR1043ND running DD-WRT) and I lost connectivity. Checking http://portal.ampr.org I can see that my new Internet IP has been updated (it takes about 1 hour I think). Problem is that now I cannot ping gb7cip.ampr.org or any other AMPRnet host I could before? I can see that rip44d is doing it's thing using "tcpdump -i tunl0". How long does it take for AMPRnet to be informed after a change in Internet IP (nor 44net IP)? It has been more than 12 hours since my router got it's new IP and no joy yet! Any ideas guys? -- 73 de SV1UY Demetre Ch. Valaris IP Coordinator for AMPRnet in Greece e-mail: demetre.sv1uy(a)gmail.com Radio e-mail: sv1uy(a)winlink.org (to use my radio e-mail put //WL2K in the beginning of the subject line) http://www.qsl.net/sv1uy

11 years, 8 months

11
20
0 0

Portal DNS requests

by Blaine Forbort

I was just curious, is the portal's DNS request page up and running, or do I need to try to contact my coordinator directly? I'd like to add a couple of A name records for my routing experiment. router-3.k1qv.ampr.org A 44.4.36.3 router-5.k1qv.ampr.org A 44.4.36.5 These will be the two routers that will be connected to my gateway via OpenVPN. Thanks for the update, Blaine, K1QV Sent from my iPhone

11 years, 8 months

2
1
0 0

experimental LISP

by Jim Alles

Anybody that knows about BGP & GRE, I was wondering if this would be useful for us to look into (I am not that person). http://www.rfc-base.org/txt/rfc-6836.txt Jim A.

11 years, 8 months

1
0
0 0

Re: [44net] rip44d update

by kb9mwr＠gmail.com

Michael, At this point, ampr-ripd (C implementation) is the best thing out there in my opinion. Hessu, wrote the rip44d, and that required Perl and a multicast package to run. So running this on a WRT54G, for instance was probably not going to happen. I'd like to think with the C implementation, this could be a reality. Also, I am not sure, but do think the C implementation stands the greatest chance to run cross platform. Hessu's perl one was kind of locked to Debian installs. Again, it's all so new, I personally haven't had they time yet to try it on a bunch of different platforms. I actaully am not sure why someone would go with amprd over ampr-ripd. Perhaps others can comment. Steve

11 years, 8 months

2
1
0 0

(no subject)

by kb9mwr＠gmail.com

Here are some random thoughts: It would be interesting or maybe helpful if the ampr.org name server did some statistics collection. These stats could be used to help prune dead records? I am not sure how resource intensive that might be however. It looks like you can use Cacti in conjunction with BIND. It is also important that we have some idea what is on the amprnet, what it used for. The Michigan Digital Radio group has some basic activity polling : http://server1.nuge.com/~drg/network.html Perhaps even something that can be installed on gateways that promiscuously monitors well know ports/services, and can be configured to report activity to a central page? If nothing else can the gateway portion of the portal have some additional text boxes, so folks can explain things a bit more like the old resource.txt?

11 years, 8 months

1
0
0 0

??? ignored packet on IPIP Tunnel

by Luc Pernot

There is a message showing on my RPI gateway 44.135.96.17 tunnel TTY0 saying "ignored packet from 44.131.160.1: 520: 504" every 5 minutes or so. any suggestion how to resolve this... Luc VE3JGL in Ottawa

11 years, 8 months

4
4
0 0

Re: [44net] 44Net Digest, Vol 2, Issue 116

by Rob Janssen

> Subject: > Re: [44net] dd-wrt and ipip > From: > lleachii(a)aol.com > Date: > 08/13/2013 05:04 PM > > To: > 44net(a)hamradio.ucsd.edu > > > All, > > I think the reason that nodes on the 44 Network cannot reach me is that my router is not allowing connections from the Internet to pass through. > > My setup: > > Router 1 > WAN 76.114.216.250 <> LAN 192.168.x.x <> > > Router 2 > WAN 192.168.x.2 <> LAN 192.168.y.x > > AMPRGW > 192.168.y.5 > > In trying to setup IPTABLES commands to allow IPIP traffic, I've had no success thus far. > > On Router1: > iptables -t filter -I INPUT -p ipip -j ACCEPT > iptables -t filter -I FORWARD -p ipip -j ACCEPT > iptables -t nat -I PREROUTING -i vlan1 -p ipip -j DNAT --to-destination 192.168.x.2 > > On Router2: > > iptables -t filter -I INPUT -p ipip -j ACCEPT > iptables -t filter -I FORWARD -p ipip -j ACCEPT > iptables -t nat -I PREROUTING 1 -s 169.228.66.251 -p ipip -i vlan1 -j DNAT --to-destination 192.168.y.5 > iptables -t nat -I PREROUTING 2 -p ipip -i vlan1 -j DNAT --to-destination 192.168.y.5 > > Any ideas? > Your problem is the protocol number used for encapsulation, I think. The "ipip" protocol is protocol 94, the one that was registered mistakenly at a time when protocol 4, which does exactly the same, already existed. Now the protocol 4 is used, which is in /etc/protocols under its name "ip". So use -p ip or just -p 4. Rob

11 years, 8 months

1
0
0 0

Cisco/juniper configs?

by Bryan Fields

Greetings, I've been doing some work to get the IPIP tunnel information into a router on a daily basis, has anyone else automated this? I was wondering how the reachability of this from the global routing table of the public internet works, if at all. Everything I've been reading says this is all separate, but we do interconnect at a couple locations. I must admit I'm new to this, but is 44/8 intended to be totally separate a la the GRX network? Granted my use of this space is for high speed wireless networks on the ham bands, I have little interest in the 9.6 kilobaud TCP/IP packet radio. I've got some of the 900MHz FHSS gear hacked to run in a narrower channel, and I've been experimenting with running some of the 5ghz units in the ham band at 5cm (5mhz channel is able to do about 10mbit/s). My intention is to have it all work across hardware routers, ie cisco/ALU/juniper rather than maintain a bunch of linux boxes. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

11 years, 8 months

5
5
0 0

Trouble setting static route with ampr-ripd

by Neil Johnson

I've been trying add the following route to my "44" table to insure that local packets get sent out the wireless interface. ip route add 44.50.128.0/24 dev wlan0 table 44 However, I can't get it to be added when the system restarts. Any suggestions would be appreciated. Thanks. -Neil -- Neil Johnson -N0SFH http://erudicon.com

11 years, 8 months

3
6
0 0

Re: [44net] Trouble setting static route with ampr-ripd

by Pieter Luteijn

When adding the route statement to the initialization sequence, make sure the wlan0 interface exists; don't put it too early in the sequence. Perhaps best to add it and its 'del' counterpart to the networking scripts that bring the wlan0 interface up and down, not to the rc-scripts? P. Sent from a mobile, sorry for any typoes... -------- Original message -------- From: Neil Johnson <neil.johnson(a)erudicon.com> Date: 2013/08/11 22:07 (GMT+01:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: [44net] Trouble setting static route with ampr-ripd ip route add 44.50.128.0/24 dev wlan0 table 44 However, I can't get it to be added when the system restarts.

11 years, 8 months

1
0
0 0

SIP Service on AMPRnet

by Marc, LX1DUC

Dear YLs and OMs, I have installed a SIP service on sipwise.ampr.org. It allows SIP users to do voice & video calls, instant messaging (via SIP), screen sharing, etc. There is also support for voicemail, call forwarding and call forking (upto 5 user-agents (devices, softphones, etc) per account). The system accepts calls from outside, try sip:lx1duc@sipwise.ampr.org or sip:+883510001204400@sipwise.ampr.org. (I'm using iNUM numbers to provide a globally unique numeric identifier so that hardware phones can make calls to other stations as well, while it's possible to dial "lx1duc" from a numeric keypad, it's more convenient for the user to actually dial a number H-I-H-I.) I'm using it on my mobile via a softphone right now (I didn't have time to configure my hardware phone), but the plan is to use it on hardware phones in our club shacks in LX. You're welcome to test it and if you want/need your own account please contact me off-list. I'm also interested in peering with other SIP services as well, so if you're running one and you're interested in peering, please contact me off-list. 73 de Marc, LX1DUC

11 years, 8 months

2
3
0 0

Why rip44d?

by Michael E. Fox - N6MEF

This is a serious question: Why is everyone so enamored with and focused on using rip44d? Rip44d disadvantages: 1) Rip44d depends on getting the routes from a single source - amprgw, i.e. a single point of failure. 2) If that single source fails (as it did recently, for more than 12 hours), then the routes are gone, even though all of the other gateways may be completely reachable. 3) If you try to avoid that problem by timing out the routes slowly, then you might as well have a static list. It seems to me that periodic downloading of the encaps file, followed by the ip.munge scripts is a far better approach. Advantages: 1) You can define how often you want to download the file, based on how quickly you want to discover new gateways. For me, once nightly is fine. But it could be more often. 2) If the download of encaps fails, I continue using the same routes I had before until the next download attempt. This happens every once in a while - maybe once a month, for whatever reason. But no connectivity is lost. 3) If amprgw fails, the direct tunnels to all other gateways are unaffected. i.e. Single point of failure eliminated. Disadvantages: None that I can see. So I fail to see why everyone is so enamored with rip44d. Please explain. Thanks much, Michael N6MEF

11 years, 8 months

9
10
0 0

bad ip address?

by Don Moore

Whoever is operating (if valid) 176.9.140.86 name = ampr-gw.fks-de.ham.lu please cease and desist sending data using the following encap line. 11:30:13.339166 IP 176.9.140.86 > 192.168.1.150: IP 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 115 (ipip-proto-4) 73, Don - ve3zda

11 years, 8 months

2
1
0 0

FW: Ampernet

by Kutche, Jerry (Mitchell) USA

fyi Looks like we have a another software available that can participate in the Amprnet! coming online soon.. :) 73 Jerry N9LYA Subject: Re: Ampernet On 09/08/13 04:28, Rod McCosker wrote: Paula, We are back from Queensland & XR32 Version D [Alpha Testing] - now works as my Ampernet Gateway 44.136.16.2 - with TinyXP We have to update the Ampernet registery with a few new local entries. There are no AXUDP or IPUDP links setup from the Gateway, only the ENCAP.TXT file It looks like - We may not have a seperate gateway laptop, but integrate the gateway into the main XR32, Will have to think about this. However from VK2DOT-3 the Gateway XR32, we can connect via Ampernet to - ZL2AQY 44.147.38.42 VK6HGR 44.136.204.77 N9LYA 44.48.0.46 regards rod..../// Hi Rod, Are we any closer to seeing the new version ? Regards ..... Peter

11 years, 8 months

2
1
0 0

Re: [44net] "Invalid Gateway Address"

by Pieter Luteijn

How are you trying to use this address? Could it be that your inadvertantly trying to set your default gateway to this address. An off-subnet default gateway is usually 'invalid'.. P. Sent from a mobile, sorry for any typoes... -------- Original message -------- From: Neil Johnson <neil.johnson(a)erudicon.com> Date: 2013/08/08 22:11 (GMT+01:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: [44net] "Invalid Gateway Address" When I try to add it, it says "Invalid Gateway IP Address" Neil Johnson -N0SFH

11 years, 8 months

3
2
0 0

"Invalid Gateway Address"

by Neil Johnson

I just received a static IP from my ISP, but I can't use it for a gateway. When I try to add it, it says "Invalid Gateway P Address" The address is 108.160.233.78. Does it have to be pingable ? Any ideas ? -- Neil Johnson -N0SFH http://erudicon.com

11 years, 8 months

1
0
0 0

Re: [44net] Why rip44d?

by Brian Kantor

Seems to me that encap routes learned by rip44 should be fairly persistant - I'd say they shouldn't expire for a day or three or more. Perhaps a week? Unless replaced by a newer route for the same subnet, of course. That way if the rip sender (amprgw) should happen to go away for a while, things will still function. And you'd have time to switch over to using the encap file if the outage were to be prolonged. There's no harm in having a dormant route in your table for a while when a gateway permanently goes away. What's the maximum rip44 route expiration time setting? You could, of course, decide to NEVER expire them. With daemon modification, they could be persistent across reboots and only purged when manually selected. - Brian

11 years, 9 months

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net