> #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
>What needs to change? Why isn't there Ubiquiti all over them mountain
>ranges?
If we could change the demographics of the hobby that would help. But
to attract some younger tech minded folks is a chicken and egg type of
thing. You have to have something first to entice them.
The second problem is regulatory. Data bandwidth issues, content
issues.. all deturants.
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
It would probably help to have our own custom firmware or recommended
hardware. I have to admit, I have been doing everything on a
raspberry pi with a usb ethernet dongle for the second port. I
haven't tried to install the custom rip daemon on something like a
WRT54G or ??
Then there is the issue of how to integrate 44net into your home network.
Well, we suck don't we. I got issued my first 44net IP nearly 30 years
ago, and now back after a "break", I find we don't have much.
What needs to change? Why isn't there Ubiquiti all over them mountain
ranges?
There must be more interesting things to do than fix the portal, track down
one stray packet per hour, or checkthat we don't dDOS the internet..gasp...
I'm sorry, but we suck.
Steve ZL1BHD
Folks, if you're running NTPD (Network Time Protocol daemon) on your
AMPRNet hosts or routers, please be sure that the MONLIST command is
disabled. If it is not, your device can be used to attack other
systems on the Internet.
You can test whether your NTP is thus misconfigured with the command
/usr/sbin/ntpdc -n -c monlist
If MONLIST is enabled, you will see a response including any IP addresses
that have made use of your NTP services.
Recommended Action:
NTPD versions prior to 4.2.7 are vulnerable by default; the simplest
recommended course of action is to upgrade all versions of ntpd that are
publically accessible to 4.2.7 or greater. In cases where upgrading is
not possible, disabling the monitor functionality can be accomplished
via the instructions below.
Add the “noquery” directive to the “restrict default” line in
the system’s ntp.conf, as shown below:
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
The links below describe the activity in more detail as well as possible
solutions.
US CERT Notifiacation:
https://www.us-cert.gov/ncas/alerts/TA14-013ACERT.ORG Message:
http://www.kb.cert.org/vuls/id/348126
Thank you
- Brian
Over the past few weeks, the portal has been subject to several brute force attacks on random usernames. In the past few days some accounts have been compromised because they used weak passwords. The attackers didn't do anything with any of the compromised accounts, it was most likely a script collecting valid usernames & passwords for later use.
As a result I have tightened up security and some accounts will tell you that you need to verify your email address when you try to login. Please follow the link to have the verification email sent to you, then follow the instructions in the email when you receive it.
Due to the enhanced security you will notice a CAPTCHA appears if you get your password wrong a few times, if you continually get your password wrong, the response time for the login process will get longer - this is intentional.
It would help greatly if you could use a strong password, one that is at least 12 characters in length and contains a mixture of letters, numbers and punctuation characters, no "real" words and no "numbers instead of letters", e.g. "numb3r".
Thanks,
Chris
