David:
Let me see what I can do about that. While iperf doesn't support user end
messages, I posted the basic info on http://kk7kx.ampr.org.
Assi kk7kx/4x1kx
PS: a week ago someone from the mailing list pinged me asking for contacts
in the IARC. Please send me a note again to assi(a)kiloxray.com so I can
forward it to the people I know. I should probably figure out how to check
the archives on the mailman but I have been pretty busy to poke the system.
-----Original Message-----
From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu
[mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of
David Ranch
Sent: Thursday, July 23, 2015 11:26 AM
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Iperf server for public use
(Please trim inclusions from previous messages)
_______________________________________________
Hello Assi,
> I'll leave the iperf server running on kk7kx.ampr.org for the benefit
> of the community. I combined both to operate on port 7000.
Thanks for doing this and I think this is a great way to not only validate
connectivity but also performance. One issue here is what performance
should people expect. I looked but it seems that Iperf doesn't support any
sort of banner to tell people something like "Internet connection is 10Mb/s
VHDSL@ MTU of 1480 - you should expect X throughput with a last hop latency
of 23ms".
Since that isn't supported (yet), can you tell us a little about your
network connection and maybe we can get this captured into the AMPR portal.
Would be very helpful!
--David
> Subject:
> [44net] Iperf server for public use
> From:
> "Assi Friedman" <assi(a)kiloxray.com>
> Date:
> 07/23/2015 05:50 PM
>
> To:
> "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu>
>
>
> Folks:
> I'll leave the iperf server running on kk7kx.ampr.org for the benefit of the
> community. I combined both to operate on port 7000. To connect, use the
> following basic syntax:
> TCP: iperf -c kk7kx.ampr.org -p 7000
> UDP: iperf -u -c kk7kx.ampr.org -p 7000
> If you do use it, please be considerate.
> Thank you,
> Assi kk7kx/4x1kx
Still no connectivity whatsoever with your system....
No ping, no tcp, no udp.
This is from 44.137.0.0/16. How do you route there?
Rob
I noticed the same thing, unable to reach kk7kx.ampr.org
I am running iperf on the same ports (till my next reboot) on
44.92.21.35, which should be reachable both ways for anyone who cares
to mess around.
Note: the gateway this host is behind is a residential cable modem
15/1 Mbps, nothing impressive.
________________________________
>> Subject:
>> Re: [44net] Packet loss through UCSD?
>> From:
>> Assi Friedman <assi at kiloxray.com>
>> Date:
>> 07/21/2015 06:28 AM
>>
>> To:
>> AMPRNet working group <44net at hamradio.ucsd.edu>
>>
>>
>> Oops, left out the host name: kk7kx.ampr.org
>> TCP -> port 7000
>> UDP -> port 7001
>> Thanks,
>> Assi
>> kk7kx/4x1kx
>
>It does not reply at all, not even to ping.
>The tunnel endpoint can be pinged.
> Subject:
> Re: [44net] Packet loss through UCSD?
> From:
> Assi Friedman <assi(a)kiloxray.com>
> Date:
> 07/21/2015 06:28 AM
>
> To:
> AMPRNet working group <44net(a)hamradio.ucsd.edu>
>
>
> Oops, left out the host name: kk7kx.ampr.org
> TCP -> port 7000
> UDP -> port 7001
> Thanks,
> Assi
> kk7kx/4x1kx
It does not reply at all, not even to ping.
The tunnel endpoint can be pinged.
Rob
What is the AMPRGW machine based on?
Assi
-----Original Message-----
From: 44net-bounces+assi=kiloxray.com(a)hamradio.ucsd.edu
[mailto:44net-bounces+assi=kiloxray.com@hamradio.ucsd.edu] On Behalf Of
Brian Kantor
Sent: Monday, July 20, 2015 10:32 PM
To: AMPRNet working group <44net(a)hamradio.ucsd.edu>
Subject: Re: [44net] Packet loss through UCSD?
(Please trim inclusions from previous messages)
_______________________________________________
> > On 2015-07-20 17:41, Assi Friedman wrote:
> >> and rather poor packet loss. Are there any issues or QoS policies
> >> implemented on the amprnet router at UCSD?
There's no QoS policy in effect, but 'amprgw' is getting hammered at the
moment, with inbound packet drops peaking in the 25% range so performance is
going to be horrible.
It's hard to see precisely what's happening but it looks like multiple hosts
(possibly a botnet) are sweeping through the 44/8 range looking for
something.
There's not much we can do about this in the short term. Long term includes
a higher-performance machine with faster network interfaces.
- Brian
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
Sounds like an excellent research topic for a UCSD summer intern.
(Please trim inclusions from previous messages)
_______________________________________________
It's hard to see precisely what's happening but it looks like multiple hosts
(possibly a botnet) are sweeping through the 44/8 range looking for
something.
> Subject:
> [44net] Some hosts from net, rest masq'd?
> From:
> Steve L <kb9mwr(a)gmail.com>
> Date:
> 07/19/2015 09:29 PM
>
> To:
> "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu>
>
>
> I had a guy ask me who I don't think is on this list yet, if its
> possible so have some 44 ips behind his gateway reachable from the
> public net, and all the remaining to use masquerading rather than the
> default 44/8 UCSD route. I told him I am sure it can be done.
>
> I am sure there is more than one way to do this. Here is what I came
> up with, I mark the traffic type by matching source address (I am
> using some hosts on my lan to test). Set a rule for that, and then
> finally set a route based on that rule.
I am doing that on my system as well, but rather than using a separate rule that
is matched by the mark, I use the mark to enable the masquerade in POSTROUTING.
(using a -m mark --mark 1 match)
But of course it can be done either way.
Rob
I had a guy ask me who I don't think is on this list yet, if its
possible so have some 44 ips behind his gateway reachable from the
public net, and all the remaining to use masquerading rather than the
default 44/8 UCSD route. I told him I am sure it can be done.
I am sure there is more than one way to do this. Here is what I came
up with, I mark the traffic type by matching source address (I am
using some hosts on my lan to test). Set a rule for that, and then
finally set a route based on that rule.
Here is what I have:
http://www.qsl.net/kb9mwr/wapr/tcpip/startampr-n3fe
I am not sure I am doing it right as the iptables marking and ip rules
are a little greek to me. I am looking for input, suggestions etc.
There may even be a much easier way that I haven't thought of.
It seems to work, but I have said that before and turns out I was
logged into something other than what I thought for testing. Seems a
bit sluggish from the net though, but maybe there is just congestion
right now.
Thanks
Steve, KB9MWR
Hi everyone,
I'm just starting to setup an AMPRNET node and am running into some
difficulty setting up a Linux gateway using the rip44d daemon and was
hoping someone has some pointers.
I've been following this guide:
http://wiki.ampr.org/index.php/Ubuntu_Linux_Gateway_Example and start
running into trouble once I try and get the rp daemon running. I've
managed to download and extract the latest tar file from:
http://www.yo2loj.ro/hamprojects/ampr-ripd-1.13.tgz and it seems to
compile and install fine. The next step, according to the guide, is to
run ./find_pass.sh but when I do that I get the error:
Tunnel socket: Setting SO_BINDTODEVICE: No such device
I took a look at the contents of the find_pass.sh file and it seems to
contain the command ./ampr-ripd -d -i ampr0 so I decided to run
./ampr-ripd -d -i eth0 from the command line and I get the message:
Waiting for RIPv2 broadcasts...
but it never prints out the "secret" password. I am running Debian
Jessie as my OS and have registered a gateway on the ampr portal. Just
wondering if there's something obvious I'm missing here?
Cheers,
Chris
VE7ALB in Victoria BC||||
