- 44net - mailman.ardc.net

rip44d
by lleachii＠aol.com 17 Feb '14

17 Feb '14

Marius, Are you still maintaining perl based rip44d software? -Lynwood KB3VWG

3 6

Re: [44net] annual reminders
by William Lewis 15 Feb '14

15 Feb '14

Brian / Chris: I take some of that back..... Upon further testing, if I edit someone's region description, the portal tells me it saved it. But when I go back into the record, it is *not saved* at all. So, bug report of a different nature. Thanks Bill Lewis / KG6BAJ

5 5

Cisco IOS Example?
by Phil Pacier - AD6NH 15 Feb '14

15 Feb '14

Good day all. Does anyone have a rough example of a 44Net tunnel setup for Cisco IOS? I only have a /32 to play with and would like to put it on the WAN router. Thanks! -- Phillip Pacier - AD6NH APRS Tier2 Network Coordinator --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

1 0

Re: [44net] ampr-ripd 1.9 released
by Rob Janssen 13 Feb '14

13 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] ampr-ripd 1.9 released > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 02/13/2014 05:14 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello OMs, > > Latest update, with improvements (again) sugested by Rob Jannsen (PE1CHL) - > tnx. Rob. > > - added option to adjust TCP window size on routes > - console is now detaching on daemon startup It works well, thank you! Rob

1 0

Re: [44net] ampr-ripd 1.8 released
by Rob Janssen 12 Feb '14

12 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] ampr-ripd 1.8 released > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 02/12/2014 06:15 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Rob, > > -w is a good idea and I will implement it. > > Regarding the daemon function, AFAIK it is not available on all systems and > does not have a standardized behavior. > I wrote the code as portable as possible (e.g. static memory allocations, > minimal needed libraries). > Since the only action on the parent is exit(), I don't think that waiting > time is relevant. > > Thank you for your input. > > Marius, YO2LOJ Ok. I think daemon is available on many Unix/Linux-like platforms. However, it is not a very complicated function. What you wrote in ampr-ripd is nearly the same, except for that daemon() closes stdin, stdout and stderr when going to daemon mode. At least on a debian system, when ampr-ripd is started from a shell script under /etc/init.d, and when it does not close the controlling tty, init keeps a process running (startpar) that waits until it does that. I think that is part of the logic that prints the OK or FAIL messages in the init procedure. So, you could add some fclose or close calls in that part of the code. (only when verbose=0) I used the following workaround before I discovered daemon(): ampr-ripd -options </dev/null >/dev/null 2>&1 Rob

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 34
by Rob Janssen 12 Feb '14

12 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] 44Net Digest, Vol 3, Issue 33 > From: > Steve Wright <stevewrightnz(a)gmail.com> > Date: > 02/11/2014 11:41 PM > > To: > 44net(a)hamradio.ucsd.edu > > >> > >> > >> > Any connects from ports >> >below 1024 are highly suspect for being reflection attacks so above I >> >block them all. > Another good trick is to block all outgoing connects to port 80 - this > makes it quite inconvenient for a virus to download its payload. In fact, > block all outgoing connects, and allow only what YOU want to do. Well, I do have that on the webserver at work. What those injection-attacks on PHP programs often do is include something that is fetched from a remote webserver. As the webserver cannot make outgoing connects, this always fails. However, for a typical hamradio computer that serves both as a server and a client, blocking outgoing port 80 is a bit unpractical. The attack is still/again going on, this time with source port 119: 21:49:23.716879 216.18.208.109 -> 44.137.41.97 TCP 52 nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:24.514385 216.18.208.109 -> 44.137.41.101 TCP 52 nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:24.819003 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:25.914034 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:25.927587 216.18.208.109 -> 44.137.41.101 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:27.009032 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:27.349359 216.18.208.109 -> 44.137.41.101 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:28.106015 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 Rob

1 0

ampr-ripd 1.8 released
by Marius Petrescu 12 Feb '14

12 Feb '14

Hello OMs, Another addition and a new version. Added support for setting a specific route metric for the created routes using the -m option (regular routes until now had metric 0). This allows routes from other sources, e.g. BGP or OSPF to take precedence over those created by ampr-ripd. For those not needing "fancy" routing, there's no need to upgrade. Download from http://www.yo2loj.ro/hamprojects/ or http://yo2tm.ampr.org/hamprojects/ (as usual), or get it via github: https://github.com/yo2loj/ampr-ripd/ Direct links: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.8.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.8.tgz Have fun, Marius, YO2LOJ

2 2

Re: [44net] ampr-ripd 1.8 released
by Rob Janssen 12 Feb '14

12 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] ampr-ripd 1.8 released > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 02/11/2014 06:00 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello OMs, > > Another addition and a new version. > > Added support for setting a specific route metric for the created routes > using the -m option (regular routes until now had metric 0). > This allows routes from other sources, e.g. BGP or OSPF to take precedence > over those created by ampr-ripd. When you make another version, consider: - a -w option to set the window (now fixed at 840), setting 0 means no window setting. - in the section to become a daemon, make use of the daemon() function. e.g.: if (FALSE == debug) { if (daemon(0,verbose)<0) { PERROR("Can not become a daemon"); } } The advantage is that the program detaches from the terminal, which is required when you want to start it in a /etc/init.d script and do not want to keep init waiting for the program. Rob

2 1

Re: [44net] 44Net Digest, Vol 3, Issue 33
by Steve Wright 11 Feb '14

11 Feb '14

> > > Any connects from ports > below 1024 are highly suspect for being reflection attacks so above I > block them all. Another good trick is to block all outgoing connects to port 80 - this makes it quite inconvenient for a virus to download its payload. In fact, block all outgoing connects, and allow only what YOU want to do.

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 32
by Rob Janssen 10 Feb '14

10 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] 44Net Digest, Vol 3, Issue 31 > From: > John Ronan <jpronans(a)gmail.com> > Date: > 02/10/2014 10:01 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hi Rob/all, > Well as long as it wasn't just me the packets were hitting, I'm happier :). I guess your 'firewall' is a chain you created yourself? Either that or my iptables/kernel is quite a bit older than yours. > > Thats a nice/handy ruleset actually, thanks for the reply. > > Oh, apologies for my slowness in replying, birthday party (my own) Saturday meant I was recovering yesterday. > > Regards > John > EI7IG Yes, "firewall" is a chain that is joined to the INPUT chain for some of the traffic. In a typical Linux tunneling server you first separate the raw input and the tunnel input, and then deal with that in separate chains. In my tunnel router I have 4 of them, one for internet traffic to the public IP address, one for traffic destined to the 44-net address of the router, one for 44-net traffic routed thu to systems behind my router, and one for traffic destined to my locally running copy of NETCHL (most others would use JNOS there). It gets kind of difficult to handle all of that in one INPUT chain. So my INPUT chain is built like this: iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -i eth0 -d 111.222.333.444 -j firewall iptables -A INPUT -i tunl0 -j firewall2 etc, and similar for the FORWARD chain. BTW, the "attack" on http (which probably was not sourced from the addresses in the packets, but was rather meant to be a reflection attack on some other party) continued through today and ended a few hours ago. The second example that I posted became the main attack later, and I added another rule below the first line in my example: iptables -A firewall -p tcp -m multiport --sport 0:1023 --syn -j DROP This blocks any incoming connects that are coming FROM port numbers below 1024. Those do not occur in normal practice. Port numbers below 1024 are "special" ports for protected system services and normally are never the source port for connects. Any connects from ports below 1024 are highly suspect for being reflection attacks so above I block them all. Rob

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 31
by Rob Janssen 10 Feb '14

10 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] incoming traffic. > From: > John Ronan <jpronans(a)gmail.com> > Date: > 02/09/2014 05:10 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hi All, > > I've seeing continuous traffic coming in from amprgw.sysnet.ucsd.edu. from 5.135.135.42 to 44.155.6.1 port 80 over my tunnel. Anyone else seeing the same? > > > I've disabled my tunnel for the moment as I don't have the time at the moment to chase it down. > > Regards > John > EI7IG It is not specifically from that address. It appears to be a distributed attack on http servers, at least to network 44. I see the same incoming stream of connects to several hosts in my subnet, all from a different source IP. Sometimes after several hours it stops and starts from another IP. I have crafted iptables rules that block it effectively: iptables -A firewall -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A firewall -p tcp --syn -m recent --name tcp --set iptables -A firewall -p tcp --syn -m recent --name tcp --update --seconds 30 --hitcount 15 -j DROP iptables -A firewall -p tcp --dport 80 --syn -j ACCEPT iptables -A firewall -p tcp --dport 443 --syn -j ACCEPT iptables -A firewall -p tcp -j DROP It just drops any source IP that sends more than 15 connects in 30 seconds. Adjust for the port numbers that you want to accept (80 and 443 in this example) There is also an internet-wide scan from source address 64.78.174.63 with traffic like this: 21:04:33.762663 64.78.174.63 -> 44.137.40.2 TCP 52 [TCP Port numbers reused] http > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 I see it on another server outside net-44 as well. It is blocked by the same rule but I have just firewalled the entire 64.78.160.0/20 net as this does not look like someone I want to deal with. Rob

2 1

Reg Exp
by William Lewis 10 Feb '14

10 Feb '14

BTW.... Anybody in the group good at formulating REGEX expressions ? If so, contact me off-list. kg6baj(a)n1oes.org Thanks Bill

1 0

Mail Hacker
by William Lewis 10 Feb '14

10 Feb '14

Thanks to all that replied. Got the iptables to forward the connects to my linux side where the commercial postfix server is running. Postfix doing what it's supposed to and killing it all if it's not a user on my box. Again, thank you to all who gave suggestions. Bill KG6BAJ

1 0

incoming traffic.
by John Ronan 10 Feb '14

10 Feb '14

Hi All, I've seeing continuous traffic coming in from amprgw.sysnet.ucsd.edu. from 5.135.135.42 to 44.155.6.1 port 80 over my tunnel. Anyone else seeing the same? I've disabled my tunnel for the moment as I don't have the time at the moment to chase it down. Regards John EI7IG

6 7

Re: [44net] Mail hacker
by kb9mwr＠gmail.com 09 Feb '14

09 Feb '14

Part of the beauty of our own IP address space is security provided by knowing your neighbors. I'd never run an open SIP or mail server on the wide internet anymore. Spam filtering is a big headache. Again, I'd firewall everyone but us for the mail port: iptables -A INPUT -s ! 44.0.0.0/8 -p tcp --dport 25 -j DROP If you have a google apps account (free for non profits) you can use them as a mail exchanger. Set your DNS records, to something like this: gvcity.ampr.org MX 10 gvcity gvcity.ampr.org MX 20 aspmx.l.google.com Outside (non 44 net) IP will timeout with a direct connect to 44.2.14.1 and will move try the next exchanger preference, in this case google. Google will accept the mail on your behalf, and they have good spam filtering (better than I could ever figure out how to incorporate with sendmail) and then I typically use fetchmail to transfer the mail from google back into my local mailboxes. If someone else wants to document a mailserver setup with spam protection, I'm all eyeballs on that one. I'm sure a number of people would appreciate that tutorial.

1 0

Re: [44net] Mail Hacker
by kb9mwr＠gmail.com 09 Feb '14

09 Feb '14

Here is what I'd do. Only allow 44 net to talk to the mail host directly: iptables -A INPUT -s ! 44.0.0.0/8 -p tcp --dport 25 -j DROP Set a MX record and set up an exchanger for any external mail you need to deal with.

1 0

Re: [44net] Mail Hacker
by Michael E Fox - N6MEF 09 Feb '14

09 Feb '14

What we do is run all inbound and outbound email to/from the Internet through a mail gateway. Then the gateway can implement all of the modern spam avoidance functions, including even which specific user addresses will be relayed. Michael N6MEF Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: William Lewis <kg6baj(a)n1oes.org> Date:02/09/2014 11:54 AM (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: [44net] Mail Hacker (Please trim inclusions from previous messages) _______________________________________________ Hello group: Need some collective help here on a mail system hacker issue I've been having. First, the IP address on my system he's coming in on is 44.2.14.1 This person is dumping thousands of random emails into my system and some of them will match BBS AREA patterns and get forwarded out to my forward partners. At first, I set up a log book scan script to look for bad logins, and then ban the IP address, but then I found out that since my 44.2.14.1 ip address goes "around" my firewall via UCSD, the block rules literally have zero effect. I found a common "from" (online...@....) line in his emails, so in my "rewrite" file I used this command "onl*@* | *@* refuse" but that also had zero effect. Then I tried telling JNOS "stop smtp" and "stop pop3" and that had zero effect. JNOS's email system uses very old RFC rules, and none of the modern RFC rules, so it's easy for this hacker to login to my JNOS mail server and dump this junk. Luckily most get held, but as stated, a few match forward patterns, so they slip through. Right now I've completely taken my JNOS off-line until a fix can be found. Anyone have some suggestions on blocking smtp and pop3 when my 44.2.14.1 address is live to global net ? Any advise is appreciated in advance. Thanks Bill KG6BAJ

1 0

Re: [44net] Portal Down ?
by William Lewis 09 Feb '14

09 Feb '14

Chris: I'm wondering if the index page issue only effects "Coordinators" ?? I've seen some postings here that some are logging in and all is ok. But the index page is suppose to show the extra "coordinator" link that non-coordinators don't see when they login. Here is the total source code my browsers get "after" logging in. ========================================================================= <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content="text/html; charset=utf-8" http-equiv=Content-Type></HEAD> <BODY></BODY></HTML> ========================================================================= That's it. That's all that comes through. Hope that helps. Bill At 02:56 AM 2/8/2014, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >Hit your refresh button, probably cached from a previous visit ;-)

6 14

Portal Down ?
by Neil Johnson 08 Feb '14

08 Feb '14

After I login I just get a blank screen. -Neil -- Neil Johnson http://erudicon.com

12 14

annual reminders
by Brian Kantor 08 Feb '14

08 Feb '14

The first batch of annual portal email reminders just went out; there were 60 folks who haven't logged in to the portal in over a year. These reminders are currently scheduled to go out monthly. Starting this July, I think we'll consider someone inactive after 18 months of no login. (That's six reminders, so they can't say they weren't warned.) Be sure to keep the portal up to date if you change your email or other contact data to avoid having problems. Please remember that current registration with the portal is necessary to maintain allocations, gateway registration in the encap database, and other functions of the portal. It's especially important for coordinators to keep it up to date. Thanks! - Brian

4 4

Re: [44net] Portal Down ?
by William Lewis 08 Feb '14

08 Feb '14

It looks like the INDEX template has an error. If you login, go ahead and get the blank screen, and then manually type in the url: https://portal.ampr.org/gateways_index.php you will see what you're suppose to. So.... Looks like a hiccup in the index file. (but just my $0.02 worth) Bill KG6BAJ

4 4

schema for portal backend database
by Eric Fort 08 Feb '14

08 Feb '14

Could someone provide the existing schema for the portal back end database. I'm taking a database class as well as a web programming class and would like to study it as it presently exists. Eric AF6EP

1 0

Re: [44net] Portal Down ?
by William Lewis 08 Feb '14

08 Feb '14

Same here.. Bill KG6BAJ At 07:45 PM 2/7/2014, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >After I login I just get a blank screen. > >-Neil > >-- >Neil Johnson >http://erudicon.com >_________________________________________ >44Net mailing list >44Net(a)hamradio.ucsd.edu >http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Apologies for my absence
by VK4AA | VK4TTT Sam 07 Feb '14

07 Feb '14

Hey Guys Apologies for my abscence and if there has been any reqests for space in 44.136.0.0/16. We moved and waiting for someone to leave or be disconnected so we can geta DSL port. We are living in the world of 3g/4g and it is not really that crash hot for a perm connection. We have been advised that they are about to do an upgrade to be told oh we did that last december. Anyway hope to be back online soon Samantha vk4aa|vk4ttt

1 0

Hacking from IP Address 178.33.151.117
by William Lewis 05 Feb '14

05 Feb '14

Just a heads up to the 44 Group who run 44 addressed mail servers. Over the last few days I've had someone trying to break into my mail server. After installing more detection software, I came up with IP Address 178.33.151.117. Just a heads up he's probably scanning the network looking for others, so heads up everyone. Bill / KG6BAJ ========================================== AUTOMATED NOTIFICATION ! The IP 178.33.151.117 has just been banned after several attempts against dovecot. Here are more information about 178.33.151.117: % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '178.33.151.112 - 178.33.151.127' % Abuse contact for '178.33.151.112 - 178.33.151.127' is 'abuse(a)ovh.net' inetnum: 178.33.151.112 - 178.33.151.127 netname: DVC-ITA descr: DoveConviene.it Italian Network country: IT org: ORG-OS43-RIPE admin-c: OTC5-RIPE tech-c: OTC5-RIPE status: ASSIGNED PA mnt-by: OVH-MNT source: RIPE # Filtered organisation: ORG-OS43-RIPE org-name: OVH Srl org-type: OTHER address: Via trieste 25 address: 20097 San Donato Milanese address: Italia abuse-mailbox: abuse(a)ovh.net mnt-ref: OVH-MNT mnt-by: OVH-MNT source: RIPE # Filtered role: OVH IT Technical Contact address: OVH Srl address: Via trieste 25 address: 20097 San Donato Milanese address: Italia admin-c: OK217-RIPE tech-c: GM84-RIPE nic-hdl: OTC5-RIPE abuse-mailbox: abuse(a)ovh.net mnt-by: OVH-MNT source: RIPE # Filtered % Information related to '178.32.0.0/15AS16276' route: 178.32.0.0/15 descr: OVH ISP descr: Paris, France origin: AS16276 mnt-by: OVH-MNT source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.71 (WHOIS1) Lines containing IP:178.33.151.117 in /var/log/mail.log Feb 5 04:15:37 linux1 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=<test(a)ampr.org>, method=PLAIN, rip=178.33.151.117, lip=44.2.14.2 Feb 5 04:17:23 linux1 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=<test(a)ampr.org>, method=PLAIN, rip=178.33.151.117, lip=44.2.14.2 Feb 5 04:17:41 linux1 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=<test(a)ampr.org>, method=PLAIN, rip=178.33.151.117, lip=44.2.14.2 ...... <snip>

3 2

Re: [44net] Hacking from IP Address 178.33.151.117
by William Lewis 05 Feb '14

05 Feb '14

I suspect. I noted he was smart enough to trace the 44.2.14.1 to "gvcity.ampr.org" and then try to access with ".....(a)ampr.org" At 10:11 AM 2/5/2014, you wrote: >(Please trim inclusions from previous messages) >_______________________________________________ >looks like someones box has been hacked it is a shopping site in Italy. > >Lin

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 25
by Steve Wright 02 Feb '14

02 Feb '14

> > > Although I have finally pulled some strings for commercial tower space > come spring. Good work! > Without one end up high (above the average 100 foot > trees), No. If you have 100 foot trees, you can't run long distance outdoor 802.11 > you need amplifiers to go anywhere, or a MESH node every > couple miles? > No, and no. So far I have not done anything with Mesh, and it sort of makes sense > for the distance/propagation delima.. Till I think, wait a second, > 802.11 is still half duplex, so when you make a (metric) hop using a > mesh topology, aren't you effectively cutting your bandwidth in half? > And in half again, and again with each new node. So there is more to this than throw a bunch of nodes out there. > (bandwidth and hidden transmitter stuff), there is just no easy way > around a decently designed network.. backbones! Then there is the oh, > well we want to expand the network this way (something not in the > original plan), and how to make the subnet and routes all work, short > of re-addressing everything. > You got it in one! Please someone please package this text inside something nice and solid, like a baseball bat, so we can whack the next person with who has this idea. > I watched the HamWAN DCC video.. and I have often thought about 5 GHz > Mikrotik Groove as they way I'd go if I were to invest in equipment > again. No, stick with multi-chain polling stuff, like the MIMO AirMAX, and get 200mbit plus symbol rates, and solid 90mbit ACTUAL throughput. > More so, if bouncing off say a water tower actually is doable. > No, stick with nice clear line-of-sight paths for infrastructure. By all means, play with things as an experiment, but puhleeeaze don't hide such a catastrophe inside a seemingly functional network, or you will bring the rest of the network to its' knees. > Whoever has IP 44.12.3.97, please stop sending UDP 5678 to 255.255.255.255. > I'm getting this every single minute. > Hehe, a single UDP every minute.. If that was over the old 1200 digipeated network it'd DDOS the entire network! lol >

1 0

Mikrotik RouterOS 6.9 bug
by Marius Petrescu 02 Feb '14

02 Feb '14

For those who use Mikrotik routers, please be aware that there is a possible bug with route marks in the latest firmware (6.9). So stay put on 6.7 until this is clarified/solved. 73 de Marius, YO2LOJ

1 0

44.12.3.97 please stop UDP 5678
by Michael E Fox - N6MEF 02 Feb '14

02 Feb '14

Whoever has IP 44.12.3.97, please stop sending UDP 5678 to 255.255.255.255. I'm getting this every single minute. Thanks, Michael N6MEF

7 8

Re: [44net] 44Net Digest, Vol 3, Issue 24
by Steve Wright 02 Feb '14

02 Feb '14

> > Yes. Amateur RF is synonymous with low bandwidth. We have unique > capabilities but it's with low bandwidth like 1200 baud, 9600 baud, > 100K ID1's and hopefully soon UDRX at 56K+. > > BBHN (Broadband hamnet, was HSMM) is generally more interested with > connectivity than performance. Unfortunately too many experimenters > there are new and not familiar with the lessons of 145.01 or 144.39... > Even implemented with good RF design the MESH ad-hoc based system has > compromises. I tried streaming the next episode of Torchwood from > Amazon a couple nights ago and my NW-MESH (based on HSMM-MESH) home > system wouldn't do it. I don't think that's even HD. :( > Precisely. I think it is fine for radio hams to experiment with attaching some cool new experimental toy to the backbone, for whatever they want to do with it! Play with it and and have fun - that's what any hobby is for, and ham radio not the least.. But people really need to remember old the days of digipeaters on a single simplex frequency and make sure we don't return there, or at the very least Ubiquiti M2/M3/M5 dual-chain AirMax nanobridges et al running on the ham bands are the new jesus. Steve

2 1

Re: [44net] 44Net Digest, Vol 3, Issue 24
by kb9mwr＠gmail.com 01 Feb '14

01 Feb '14

> Message: 1 > Date: Fri, 31 Jan 2014 15:33:41 -0800 > From: Bill Vodall <wa7nwp(a)gmail.com> > To: AMPRNet working group <44net(a)hamradio.ucsd.edu> > Subject: Re: [44net] 44Net Digest, Vol 3, Issue 19 <snip> > BBHN (Broadband hamnet, was HSMM) is generally more interested with > connectivity than performance. Unfortunately too many experimenters > there are new and not familiar with the lessons of 145.01 or 144.39... > Even implemented with good RF design the MESH ad-hoc based system has > compromises. I tried streaming the next episode of Torchwood from > Amazon a couple nights ago and my NW-MESH (based on HSMM-MESH) home > system wouldn't do it. I don't think that's even HD. :( Here in Green Bay, WI a few of us have been messing with point to point 802.11 since 1999. Sadly there isn't enough interest (mostly due to the average ham club members age I suspect), for it to advance much beyond that... so far. Although I have finally pulled some strings for commercial tower space come spring. Without one end up high (above the average 100 foot trees), you need amplifiers to go anywhere, or a MESH node every couple miles? So far I have not done anything with Mesh, and it sort of makes sense for the distance/propagation delima.. Till I think, wait a second, 802.11 is still half duplex, so when you make a (metric) hop using a mesh topology, aren't you effectively cutting your bandwidth in half? So there is more to this than throw a bunch of nodes out there. (bandwidth and hidden transmitter stuff), there is just no easy way around a decently designed network.. backbones! Then there is the oh, well we want to expand the network this way (something not in the original plan), and how to make the subnet and routes all work, short of re-addressing everything. I watched the HamWAN DCC video.. and I have often thought about 5 GHz Mikrotik Groove as they way I'd go if I were to invest in equipment again. More so, if bouncing off say a water tower actually is doable. Steve, KB9MWR

1 0

Re: [44net] Updated BGP design (was 44Net Digest, Vol 3, Issue 20)
by Bryan Fields 01 Feb '14

01 Feb '14

On 1/29/14 2:05 PM, Steve Wright wrote: > This mesh crap really needs to be binned, or at the very least not try and > do anything important over it, such as route an entire /16. If you want to > connect a /24 with it to make a neat local play toy then go for it, but > using it as an enterprise routing tool is absurd at the very least, and at > it's WORST, it's very likely to just completely stop anyone from trying to > build anything new over it because it's connectivity and throughput sucks. This. So this is how I'd see it work, I need to write up a proposal for it. You have regional BGP routers that route subnets to the internet. These could then tunnel the subnets to end users via GRE. End users could route via an IGP over this tunnel to the regional speaker(s). Multiple tunnels would give redundancy. The regional speakers would have a tunnel between them. In the event of an outage the other BGP speakers would route subnets. Multiple links from end users to other BGP speakers (or non-speakers that are aggravation routers) would provide redundancy to the end users. Of course nothing prevents having a direct BGP speaker with an RF link to end users, most data centers will not have roof rights however. We could setup redistribution that would pull announcements from BGP if end nodes went down. Each BGP speaker could announce the subnets it knows about and a /8 providing we have a mesh of the backbone bgp speakers. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

10 13

Re: [44net] DNS records 44.131.56.0/24
by Michael E Fox - N6MEF 01 Feb '14

01 Feb '14

We've had a year of people putting things in, only to be told it isn't live yet. Damped annoying. If the thing is not live and if any entries made now will not be put in, then please, please take the darn link off the website until it IS ready. Michael Sent from my Verizon Wireless 4G LTE smartphone -------- Original message -------- From: Chris <chris(a)g1fef.co.uk> Date:01/20/2014 12:49 PM (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] DNS records 44.131.56.0/24 (Please trim inclusions from previous messages) _______________________________________________ Basically, the DNS portion of the portal is ready and awaiting deployment, we are implementing an email robot to run alongside, much the same as we did for the gateway robot, once it is completed and tested the whole thing can be deployed. The email robot should be ready in about a week. When it is deployed we will announce the fact on this list at which point any new requests will be processed, any requests sent in prior to the deployment will not be processed. Regards, Chris > On 20 Jan 2014, at 20:34, Nick G4IRX <g4irx.44net(a)nowindows.net> wrote: > > (Please trim inclusions from previous messages) > _______________________________________________ > Thanks for clarifying Chris. Presumably my requests will sit there until it becomes active? > > Nick. > >> On 20/01/2014 20:20, Chris wrote: >> (Please trim inclusions from previous messages) >> _______________________________________________ >> The DNS section of the portal is not active yet > > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

2 1

[nos-bbs] strange udp broadcasts...
by Nigel Vander Houwen 31 Jan '14

31 Jan '14

First, apologies for this email not being a valid reply. Finally got around to getting on the mailing list, so I haven't gotten the previous thread to reply to. I've adjusted our scripting that generates our AMPR tunnels on the HamWAN edge routers to disable neighbor discovery for those interfaces, and the change should now be in effect. Thanks, Nigel K7NVH

4 4

Re: [44net] [nos-bbs] strange udp broadcasts...
by Don Moore 30 Jan '14

30 Jan '14

I too am getting this and have been for a few weeks now but initiated by a different address... 07:04:00.406011 IP 209.189.196.68 > 192.168.1.150: IP 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 119 (ipip-proto-4) 07:05:00.408246 IP 209.189.196.68 > 192.168.1.150: IP 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 119 (ipip-proto-4) 73, Don On Thu, Jan 30, 2014 at 12:49 AM, Jerome Schatten <romers(a)shaw.ca> wrote: > 44ers... > > So every minute of every hour of every day, I get this below; it started > several weeks ago. It looks like it's coming from the Ampr portal -- why? > 24.84.205.232 is indeed my ip and it seems that 209.84.205.232 is the > same ip as the rip broadcasts are coming from. Is there any way to turn > this off other than turning off rip? > > Wed Jan 29 21:35:27 2014 - tun0 recv: > IP: len 167 209.189.196.68->192.168.1.149 ihl 20 ttl 55 DF prot IP > IP: len 147 0.0.0.0->255.255.255.255 ihl 20 ttl 64 prot UDP > UDP: len 127 5678->5678 Data 119 > 0000 ..1.....Seattle-ER1....6.7....MikroTik............FLNH-GLS0....R > 0040 B2011UAS......................T......ampr-24.84.205.232 > (encap) 0.0.0.0->255.255.255.255 UDP > 0000 ..1.....Seattle-ER1....6.7....MikroTik............FLNH-GLS0....R > 0040 B2011UAS......................T......ampr-24.84.205.232 > > jerome - ve7ass > > _______________________________________________ > nos-bbs mailing list > nos-bbs(a)tapr.org > http://www.tapr.org/mailman/listinfo/nos-bbs >

6 7

Getting mikrotik router gateway connected to amprgw
by Ryan Elliott Turner 30 Jan '14

30 Jan '14

Hi list, I'm trying to get a mikrotik RB2011 connected to AMPRGW but not having success. /ip route check 44.0.0.1 status: ok interface: ampr-gw nexthop: 44.0.0.1 /tool traceroute 44.0.0.1 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 44.34.128.1 0% 2 0.5ms 0.5 0.5 0.5 0 host unreachable from 44.34.128.1 2 0% 0 0ms Using the sniffer, I've tried to also ping my address (44.34.128.1) from the outside, but it does not get through. In addition, pinging 44.0.0.1 from the router fails as well (tracert shown above). I do however see a discovery attempt going out and not getting any response back. /tool sniffer quick interface=ampr-gw INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE ampr-gw 33.3 1 -> 44.34.128.1:5678 (discovery) 255.255.255.255:5678 (discovery) ip:udp 114 I do have an IPIP interface to the edge router for 44.24.240.0/20, and that is operating properly; I can access their network, and they can access mine. So, I'm a bit puzzled by this. My config amprgw: /interface ipip add local-address=99.173.137.24 name=ampr-gw remote-address=169.228.66.251 /ip route add distance=1 dst-address=44.0.0.0/8 gateway=ampr-gw Any help is greatly appreciated! -- Ryan Turner

3 8

Re: [44net] Updated BGP design (was 44Net Digest, Vol 3, Issue 20)
by Bryan Fields 30 Jan '14

30 Jan '14

On 1/30/14 12:47 AM, Heikki Hannikainen wrote: > As I understand it, currently all BGP sites must have an IPIP gateway too > to enable connectivity with all the rest of the non-BGP sites. This, i've got it going, but requiring a mesh of tunnels is nasty and it's hard to maintain (absent custom protocols) As it stands now, my BGP space can talk to the rest of the internet, but no other 44/8 (excluding the 9 BGP subnets). I'd love to write up an draft proposal for AMPRnet on how to fix this, but I just don't have the time right now. I'd want it as a standard that works on all routers at least for the "core". Perhaps even a route reflector software would work (ALU/CSCO/JNPR have this now). Even foundcade would work, the MLX's don't shit the bed anymore :) Mikrotik is not something you can put in a CO/datacenter for obvious reasons. I'd love to say we need a custom protocol, but the chances of getting that supported on anything production grade is slim to none. Argh, I'll have to make time to do this. I travel about 75% of the time for work, it sucks. I'm a bit hungover in an airport now even :) 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 20
by Steve Wright 29 Jan '14

29 Jan '14

With the BPG routed system, the > gateway is another weak link in the routing chain. What happens if > the BPG gateway goes down - every station down stream is isolated. > Yes thats correct. Why do you think an unreliable gateway is the proper way to build a network? If that subnet needs failover, then add failover. This is a volunteer effort, with > distributed network design and management. > No, it's a volunteer effort that's broken, because everyone wants to over-engineer some new unduly-complicated idea into a very uncomplicated system that actually works REALLY WELL EVERYWHERE else.. > What we have now, with IPIP Encap (protocol 4) is a FULLY MESHED > network. How much better can you get than a network that speaks DIRECTLY > gateway to gateway with NO intermediate hops??? Isn't this one of the > benefits of HSMM-Mesh in that any node that has a path to another node can > continue to pass traffic when other nodes have failed? > > This mesh crap really needs to be binned, or at the very least not try and do anything important over it, such as route an entire /16. If you want to connect a /24 with it to make a neat local play toy then go for it, but using it as an enterprise routing tool is absurd at the very least, and at it's WORST, it's very likely to just completely stop anyone from trying to build anything new over it because it's connectivity and throughput sucks. It's just a subnet for gods sake - stop playing with it and route the shit already, then we might actually get to DO SOMETHING over it. Puhleeease.. >

1 0

amprnet portal
by Eric Fort 28 Jan '14

28 Jan '14

is there a written spec for exactly what the amprnet portal needs to do and keep track of? Might it be available for review and reading? Thanks, Eric Fort AF6EP

3 2

Newmembers
by Jerry 27 Jan '14

27 Jan '14

I forget how does someone join NET 44 working group.. Sorry.. Thanks 73 jerry

1 1

Re: [44net] amprnet portal
by kb9mwr＠gmail.com 27 Jan '14

27 Jan '14

Brian, Interesting, thanks for sharing. Amplifiers are something I really think the ham community needs to think about. They exist, but like you say, but at outrageous prices. i.e.: http://www.shireeninc.com/300-500mhz-20-watts-outdoor-amplifier/ I have been reading Dubus magazine (focused on microwave), hoping to read more data oriented construction articles. I am much in the same line of thinking. 1200 and 9600 is really not worth re-deploying in 2014. The regulatory landscape needs some major changes so that manufactures can put something different in the hands of many. Steve

1 0

Re: [44net] amprnet portal
by Bryan Fields 26 Jan '14

26 Jan '14

On 1/26/14 2:20 PM, kb9mwr(a)gmail.com wrote: > It would be interesting to hear more about how those other BGP > announced chunks of 44net are using the space. My segment 44.98.254.0/24 is being used for one PtP data link now, and some asterisk based repeater controllers. I have email for kb9mci.net on it (but need to get SWIP/PTR going Brian ;). My intent is to fire up some of the doodle labs 23cm link cards as we get another repeater site and link it over on that space. As this grows over the next couple years it will be quite a high speed data network with VoIP as the primary purpose. Doing all the RF links in the ham bands is part of the fun. (anyone have a OFDM rated 20-30 watt amp for 23cm that's not $2k?) One of the pet peeves I've have is not being able to access the other AMPR net space with out tunnels. I think tunnels are just an ugly hack IMO. I'd like to see us transition into more of a regionally routed network, rather than the few BGP nets and UCSD gateway. Well aware of how much time this would take I'm not ready to write up a proposal just yet (ampRFC?). If anyone wants a subnet I'd be happy to route it to you, as I'm not using the whole /24 and won't be for some time. Global routing policies being what they are, a /24 is the smallest subnet you can announce. My interest lies in high speed networks, and see little to no value in 9600 baud IP networks in 2014 :) 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] amprnet portal
by kb9mwr＠gmail.com 26 Jan '14

26 Jan '14

Along the same lines, I have been wondering: Will the portal design/code be available for other regional BGP enabled 44net gateways to implement? It would be interesting to hear more about how those other BGP announced chunks of 44net are using the space.

1 0

Are there (still) issues with SMP and/or x86_64 and AX25 on linux?
by Robert Brose 25 Jan '14

25 Jan '14

For a quite a while I've been getting "bugs in scheduling while atomic" kernel messages. I seem to recall there were some issues with SMP and mkiss at some point in the past. This isn't a hardware problem since the issue remains after putting together a completely new system. This is currently a machine running debian wheezy i386 userland with a x86_64 kernel. ax25_rebuild_header is in all of these dumps. Seems suspicious. The hardware is a i7-4770K CPU @ 3.50GHz with 16 gigs of ram, dual ethernet ports (acting as a router), a serial kiss port to a TNC and an AXIP port. ham related modules in use: ipip 12941 0 tunnel4 12629 1 ipip ip_tunnel 21436 1 ipip netrom 36534 4 mkiss 17161 2 ax25 54676 60 mkiss,netrom dmesg [10433.518914] Hardware name: MSI MS-7850/Z87-G41 PC Mate(MS-7850), BIOS V1.2 06/07/2013 [10433.518915] 0000000000000000 ffff88002e21e7c0 ffffffff814b98af ffff8803f603e000 [10433.518917] ffffffff814b6f16 ffff88040eb93800 ffffffff814bd1ad 0000000000000000 [10433.518918] ffff88041fac3bd8 ffff8803f603ffd8 ffff8803f603ffd8 ffff8803f603ffd8 [10433.518919] Call Trace: [10433.518920] <IRQ> [<ffffffff814b98af>] ? dump_stack+0x41/0x51 [10433.518927] [<ffffffff814b6f16>] ? __schedule_bug+0x46/0x55 [10433.518928] [<ffffffff814bd1ad>] ? __schedule+0x5cd/0x780 [10433.518931] [<ffffffff8108d3dd>] ? __cond_resched+0x1d/0x30 [10433.518932] [<ffffffff814bd3d7>] ? _cond_resched+0x27/0x30 [10433.518934] [<ffffffff814bc209>] ? mutex_lock_interruptible+0x9/0x40 [10433.518942] [<ffffffffa0309c08>] ? rp_write+0x68/0x340 [rocket] [10433.518943] [<ffffffffa08adf0d>] ? ax_xmit+0x1ad/0x440 [mkiss] [10433.518946] [<ffffffff813d2669>] ? dev_hard_start_xmit+0x319/0x500 [10433.518948] [<ffffffff8106ac18>] ? internal_add_timer+0x18/0x50 [10433.518950] [<ffffffff813f010d>] ? sch_direct_xmit+0xfd/0x1d0 [10433.518951] [<ffffffff813d2a40>] ? dev_queue_xmit+0x1f0/0x490 [10433.518954] [<ffffffffa08988f8>] ? ax25_rebuild_header+0x108/0x2b0 [ax25] [10433.518956] [<ffffffff813d9e3d>] ? neigh_compat_output+0x8d/0xa0 [10433.518957] [<ffffffff8140a4d1>] ? ip_finish_output+0x1b1/0x3a0 [10433.518959] [<ffffffff8143ec85>] ? igmp_ifc_timer_expire+0x175/0x280 [10433.518960] [<ffffffff8143eb10>] ? igmp_group_added+0x170/0x170 [10433.518962] [<ffffffff8106ab1c>] ? call_timer_fn+0x2c/0x100 [10433.518963] [<ffffffff8143eb10>] ? igmp_group_added+0x170/0x170 [10433.518964] [<ffffffff8106c0d5>] ? run_timer_softirq+0x1f5/0x2a0 [10433.518967] [<ffffffff812860f1>] ? timerqueue_add+0x61/0xb0 [10433.518969] [<ffffffff81063bbe>] ? __do_softirq+0xde/0x220 [10433.518970] [<ffffffff814c875c>] ? call_softirq+0x1c/0x30 [10433.518973] [<ffffffff810155b5>] ? do_softirq+0x75/0xb0 [10433.518974] [<ffffffff81063e65>] ? irq_exit+0xa5/0xb0 [10433.518977] [<ffffffff810407cb>] ? smp_apic_timer_interrupt+0x3b/0x50 [10433.518979] [<ffffffff814c7a9d>] ? apic_timer_interrupt+0x6d/0x80 [10433.518979] <EOI> [<ffffffff814c8a2c>] ? sysenter_dispatch+0x7/0x21 Thanks for any ideas. Bob Brose / N0QBJ

3 2

DNS records 44.131.56.0/24
by Nick G4IRX 20 Jan '14

20 Jan '14

Hi, I've checked DNS A records for various hosts in the net that I'm co-ordinator for and they resolve but to to obsolete records. I've entered some new records via portal.ampr.org, expecting them to come to me for approval but as yet, no email! The correct entries should be - gw.g4irx.ampr.org IN A 44.131.56.9 g4irx.ampr.org IN A 44.131.56.10 Ideally the entire 44.131.56.0/24 block could be deleted as we've started afresh re-allocating addresses. Any suggestions to get this fixed? Thanks, Nick G4IRX.

3 5

Re: [44net] DNS records 44.131.56.0/24
by Rob Janssen 20 Jan '14

20 Jan '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] DNS records 44.131.56.0/24 > From: > Nick G4IRX <g4irx.44net(a)nowindows.net> > Date: > 01/20/2014 08:34 PM > > To: > 44net(a)hamradio.ucsd.edu > > > Hi, > > I've checked DNS A records for various hosts in the net that I'm co-ordinator for and they resolve but to to obsolete records. I've entered some new records via portal.ampr.org, expecting them to come to me for approval but as yet, no email! > > The correct entries should be - > gw.g4irx.ampr.org IN A 44.131.56.9 > g4irx.ampr.org IN A 44.131.56.10 > > Ideally the entire 44.131.56.0/24 block could be deleted as we've started afresh re-allocating addresses. > > Any suggestions to get this fixed? > > Thanks, > Nick G4IRX. Nick, I think this part of the portal does not work. It would be better if it were disabled until time can be spent on it. You need to send the updates of your address space to the ampraddr robot as before. To delete a block, first download the existing allocations from ftp://hamradio.ucsd.edu/pub/ampr.tar.gz, isolate what you want to delete, edit the "IN" to "DEL" and submit it to the robot. Rob

2 1

new ip
by Brian Rogers 20 Jan '14

20 Jan '14

For those who wish to try and relink my new IP is: 76.28.121.159 I haven't received an encap file yet and the ISP screwed things up on their end which most likely will be resolved sometime tomorrow. If I set you up double check your startup file to see if I put in a static route to myself in your file. If so please delete it and let RIP handle the rest. -- 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.

2 1

Re: [44net] Help with 44.152 subnet
by Gabriel Medinas 20 Jan '14

20 Jan '14

Hello friends, After a hard weekend installing 2 JNOS machines to serve each a middle split 44.152.0.0./16 The 44.152.128.1 working the second part of the subnet (yv5sat.ampr.org) 44.152.128.0/17 in this first time the second subnet that cover all cities out of Capital District in YV. The other first split 44.152.0.0/17 Capital District with yv5kxe.ampr.org 44.152.0.60, this machine now with ubuntu desktop (3 formats this weekend) to reach the cause of the problem with RIP and encap tunnels. Thanks to Tom SL2LOB and Pedro LU7ABF, that help me to test and find the solution of why dont work the ampr tunnels in my system. Yet the RIP dont work but may find a solution, the mayor problem is the impossibility to SYN encap packets datagrams trougth Internet, think first the Ubuntu, then the JNOS, or any ISP ADSL filter, and last find the problem in the Tp-Link firewall TL-R480T that dont want pass any encapsulated datagram, I check all parameters but dont is possible, change to other D-link with DD-WRT v24-sp2 and work perfect. Meanwhile I find other firewall to change the TL-R480T TPLINK the first 44.152 split subnet is down, only with comercial IP yv5kxe.org. Thanks for your attention. 73 de Gabriel YV5KXE. YV Local AmprNet Coordinator ---------- From: Gabriel Medinas <gmedinas(a)gmail.com> Date: 2014/1/18 Subject: Help with 44.152 subnet To: 44net(a)hamradio.ucsd.edu Hello fellows hams. We want restart again here the 44.152 subnet from Venezuela amprnet. In this first step mount the first gateway with 44.152.0.0./17 network, this is a Ubuntu 12.04 server machine in a dinamic IP service. Now for resume, think i miss something: Internet IP-->TpLink TL-R480T firewall->UbuntuServer12.04->JNOS2.0j Internet IP (dinamic from ISP)->Tplink LAN 192.168.1.2->Ubuntu Server eth0 192.168.1.109->JNOS IP 44.152.0.60, tun0 192.168.1.110 in JNOS autoexec.nos: attach tun tun0 1500 0 ifconfig tun0 ipaddress 192.168.1.110 ifconfig tun0 netmask 255.255.255.0 ifconfig tun0 mtu 1500 # shell ifconfig tun0 192.168.1.109 pointopoint 192.168.1.110 mtu 1500 up shell arp -s 192.168.1.110 00:19:DB:4A:CE:2A pub shell arp -s 44.152.0.60 00:19:DB:4A:CE:2A pub shell route add 44.152.0.60 gw 192.168.1.110 tun0 # shell arp -sD 192.168.1.110 eth0 pub # shell iptables -I INPUT 1 -j ACCEPT --proto 4 shell iptables -I INPUT 1 -j ACCEPT --proto 94 shell iptables -I OUTPUT 1 -j ACCEPT --proto 4 shell iptables -I OUTPUT 1 -j ACCEPT --proto 94 shell iptables -I FORWARD 1 -j ACCEPT --proto 4 shell iptables -I FORWARD 1 -j ACCEPT --proto 94 shell /sbin/iptables -I INPUT -i tun0 -j ACCEPT shell /sbin/iptables -I FORWARD -i tun0 -j ACCEPT # shell iptables -t nat -A PREROUTING -d 192.168.1.110/32 --proto 4 \-j DNAT --to 44.152.0.60 shell iptables -t nat -A PREROUTING -d 192.168.1.110/32 --proto 94 \-j DNAT --to 44.152.0.60 shell iptables -t nat -A POSTROUTING -s 44.152.0.60/32 -o eth0 -p 4 shell iptables -t nat -A POSTROUTING -s 44.152.0.60/32 -o eth0 -p 94 # I am little lost here, the JNOS 44.152.0.60/ lan 192.168.1.110 work with all Internet IP well but with ampr dont (think for encap routes and rip2 dont work) in Linux console: ./rip44d -v found local address: 192.168.1.109 found local address: 127.0.0.1 found local address: 192.168.1.109 opening UDP socket 520... entering main loop, waiting for RIPv2 datagrams and stop here dont receive the routes BUT in JNOS trace monitor see the incoming the rip UDP from 169.228.66.251 but my JNOS ip lan 192.168.1.110 replay a ICMP UnreachablePort Please, I need be clear about what is the better way to RIP amproutes in linux or jnos? I think have any very wrong here in the routing, please any advice is welcome to me (gmedinas(a)gmail.com) Thanks for help, 73 de Gabriel YV5KXE

1 0

Status at URO
by Brian Rogers 19 Jan '14

19 Jan '14

Thanks Brian for relaying the message for me. At the moment I see I have link so here's hoping this will make it. They're doing some pretty heavy renovations in the center of my town and while doing so my line was cut. This also happened a few weeks ago. The combo voip/data router took a bit of a spike when they reconnected the cable and did it some harm. It's an old Thomson. This second cut/repair sent another spike and harmed it even worse. I don't have access into it, only the provider does but the way it's acting is as if it's NAT isn't properly flushing. I did get a replacement which is also an upgrade and hope to put it online over the weekend pending no issues. My guess is that my IP will change due to the new mac address. Those who have a static encap route programmed in will need to change this, I'll post the new IP in here so you can make the change, or delete it and let rip handle the rest. Hopefully the transition will go smoothly - but this is networking here... -- 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.

4 5

Help with 44.152 subnet
by Gabriel Medinas 18 Jan '14

18 Jan '14

Hello fellows hams. We want restart again here the 44.152 subnet from Venezuela amprnet. In this first step mount the first gateway with 44.152.0.0./17 network, this is a Ubuntu 12.04 server machine in a dinamic IP service. Now for resume, think i miss something: Internet IP-->TpLink TL-R480T firewall->UbuntuServer12.04->JNOS2.0j Internet IP (dinamic from ISP)->Tplink LAN 192.168.1.2->Ubuntu Server eth0 192.168.1.109->JNOS IP 44.152.0.60, tun0 192.168.1.110 in JNOS autoexec.nos: attach tun tun0 1500 0 ifconfig tun0 ipaddress 192.168.1.110 ifconfig tun0 netmask 255.255.255.0 ifconfig tun0 mtu 1500 # shell ifconfig tun0 192.168.1.109 pointopoint 192.168.1.110 mtu 1500 up shell arp -s 192.168.1.110 00:19:DB:4A:CE:2A pub shell arp -s 44.152.0.60 00:19:DB:4A:CE:2A pub shell route add 44.152.0.60 gw 192.168.1.110 tun0 # shell arp -sD 192.168.1.110 eth0 pub # shell iptables -I INPUT 1 -j ACCEPT --proto 4 shell iptables -I INPUT 1 -j ACCEPT --proto 94 shell iptables -I OUTPUT 1 -j ACCEPT --proto 4 shell iptables -I OUTPUT 1 -j ACCEPT --proto 94 shell iptables -I FORWARD 1 -j ACCEPT --proto 4 shell iptables -I FORWARD 1 -j ACCEPT --proto 94 shell /sbin/iptables -I INPUT -i tun0 -j ACCEPT shell /sbin/iptables -I FORWARD -i tun0 -j ACCEPT # shell iptables -t nat -A PREROUTING -d 192.168.1.110/32 --proto 4 \-j DNAT --to 44.152.0.60 shell iptables -t nat -A PREROUTING -d 192.168.1.110/32 --proto 94 \-j DNAT --to 44.152.0.60 shell iptables -t nat -A POSTROUTING -s 44.152.0.60/32 -o eth0 -p 4 shell iptables -t nat -A POSTROUTING -s 44.152.0.60/32 -o eth0 -p 94 # I am little lost here, the JNOS 44.152.0.60/ lan 192.168.1.110 work with all Internet IP well but with ampr dont (think for encap routes and rip2 dont work) in Linux console: ./rip44d -v found local address: 192.168.1.109 found local address: 127.0.0.1 found local address: 192.168.1.109 opening UDP socket 520... entering main loop, waiting for RIPv2 datagrams and stop here dont receive the routes BUT in JNOS trace monitor see the incoming the rip UDP from 169.228.66.251 but my JNOS ip lan 192.168.1.110 replay a ICMP UnreachablePort Please, I need be clear about what is the better way to RIP amproutes in linux or jnos? I think have any very wrong here in the routing, please any advice is welcome to me (gmedinas(a)gmail.com) Thanks for help, 73 de Gabriel YV5KXE

2 1

n1uro offline
by Brian Kantor 18 Jan '14

18 Jan '14

N1URO wants me to let you folks know what his site is offline for a few days because construction work cut his network link. His email is similarly affected. - Brian

9 30

Re-thinking the internet
by kb9mwr＠gmail.com 17 Jan '14

17 Jan '14

A few years back Vinton Cerf, was invited back to Stanford where he graduated, to give a speech to future engineering students. I don't know why it didn't occur to me to share the video here on this list back when I first discovered it. It seems relevant to what we do on this list. There is a lot of interesting history and things to get you thinking in his presentation. http://kb9mwr.blogspot.com/2011/02/vint-cerf-re-thinking-internet.html

2 1

Link
by Jerry 17 Jan '14

17 Jan '14

Would anyone like to link with me .. Send me your Ip and gateway Here is mine, to my Jnos system. 44.48.0.46 encap 69.27.54.92 Call n9lya-5 BBS Call n9lya-6 Node Call n9lya-5 73 jerry Join Dropbox today <https://db.tt/72qWEIC2> https://db.tt/72qWEIC2 N9LYA/K9BBS <http://w9bbs.no-ip.org:8080/> http://w9bbs.no-ip.org:8080 K9BBS IP 44.48.0.42 Linbpq 6.0.5.1 Debian Linux 6.0.7 Dell_Server_2600_4GBRAM_73GBHD_Dual_Dual_Core_CPU_1.8Ghz W9HU <http://w9bbs.no-ip.org:8081/> http://w9bbs.no-ip.org:8081 W9HU IP 44.48.0.44 PilinBPQ 6.0.5.1 Raspbian-wheezy-7_Rpi_B_700MHz_256MBram_128GB-SD-class10 W9OTR <http://w9bbs.no-ip.org:8082/> http://w9bbs.no-ip.org:8082 W9OTR IP 44.48.0.43 PilinBPQ 6.0.5.1 Raspbian-wheezy-7_Rpi_B_700MHz_256MBram_128GB-SD-class10 N9LYA-5 IP 44.48.0.46 Jnos 2.0j N9LYA-9 IP 44.48.0.41 Uronode 2.1 Debian Linux 6.0.7 HP 3.4Ghz 2GB Ram 2TB Hard drive W9BBS-3 IP 44.48.0.45 MSYS 1.20Beta4 Dell XP Sp3 40GB HD 756 MB Ram <http://www.mitchellwx.com/> http://www.mitchellwx.com wview 5.20.2 <http://www.n9lya.com/> http://www.n9lya.com <http://www.hfskipnet.net/> http://www.hfskipnet.net <http://www/indianapacketcouncil.com> http://www/indianapacketcouncil.com <http://aprs.fi/#!mt=roadmap&z=11&call=a%2FN9LYA-5&timerange=3600&tail=3600> http://aprs.fi/#!mt=roadmap&z=11&call=a%2FN9LYA-5&timerange=3600&tail=3600 <http://aprs.fi/#!mt=roadmap&z=11&call=a%2FN9LYA-3&timerange=3600&tail=3600> http://aprs.fi/#!mt=roadmap&z=11&call=a%2FN9LYA-3&timerange=3600&tail=3600 My net44 subnet 44.48.0.41 uronode.n9lya.ampr.org uronode.n9lya 44.48.0.42 k9bbs.ampr.org k9bbs 44.48.0.43 w9otr.ampr.org w9otr 44.48.0.44 w9hu.ampr.org w9hu 44.48.0.45 w9bbs.ampr.org w9bbs 44.48.0.46 n9lya.ampr.org n9lya n9lya-3 73 Jerry N9LYA HF Skipnet Coordinator HF Skipnet Midwest HUB ARRL Net Manager - Packet Indiana AmprNet IP Coordinator Indiana Indiana Packet Coordinator Sysop N9LYA/K9BBS/W9BBS/W9OTR W9OTR Hoosier Amateur Radio Digital Society W9HU Hoosier Radio Society

2 2

Gateways but no region network
by kb9mwr＠gmail.com 13 Jan '14

13 Jan '14

In browsing the encap file I see entries that aren't defined as regional networks: ex: 44.71.28.0/27 44.71.4.0/27 44.71.4.32/27 44.72.26.0/24 44.72.73.0/26 https://portal.ampr.org/networks.php?a=region&id=162 The listed regional networks skip from 44.70 to 44.74 44.70.0.0/16 Ohio 44.74.0.0/16 North Carolina

2 1

Where to start
by Andy Brittain 11 Jan '14

11 Jan '14

Hi all First time poster here so be gentle :-) Can anyone point me in the direction of where to start? I have an IP address allocated from the portal, a shiny Linux server, 2m rig and an old KAM TNC that can be put in to Kiss mode. What's missing is what to do and where to start. Any advise very welcome and I look forward to some contacts over data. Regards Andy G0HXT

4 4

Re: [44net] known good routers that pass rip/44-net friendly in uk?
by Rob Janssen 10 Jan '14

10 Jan '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] known good routers that pass rip/44-net friendly in uk? > From: > ve1jot <ve1jot(a)eastlink.ca> > Date: > 01/08/2014 09:43 AM > > To: > 44net(a)hamradio.ucsd.edu > > > Anyone know of a list of routers that pass ripv2? A ham in EU is trying > to set up ripv2 with our help but ripv2 gateway announcements don't seem to be coming through the router...yes, the pi is in the DMZ, hi hi! He's on virginmedia, any issues with their modems known? You mean the ipip tunneling is working with static routing but you cannot get RIP to work? Or is the situation merely "it does not work" and the diagnosis "there are no RIP announcements"? I set up a Pi some time ago and I had a strange problem with RIP that I finally resolved, and submitted a patch to ampr-ripd that makes it work problemfree. I don't know if the other ripd was similarly modified, for sure it had the same issue. The problem was that although RIP announcements made it all the way to the Pi, they were not properly received on the UDP socket the daemon created. Rob

8 18

Re: [44net] known good routers that pass rip/44-net friendly in uk?
by lleachii＠aol.com 09 Jan '14

09 Jan '14

- Any iptables-based device (e.g. Linux kernel/OS, DD-WRT, OpenWRT, RaspberyPi) - DLink devices that allow selecting of "Other" protocol, DLink provides Web GUI simulators for most router models **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

1 0

Re: [44net] gateways cleanup/deletion (Brian Kantor)
by Gabriel Medinas 09 Jan '14

09 Jan '14

Hello Brian and fellow amprnet friends. First, let me introduce myself, I am Gabriel Medinas YV5KXE from Caracas, Venezuela, working in the past time with the last one Venezuela amprnet coordinator YV5CIV that is away of the activity. I work amprnet for about 20 years, in the last years the activity in my country is down with the packet radio mode, but a group of YV-YY want rise it again. I maintain operative the last packet radio gateway (yv5kxe.org) with VHF 145.010 YVNET working together with APRS, in this month Brian Kantor let me the responsability of the Amprnet Local Coordinator of 44.152.x.x Venezuela network, I glad to share this with my friends in amprnet of many years, now in the coordination position. In a first step, I mount a Linux amprnet JNOS gateway with N6ROE help (thanks Kim). The second step is work to find the way to re-start the amprnet here, the idea of a new gateway with static IP or see the posibility to mount a dynaIP tool or other. I think (personal idea) this network may grow if our fellow ham radio may have the possibility to use their ADSL (dynamic IP) home connections to mount their NOS amprnet system, also we are study the ways to start first a static IP gateway to server the others via AXUDP/AXIP connections. Now Brian, with this comercial IP list see any of our old gateway IP (not working now), please you may delete it to clean the gateway list to be a real and accurate network, please to all gateways sysops, delete all 44.152.x.x routes to restart in clean mode. Grettings all for your time and hope work together in more and operative amprnet network! 73 de Gabriel YV5KXE AMPR Net IP Address Coordinator - Venezuela yv5kxe.org yv5kxe.ampr.org www.gmedinas.com Message: 1 Date: Tue, 7 Jan 2014 12:32:50 -0800 From: Brian Kantor <Brian(a)UCSD.Edu> To: 44net(a)hamradio.ucsd.edu Subject: [44net] gateways cleanup/deletion Message-ID: <20140107203249.GA8539(a)UCSD.Edu> Content-Type: text/plain; charset=us-ascii A while back I published a list of unclaimed gateways (those with no known owner/operator). Some small number of those were subsequently claimed and have been associated with their registered owner in the portal. However, there remain some 91 gateways whose owner/operator remains unknown. I intend to delete these gateways from the encap/gateways file around the end of the month. So in effect, this is the last chance for people operating these gateways to get them properly registered before they go away. If you find your gateway on this list, be sure you are personally registered with the portal and SEND ME AN EMAIL to get the gateway associated with your callsign in the portal. Thank you all! - Brian In order by commercial IP address: 8.22.205.37 12.195.50.128 24.55.199.25 24.84.205.232 24.89.203.65 24.137.76.29 24.224.157.206 50.79.209.150 64.22.214.233 64.119.33.202 64.119.42.138 64.255.99.17 65.41.209.137 65.48.61.133 65.70.212.35 66.11.68.11 66.112.51.126 66.114.139.158 67.108.91.190 68.61.222.68 68.209.144.3 69.69.168.201 69.145.172.163 69.254.106.173 71.36.92.66 71.107.40.238 71.107.40.238 71.201.92.148 74.85.194.5 75.21.234.175 76.14.161.185 76.64.80.228 76.247.140.206 76.253.114.92 77.249.108.97 79.116.75.255 80.59.234.233 81.235.253.122 84.92.153.154 90.206.95.108 91.84.215.75 94.72.251.181 94.172.232.113 96.20.43.106 96.35.76.41 98.193.215.29 98.208.81.22 99.88.77.66 99.116.194.13 108.185.66.208 113.212.169.28 122.108.78.111 130.208.168.63 141.85.43.57 146.48.126.26 146.48.126.28 148.223.34.6 150.188.8.195 152.66.0.109 155.207.19.57 158.42.128.200 161.53.16.179 168.96.128.17 173.14.57.181 184.175.46.166 186.125.37.47 189.42.190.50 190.31.163.55 190.139.56.180 193.22.2.254 194.27.119.2 195.22.112.28 195.66.148.106 195.113.115.135 198.108.247.220 200.17.207.2 200.46.129.3 201.252.37.40 202.63.57.97 206.251.38.99 207.111.203.194 207.179.123.166 208.74.106.137 208.94.114.29 208.115.126.75 212.159.74.68 212.159.102.156 216.144.222.182 216.253.203.30 220.157.89.84 220.233.86.207 ------------------------------

1 0

Hack fix for Pi
by Brian Rogers 09 Jan '14

09 Jan '14

Greetings list members; While I still search for a true fix, a hack fix would be to create a tunl1 and route via that interface, however if you take tunl0 down, for some reason rip fails. If anyone has a better solution or a true fix, please relay it. Thanks in advance... -- 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.

9 13

AMPRNet Flow Charts
by Jann Traschewski 08 Jan '14

08 Jan '14

Hi! I'm about to put some Flow Charts on the AMPRNet wiki. Can you please review the following files for correction? http://db0fhn.efi.fh-nuernberg.de/files/amprnet Thank you! 73, Jann -- Jann Traschewski, Lenbachstr. 6, D-90489 Nuernberg, Germany Tel.: +49-911-696971, Mobile: +49-170-1045937, E-Mail: jann(a)gmx.de Ham: DG8NGN / DB0VOX, http://www.qsl.net/dg8ngn

1 0

gateways cleanup/deletion
by Brian Kantor 08 Jan '14

08 Jan '14

A while back I published a list of unclaimed gateways (those with no known owner/operator). Some small number of those were subsequently claimed and have been associated with their registered owner in the portal. However, there remain some 91 gateways whose owner/operator remains unknown. I intend to delete these gateways from the encap/gateways file around the end of the month. So in effect, this is the last chance for people operating these gateways to get them properly registered before they go away. If you find your gateway on this list, be sure you are personally registered with the portal and SEND ME AN EMAIL to get the gateway associated with your callsign in the portal. Thank you all! - Brian In order by commercial IP address: 8.22.205.37 12.195.50.128 24.55.199.25 24.84.205.232 24.89.203.65 24.137.76.29 24.224.157.206 50.79.209.150 64.22.214.233 64.119.33.202 64.119.42.138 64.255.99.17 65.41.209.137 65.48.61.133 65.70.212.35 66.11.68.11 66.112.51.126 66.114.139.158 67.108.91.190 68.61.222.68 68.209.144.3 69.69.168.201 69.145.172.163 69.254.106.173 71.36.92.66 71.107.40.238 71.107.40.238 71.201.92.148 74.85.194.5 75.21.234.175 76.14.161.185 76.64.80.228 76.247.140.206 76.253.114.92 77.249.108.97 79.116.75.255 80.59.234.233 81.235.253.122 84.92.153.154 90.206.95.108 91.84.215.75 94.72.251.181 94.172.232.113 96.20.43.106 96.35.76.41 98.193.215.29 98.208.81.22 99.88.77.66 99.116.194.13 108.185.66.208 113.212.169.28 122.108.78.111 130.208.168.63 141.85.43.57 146.48.126.26 146.48.126.28 148.223.34.6 150.188.8.195 152.66.0.109 155.207.19.57 158.42.128.200 161.53.16.179 168.96.128.17 173.14.57.181 184.175.46.166 186.125.37.47 189.42.190.50 190.31.163.55 190.139.56.180 193.22.2.254 194.27.119.2 195.22.112.28 195.66.148.106 195.113.115.135 198.108.247.220 200.17.207.2 200.46.129.3 201.252.37.40 202.63.57.97 206.251.38.99 207.111.203.194 207.179.123.166 208.74.106.137 208.94.114.29 208.115.126.75 212.159.74.68 212.159.102.156 216.144.222.182 216.253.203.30 220.157.89.84 220.233.86.207

3 3

Re: [44net] gateways cleanup/deletion
by Wm Lewis 08 Jan '14

08 Jan '14

At 01:28 PM 1/7/2014, you wrote: > 50.79.209.150 This address is for KE6I, CATHRYN MATAGA. She does have an active node and BBS "BERK" in Berkeley, Calif. I sent her a copy of your first email but had no response. I'll try and contact her again. I suppose if you pull the plug, that will get her attention :) Wm Lewis (KG6BAJ) AMPR Net IP Address Coordinator - Northern and Central California Regions (A 100% Volunteer Group) (530) 263-1595 (Home/Office) ______________________________________________ ---------- 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.

1 0

Happy New Year
by Brian Kantor 02 Jan '14

02 Jan '14

I want to wish each of you a Happy New Year and to extend my thanks to you for all the contributions you folks have made to the advancement of amateur radio tcp/ip networking. And I'd like to extend a very special thanks to those of you who have been generous enough to make a donation to help keep the Amateur Radio Digital Communications non-profit corporation a going concern at http://www.ampr.org/donate.html Best wishes! - Brian

4 3

Re: [44net] Pi bug for ipencap?
by lleachii＠aol.com 31 Dec '13

31 Dec '13

Brian, I found the following in a Linux manual for the 'ip tunnel' command: nopmtudisc -- disable Path MTU Discovery on this tunnel. It is enabled by default. Note that fixed ttl is incompatible with this option: tunnels with fixed ttl always make pmtu discovery. If you create a tunnel that does not care about MTU state, it's also unconcerend about the 'distance' the packet has traveled, your eth interface would handle both tasks in that instance (being a 'dumb tunnel,' if you will). With nopmtudisc on, your 44Router would properly fragment the packet when transmitting on eth and sets the ttl on the ARPA Internet, as opposed to AMPRnet. If this command worked before you updated your IP utilities, it was probally due to the previous version not being written true to RFC. 73, Lynwood KB3VWG

2 1

Re: [44net] Pi bug for ipencap?
by Rob Janssen 31 Dec '13

31 Dec '13

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] Pi bug for ipencap? > From: > Brian Rogers <n1uro(a)n1uro.ampr.org> > Date: > 12/30/2013 12:59 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Greetings; > > I've noticed recently after doing a package update on the iproute > packages I can no longer configure my tunnel interface tunl0. How did you get that update? is it an update that is currently queued on "apt-get upgrade"? or was it something you installed yourself? (my Pi is still working but I'd like to know what to avoid) Rob

3 2

Forgot robot password
by Assi Friedman 30 Dec '13

30 Dec '13

Folks: I managed to forget my robot password. What's my recourse? Assi kk7kx/4x1kx

1 0

Merry Christmas and a Happy New Year
by Glenn Bursell 25 Dec '13

25 Dec '13

Merry Christmas and a Happy New Year! 73 Glenn KA0MOS/VE1 --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

1 0

Merry Christmas & Happy New Year 2014
by Demetre SV1UY 25 Dec '13

25 Dec '13

To all AMPRnet friends, Merry Christmas and a Happy New Year with more AMPRnet Radio Links in 2014! -- 73 de SV1UY Demetre Ch. Valaris e-mail: demetre.sv1uy(a)gmail.com AMPRnet: sv1uy(a)sv1uy.ampr.org 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

Re: [44net] Amprnet Gateway and Dynamic DNS.
by sp2lob 24 Dec '13

24 Dec '13

John, AFAIK, encap.txt file available via ftp site is updated once per hour, whilst encap.txt file available via portal.ampr.org is updated once update was made on the portal - immediately! -- Best regards. Tom - sp2lob

4 3

data bandwidth in other countries
by kb9mwr＠gmail.com 23 Dec '13

23 Dec '13

Hello all, I don't like the idea of regulatory discussions on this list. However, I am curious (as it's pertinent to what we do on this list) what the rules are in other counties for ham radio.. So far I haven't had much luck finding the answers on the web. Presently in US ham radio data bandwith: 2 meters is 20 khz max, 19.6 kilobauds 70 cm is 100 khz max, 56 kilobauds Ironically, while there is plenty of space on 70 cm, other modes like ATV are permitted to occupy up to 6 MHz of bandwidth. Since we have a nice mix of hams from all over the world on this list, I'd appreciated a reply (can be off list) on what is permitted in your country on 2 meters and 70 cm. Thanks, Steve, KB9MWR

16 16

Re: [44net] data bandwidth in other countries
by Rob Janssen 20 Dec '13

20 Dec '13

> Hello all, > > I don't like the idea of regulatory discussions on this list. I don't mind any disussion as long as people don't quote other people's replies and add their own ones. Quoting other people's text is only required when you react to those lines, and usually when you type above someone else's text it is completely superfluous. We all get all the messages, there is no need for us to read them 5 times. (I refer both to what I see happening in this thread, and in the other one with the long list of IP addresses a couple of days ago) That out of the way, it is correct what Andre writes about the Netherlands. Of course it is because of deregulation. The "we don't care what you do as long as you don't do it outside the amateur bands". We have wide-FM-stereo on 70cm as well, even with RDS :-) Rob

1 0

Re: [44net] data bandwidth in other countries
by kb9mwr＠gmail.com 20 Dec '13

20 Dec '13

Yes, sadly RM 11708 primarily focuses on HF. However if you read carefully (or email someone at the ARRL to confirm): “The Board’s instruction is to seek the deletion of all references to symbol rate in 97.307(f). That includes (f)(5) and (f)(6). There is already a bandwidth limit in those subparagraphs.” So the baud rate part will disappear for HF and above. So that is a good start. The end result will be just the bandwidth limits.

1 0

Re: [44net] data bandwidth in other countries
by kb9mwr＠gmail.com 20 Dec '13

20 Dec '13

Yes those are the baud limits, per Part 97.305 There is a recent attempt to remove that part however: http://www.arrl.org/news/arrl-executive-committee-okays-filing-symbol-rate-…. ---- Quote --- A question...is it really limited in bandwidth to 19.6K on 2m and 56K on 440 or is it just that this is the maximum used by the modes in common use?

2 1

Raspberry Pi - NET44 Gateway.
by Kutche, Jerry (Mitchell) USA 18 Dec '13

18 Dec '13

While on the subject.. You can run the RPi with URONODE and have NET44 gateway as well. There is a PiTNC available as well. That fits nicely on top of the Pi GPIO pins. 73 Jerry N9LYA mailto:raspberry_pi_4-ham_radio-subscribe@yahoogroups.com

6 13

Changes IP w 44.165.25.
by Janusz Przybylski SP1LOP 16 Dec '13

16 Dec '13

I do not know who affixed the ping address: 75 .80.130.94 to my IP 44.165.25.232 very please turn off .... It will not work, because I change ISP blocked and a new 44-net frame from my server in the world .. And now I do not know how to unlock it. At the same time, please make any changes at home IP to my Linux and JNOS: old:44.165.25.232Now:44.165.25.254 old:44.165.25.233Now:44.165.25.250 -- 73 de Janusz / SP1LOP ===== Janusz J. Przybylski, SP1LOP ================== Poland AMPRNet Co-ordinator [44.165/16] from Mar 2003 =====================================================

1 0

one-to-one translation of IP addresses?
by kb9mwr＠gmail.com 16 Dec '13

16 Dec '13

How does everyone handle servers that they have accessible via net 44? (As well as their local network) I typically use the 192.168.1.X private IP range on my home network. A couple IPs on that network are servers (askerisk, samba etc). I don't really want to change my internal network configuration. So I was thinking some sort of one-to-one translation of IP addresses. I have tried everything I have read thus far with no luck. Lets say: server: 192.168.1.20 that I'd like translated to 44.92.21.35

2 1

Tester requested.
by Jean Létourneau 16 Dec '13

16 Dec '13

Good day all, I am wondering if my setup is fully operational, can you guy's take 2 minute of your time and try to ping the following adddresses from your ampr.org network and reporte them back to me: 44.135.49.1, 44.135.49.2 and 44.135.49.4 thank you! 73 de Jean, -- Sysop de: VE2PKT (BBS), VE2PKT-3 (URONode),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: ve2pkt(a)ve2pkt.ampr.org Inet: ve2pkt(a)amsat.org or ve2pkt(a)gmail.com

15 31

unclaimed gateways
by Brian Kantor 15 Dec '13

15 Dec '13

According to records on the portal, the following 120 (of 275 total) entries in the gateways list are unclaimed - that is, no one has come forward to take ownership of the entry. They therefore appear to be inactive. I propose we mark these as no longer in service. That will have the effect of no longer including them in the encap list. Eventually we'll delete them from the database if they're not reactivated. If a gateway that is still valid is listed below, contact me or Chris to get it assigned to the proper registered owner. - Brian 8.22.205.37 12.195.50.128 24.55.199.25 24.84.205.232 24.89.203.65 24.137.76.29 24.212.252.100 24.212.252.109 24.212.252.110 24.224.157.206 50.79.209.150 62.49.17.234 64.22.214.233 64.119.33.202 64.119.42.138 64.255.99.17 65.41.209.137 65.48.61.133 65.70.212.35 66.11.68.11 66.112.51.126 66.114.139.158 67.108.91.190 68.61.222.68 68.188.234.106 68.209.144.3 69.69.168.201 69.137.244.193 69.145.172.163 69.178.117.150 69.254.106.173 70.137.68.217 71.36.92.66 71.107.40.238 71.107.40.238 71.201.92.148 74.85.194.5 75.21.234.175 76.14.161.185 76.64.80.228 76.247.140.206 76.253.114.92 77.249.108.97 79.116.75.255 79.116.81.105 80.59.234.233 80.229.68.173 81.235.253.122 84.92.153.154 89.228.59.72 90.206.95.108 91.84.215.75 94.72.251.181 94.101.48.134 94.172.232.113 96.20.43.106 96.35.76.41 97.84.11.198 98.193.215.29 98.208.81.22 99.88.77.66 99.116.194.13 108.185.66.208 113.212.169.28 118.22.1.194 118.82.200.153 122.108.78.111 130.208.168.63 131.155.192.172 141.85.43.57 142.103.194.1 146.48.126.26 146.48.126.28 148.223.34.6 150.188.8.195 152.66.0.109 155.207.19.57 158.42.128.200 161.53.16.179 168.96.128.17 173.14.57.181 173.177.124.119 173.208.214.53 184.175.46.166 186.125.37.47 189.42.190.50 190.31.163.55 190.139.56.180 192.147.172.252 193.22.2.254 194.27.119.2 195.22.112.28 195.113.115.135 195.150.236.251 198.108.247.220 200.17.207.2 200.46.129.3 201.252.37.40 202.63.57.97 203.5.58.162 203.24.120.198 203.24.120.199 203.24.120.200 203.26.188.134 203.59.134.49 206.251.38.99 207.111.203.194 207.179.123.166 208.74.106.137 208.94.114.29 208.115.126.75 208.127.104.172 212.159.74.68 212.159.90.90 213.73.1.100 216.86.85.144 216.144.222.182 217.42.40.69 220.157.89.84 220.233.86.207

17 31

Re: [44net] rip routes - how often?
by kb9mwr＠gmail.com 15 Dec '13

15 Dec '13

Its working now. But it took much longer than 5 mins to get the inital transmission. After that it appears to be every 5 min. The same thing I observed last time I set a gateway up. Oh well, just need to learn patience. Thanks

2 1

rip routes - how often?
by kb9mwr＠gmail.com 15 Dec '13

15 Dec '13

How often are the rip routes transmitted? I have read every 5 mins, but ever time I initially set up a gateway it always seems to take a *lot* longer than that to see anything come thru. https://raw.github.com/hessu/rip44d/master/rip44d I have DMZ on my DD-WRT home router pointed to the pc running the rip daemon, 192.168.1.106 My gateway entry is: 174.103.204.106 ifconfig tunl0 up 44.92.21.1 netmask 255.0.0.0 tunl0 Link encap:IPIP Tunnel HWaddr inet addr:44.92.21.1 Mask:255.0.0.0 UP RUNNING NOARP MULTICAST MTU:0 Metric:1 RX packets:1 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:152 (152.0 B) TX bytes:0 (0.0 B) root@test:~# ./rip44d -v found local address: 192.168.1.106 found local address: 127.0.0.1 found local address: 44.92.21.1 opening UDP socket 520... entering main loop, waiting for RIPv2 datagrams Also watching with tcpdump. Perhaps someone could create a tool to verify protocol 4 packets are reaching the daemon? I always though that might be handy... go to a webpage enter your outside address and it sends a protocol 4 packet... or something?

2 1

Gateway Management
by Brian Rogers 14 Dec '13

14 Dec '13

Greetings; <$0.02> As Jay mentioned, we had the email robot before... perhaps it may be wise to run such again parallel to the portal while the issues Chris mentioned are worked out? This is standard practices almost anywhere in which a production environment is being modified/upgraded/replaced. </$0.02> -- 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.

3 5

Re: [44net] unclaimed gateways
by VK4AA | VK4TTT Sam 14 Dec '13

14 Dec '13

----- Original Message ----- From: "VK4AA | VK4TTT Sam" <vk4ttt(a)ampr.org.au> To: "AMPRNet working group" <44net(a)hamradio.ucsd.edu> Cc: <danny(a)ddmcomputers.com> Sent: Sunday, December 15, 2013 12:49 AM Subject: Re: [44net] unclaimed gateways > Hi Brian > > These are current > VK7HDM (should be on bgp but Danny is yet to fix it up at his end) > 203.24.120.198 > 203.24.120.199 > 203.24.120.200 > > This is for a range waiting for BGP approval (it has slipped by for our > shared DSTAR|APRS|PAKET Site) > 203.26.188.134 > > > Sam > VK4AA > > ----- Original Message ----- > From: "Brian Kantor" <Brian(a)ucsd.edu> > To: <44net(a)hamradio.ucsd.edu> > Sent: Saturday, December 14, 2013 8:24 AM > Subject: [44net] unclaimed gateways > > >> (Please trim inclusions from previous messages) >> _______________________________________________ >> According to records on the portal, the following 120 (of 275 total) >> entries in the gateways list are unclaimed - that is, no one has come >> forward to take ownership of the entry. They therefore appear to be >> inactive. >> >> I propose we mark these as no longer in service. That will have the >> effect of no longer including them in the encap list. Eventually >> we'll delete them from the database if they're not reactivated. >> >> If a gateway that is still valid is listed below, contact me or Chris >> to get it assigned to the proper registered owner. >> - Brian >> >> >> 8.22.205.37 >> 12.195.50.128 >> 24.55.199.25 >> 24.84.205.232 >> 24.89.203.65 >> 24.137.76.29 >> 24.212.252.100 >> 24.212.252.109 >> 24.212.252.110 >> 24.224.157.206 >> 50.79.209.150 >> 62.49.17.234 >> 64.22.214.233 >> 64.119.33.202 >> 64.119.42.138 >> 64.255.99.17 >> 65.41.209.137 >> 65.48.61.133 >> 65.70.212.35 >> 66.11.68.11 >> 66.112.51.126 >> 66.114.139.158 >> 67.108.91.190 >> 68.61.222.68 >> 68.188.234.106 >> 68.209.144.3 >> 69.69.168.201 >> 69.137.244.193 >> 69.145.172.163 >> 69.178.117.150 >> 69.254.106.173 >> 70.137.68.217 >> 71.36.92.66 >> 71.107.40.238 >> 71.107.40.238 >> 71.201.92.148 >> 74.85.194.5 >> 75.21.234.175 >> 76.14.161.185 >> 76.64.80.228 >> 76.247.140.206 >> 76.253.114.92 >> 77.249.108.97 >> 79.116.75.255 >> 79.116.81.105 >> 80.59.234.233 >> 80.229.68.173 >> 81.235.253.122 >> 84.92.153.154 >> 89.228.59.72 >> 90.206.95.108 >> 91.84.215.75 >> 94.72.251.181 >> 94.101.48.134 >> 94.172.232.113 >> 96.20.43.106 >> 96.35.76.41 >> 97.84.11.198 >> 98.193.215.29 >> 98.208.81.22 >> 99.88.77.66 >> 99.116.194.13 >> 108.185.66.208 >> 113.212.169.28 >> 118.22.1.194 >> 118.82.200.153 >> 122.108.78.111 >> 130.208.168.63 >> 131.155.192.172 >> 141.85.43.57 >> 142.103.194.1 >> 146.48.126.26 >> 146.48.126.28 >> 148.223.34.6 >> 150.188.8.195 >> 152.66.0.109 >> 155.207.19.57 >> 158.42.128.200 >> 161.53.16.179 >> 168.96.128.17 >> 173.14.57.181 >> 173.177.124.119 >> 173.208.214.53 >> 184.175.46.166 >> 186.125.37.47 >> 189.42.190.50 >> 190.31.163.55 >> 190.139.56.180 >> 192.147.172.252 >> 193.22.2.254 >> 194.27.119.2 >> 195.22.112.28 >> 195.113.115.135 >> 195.150.236.251 >> 198.108.247.220 >> 200.17.207.2 >> 200.46.129.3 >> 201.252.37.40 >> 202.63.57.97 >> 203.5.58.162 >> 203.24.120.198 >> 203.24.120.199 >> 203.24.120.200 >> 203.26.188.134 >> 203.59.134.49 >> 206.251.38.99 >> 207.111.203.194 >> 207.179.123.166 >> 208.74.106.137 >> 208.94.114.29 >> 208.115.126.75 >> 208.127.104.172 >> 212.159.74.68 >> 212.159.90.90 >> 213.73.1.100 >> 216.86.85.144 >> 216.144.222.182 >> 217.42.40.69 >> 220.157.89.84 >> 220.233.86.207 >> _________________________________________ >> 44Net mailing list >> 44Net(a)hamradio.ucsd.edu >> http://hamradio.ucsd.edu/mailman/listinfo/44net > --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

2 1

OLSR over net 44?
by kb9mwr＠gmail.com 13 Dec '13

13 Dec '13

ON1ARF wrote: > True. Now, one thing I had in the back of my mind is that OLSR can actually > run over any interface. > > OLSR Is usually done over ad-hoc wifi interface, but you can run it over > -say- an ethernet link between two nodes ..; or -why not- a VPN tunnel. > > So, in the end, even if there is no direct radio-contact with other nodes, > you could -sort of- "fake" it by connecting nodes over the internet. It > would probably only require to set up a (say) OpenVPN server in some > datacenter. I never thought of this. Very interesting. I may have found a winter project to try. Perhaps I can find some folks on the ampr net 44 list to try this with?

4 4

Re: [44net] Raspberry Pi - FM transmitter
by Rob Janssen 13 Dec '13

13 Dec '13

> Subject: > Re: [44net] Raspberry Pi - FM transmitter > From: > David Ranch <amprgw(a)trinnet.net> > Date: > 12/11/2013 04:49 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > > Hello Tom, > > One of my elmers tried setting something similar up for WSPR but even with adding the various filters, the harmonics on the higher frequencies were very significant and went well out of the HAM bands! Well, the article says that the harmonics must be 43dB down to meet FCC regulations, or maybe 40dB when reading the complicated if-then-else-if sentences in those paragraphs (why not use a table?). That is quite harsh, for a 10mW transmitter. 1uW is not a lot of power. A homeplug device probably transmits a lot more than that. Rob

2 1

Raspberry Pi - FM transmitter
by sp2lob＠tlen.pl 11 Dec '13

11 Dec '13

Hello all, It’s a bit off topic, but worth to mention. I read article from link below with growing amaze... http://www.icrobotics.co.uk/wiki/index.php/Turning_the_Raspberry_Pi_Into_an… http://www.youtube.com/watch?v=ekcdAX53-S8 Such small piece of hardware and such broad flexibility! What next? Low power APRS beacon? Or full-blown SDR radio? Best regards. Tom – sp2lob

2 1

network size estimates
by Michael E. Fox - N6MEF 08 Dec '13

08 Dec '13

I'm working on a presentation about packet networking. Does anyone have a reasonable estimate of: -- The number of BBS Systems reachable via AMPRnet -- The number of BBS Systems reachable via non-AMPRnet BBS forwarding network -- The number of BBS systems connected via both networks Note: This is not an attempt to compare the two. We're connected both ways. AND, I realize that other BBSs also connect to both, so there will be duplication. That's o.k. I'd just like to be able to give people a sense of how big (or small) each of the networks still is. If you have an estimate for any of the above numbers, can you tell me what it is and how you arrived at it? Thanks, Michael N6MEF

7 7

HAM TV Bulgaria
by lz4ny＠mail.bg 07 Dec '13

07 Dec '13

In Bulgaria start HAM TV via streaming with hamnet IP - http://lz4ny.ampr.org/cms/index.php?id=ham-tv 73, Miro LZ4NY ------------------------------------- Mail.BG: Безплатен e-mail адрес. Най-добрите характеристики на българския пазар - 20 GB пощенска кутия, 1 GB прикрепен файл, безплатен POP3, мобилна версия, SMS известяване и други. http://mail.bg

4 4

Re: [44net] 44Net Digest, Vol 2, Issue 188
by lleachii＠aol.com 06 Dec '13

06 Dec '13

Miro LZ4NY, The 2 commands would be entered by selecting Administration > Commands iptables -t nat -I PREROUTING -p ipencap -d AAA.AAA.AAA.AAA -j DNAT --to-destination BBB.BBB.BBB.BBB iptables -t filter -I FORWARD -p ipencap -d BBB.BBB.BBB.BBB -j ACCEPT Then select: "Save Firewall" 73, Lynwood KB3VWG On 12/06/2013, lz4ny(a)mail.bg wrote: > Hello, > What command line to ask in DD-WRT router to release protocol IPENCAP (4) > to my local machine assuming that AAA.AAA.AAA.AAA is my real address of the > interface WAN of DD-WRT and BBB.BBB.BBB.BBB is the address of the Linux > machine behind the router. > > > 73, Miro LZ4NY

1 0

ipencap (4) via ddwrt ?
by lz4ny＠mail.bg 06 Dec '13

06 Dec '13

Hello, What command line to ask in DD-WRT router to release protocol IPENCAP (4) to my local machine assuming that AAA.AAA.AAA.AAA is my real address of the interface WAN of DD-WRT and BBB.BBB.BBB.BBB is the address of the Linux machine behind the router. 73, Miro LZ4NY ------------------------------------- Mail.BG: Безплатен e-mail адрес. Най-добрите характеристики на българския пазар - 20 GB пощенска кутия, 1 GB прикрепен файл, безплатен POP3, мобилна версия, SMS известяване и други. http://mail.bg

2 1

Help config eth1
by Janusz Przybylski SP1LOP 03 Dec '13

03 Dec '13

I need help in the network configuration via eth0 (192.168.x.x) from WinXP to be able to connect to the addresses 44-Net? For connoisseurs will send more information .. -- 73 de Janusz / SP1LOP ===== Janusz J. Przybylski, SP1LOP ================== Poland AMPRNet Co-ordinator [44.165/16] from Mar 2003 =====================================================

1 2

Chris Maness
by Michael E. Fox - N6MEF 01 Dec '13

01 Dec '13

Chris, Please contact me off list. I've been trying to send you email, for quite a while, but it keeps bouncing with connection timed out at 44.18.44.3. Michael N6MEF

1 0

Re: [44net] DMCA
by Bryan Fields 30 Nov '13

30 Nov '13

On 11/26/13 5:28 PM, Brian Kantor wrote: > Not really. We probably should. I'm a little unclear on exactly > what would be required and how much it's going to cost. > - Brian I'm happy to help out, as it's quite easy to fill out the SWIP forms and then submit it. We could setup rwhois for the 44/net space, but that might be a bit much for us as the portal is not always available. ARIN should not charge a fee to administrator resources for legacy users: 10. I have legacy resources registered in ARIN's Whois database but have no plans to sign the LRSA. Will ARIN continue to maintain my records, and can I still make database changes to my records if I need to? ARIN will continue to process requests from the authorized points of contact of legacy resources for updates to their registration records. Currently, there is no community driven policy specifically prohibiting ARIN from processing updates to records that are not covered under a LRSA or RSA, although that could change in the future. info on swip is here https://www.arin.net/resources/request/reassignments.html Basically you could swip the regional blocks to the regional admins, and when they assign them they swip the assigned blocks to end users. This would fix the in-addr.arpa mapping too, which as of now does not exist for anything on AMPRNET. Thoughts? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

5 4

Re: [44net] DMCA
by Bryan Fields 27 Nov '13

27 Nov '13

On 11/26/13 10:39 PM, Antonio Querubin wrote: > Time has no cost :) We have a volunteer! -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

Re: [44net] DMCA
by Bryan Fields 27 Nov '13

27 Nov '13

Have we considered SWIPing the blocks? A DMCA notice is not necessarily a violation caused by the registrant of the IP, but perhaps one of their users. I've had DMCA notices for unused IP's before, so not all are valid. However 90% of them valid and are people running bit torrent for movies and stuff. How many DMCA notices are you getting from 44/8 on a monthly basis? On 11/26/13 3:55 PM, Brian Kantor wrote: > (Please trim inclusions from previous messages) > _______________________________________________ > Probably most of you folks haven't seen one of these before. > This is the kind of notice I receive and have to respond to > when one of the users of network 44 misbehaves. > > Keep in mind that this is a violation of our terms of service and > is cause to have network access revoked. > > Please be careful not to cause me to get more of these. > > Thank you. > - Brian > > PS: I've obscured the IP address because the matter is already > being dealt with by the persons concerned. > > > ----- Forwarded message from IP-Echelon Compliance <notices.warner(a)ip-echelon.com> ----- > > Date: Tue, 26 Nov 2013 20:19:33 +0000 > From: IP-Echelon Compliance <notices.warner(a)ip-echelon.com> > To: bk29(a)ucsd.edu > Subject: Notice of Claimed Infringement - Case ID 1335xxxxx > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Dear bk29(a)ucsd.edu > > We are writing this message on behalf of Warner Bros. Entertainment Inc.. > > We have received information that an individual has utilized the > below-referenced IP address at the noted date and time to offer > downloads of copyrighted material. > > The title in question is: Pacific Rim > > The distribution of unauthorized copies of copyrighted television > programs constitutes copyright infringement under the Copyright Act, > Title 17 United States Code Section 106(3). This conduct may also > violate the laws of other countries, international law, and/or treaty > obligations. > > Since you own this IP address (44.xxx.xxx.xxx), > we request that you immediately do the following: > > 1) Contact the subscriber who has engaged in the conduct described > above and take steps to prevent the subscriber from further downloading > or uploading Warner Bros. Entertainment Inc. content without authorization; and > > 2) Take appropriate action against the account holder under your Abuse > Policy/Terms of Service Agreement. > > On behalf of Warner Bros. Entertainment Inc., owner of the exclusive rights > in the copyrighted material at issue in this notice, we hereby state that > we have a good faith belief that use of the material in the manner > complained of is not authorized by Warner Bros. Entertainment Inc., > its respective agents, or the law. > > Also, we hereby state, under penalty of perjury, that we are authorized > to act on behalf of the owner of the exclusive rights being infringed > as set forth in this notification. > > We appreciate your assistance and thank you for your cooperation in this > matter. Your prompt response is requested. > > Any further enquiries can be directed to copyright(a)ip-echelon.com > Please include this message with your enquiry to ensure a swift response. > > Respectfully, > > Michael Lambert > Enforcement Officer > IP-Echelon > Email: copyright(a)ip-echelon.com > Address: 6715 Hollywood Blvd, Los Angeles, 90028, United States > > > - ------------- Infringement Details ---------------------------------- > Title: Pacific Rim > Timestamp: 2013-11-26T20:00:37Z > IP Address: 44.xxx.xxx.xxx > Port: 51963 > Type: BitTorrent > Torrent Hash: 0d8c999ddbe439117fbc09899e2fb7fd2ea50bb2 > Filename: Pacific Rim 2013 1080p WEB-DL x264 AC3-JYK > Filesize: 3413 MB > - --------------------------------------------------------------------- > ----- End forwarded message ----- > _________________________________________ > 44Net mailing list > 44Net(a)hamradio.ucsd.edu > http://hamradio.ucsd.edu/mailman/listinfo/44net > http://www.ampr.org/donate.html -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

4 3

Re: [44net] SWIP/rwhois (was DMCA)
by Bryan Fields 27 Nov '13

27 Nov '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/26/13 6:46 PM, Marc, LX1DUC wrote: > On 27/11/2013 00:12, Bryan Fields wrote: >> > In my example, how can I get 254.98.44.in-addr pointed at my DNS >> > servers? I don't see an ability to do this via the portal page. > You just don't. All revDNS for the AMPR/44net addresses end in > ampr.org. I don't see aproblem with that. Who says this should be? I can't find anything in the TOS or documents on ampr.org saying this is a requirement. I don't agree with this (for CIDR blocks), there are valid reasons to have forward and reverse matching DNS. If we had SWIP/rwhois working we could do this ourselves. Perhaps we need to put an APMRnet use case RFC together, but I'd rather have policy reached by a consensus if we're going to have non Internet standard requirements. Thoughts? - -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSlVXzAAoJEGWJwvsug9rS1KsIANZydzWyFWg6n1VCKaKrzo2A cZLpKhWgimDSjeT+bFX7GnbEWNSZ1peX5p+OQzrCGXqTxD3hDIiCrSB05UZp0p6c 9NhxFH9BtSNlgaVdkV6k9sbcPkY7wieYB9l0AWSgQMnKOJHbWM/6Vu4ndFbJwqig 8diMiIQgbV4Yz1isHGkiVsDsC+qhKAQJUXH3kKCThUSMK3o7ANZk5X2BEU2F94D2 9Q9ai/TNx7cr7YXlYFRiLa7xTR/ExeQEZDzNOSl2Sx1N0YvB9qkdAVEfb1Jf/XB+ ijMFVMMMVISGy5bRUgYXHWLCDvbPJusmUi+JC76lwZWN6qREidQItecavt6ENGQ= =aqgE -----END PGP SIGNATURE-----

1 0

Re: [44net] DMCA
by Bryan Fields 26 Nov '13

26 Nov '13

On 11/26/13 6:06 PM, Brian Kantor wrote: > We don't handle the DNS through the portal; there's a robot that > handles updates to the DNS hourly and updates both the AMPR.ORG and > 44.in-addr domains. Every net-44 A record in the ampr.org domain has > a corresponding PTR in the in-addr domain. > > Note that the 44.in-addr domain was delegated to us long ago; ARIN does > not update it at all except to handle changes to our nameserver constellation. > We do not currently further delegate the in-addr domain. In my example, how can I get 254.98.44.in-addr pointed at my DNS servers? I don't see an ability to do this via the portal page. I understand I can make DNS entries for ampr.org and have those mapped, but not everyone is going to use ampr.org. I use kb9mci.net, and yes it's down now, I'm moving boxes around and hamradio takes a back seat to travel for work :( -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 2

Re: [44net] DMCA
by Bryan Fields 26 Nov '13

26 Nov '13

On 11/26/13 5:52 PM, Brian Kantor wrote: > I don't understand what you mean by that; I thought we were doing a good > job of providing in-addr entries for every registered host. What am I missing? Unless I'm missing something, that has to be in the portal on a per IP basis. With SWIP you can designate a different DNS server for a subnet. (well actually it's arin updating the DNS records keyed off swip, but same difference). Is there a way to do this in the portal now? I didn't want to put down the portal service, but I was just saying that it might be easier to let ARIN do the updates for us than to run our own rwhois server. If we can do it, sure rwhois is great, but we're not changing/updating more than a few records a month, are we? -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

2 1

DMCA
by Brian Kantor 26 Nov '13

26 Nov '13

Probably most of you folks haven't seen one of these before. This is the kind of notice I receive and have to respond to when one of the users of network 44 misbehaves. Keep in mind that this is a violation of our terms of service and is cause to have network access revoked. Please be careful not to cause me to get more of these. Thank you. - Brian PS: I've obscured the IP address because the matter is already being dealt with by the persons concerned. ----- Forwarded message from IP-Echelon Compliance <notices.warner(a)ip-echelon.com> ----- Date: Tue, 26 Nov 2013 20:19:33 +0000 From: IP-Echelon Compliance <notices.warner(a)ip-echelon.com> To: bk29(a)ucsd.edu Subject: Notice of Claimed Infringement - Case ID 1335xxxxx -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear bk29(a)ucsd.edu We are writing this message on behalf of Warner Bros. Entertainment Inc.. We have received information that an individual has utilized the below-referenced IP address at the noted date and time to offer downloads of copyrighted material. The title in question is: Pacific Rim The distribution of unauthorized copies of copyrighted television programs constitutes copyright infringement under the Copyright Act, Title 17 United States Code Section 106(3). This conduct may also violate the laws of other countries, international law, and/or treaty obligations. Since you own this IP address (44.xxx.xxx.xxx), we request that you immediately do the following: 1) Contact the subscriber who has engaged in the conduct described above and take steps to prevent the subscriber from further downloading or uploading Warner Bros. Entertainment Inc. content without authorization; and 2) Take appropriate action against the account holder under your Abuse Policy/Terms of Service Agreement. On behalf of Warner Bros. Entertainment Inc., owner of the exclusive rights in the copyrighted material at issue in this notice, we hereby state that we have a good faith belief that use of the material in the manner complained of is not authorized by Warner Bros. Entertainment Inc., its respective agents, or the law. Also, we hereby state, under penalty of perjury, that we are authorized to act on behalf of the owner of the exclusive rights being infringed as set forth in this notification. We appreciate your assistance and thank you for your cooperation in this matter. Your prompt response is requested. Any further enquiries can be directed to copyright(a)ip-echelon.com Please include this message with your enquiry to ensure a swift response. Respectfully, Michael Lambert Enforcement Officer IP-Echelon Email: copyright(a)ip-echelon.com Address: 6715 Hollywood Blvd, Los Angeles, 90028, United States - ------------- Infringement Details ---------------------------------- Title: Pacific Rim Timestamp: 2013-11-26T20:00:37Z IP Address: 44.xxx.xxx.xxx Port: 51963 Type: BitTorrent Torrent Hash: 0d8c999ddbe439117fbc09899e2fb7fd2ea50bb2 Filename: Pacific Rim 2013 1080p WEB-DL x264 AC3-JYK Filesize: 3413 MB - --------------------------------------------------------------------- ----- End forwarded message -----

3 2

fortiwifi 60c
by Jean Létourneau 11 Nov '13

11 Nov '13

Hi, Anyone on this list have a fortiwifi 60c and can get their amrp.orgworking? Please contact me off list. ve2pkt(a)gmail.com 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: ve2pkt(a)ve2pkt.ampr.org Inet: ve2pkt(a)amsat.org or ve2pkt(a)gmail.com

3 3

dxc link needed
by Brian Rogers 11 Nov '13

11 Nov '13

Greetings list; Is anyone running a dxcluster who can link me in? Would appreciate it. email me off-list please. -- 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.

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net