- 44net - mailman.ardc.net

by Marius Petrescu

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

11 years, 10 months

2
2
0 0

Re: [44net] ampr-ripd 1.8 released

by Rob Janssen

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

11 years, 10 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 33

by Steve Wright

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

11 years, 10 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 32

by Rob Janssen

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

11 years, 10 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 31

by Rob Janssen

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

11 years, 10 months

2
1
0 0

Reg Exp

by William Lewis

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

11 years, 10 months

1
0
0 0

Mail Hacker

by William Lewis

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

11 years, 10 months

1
0
0 0

incoming traffic.

by John Ronan

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

11 years, 10 months

6
7
0 0

Re: [44net] Mail hacker

by kb9mwr＠gmail.com

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.

11 years, 10 months

1
0
0 0

Re: [44net] Mail Hacker

by kb9mwr＠gmail.com

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.

11 years, 10 months

1
0
0 0

Re: [44net] Mail Hacker

by Michael E Fox - N6MEF

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

11 years, 10 months

1
0
0 0

Re: [44net] Portal Down ?

by William Lewis

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

11 years, 10 months

6
14
0 0

Portal Down ?

by Neil Johnson

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

11 years, 10 months

12
14
0 0

annual reminders

by Brian Kantor

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

11 years, 10 months

4
4
0 0

Re: [44net] Portal Down ?

by William Lewis

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

11 years, 10 months

4
4
0 0

schema for portal backend database

by Eric Fort

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

11 years, 10 months

1
0
0 0

Re: [44net] Portal Down ?

by William Lewis

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

11 years, 10 months

1
0
0 0

Apologies for my absence

by VK4AA | VK4TTT Sam

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

11 years, 10 months

1
0
0 0

Hacking from IP Address 178.33.151.117

by William Lewis

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>

11 years, 10 months

3
2
0 0

Re: [44net] Hacking from IP Address 178.33.151.117

by William Lewis

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

11 years, 10 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 25

by Steve Wright

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

11 years, 10 months

1
0
0 0

Mikrotik RouterOS 6.9 bug

by Marius Petrescu

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

11 years, 10 months

1
0
0 0

44.12.3.97 please stop UDP 5678

by Michael E Fox - N6MEF

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

11 years, 10 months

7
8
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 24

by Steve Wright

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

11 years, 10 months

2
1
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 24

by kb9mwr＠gmail.com

> 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

11 years, 10 months

1
0
0 0

Re: [44net] Updated BGP design (was 44Net Digest, Vol 3, Issue 20)

by Bryan Fields

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

11 years, 10 months

10
13
0 0

Re: [44net] DNS records 44.131.56.0/24

by Michael E Fox - N6MEF

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

11 years, 10 months

2
1
0 0

[nos-bbs] strange udp broadcasts...

by Nigel Vander Houwen

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

11 years, 10 months

4
4
0 0

Re: [44net] [nos-bbs] strange udp broadcasts...

by Don Moore

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 >

11 years, 10 months

6
7
0 0

Getting mikrotik router gateway connected to amprgw

by Ryan Elliott Turner

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

11 years, 10 months

3
8
0 0

Re: [44net] Updated BGP design (was 44Net Digest, Vol 3, Issue 20)

by Bryan Fields

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

11 years, 10 months

1
0
0 0

Re: [44net] 44Net Digest, Vol 3, Issue 20

by Steve Wright

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

11 years, 10 months

1
0
0 0

amprnet portal

by Eric Fort

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

11 years, 10 months

3
2
0 0

Newmembers

by Jerry

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

11 years, 10 months

1
1
0 0

Re: [44net] amprnet portal

by kb9mwr＠gmail.com

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

11 years, 10 months

1
0
0 0

Re: [44net] amprnet portal

by Bryan Fields

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

11 years, 10 months

1
0
0 0

Re: [44net] amprnet portal

by kb9mwr＠gmail.com

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.

11 years, 10 months

1
0
0 0

Are there (still) issues with SMP and/or x86_64 and AX25 on linux?

by Robert Brose

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

11 years, 10 months

3
2
0 0

DNS records 44.131.56.0/24

by Nick G4IRX

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.

11 years, 11 months

3
5
0 0

Re: [44net] DNS records 44.131.56.0/24

by Rob Janssen

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

11 years, 11 months

2
1
0 0

new ip

by Brian Rogers

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.

11 years, 11 months

2
1
0 0

Re: [44net] Help with 44.152 subnet

by Gabriel Medinas

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

11 years, 11 months

1
0
0 0

Status at URO

by Brian Rogers

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.

11 years, 11 months

4
5
0 0

Help with 44.152 subnet

by Gabriel Medinas

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

11 years, 11 months

2
1
0 0

n1uro offline

by Brian Kantor

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

11 years, 11 months

9
30
0 0

Re-thinking the internet

by kb9mwr＠gmail.com

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

11 years, 11 months

2
1
0 0

Link

by Jerry

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

11 years, 11 months

2
2
0 0

Gateways but no region network

by kb9mwr＠gmail.com

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

11 years, 11 months

2
1
0 0

Where to start

by Andy Brittain

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

11 years, 11 months

4
4
0 0

Re: [44net] known good routers that pass rip/44-net friendly in uk?

by Rob Janssen

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

11 years, 11 months

8
18
0 0

Re: [44net] known good routers that pass rip/44-net friendly in uk?

by lleachii＠aol.com

- 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

11 years, 11 months

1
0
0 0

Re: [44net] gateways cleanup/deletion (Brian Kantor)

by Gabriel Medinas

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

11 years, 11 months

1
0
0 0

Hack fix for Pi

by Brian Rogers

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.

11 years, 11 months

9
13
0 0

AMPRNet Flow Charts

by Jann Traschewski

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

11 years, 11 months

1
0
0 0

gateways cleanup/deletion

by Brian Kantor

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

11 years, 11 months

3
3
0 0

Re: [44net] gateways cleanup/deletion

by Wm Lewis

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.

11 years, 11 months

1
0
0 0

Happy New Year

by Brian Kantor

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

11 years, 11 months

4
3
0 0

Re: [44net] Pi bug for ipencap?

by lleachii＠aol.com

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

11 years, 11 months

2
1
0 0

Re: [44net] Pi bug for ipencap?

by Rob Janssen

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

11 years, 11 months

3
2
0 0

Forgot robot password

by Assi Friedman

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

11 years, 11 months

1
0
0 0

Merry Christmas and a Happy New Year

by Glenn Bursell

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

11 years, 11 months

1
0
0 0

Merry Christmas & Happy New Year 2014

by Demetre SV1UY

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

11 years, 11 months

2
1
0 0

Re: [44net] Amprnet Gateway and Dynamic DNS.

by sp2lob

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

11 years, 11 months

4
3
0 0

data bandwidth in other countries

by kb9mwr＠gmail.com

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

11 years, 12 months

16
16
0 0

Re: [44net] data bandwidth in other countries

by Rob Janssen

> 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

11 years, 12 months

1
0
0 0

Re: [44net] data bandwidth in other countries

by kb9mwr＠gmail.com

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.

11 years, 12 months

1
0
0 0

Re: [44net] data bandwidth in other countries

by kb9mwr＠gmail.com

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?

11 years, 12 months

2
1
0 0

Raspberry Pi - NET44 Gateway.

by Kutche, Jerry (Mitchell) USA

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

12 years

6
13
0 0

Changes IP w 44.165.25.

by Janusz Przybylski SP1LOP

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

12 years

1
0
0 0

one-to-one translation of IP addresses?

by kb9mwr＠gmail.com

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

12 years

2
1
0 0

Tester requested.

by Jean Létourneau

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

12 years

15
31
0 0

unclaimed gateways

by Brian Kantor

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

12 years

17
31
0 0

Re: [44net] rip routes - how often?

by kb9mwr＠gmail.com

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

12 years

2
1
0 0

rip routes - how often?

by kb9mwr＠gmail.com

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?

12 years

2
1
0 0

Gateway Management

by Brian Rogers

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.

12 years

3
5
0 0

Re: [44net] unclaimed gateways

by VK4AA | VK4TTT Sam

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

12 years

2
1
0 0

OLSR over net 44?

by kb9mwr＠gmail.com

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?

12 years

4
4
0 0

Re: [44net] Raspberry Pi - FM transmitter

by Rob Janssen

> 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

12 years

2
1
0 0

Raspberry Pi - FM transmitter

by sp2lob＠tlen.pl

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

12 years

2
1
0 0

network size estimates

by Michael E. Fox - N6MEF

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

12 years

7
7
0 0

HAM TV Bulgaria

by lz4ny＠mail.bg

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

12 years

4
4
0 0

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

by lleachii＠aol.com

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

12 years

1
0
0 0

ipencap (4) via ddwrt ?

by lz4ny＠mail.bg

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

12 years

2
1
0 0

Help config eth1

by Janusz Przybylski SP1LOP

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

12 years

1
2
0 0

Chris Maness

by Michael E. Fox - N6MEF

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

12 years

1
0
0 0

Re: [44net] DMCA

by Bryan Fields

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

12 years

5
4
0 0

Re: [44net] DMCA

by Bryan Fields

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

12 years

2
1
0 0

Re: [44net] DMCA

by Bryan Fields

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

12 years

4
3
0 0

Re: [44net] SWIP/rwhois (was DMCA)

by Bryan Fields

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

12 years

1
0
0 0

Re: [44net] DMCA

by Bryan Fields

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

12 years

2
2
0 0

Re: [44net] DMCA

by Bryan Fields

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

12 years

2
1
0 0

DMCA

by Brian Kantor

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

12 years

3
2
0 0

fortiwifi 60c

by Jean Létourneau

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

12 years, 1 month

3
3
0 0

dxc link needed

by Brian Rogers

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.

12 years, 1 month

3
4
0 0

Linux Raid-1

by William Lewis

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

12 years, 1 month

1
0
0 0

Re: [44net] dxc link needed

by Janusz Przybylski SP1LOP

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

12 years, 1 month

1
1
0 0

Please delete this portal entry please

by Jerry

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

12 years, 1 month

1
0
0 0

please delete item in red.

by Jerry

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

12 years, 1 month

1
1
0 0

portal.ampr.org

by Daniel Curry

I would like to see that the portal.ampr.org get shut off until that all co-coordinators and owner, have the ability to changed networks that were submitted. I have a request to change the netmask from a /29 to a /26. All co-coordinators and the owner of the 44 network, for lack of words, are lock out from doing any changes. From my understanding is where the encap.txt file is being generated. 73's K6DLC -- Daniel Curry IPV6 Sage Certified PGP: AD5A 96DC 7556 A020 B8E7 0E4D 5D5E 9BA5 C83E 8C92 San Francisco/Silicon Valley AmprNet Co-coordinator [44.4.0.0/16]

12 years, 1 month

5
4
0 0

ON7LR Contest Cam

by Robbie De Lise

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

12 years, 1 month

3
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net