- 44net - mailman.ardc.net

Linux Raid-1
by William Lewis 11 Nov '13

11 Nov '13

Any Linux (Ubuntu 13.10) RAID guru's in the group ? If so, contact me offline. Thanks, ---------- This message is for the designated recipient only and MAY CONTAIN PRIVILEGED OR CONFIDENTIAL INFORMATION. If you have received it in error, please notify the sender immediately and delete the original. Any other use of this E-mail is prohibited. Wm Lewis - KG6BAJ

1 0

Re: [44net] dxc link needed
by Janusz Przybylski SP1LOP 10 Nov '13

10 Nov '13

An HTML attachment was scrubbed... URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20131110/98f9b75…>

1 1

Please delete this portal entry please
by Jerry 03 Nov '13

03 Nov '13

Only…. 44.48.0.0/32 Andrew Davis user <https://portal.ampr.org/coord_ip.php?a=edit&id=570> Edit Boy why would this modify my posting.. ☹ Leave all the others as is… 73 Jerry N9LYA

1 0

please delete item in red.
by Jerry 03 Nov '13

03 Nov '13

44.48.0.0/16 Jerome Kutche region Edit <https://portal.ampr.org/coord_ip.php?a=edit&id=192> 44.48.0.0/32 Andrew Davis user <https://portal.ampr.org/coord_ip.php?a=edit&id=570> Edit 44.48.3.0/29 Joseph Ferraro user Edit <https://portal.ampr.org/coord_ip.php?a=edit&id=343> 44.48.12.0/24 Andrew Davis user Edit <https://portal.ampr.org/coord_ip.php?a=edit&id=720> Thanks. 73 Jerry Kutche n9lya Ampr IP Coordinator Indiana.

1 1

portal.ampr.org
by Daniel Curry 03 Nov '13

03 Nov '13

I would like to see that the portal.ampr.org get shut off until that all co-coordinators and owner, have the ability to changed networks that were submitted. I have a request to change the netmask from a /29 to a /26. All co-coordinators and the owner of the 44 network, for lack of words, are lock out from doing any changes. From my understanding is where the encap.txt file is being generated. 73's 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]

5 4

ON7LR Contest Cam
by Robbie De Lise 01 Nov '13

01 Nov '13

Dr. Om's, We will be running a camserver on http://44.144.10.45/ this weekend for the CQ.WW contest, with camera's in all the shacks of the ON7LR contest station http://www.on7lr.org/ in Lier Belgium The cam server is located at the contest station, where the shacks are connected with a mixture of network cabling and 5ghz wifi links. The contest station itself is linked via a 5ghz wifi link to another node in Antwerp, 20km away, which in turn is linked over 5ghz to the Antwerp Datacenter. Here we link to the fiberbackbone of a commercial ISP and have an ipip tunnel to HamNet in Germany for AMPR connectivity. We also announce this 44 subnet to the internet, so its possible to view these cams over the public internet, even if you are not connected to AMPRnet. I just wanted to share since this is the first time we are doing this over AMPRnet :) 73s Robbie ON4SAX

3 4

SJVBBS W6RAY
by Ray Quinn 29 Oct '13

29 Oct '13

This is a quick message to my forwarding partners that on Sunday, October 27, 2013, the SJVBBS (W6RAY) BBS will be offline for a short time. The BBS will be moved to a Raspberry Pi with two TNC-Pis connected to it. This setup will be located entirely at the repeater site (Park Ridge) instead of via remote. The gateway IP address will remain the same as will the AMPR IP addresses. The setup is currently in testing using a different alias and SSIDs at ground level. If the test is successful, then it will be installed at the repeater site. -- --- 73 de Ray Quinn W6RAY Visalia, CA DM06ih SJVBBS W6RAY 44.2.10.1

11 15

Re: [44net] 44Net Pi rackmount
by Rob Janssen 28 Oct '13

28 Oct '13

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] SJVBBS W6RAY > From: > <sp2lob(a)tlen.pl> > Date: > 10/28/2013 04:03 PM > > To: > "AMPRNet working group" <44net(a)hamradio.ucsd.edu> > > > Brian, > > It's designed to accomodate _two_ Pi's only. > > Best regards. > Tom - sp2lob I investigated this before and there does not seem to be a rack enclosure for a reasonable number (like 4 or 5). Probably the best bet is to get an old HUB or Switch, rip out all the electronics except the power supply, and cut holes to fit the desired number. There are also larger-scale custom made solutions, e.g. here: http://blog.raspberrycolocatie.nl/raspberry-pi-colocation/ I have a colocated Pi there. Rob

1 0

advertised services
by kb9mwr＠gmail.com 28 Oct '13

28 Oct '13

I stumbled into a useful function that the Hamnet/HSMM folks have: http://hsmm-mesh.org/hsmm-mesh-forums/view-postlist/forum-1-general/topic-5… Maybe there is a way to do (code) something similar for the more traditional nodes on the amprnet. Advertising what is out there on a network seems to be a major issue at least in my eyes.

3 3

Galileo
by Brian Rogers 28 Oct '13

28 Oct '13

Has anyone seen one of these yet? http://www.mouser.com/new/Intel/intel-galileo-development-board/?utm_source… Looks like Intel is going after the Pi market with a processor that's half the speed of the Arm in PIs. -- 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.

1 0

Raspberry Pi vs. Beagleboard
by Geoff Joy 28 Oct '13

28 Oct '13

Looking into networking some XBee Pro 900 Zigbee modules into a mesh network on 902-928 MHz. I have the Digi development package and it looks like I will need to either invent a TCP/IP stack for PC thru USB to the Digi XBIB or else host the S3B radio on Raspberry Pi or Beagleboards. What are the groups thoughts on pros/cons on each?

5 9

VE2PKT is back
by Jean Létourneau 25 Oct '13

25 Oct '13

Please if you need, update your ENCAP.TXT, as of this morning, ve2pkt.ampr.org in back using a new gateway address. Thank you. 73 de Jean -- Sysop de: VE2PKT (BBS), VE2PKT-3 (X-NET),VE2PKT-4, VE2RAJ (XRouter) : VE2RCN-1, VE2RDL-1, VE2RGC-1, VE2RVA-1, (The-Net) : VE2PKT-9 (DXCluster), VE2PKT-10 (Winlink Gateway) RF: 147.435 Mhz (1200 Bps) Internet: Telnet xrouter-ve2pkt.dyndns.org port 23 (Network Node) Telnet fbb-ve2pkt.dyndns.org port 6300 (FBB BBS) Telnet ve2pkt.dyndns.org port 9000 (DXCluster) E-Mail: packet: ve2pkt(a)ve2pkt.#qbc.qc.can.noam ampr net: va2om(a)ve2pkt.ampr.org <ve2pkt(a)ve2pkt.ampr.org> Inet: ve2pkt(a)amsat.org or ve2pkt(a)gmail.com

3 2

Re: [44net] Raspberry Pi
by Assi Friedman 23 Oct '13

23 Oct '13

I am not sure that overclocking is relevant to NAND flash. The issue is quality control for the device. NAND cells are simple and the process drives reliability significantly. Vendors pay per quality, which translates to a number of cycles the device will endure. Well known brands demand and get better dies. Overclocking NAND will result in timing violations that will lead to failed commands - but it will not damage the die. This is different from the traditional overclocking to death of CPUs. The order of magnitude of power makes a significant difference. Assi -----Original Message----- From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of Jerry Sent: Tuesday, October 22, 2013 4:11 PM To: 'AMPRNet working group' Subject: Re: [44net] Raspberry Pi (Please trim inclusions from previous messages) _______________________________________________ Hi Demetre. Have you studied the Compatibility list... Some are shown to be a bad choice.. Some Kingston are listed as such. My first two SD cards I got from Fry's Electronics and they were I think, PNY brands. PNY I have found even their USB Sticks are junk.. But the two I got were only $4 ea.. Bad choice for the Pi. One lasted a few weeks the other until I had a sudden power outage about 6 weeks into it. I now have 2 Kingston SDXC Card 128GB Class 10 SDX10V/128GB Running on TWO pi.. Or Pi Squared.. lol One is under heavy abuse.. I have tried experimenting with sudden power outages, and constant read writes on one unit... And it has not suffered any issues.. In Fact I even tried it from -20F to +140F for S&G's They are NOT OVERCLOCKED. The other runs w9hu BBS Linbpq.. What do you use to image the SD card I used to use Windows program WinDisk32 .. I think this is the biggest issue with the Pi SD Cards.. At least I have had no issues with mine since I stopped that practice. Also what are you using that requires an external HUB.. You can also connect a TNC (other serial devices) to the GPiO port instead of the USB. Have you tried a PiTNC yet? Makes good topping.. :) it is the same size and sits atop the Pi. Like Icing!! 73 Jerry N9LYA PS I ll try to get back one the conv server as time permits.. _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

3 2

Re: [44net] Raspberry Pi
by Jerry Kutche 23 Oct '13

23 Oct '13

I have been running a test pi 128gb SD .running for 3 months. No issues with constant abuse... My linbpq pi been running same sd for 6... -----Original Message----- From: "Demetre SV1UY" <demetre.sv1uy(a)gmail.com> Sent: ‎10/‎22/‎2013 5:40 PM To: "AMPRNet working group" <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Raspberry Pi (Please trim inclusions from previous messages) _______________________________________________ Hi all, If we are to use an external harddrive and an external USB Hub, why not get a mini-ITX MBO powered with 12V and a small mini-ITX box? This way we can have a decent CPU which is also low power in electricity not low in computing power (about 30 watts total). I think the RPi is only good in portable apps, but then again the SD Card is a major handicap. It could be good for applications that are not 24/7/365, such as an event where an AMPRnet GATEWAY is desired only for a few hours or maybe a few days max. If you operate the SD Card for more than a few days, it might get destroyed from the constant write of log files, updating databases etc. Can we have a system with no writting on the disk all the time? I'm not sure. 73 de Demetre SV1UY On Wed, Oct 23, 2013 at 12:26 AM, K7VE - John <k7ve(a)k7ve.org> wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Yes, the Pi boots from the SD, but one can put files on an attached drive, > especially swap, database, and logs. With a little configuration one could > probably put everything except the boot configuration on an external drive > and never write to the SD. > > > ------------------------------ > John D. Hays > K7VE > PO Box 1223, Edmonds, WA 98020-1223 > <http://k7ve.org/blog> <http://twitter.com/#!/john_hays> > <http://www.facebook.com/john.d.hays> > > > On Tue, Oct 22, 2013 at 12:05 PM, <sp2lob(a)tlen.pl> wrote: > >> (Please trim inclusions from previous messages) >> ______________________________**_________________ >> SD card is the _must_ for Pi to boot... >> To my knowledge - there is no other choice. >> >> Best regards. >> Tom - sp2lob >> >> ______________________________**___________ >> 44Net mailing list >> 44Net(a)hamradio.ucsd.edu >> http://hamradio.ucsd.edu/**mailman/listinfo/44net<http://hamradio.ucsd.edu/mailman/listinfo/44net> >> http://www.ampr.org/donate.**html <http://www.ampr.org/donate.html> >> >

3 2

Re: [44net] Raspberry Pi
by Assi Friedman 22 Oct '13

22 Oct '13

Don't buy crappy SD cards - i.e. PNY. That is especially true in an application where it's used 24/7 as a solid state drive. Wear leveling in flash is very important and crappy flash won't endure. Assi Kk7kx.ampr.org -----Original Message----- From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu [mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of kb9mwr(a)gmail.com Sent: Tuesday, October 22, 2013 8:59 AM To: 44net(a)hamradio.ucsd.edu Subject: Re: [44net] Raspberry Pi (Please trim inclusions from previous messages) _______________________________________________ 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. _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net http://www.ampr.org/donate.html

9 9

DNS A Records Missing
by lleachii＠aol.com 22 Oct '13

22 Oct '13

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

2 2

Re: [44net] Raspberry Pi
by kb9mwr＠gmail.com 22 Oct '13

22 Oct '13

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.

1 0

Portal
by Brian Rogers 17 Oct '13

17 Oct '13

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.

12 19

net-44 source address spoofing?
by Rob Janssen 15 Oct '13

15 Oct '13

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

3 2

Re: [44net] net-44 source address spoofing?
by Bryan Fields 14 Oct '13

14 Oct '13

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

1 0

Re: [44net] net-44 source address spoofing?
by Rob Janssen 13 Oct '13

13 Oct '13

> 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

2 1

Re: [44net] net-44 source address spoofing?
by lleachii＠aol.com 13 Oct '13

13 Oct '13

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

1 0

Fwd: [nos-bbs] encap.txt
by Don Moore 13 Oct '13

13 Oct '13

---------- 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 > >

2 1

Re: [44net] Announcement: ampr-ripd new version 1.6
by Rob Janssen 11 Oct '13

11 Oct '13

> 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

1 0

Re: [44net] 44Net Digest, Vol 2, Issue 162
by Rob Janssen 10 Oct '13

10 Oct '13

> 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

3 4

Re: [44net] 44Net Digest, Vol 2, Issue 159
by Rob Janssen 08 Oct '13

08 Oct '13

> 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

4 6

Re: [44net] no more 44-net routing through amprgw?
by Rob Janssen 06 Oct '13

06 Oct '13

> 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

1 0

no more 44-net routing through amprgw?
by Rob Janssen 06 Oct '13

06 Oct '13

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

3 2

Re: [44net] 44Net Digest, Vol 2, Issue 159
by Rob Janssen 05 Oct '13

05 Oct '13

> 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

2 1

Re: [44net] 44Net Digest, Vol 2, Issue 156
by Rob Janssen 04 Oct '13

04 Oct '13

> > 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

3 3

Re: [44net] 44Net Digest, Vol 2, Issue 158
by Rob Janssen 04 Oct '13

04 Oct '13

> 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

3 2

Re: [44net] DMZ
by lleachii＠aol.com 04 Oct '13

04 Oct '13

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

3 2

Re: [44net] 44Net Digest, Vol 2, Issue 157
by sp2lob 03 Oct '13

03 Oct '13

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

1 0

Re: [44net] 44Net Digest, Vol 2, Issue 157
by Rob Janssen 03 Oct '13

03 Oct '13

> 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

2 1

RIP question
by Lakenet 03 Oct '13

03 Oct '13

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

2 1

Attempting to contact 4Z4ZQ
by Assi Friedman 02 Oct '13

02 Oct '13

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 :)

1 0

rip44d rp_filter problem fixed
by Heikki Hannikainen 01 Oct '13

01 Oct '13

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

1 0

Re: [44net] How to use my IP 44.xx.xx.xx
by Robbie De Lise 28 Sep '13

28 Sep '13

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:

4 13

community-wide networking discussion group
by Brian Kantor 23 Sep '13

23 Sep '13

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

3 2

Portal
by Brian Rogers 22 Sep '13

22 Sep '13

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.

2 2

DNS
by ian 22 Sep '13

22 Sep '13

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..

1 0

(no subject)
by Robbie De Lise 22 Sep '13

22 Sep '13

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

1 1

TAPR/ARRL DCC 2013
by Brian Kantor 20 Sep '13

20 Sep '13

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

3 2

Att: Chris G1FEF
by Brian Rogers 17 Sep '13

17 Sep '13

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.

3 3

(no subject)
by Robbie De Lise 17 Sep '13

17 Sep '13

on0ck del

2 1

Re: [44net] 44Net Reboot (DNS)
by Rob Janssen 16 Sep '13

16 Sep '13

> 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

9 9

Re: [44net] 44Net Reboot (DNS)
by Rob Janssen 16 Sep '13

16 Sep '13

> 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

2 1

Re: [44net] 44Net Reboot (DNS)
by Rob Janssen 16 Sep '13

16 Sep '13

> 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

1 0

Re: [44net] Reboot (DNS)
by kb9mwr＠gmail.com 16 Sep '13

16 Sep '13

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.

7 8

More fun with DNS
by Blaine Forbort 15 Sep '13

15 Sep '13

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

1 0

How to use my IP 44.xx.xx.xx
by on4hu 15 Sep '13

15 Sep '13

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

1 0

Reboot
by Kutche, Jerry (Mitchell) USA 15 Sep '13

15 Sep '13

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.

5 5

Re: [44net] IP Gateway
by Jerry 13 Sep '13

13 Sep '13

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

3 7

Radio-based networking
by Brian Kantor 11 Sep '13

11 Sep '13

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

13 14

IPV6 Rumors
by Daniel Curry 11 Sep '13

11 Sep '13

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]

6 5

Off Topic.. NOSview
by Jerry 09 Sep '13

09 Sep '13

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

5 6

From Scratch
by Rosalio Salas 08 Sep '13

08 Sep '13

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

4 9

NetScreen NS-25 IPSEC Devices
by William Bressette 07 Sep '13

07 Sep '13

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$

1 0

amprnet routing made simple
by Brian Rogers 07 Sep '13

07 Sep '13

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.

3 5

BGP on commercial ISP lines
by Assi Friedman 07 Sep '13

07 Sep '13

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".

2 1

Re: [44net] 44Net Digest, Vol 2, Issue 139
by Rob Janssen 06 Sep '13

06 Sep '13

> 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

2 1

Routing and encap minor issue in JNOS
by Mark Phillips 05 Sep '13

05 Sep '13

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

4 9

jnos
by Eric Fort 05 Sep '13

05 Sep '13

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

2 2

Something simple
by Rod Ekholm 03 Sep '13

03 Sep '13

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

8 23

Chris Smith G1FEF?
by Brian Kantor 02 Sep '13

02 Sep '13

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

4 3

Re: [44net] ripv2
by Rob Janssen 02 Sep '13

02 Sep '13

> 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

5 5

AMPRNet-config
by Willie Hein WJ3G 02 Sep '13

02 Sep '13

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

1 0

Microtik is Broadcasting
by Michael E. Fox - N6MEF 01 Sep '13

01 Sep '13

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

1 0

Re: [44net] Off Topic.. NOSview
by kb9mwr＠gmail.com 01 Sep '13

01 Sep '13

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.

1 0

rip44d
by Rob Janssen 31 Aug '13

31 Aug '13

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

4 3

Re: [44net] 44Net Digest, rip44d
by Rob Janssen 30 Aug '13

30 Aug '13

> 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

1 0

Anyone tried to use transverters from 2.4GHz to 432 Mhz?
by YT9TP Pedja 29 Aug '13

29 Aug '13

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

1 0

Re: [44net] (no subject)
by kb9mwr＠gmail.com 28 Aug '13

28 Aug '13

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

3 3

Re: [44net] Multiple gateways for same route
by Michael E Fox - N6MEF 27 Aug '13

27 Aug '13

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 >

4 3

Re: [44net] Multiple gateways for same route
by Rob Janssen 27 Aug '13

27 Aug '13

> 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

1 0

Multiple gateways for same route
by Marc, LX1DUC 27 Aug '13

27 Aug '13

-----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-----

9 9

Re: [44net] Routing Tables
by William Lewis 26 Aug '13

26 Aug '13

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

4 5

Re: [44net] ipip tunnel
by lleachii＠aol.com 26 Aug '13

26 Aug '13

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

9 24

Re: [44net] 44Net Routing tables
by Rob Janssen 26 Aug '13

26 Aug '13

> 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

1 0

Re: [44net] 44Net (no subject)
by Rob Janssen 26 Aug '13

26 Aug '13

> 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

2 1

Portal Feature Request
by Neil Johnson 26 Aug '13

26 Aug '13

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

2 1

Routing Tables
by Demetre SV1UY 25 Aug '13

25 Aug '13

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

2 1

FW: RIP from teqsys.net
by Hugh Golding 25 Aug '13

25 Aug '13

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

3 3

Re: [44net] 44Net (no subject)
by Rob Janssen 24 Aug '13

24 Aug '13

> 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

2 1

Dynamic Routing: LISP
by Jim Alles 24 Aug '13

24 Aug '13

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

2 1

(no subject)
by kb9mwr＠gmail.com 24 Aug '13

24 Aug '13

--- 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.

1 0

Re: [44net] Something simple
by Rod Ekholm 23 Aug '13

23 Aug '13

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

2 1

Re: [44net] Who is teqsys.net and why is he sending me RIP?
by Heikki Hannikainen 22 Aug '13

22 Aug '13

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

1 0

Re: [44net] Radio-based networking
by Paul Delaney - K6HR 21 Aug '13

21 Aug '13

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

1 0

Re: [44net] Radio-based networking
by Paul Delaney - K6HR 21 Aug '13

21 Aug '13

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

1 0

Re: [44net] Radio-based networking
by kb9mwr＠gmail.com 21 Aug '13

21 Aug '13

------ 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.

1 0

Re: [44net] Radio-based networking
by Brian Rogers 21 Aug '13

21 Aug '13

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.

1 0

Re: [44net] Something simple
by kb9mwr＠gmail.com 20 Aug '13

20 Aug '13

>> 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

1 0

IP Protocol 4 in DD-WRT and rip44d script
by Demetre SV1UY 20 Aug '13

20 Aug '13

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

8 21

Re: [44net] Something simple
by kb9mwr＠gmail.com 20 Aug '13

20 Aug '13

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

2 1

re: Something simple
by Rod Ekholm 20 Aug '13

20 Aug '13

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

1 0

Re: [44net] Something simple
by kb9mwr＠gmail.com 20 Aug '13

20 Aug '13

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.

1 0

Who is teqsys.net and why is he sending me RIP?
by Mark Phillips 18 Aug '13

18 Aug '13

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

4 4

Dynamic IP Gateway problem.
by Demetre SV1UY 17 Aug '13

17 Aug '13

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 20

Portal DNS requests
by Blaine Forbort 16 Aug '13

16 Aug '13

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

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net