New 44net user/coordinator here.
Following the wiki (at ampr.org) I think I found an issue with the
documentation when using Ubuntu 14.04.
The ifconfig multicast command I believe has been deprecated. It didn't set
multicast on my ampr0 device. I was able to set the flag on when I ran the
following command after referencing the manpage (
http://linux.die.net/man/8/ip) -
ip link set dev ampr0 multicast on
Can someone help me figure out if that's the only line deprecated? I
suspect the onlink route might also be awry because when i run 'ip route' I
don't see the route to send traffic to amprnet gateway at UCSD
Thanks!
Rial F Sloan II
KJ4IKD
GA AMPRNet Coordinator
Hello Maiko,
Is a general bruteforcing, root and admin attemps logins (telnet), see all
hour of all days, very more attemps with "root" in all 44.152...
73 de Gabriel YV5KXE
yv5kxe.ampr.org
Message: 1
Date: Thu, 8 Jan 2015 09:37:29 -0600 (CST)
From: Maiko Langelaar <maiko(a)pcs.mb.ca>
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: [44net] lots of telnet attacks from china, australia
Message-ID:
<alpine.LNX.2.02.1501080934570.12131(a)shodan.physics.umanitoba.ca>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Is it just my system ?
I'm seeing many many login attempts as root on telnet.
Are they targetting just 44 ?
Maiko / VE4KLM
As we're a technically savvy bunch, can I ask that when posting to the list
with a new message not to reply to another and then change the subject?
This breaks threading and will cause issues when looking at the archives.
I'm simply asking this as a user of the list who uses a threading MUA.
Thanks & 73's
W9CR
--
Bryan Fields
727-409-1194 - Voice
727-214-2508 - Fax
http://bryanfields.net
I run a software that watches the log book. It's called "Fail2Ban".
I have it watch many system logs including JNOS. I have it set to look for
3 failed attempts from the same IP address and then it bans that IP address
for a month.
It must ban at least 20-30 ip addresses a day. Most are from China.
Wm Lewis
KG6BAJ
At 07:37 AM 01/08/15, you wrote:
>(Please trim inclusions from previous messages)
>_______________________________________________
>
>Is it just my system ?
>
>I'm seeing many many login attempts as root on telnet.
>
>Are they targetting just 44 ?
>
>Maiko / VE4KLM
>
>_________________________________________
>44Net mailing list
>44Net(a)hamradio.ucsd.edu
>http://hamradio.ucsd.edu/mailman/listinfo/44net
> Subject:
> Re: [44net] Tunnel mesh is (mostly) down
> From:
> "John Wiseman" <john.wiseman(a)cantab.net>
> Date:
> 01/04/2015 10:09 AM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Wouldn't the simplest solution be to modify the rip44 process so it doesn't
> delete routes that haven't been announced for a while, or at least for a
> much longer period?
>
> IPIP tunnels and RIP have the major advantage that they allow those who have
> a dynamic IP address to participate in net44. I feel it is important that we
> remember that we are radio hams first, and should use solutions that can be
> used by the majority of hams, not just those network professionals who want
> to play a being an ISP.
>
> 73,
> John G8BPQ
That sounds like a good idea, John.
The ampr-ripd has a route lifetime of only 600 seconds. Routes are announced every
300 seconds, so when two subsequent announces are incomplete we lose the route.
It happened again this morning at 08:05 local (07:05 UTC). My route again was lost, and
recovered at 08:10.
I think I'll recompile ampr-ripd with a bit larger timeout. Marius, what do you think?
Does this have any negative consequences? (e.g. to change EXPTIME from 600 to
3600 or even 7200)
However, aside from that, the source of the problem should be located, or it will bite us
again in the future. There could be big packet loss on the link from UCSD, or maybe
some buffer overflow internal to the RIP server (I think it sends big bursts of data rather
than slowly throttled streams), or it could be the RIP server somehow sends shortened
information because it temporarily does not have the full route list, e.g. because the
portal sends an incomplete list.
This has to be investigated or else it will come back. I predict.
(I mention this because I recently had a long discussion with someone who thinks that
we can live with malfunctioning solutions because we are amateurs. I think we should
strive for correctly working systems anyway. And that a system that works well in practice
is always better than a system that works well in theory but does not work in real life)
Rob
> Subject:
> Re: [44net] Tunnel mesh is (mostly) down
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 01/05/2015 10:54 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Yes, the latest version drops subnets for which the gateway is set inside
> their own subnet, sice this breaks routing.
>
> Marius
>
> -----Original Message-----
> From:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu
> [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Rob
> Janssen
> Sent: Monday, January 05, 2015 22:28
> To:44net@hamradio.ucsd.edu
> Subject: Re: [44net] Tunnel mesh is (mostly) down
>
> ...
> It could be that the latest version that I now downloaded hides that problem
> with 44.140.0.1
> but I can easily see if other routes are appearing/disappearing regularly.
> ...
>
> Rob
There is still something wrong with that network.
Now that the 44.140.0.1 gateway is rejected, a gateway 192.16.126.18 inconsistently
appears in the route table (sometimes it is there, sometimes it isn't).
But that gateway is not listed at all in the portal!
In the portal there is a gateway at 44.140.0.1 that advertises to be the gateway for
subnet 44.140.0.0/16, of course wrong. The 192.16.126.18 would be fine, but it does
not appear in the gateway listing at portal.ampr.org. But it is broadcast (occasionally)
in the RIP broadcast.
Difficult to follow what is going on here, I would say there is insufficient error checking
somewhere.
Rob
> Subject:
> Re: [44net] Tunnel mesh is (mostly) down
> From:
> "Michael E Fox - N6MEF" <n6mef(a)mefox.org>
> Date:
> 01/06/2015 12:32 AM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Hmmm. Given a 1 hour timeout, then any error would need to be detected and
> corrected within that hour, or else routes will still be lost. Correct?
>
> It would seem that a timeout of something more like 24 hours would be more
> practical.
The rationale behind the 1 hour timeout is not to cover errors and outages, although
it could cover cases where e.g. the server has to be relocated within the same room,
or network maintenance occurs.
The reason is that one of the hypotheses is that there is packet loss that drops the RIP
packets, and when two subsequent RIP bursts would each loss the last (or n'th) packet
e.g. because of a queue overflow somewhere the route would be already lost. The
chance of this happening to 12 subsequent broadcasts (1 hour) is smaller.
Further increasing the timeout would mean that a route that is no longer present would
take much longer to disappear, unless a mechanism as described by Marius is added.
(where a deleted route is announced in a special way)
With that modification, the timeout could be safely set to something like 1 week.
Rob
44net-request(a)hamradio.ucsd.edu wrote:
> Subject:
> Re: [44net] Tunnel mesh is (mostly) down
> From:
> "Marius Petrescu" <marius(a)yo2loj.ro>
> Date:
> 01/05/2015 07:30 AM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Hello,
>
> I don't think that increasing the route timeout the would have any bad side
> effects (I think 7200 would be a good value).
I have recompiled with 3600 before I read that. However, I'll keep a watch on it for some
time to see if strange things still happen.
It could be that the latest version that I now downloaded hides that problem with 44.140.0.1
but I can easily see if other routes are appearing/disappearing regularly.
>
> But maybe there is another mechanism that could be added to the ampr gateway
> (And which is already implemented in ampr-ripd):
> The daemon is capable of force exipring routes if they are received with
> metric 15.
> So adding the sending of deleted subnets with metric 15 fore a given time
> AND increasing normal expire time to higher values (e.g. 10800 - 3 hours, or
> even more) would make the system more stable.
>
> Marius, YO2LOJ
>
>
That sounds like a good idea, in that case there could be a much longer timeout, but
maybe it should then (as Brian suggested) log when it receives less packets than normal.
E.g. count the received packets in a single burst and syslog a message when it is 2-3 less
than in the previous burst.
When we fix the problem that routes disappear too soon, but then nobody notices anything
and 24 hours later we still have a problem because the routes are suddenly deleted, not
much has improved. When there is some alert I can watch it in our nagios monitoring.
Rob
> Subject:
> Re: [44net] Tunnel mesh is (mostly) down
> From:
> Brian Kantor <Brian(a)UCSD.Edu>
> Date:
> 01/05/2015 07:26 PM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> On Mon, Jan 05, 2015 at 02:27:18PM +0200, Marius Petrescu wrote:
>> >Let me get this right... You are talking about the encapsulated RIP
>> >transmissions originating from 169.228.66.251 to each public gateway IP?
>> >
>> >-----Original Message-----
>> >On Behalf Of Rob Janssen
>> >Sent: Monday, January 05, 2015 11:11
>> >To: Brian Kantor
>> >Cc:44net@hamradio.ucsd.edu
>> >Subject: Re: [44net] Tunnel mesh is (mostly) down
>> >
>> >Maybe something else you can do is drop the extra transmission of RIP
>> >packets from the public IP
>> >address. I think nobody is really using those (if not because of the funny
>> >destination port number), and
>> >they only add to this problem by putting even more data in the queue.
> Up until a few minutes ago, the amprgw system was sending the RIP data
> twice - once UNencapsulated to the public gateway IP, once encapsulated.
>
> Since to the best of my knowledge, no one was using the UNencapsulated RIP
> for anything, I've discontinued sending it.
>
> If I'm wrong and someone is using it for something, I'll turn it back on.
> - Brian
>
>
>
Note that those transmissions were sent to a seemingly random destination port number,
which made them kind of hard to use. The source port number was always 520.
I don't know if that was a bug or a feature, but it puzzled me when I was trying to receive
them and could not get the encapsulated transmission working in ampr-ripd.
(an issue that I later located and Marius made a change that fixed that)
Rob
