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
Hello Rob, thanks for your information, I changed to 44.0.0.1 from
169.228.66.251, but dont see here any rip broadcast from this IP, i
waiting if arrive in any moment.
73 de Gabriel.
YV5KXE
YV AmpNet Coordinator
44net-request at hamradio.ucsd.edu wrote:
> Subject:
> [44net] RIP UDP question
> From:
> Gabriel Medinas <gmedinas at gmail.com>
> Date:
> 02/26/2014 05:48 PM
>
> To:
> 44net at hamradio.ucsd.edu
>
>
> Hello all,
>
> I want test to receive the RIP2 broadcast in my JNOS but dont work:
>
> Trace jnos monitor:
>
> (tun0) 169.228.66.251->192.168.2.110 UDP
Don't use that version. Use the one that is from 44.0.0.1 ->
224.0.0.9 instead.
(there are two RIP broadcasts and some time ago Brian already considered to
stop the one from 169.228.66.251 to the public IP adress. This one is sent to
a different portnumber so your jnos probably does not recognize it)
Rob
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> [44net] RIP UDP question
> From:
> Gabriel Medinas <gmedinas(a)gmail.com>
> Date:
> 02/26/2014 05:48 PM
>
> To:
> 44net(a)hamradio.ucsd.edu
>
>
> Hello all,
>
> I want test to receive the RIP2 broadcast in my JNOS but dont work:
>
> Trace jnos monitor:
>
> (tun0) 169.228.66.251->192.168.2.110 UDP
Don't use that version. Use the one that is from 44.0.0.1 -> 224.0.0.9 instead.
(there are two RIP broadcasts and some time ago Brian already considered to
stop the one from 169.228.66.251 to the public IP adress. This one is sent to
a different portnumber so your jnos probably does not recognize it)
Rob
Hello all,
I want test to receive the RIP2 broadcast in my JNOS but dont work:
Trace jnos monitor:
(tun0) 169.228.66.251->192.168.2.110 UDP
0000 ........pLaInTeXtpAsSwD.....,.......[yZ.........,.........Y.....
0040 ....,.......E..>........,.......Q.v>........,I@.....2.D>........
0080 ,.@.....[yZ.........,.......[yZ.........,I......2.D>........,...
00c0 ....W...........,...................,........K..........,.......
0100 ............,........&..........,^..................,.......v...
0140 ........,........K..........,........K..........,.......yc......
0180 ....,........K..........,.......^e0.........,........K..........
01c0 ,........K......
(tun0) 192.168.2.110->169.228.66.251 ICMP UnreachablePort
Returned 169.228.66.251->192.168.2.110 UDP
192.168.2.110 is my JNOS IP in LAN (also 44.152.0.60)
169.228.66.251 (amprnetgw-ucsd)
The jnos return a ICMP UnreachablePort, have check firewall, ip
forwading in opensuse 13.1 linux, router and in my autoexec.nos:
ip upstairs 224.0.0.9
rip ttl 43200
start rip
#rip accept 44.0.0.1
rip accept 169.228.66.251
rip trace 9 rip.log
My question, why my jnos said unreachablePort?
Thanks.
Gabriel YV5KXE
Thanks Chris.
Now if there is a problem originating from one of the gateways we know
who to get a hold of.
It may also be desirable if their callsign had a link to method of
contact (email) that is on file for them. But I heard a whois
function is in the works, and I assume that will have something like
that.
Steve
