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
>
