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.
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
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 ;-)
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
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
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
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
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
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>
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
>
>
> 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
>
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
>
> 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
> 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
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
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
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
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
>
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
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
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..
>
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
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
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
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.
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
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.
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
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.
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
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.
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
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
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
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
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
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
- 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
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.orgyv5kxe.ampr.orgwww.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
------------------------------
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.
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
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
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.
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
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
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
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
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
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
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
> 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
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.
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?
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
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
=====================================================
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
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
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
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
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?
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.
----- 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
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?
> 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
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
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
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
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
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
=====================================================
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
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
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
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
-----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-----
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
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
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 -----
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
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.
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
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]
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
This is a quick message to my forwarding partners that on Sunday,
October 27, 2013, the SJVBBS (W6RAY) BBS will be offline for a short
time. The BBS will be moved to a Raspberry Pi with two TNC-Pis connected
to it. This setup will be located entirely at the repeater site (Park
Ridge) instead of via remote. The gateway IP address will remain the
same as will the AMPR IP addresses.
The setup is currently in testing using a different alias and SSIDs at
ground level. If the test is successful, then it will be installed at
the repeater site.
--
---
73 de Ray Quinn W6RAY
Visalia, CA DM06ih
SJVBBS W6RAY
44.2.10.1
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] SJVBBS W6RAY
> From:
> <sp2lob(a)tlen.pl>
> Date:
> 10/28/2013 04:03 PM
>
> To:
> "AMPRNet working group" <44net(a)hamradio.ucsd.edu>
>
>
> Brian,
>
> It's designed to accomodate _two_ Pi's only.
>
> Best regards.
> Tom - sp2lob
I investigated this before and there does not seem to be a rack enclosure for a reasonable number (like 4 or 5).
Probably the best bet is to get an old HUB or Switch, rip out all the electronics except the power supply, and
cut holes to fit the desired number.
There are also larger-scale custom made solutions, e.g. here: http://blog.raspberrycolocatie.nl/raspberry-pi-colocation/
I have a colocated Pi there.
Rob
I stumbled into a useful function that the Hamnet/HSMM folks have:
http://hsmm-mesh.org/hsmm-mesh-forums/view-postlist/forum-1-general/topic-5…
Maybe there is a way to do (code) something similar for the more
traditional nodes on the amprnet.
Advertising what is out there on a network seems to be a major issue
at least in my eyes.
Looking into networking some XBee Pro 900 Zigbee modules into a mesh
network on 902-928 MHz. I have the Digi development package and it
looks like I will need to either invent a TCP/IP stack for PC thru USB
to the Digi XBIB or else host the S3B radio on Raspberry Pi or
Beagleboards.
What are the groups thoughts on pros/cons on each?
Please if you need, update your ENCAP.TXT, as of this morning,
ve2pkt.ampr.org in back using a new gateway address.
Thank you.
73 de Jean
--
Sysop de: VE2PKT (BBS), VE2PKT-3 (X-NET),VE2PKT-4, VE2RAJ (XRouter)
: VE2RCN-1, VE2RDL-1, VE2RGC-1, VE2RVA-1, (The-Net)
: VE2PKT-9 (DXCluster), VE2PKT-10 (Winlink Gateway)
RF:
147.435 Mhz (1200 Bps)
Internet:
Telnet xrouter-ve2pkt.dyndns.org port 23 (Network Node)
Telnet fbb-ve2pkt.dyndns.org port 6300 (FBB BBS)
Telnet ve2pkt.dyndns.org port 9000 (DXCluster)
E-Mail:
packet: ve2pkt(a)ve2pkt.#qbc.qc.can.noam
ampr net: va2om(a)ve2pkt.ampr.org <ve2pkt(a)ve2pkt.ampr.org>
Inet: ve2pkt(a)amsat.org or ve2pkt(a)gmail.com
I am not sure that overclocking is relevant to NAND flash. The issue is
quality control for the device. NAND cells are simple and the process
drives reliability significantly. Vendors pay per quality, which translates
to a number of cycles the device will endure. Well known brands demand and
get better dies. Overclocking NAND will result in timing violations that
will lead to failed commands - but it will not damage the die. This is
different from the traditional overclocking to death of CPUs. The order of
magnitude of power makes a significant difference.
Assi
-----Original Message-----
From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu
[mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of
Jerry
Sent: Tuesday, October 22, 2013 4:11 PM
To: 'AMPRNet working group'
Subject: Re: [44net] Raspberry Pi
(Please trim inclusions from previous messages)
_______________________________________________
Hi Demetre.
Have you studied the Compatibility list... Some are shown to be a bad
choice.. Some Kingston are listed as such.
My first two SD cards I got from Fry's Electronics and they were I think,
PNY brands. PNY I have found even their USB Sticks are junk.. But the two I
got were only $4 ea.. Bad choice for the Pi. One lasted a few weeks the
other until I had a sudden power outage about 6 weeks into it.
I now have 2 Kingston SDXC Card 128GB Class 10 SDX10V/128GB Running on TWO
pi.. Or Pi Squared.. lol
One is under heavy abuse.. I have tried experimenting with sudden power
outages, and constant read writes on one unit... And it has not suffered any
issues.. In Fact I even tried it from -20F to +140F for S&G's They are NOT
OVERCLOCKED.
The other runs w9hu BBS Linbpq..
What do you use to image the SD card I used to use Windows program WinDisk32
.. I think this is the biggest issue with the Pi SD Cards..
At least I have had no issues with mine since I stopped that practice.
Also what are you using that requires an external HUB.. You can also connect
a TNC (other serial devices) to the GPiO port instead of the USB. Have you
tried a PiTNC yet? Makes good topping.. :) it is the same size and sits atop
the Pi. Like Icing!!
73 Jerry N9LYA
PS I ll try to get back one the conv server as time permits..
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44nethttp://www.ampr.org/donate.html
I have been running a test pi 128gb SD .running for 3 months. No issues with constant abuse... My linbpq pi been running same sd for 6...
-----Original Message-----
From: "Demetre SV1UY" <demetre.sv1uy(a)gmail.com>
Sent: 10/22/2013 5:40 PM
To: "AMPRNet working group" <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Raspberry Pi
(Please trim inclusions from previous messages)
_______________________________________________
Hi all,
If we are to use an external harddrive and an external USB Hub, why
not get a mini-ITX MBO powered with 12V and a small mini-ITX box? This
way we can have a decent CPU which is also low power in electricity
not low in computing power (about 30 watts total).
I think the RPi is only good in portable apps, but then again the SD
Card is a major handicap. It could be good for applications that are
not 24/7/365, such as an event where an AMPRnet GATEWAY is desired
only for a few hours or maybe a few days max. If you operate the SD
Card for more than a few days, it might get destroyed from the
constant write of log files, updating databases etc.
Can we have a system with no writting on the disk all the time? I'm not sure.
73 de Demetre SV1UY
On Wed, Oct 23, 2013 at 12:26 AM, K7VE - John <k7ve(a)k7ve.org> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> Yes, the Pi boots from the SD, but one can put files on an attached drive,
> especially swap, database, and logs. With a little configuration one could
> probably put everything except the boot configuration on an external drive
> and never write to the SD.
>
>
> ------------------------------
> John D. Hays
> K7VE
> PO Box 1223, Edmonds, WA 98020-1223
> <http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
> <http://www.facebook.com/john.d.hays>
>
>
> On Tue, Oct 22, 2013 at 12:05 PM, <sp2lob(a)tlen.pl> wrote:
>
>> (Please trim inclusions from previous messages)
>> ______________________________**_________________
>> SD card is the _must_ for Pi to boot...
>> To my knowledge - there is no other choice.
>>
>> Best regards.
>> Tom - sp2lob
>>
>> ______________________________**___________
>> 44Net mailing list
>> 44Net(a)hamradio.ucsd.edu
>> http://hamradio.ucsd.edu/**mailman/listinfo/44net<http://hamradio.ucsd.edu/mailman/listinfo/44net>
>> http://www.ampr.org/donate.**html <http://www.ampr.org/donate.html>
>>
>
Don't buy crappy SD cards - i.e. PNY. That is especially true in an
application where it's used 24/7 as a solid state drive. Wear leveling in
flash is very important and crappy flash won't endure.
Assi
Kk7kx.ampr.org
-----Original Message-----
From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu
[mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of
kb9mwr(a)gmail.com
Sent: Tuesday, October 22, 2013 8:59 AM
To: 44net(a)hamradio.ucsd.edu
Subject: Re: [44net] Raspberry Pi
(Please trim inclusions from previous messages)
_______________________________________________
It's funny how you though going away from a moving disk hard-drive would be
a good thing.
Anyway here are my experiences. I have several Pi's in use. I have had a
lot of head aches with PNY SD Cards. They go bad in rather short order. I
have had a few Sandisk cards that have been in use just over a year. I have
yet to have a problem with Sandisk.
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44nethttp://www.ampr.org/donate.html