> From: Robbie De Lise <robbie.delise(a)gmail.com>
> To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
> Subject: Re: [44net] 44net problems - was: 44net cool toys
>
> We announce 44.144.0.0/16 over BGP to the public internet (in Belgium)
> This ip space is then run on our local variant of "hamwan/hamnet" in
> Belgium on 2.4ghz accesspoints and 5ghz and recently 24ghz backbone
> links.
> [....] very interesting read trimmed
Well done! Very nice! I think the best way to set up my local HamWAN is
just to get off this list and go do it your way. Others can also make up
their mind for themselves.
Steve
Hi folks,
Is there a howto available that will tell me how to work the gateways robot?
I am almost done working on the subnet breakdown for NJ (I'm the NJ co-ord)
and will be needing to make some changes in order to put the plan into
place.
I'll be looking to add hosts to the DNS, change some existing hosts and
change the master NJ subnet gateway (currently pointed at my house).
I'm not proposing anything that hasn't already been done before. I'm simply
chopping up the subnet into further subnets and allocating them to each of
the counties with the "spare" numbers then being available for clever data
experiments should there be any.
Ordinarily I'd be doing this via the portal but ......
Thanks
Mark
G7LTT/NI2O
I was wondering if the 44 ip address can be use for ham mesh 2.4 GHz
channel 1 - 6? Reason for the question is from what I understand that is
the amateur radio
frequency and it should be ok? Hey just asking.
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]
On 3/22/14, 6:10 PM, Neil Johnson wrote:
> - Be sure read up on BCP38 http://tools.ietf.org/html/bcp38 to
> understand why your local ISP won't (and shouldn't) let you source
> traffic from IP addresses other than theirs
It's called peering. I'm not expecting the end users who don't understand
with a /29 to get on with it.
> - Explain how you would justify and obtain stable funding to get (and
> keep) an ASN for the 44-net address space ($500 initial, $100/yr
> maintenance from ARIN). An ASN is necessary for multi-homing and BGP
> routing.
I've stated I'd donate an ASN to AMPR. Money where my mouth is, etc. AFAIK
AMPR is not 501c3 with the IRS, so this is going to hold donations back.
> - Explain to me what financial incentive a commercial ISP has to
> routing (or peering with) 44-net address space for a small number of
> customers.
It's cool, lots of groups would peer with AMPRnet. We'd have to get people to
run gateways in different places around the world. Might need to start
talking to a few more people at NANOG/xNOG's but it's like finding a good
repeater site, you have to pound the pavement and talk to people. Law of
averages we'd find a half dozen companies that would do it.
The legitimacy of a 501c3 status would go a long way to help this.
>
> - As for using VPN's, explain how to pay for and maintain the
> appropriate size server(s) to host CPU-intensive VPN (IPSec and GRE)
> end-points.
Don't know why we'd need IPSEC on the backbone, GRE would be fine. GRE is a
hardware operation in most routers (I can only speak to ALU 7x50), but really
we're not pushing 100mbit/s, so it's a moot point. A linux/bsd box can do it.
> After understanding all the nuances of 44-net, I find that the mesh
> of IP-IP tunnels and the rip44d daemon are actually quite an elegant
> solution to the limitations and constraints we have to work with.
It's a dirty hack IMO. There is no reason we can't build a virtual backbone
that would provide 44net space to end users and give the users redundant (or
better!) routes to the internet.
73's
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
Hello fellows friends, now after an extended test period and when my office
allowed me time, I could achieve put online both YV gateways "
yv5kxe.ampr.org" and "yv5sat.ampr.org"
These systems have access to VHF packet radio network YVNET 145.010 Mhz and
are currently in the capital Caracas in different locations, the systems
are under Linux Slackware (for now), to access them please send my a email
with your login and password to place you in the ftpusers.
The whole problem of the update via RIP2 was the ISP modem that blocks
multicast RIP??? although saw the RIP packets incoming on JNOS monitor
screen from UCSD amprgw. The modem with this problem is SENDTEL ADSL2 +
Router MS8-8817 which I have changed to another ADSL brand (StartBridge)
now working perfect the encapsulation and RIP update.
Other experience to share....thanks and regards
73 de Gabriel YV5KXE.
Venezuela Amprnet
On Sat, 22 Mar 2014 19:33:14 +0100, YT9TP Pedja <yt9tp(a)uzice.net>
wrote:
>On 22.3.2014 16:14, Geoff Joy wrote:
>
>> Wiki's are a collective effort, what have you done to fix the flaws
>> you see there? Have you signed on as a Wiki editor? Have you written
>> articles for inclusion on that Wiki? Links go stale, there has to be
>> an "ugly bag of mostly water" behind the keyboard to keep a document
>> tree fresh and healthy, otherwise off-site links go bad when someone
>> drops dead or an organization folds. What are you doing in YOUR spare
>> time.
>>
>> I see a whole lot of room for improvement and a whole lot of
>> networking experts who can "advance the state of the art" but who
>> don't seem to be inclined to actually publish what they know.
>>
>> What I see above from both of you is "this is a mess, someone needs to
>> clean it up, but that someone isn't going to be me". I must boldly
>> state that if you have the time to discern a problem and criticize a
>> state of affairs, you have the time to take ownership of that problem
>> and fix it.
>
>
>I think you are on wrong track.
>
You might be right.
>Don't you see the pattern. People who consider themselves knowledgeable
>about networking want to get involved in 44net but they cannot
>understand it because there is lack of proper documentation.
>
Those who understand networking would be most likely to be able to
write proper documentation for 44net since the protocols involved are
no different than any other internet. AX.25 is nothing more than a
modified X.25. The only thing that changes is the medium of
transmission and the latencies.
>If they cannot understand and ask for better documentation, so they
>cannot learn, they are the last persons that should be advised to write
>that documentation.
I perceived hams criticizing other hams for not being "friendly" to
newcomers, I have been a victim of unfriendly hams myself in the past
and went out of my way to create a new environment in response to
that. My Elmer was the father of a high school friend who took time
out at the end of his workday to mentor us in Morse code. I didn't go
on to get my license until college, however.
>
>Documentation should be written by people who do have very good
>knowledge and experience with 44net.
>
I agree. And that experience best comes with experimentation. But is
44net so different that it's a completely different environment than
hardwired networking? I learned what I know about the protocols by
installing JNOS on a PC and poking and sniffing packets on air when
Windows didn't have a TCP/IP stack. Why is the reverse so difficult?
Current Wifi technology follows directly from the original wireless
development hams pioneered. Even SSID comes from us. The original
development follows directly from the University of Hawaii's
experiments with RF networking, which was well documented. Most of
this isn't "webified", it's all plain text on the FTP site. But yes,
my generation has let the new generation down, we left a plain text
legacy where everyone wants it all on a searchable Wiki and color
pictures.
>73
>Pedja YT9TP
>
>p.s. I am posting this directly to you, besides sending it on the list
>as my message cannot go through the list - almost all my messages return
>back marked as blacklisted.
>
I'm posting my reply directly and also to the list so perhaps someone
can review the list logs and fix the rejection. Thanks for your input.
--
Geoff Joy - ke6qh -
AmprNet IP Address Coordinator for San Bernardino & Riverside Counties.
geoff(a)windomeister.com
> #authors identity deliberately removed
>Wiki's are a collective effort, what have you done to fix the flaws
>you see there? Have you signed on as a Wiki editor? Have you written
>articles for inclusion on that Wiki? Links go stale, there has to be
>an "ugly bag of mostly water" behind the keyboard to keep a document
>tree fresh and healthy, otherwise off-site links go bad when someone
>drops dead or an organization folds. What are you doing in YOUR spare
>time.
Well, I just spent two days researching at typing this review document.
Perhaps you think I idly blew it out of my armpit? I'm good, but not that
good.
[annoyed rant deleted]
I'm a 44net newbie as well, but I'm not a newbie at accurately documenting
"the problem", or "the global solution". Ask me to stop at any time.
As such, I will document what I use but I am not in a position to do the
rest.
Steve
Ok here's my opinion.
Technically, it's difficult for prospective members to connect a 44 subnet
of any type, using any method. It is not clear at all how this is ACTUALLY
done or what options are available.
The wiki should be the authoritative document, but ;
1.) The main page is all about how to edit the wiki and a logo
competition, and ONE LINE on how to set up a gateway - which the whole
reason people went to the wiki.
2.) The "Setting_up_a_gateway_on_Linux" wiki page has a broken link leading
to "common instructions for setting up a gateway", inviting newcomers to
consider that there ARE NO such instructions, at which point they'll
probably completely give up.
3.) The three main options, munge script, rip44d.pl and rip44.c are not
stated clearly, nor are there links to any such subsection, nor are these
options grouped from the users' perspective - namely their chosen platform,
be it JNOS, x86 Linux, OpenWRT, or METARouter.
4.) There's no real index to what people are actually DOING over the 44net,
and people ARE DOING some cool stuff. If there were some page in the wiki
where people shared what they were making, then others might duplicate
their efforts.
Sysadmins on the portal are reluctant to issue /24s, when there's lots and
lots available.
The portals' "Law and Jurisdiction" section in the terms and conditions
insults the user. Most of the rest of that section is pretty unsavoury too.
WISPs and others who want to peer don't have access to any toolkit or
support.
Some stuff in the portal doesn't (or didn't) work, and it's not clear which.
There's not really an apparent reason WHY newcomers might even WANT to
number a network with 44. It's simpler to just throw a DHCP server at an
interface and add some routing - easy peasy, why number the network with
44, and if they did - HOW to do that?
It's not really clear to network builders, that they can actually number up
with 44 right now, and worry about connecting to other 44/xx Networks later
when they're ready. If they want to expose several 44/24's to the wild
internet, then that doesn't really affect anyone else but themselves.
All this tunnelling really is an unstable mess. Apart from allowing the
wild internet to connect inbound, why not just route the whole thing?
HTH,
Steve
--
Meshnetworks - Rangitaiki Plains Rural Broadband Internet Providers
+64 21 040 5067
Lets keep this discussion going - we can change things.
Quoting as required;
> Ubiquiti & Mikrotik are great for building highspeed wireless ip networks
Yup I have three APs on 2.4 and another three on 5.8 on a mountain top
site. No 44 on it, because the routing daemon doesn't work on Mikrotik.
And the gear costs almost nothing - compare a "new transceiver" for these
bands compared to a "new transceiver" for any other band.
> If we could change the demographics of the hobby that would help.
I take your point, but you get on PSK31 and have a look at the age
demographic there - be prepared to be shocked to see many of these
operators over 60y.
> You have to have something first to entice them.
Agreed. We need cool toys! And there ARE PLENTY.. As in the next
paragraph - engage with these groups and offer them our product.
> How many people even know about the 44net
> space? Maybe we need to reach out to;
>
>-The broadband-hamnet developers - presently
>they use 10.X.X.X address space
>
> -VOIP developers, like IRLP, Echolink, and Allstar.
>
> -Hams who run internet servers, like qsl.net, etc
>
I think your suggestion is paramount. I submit this is a way forward, if
not THE way forward.
> Then there is the issue of how to integrate 44net into your home network.
Agree completely. Do we need a dial-in PPP server for those who "just want
a 44/32" ?
>The second problem is regulatory. Data bandwidth issues, content issues..
all deturants.
I agree, but the problem is not what quite you suggest here.
I think we need to ditch this attitude of heavily self-regulating
ourselves. Hams have traditionally held this concept dear - one of overtly
interpreting the rules heavily in our own disfavor. I don't think we do
ourselves any positive service at all with this, particularly so when the
result is we now stop and do nothing at all because of our own attitude.
If some user does something inappropriate, it is normal to warn once then
revoke access for some time - a normal and acceptable approach anywhere. I
think we should free our attitude up a little.
There have been issues of bandwidth as well, but these days a VDSL or fibre
connection isn't expensive, and neither is 100G of data to go with it.
Steve
--
Meshnetworks - Rangitaiki Plains Rural Broadband Internet Providers
+64 21 040 5067
Sorry for the OT, but this does effect us all in the US.
The FCC has invited public comment on a Petition for Rule Making (RM-11715)
that would make a significant portion of the 10.0 to 10.5 GHz band available
for wireless broadband services. The Petition by Mimosa Networks Inc proposes
a band plan for 10.0 to 10.5 GHz that, it says, would protect frequencies most
often used by radio amateurs. The petition hinges on FCC adoption of rule
changes that would put the 10 GHz band under Subpart Z of the Commission’s
Part 90 rules. Subpart Z currently sets out regulations governing wireless
licensing, technical standards, and operational standards in the 3650 to 3700
MHz band.
I've made my comments on this, and would invite other hams to do so. I feel
I'm uniquely qualified to see this from both side as I owned a WISP before.
http://mimosa.co/support-our-petition.html is the link mimosa networks has on
how to comment. I'd encourage you to comment on this, as it will negatively
affect the amateur radio allocation on the most popular microwave band.
Feel free to steal from my comments below:
Comments on RM-11715 Petition for Rulemaking from Mimosa Networks
regarding the 10.0 to 10.5 GHz band.
I am uniquely qualified to comment on this petition as both a licensed
Amateur Radio operator (callsign KB9MCI), and former owner of a Wireless
Internet Service Provider, Illiana Internet LLC from 2000-2006. Currently I
work as Consulting Engineer in the Cellular and Service Provider space. I
have built and operated many amateur radio microwave stations in the 3CM (10
GHz) band.
Wireless Internet Service Providers (WISPs) present themselves as a group
providing Internet to the rural and underserved communities of the USA. To an
extent this is true, however their services are not a substitute for fiber and
wire line carriers. WISP’s are typically a small business, lacking the
capital and skilled engineers needed for day-to-day operation of a multi-site
wireless network. There is little incentive to design with good RF
engineering practices, as most WISP’s lack the ability to hire competent RF
engineers, and supply them with the tools they would need (Spectrum analyzer,
test equipment, etc.).
This lack of RF engineering knowledge leads to inevitable interference
between competing operators, and other users of the ISM and UNI bands. As
interference goes up, power and antenna size invariable increases (even
exceeding the EIRP FCC rules) to maintain service to their customers. This
cannot be allowed to happen in a band shared with weak signal users such as
the Amateur Radio Service.
I am in favor of more spectrum for WISP’s and ideally this would be sub 7
GHz, however if it must be shared spectrum, it needs to be shared with users
that can tolerate a higher noise floor. Weak signal services such as amateur
radio or GPS satellite should not share with such use. Spectrum should be
aligned with international users as well in my opinion; a 10GHz band use under
the Mimosa proposal would be incompatible with this.
The requirements in the 10.0 to 10.5 GHz band as proposed allow a
non-restricted contention based protocol. This should not be permitted in any
case. The amateur radio use of this band is based on such contention-based
protocols (i.e. listening before transmitting). This will encourage WISP
users of this band to run hotter systems to “talk” over competing systems not
unlike what has happened in the ISM and UNI bands. This need for a restricted
contention-based protocol must be retained in any case.
DFS is proposed to avoid co-channel operation with only radar systems.
This excludes the amateur use of these bands. Further threshold is -64 dBm,
which is well above level amateur systems operate at. Amateur use of the 10
GHz band is not “strong signal” fixed operations as point-to-point microwave
use is. Rather, Amateur use is characterized by weak signals and “pushing the
envelope” of RF path link budget. Amateurs may employ CW (A1A), SSB (J3E), FM
(F3E) and other emissions at these frequencies.
DFS needs to be a requirement for not only radar systems, but amateur
systems as well. Even with DFS as a requirement the proliferation of cheap
non-carrier grade WISP equipment from foreign vendors has the potential to be
“unlocked” with DFS and even the proposed protected bands at 10.350-10.370 and
10.450-10.500 GHz being illegally used by untrained operators. Further, most
equipment can be “hacked” to use such restricted channels.
This last point is not to be dismissed, as there have been numerous
actions by the FCC of 5.4 GHz interference from WISP’s to TDWR RADAR.
(http://www.fcc.gov/encyclopedia/weather-radar-interference-enforcement)
Others commenting in favor of this NPRM have been the recipient of Notices
of Liability and Fines for repeated violations of the requirements to operate
legally in the 5.4 GHz band (ex. EB-09-SJ-0014 – Aeronet Wireless Broadband,
San Juan, PR). What assurance can these operators give the commission and
the amateur radio community that they will not do this again? If this NPRM
is implemented and such interference effects amateur stations it would be
almost impossible for the commission to enforce, as amateur stations are not
fixed or as critical as TDWR RADAR stations are. This would be an
incompatible use.
In 10 GHz amateur operation using narrow bandwidth useful signals may be
below the -174 dBm/hz common minimum discernible signal noise floor,
especially in amateur satellite service, or in Earth Moon Earth (EME) where
signals are reflected off the moon. Further for DFS to work, these narrow
band signals would need to be detected by a receiver with a 20 MHz receive
bandwidth. In these wide band commodity receivers an amateur radio signal at
-130 dBm would not be detected even in the absence of signal. As DFS is not
required to act on a signal less than -64 dBm most amateur radio communication
use would not trigger it. Even more so in the amateur satellite service from
10.450-10.500 GHz, severe interference would be caused by normal operations by
the WISP radios raising the effective noise floor.
An amateur satellite receiver has a wide band pre-amplifier, such strong
signals even 20 MHz removed from the intended signal would require expensive
and high signal loss pre-selective filters. Would Mimosa networks intend to
pay for these filters for every amateur radio receiver? What of current
satellite receivers in orbit that cannot be retrofitted?
The proposed strong signal use adjacent to the Amateur Satellite service
at 10.450-10.500 GHz by channel 21 is without technical precedent. A receiver
on a satellite would hear every strong broadband transmitter in its footprint
as it passes over the US. This interference would cause amateur radio
operators far removed from the transmitter to be unable to communicate through
satellites they had previously been able to communicate through. I would
refer to the LightSquared Petition to the FCC for use of ancillary terrestrial
component equipment in its spectrum and the impact on GPS receivers.
Based on these facts I would ask the Commission to deny the Mimosa petition.
73's
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
