Thought maybe this is the place to let people know (as a courtesy I
suppose). I recently lost my static IP address (my bridge radio died
after 12+ years or so), looking at other solutions.
So in the meantime my existing IP address as noted in the encap.txt
and rip broadcasts will simply not respond to anything. No worries
about it being used by other entities, it's an IP on 'our system'
that no one else will ever use for a long time down the road.
I don't want to delete my entry in the portal, so I will try to get
some form of Dynamic DNS hostname in place as soon as possible, since
I am now using a DSL service as a temporary internet connection.
It might be a while, just saying.
Thanks for your understanding.
Maiko / VE4KLM
David,
For the purpose of placing devices on a world map a 6-position
gridsquare should be minimal and enough.
People wanting to send a more exact position can do it, but a 4-position
grid square is IMHO not sufficient. So for the moment, the receiving
side truncates the locator to 6 positions and converts that one to a
lon/lat value (the center of the subsquare).
Let me get this map running first and we will see where we go from there.
On 31.05.2017 03:58, David Ranch wrote:
> Hey Marius,
>
> If you are going to use grid squares instead of Lat/Long or GPS
> coordinates, could you maybe support addition resolution on the Grid
> square? For example, my high resolution grid square is CM97ai02ak
> <http://www.dxmaps.com/callbook/gmap.php> . Most people might only
> like to give say CM97, most people will give CM97ai, maybe others
> might give CM97ai02 .
>
> --David
>
>
> On 05/30/2017 01:43 PM, Marius Petrescu wrote:
>> (Please trim inclusions from previous messages)
>> _______________________________________________
>> Hello everyone,
>>
>> For the proposed experiment on creating a interactive dynamic map of
>> the ampr-ripd systems, I created a special version (2.2).
>>
>> The daemon accepts a new parameter -L <string>. If this string is
>> defined, it will be sent every 5 minutes to my gateway 44.182.21.1
>> via UDP to port 59001.
>>
>> The format I will use is plain and simple gwcallsign@locator, case
>> insensitive e.g. -L yo2loj@kn05or.
>>
>> If we will ned somehow more data, the string can be replaced wit
>> anything, it is just sent as it is and will be parsed by the backend.
>>
>> For the moment there is only a simple listener monitoring that port,
>> and I am working on the server and interactive map which will be
>> available at
>>
>> http://yo2tm.ampr.org/ampr-map/
>>
>>
>> For those that do not want to participate, there is no need to upgrade.
>>
>> And even if you do, not setting the -L parameter will not send any
>> data, the result being the same behavior like 2.1.1.
>>
>>
>> Download:
>>
>> http://www.yo2loj.ro/hamprojects/ampr-ripd-2.2.tgz
>>
>> http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.2.tgz
>>
>>
>> Have fun,
>>
>> Marius, YO2LOJ
>>
>>
>>
Brian,
That seems to have fixed it!
Thanks and 73,
-KB3VWG
----- Reply message -----
From: "Brian Kantor" <Brian(a)UCSD.Edu>
To: "lleachii--- via 44Net" <44net(a)hamradio.ucsd.edu>
Cc: <lleachii(a)aol.com>
Subject: [44net] Gateways errors at amprgate
Date: Wed, May 31, 2017 17:31
Well, damn. I restarted the ipip daemon and they went away.
Looks like it's time to debug the routing table maintenance routing.
The log shows a new route being added but it appears to have been
loaded on top of your route, thus misdirecting traffic. I'll work
on it. Sorry for the bug.
- Brian
On Wed, May 31, 2017 at 05:14:13PM -0400, lleachii--- via 44Net wrote:
> Odd...they're still being received (Eastern Daylight Time). Just a few
> moments ago:
Amprgw ignores the TOS field. I don't see how that would affect
anything here.
- Brian
On Wed, May 31, 2017 at 04:47:44PM -0400, lleachii(a)aol.com wrote:
> Brian,
> Since I noticed the connection issue, I switched back to ToS 0x00 (Default)...just to be sure.
>
> I can still reach other gateways directly... I'll check to make sure I'm receiving routes.
>
> - KB3VWG
Brian,
Since I noticed the connection issue, I switched back to ToS 0x00 (Default)...just to be sure.
I can still reach other gateways directly... I'll check to make sure I'm receiving routes.
- KB3VWG
----- Reply message -----
From: "Brian Kantor" <Brian(a)UCSD.Edu>
To: "lleachii--- via 44Net" <44net(a)hamradio.ucsd.edu>
Cc: <lleachii(a)aol.com>
Subject: [44net] Gateways errors at amprgate
Date: Wed, May 31, 2017 16:38
Everything is fine here as far as I can see.
I don't know why you got traffic for 44.62.1.x when you're
not the gateway for it. The route table has the proper route in it.
Nor do I know why you're having intermittent connectivity. The
cross-country link from Los Angeles to Washington doesn't seem to
be dropping packets.
And I've been at lunch so I wasn't fiddling with the router.
- Brian
On Wed, May 31, 2017 at 04:14:37PM -0400, lleachii--- via 44Net wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> Brian,
>
> Is everything OK at AMPRGW, I just received some VERY odd traffic (and I've
> been having interment connectivity):
>
>
> 2017-05-31 14:59:57.803 0.000 TCP 104.236.151.76:48212 ->
> 44.62.1.10:143 1 40 1
> 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 ->
> 44.62.1.14:22 1 48 1
> 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 ->
> 44.62.1.12:22 1 48 1
> 2017-05-31 15:00:32.321 0.000 TCP 125.212.218.198:65415 ->
> 44.62.1.10:22 1 48 1
> 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 ->
> 44.62.1.9:22 1 48 1
> 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 ->
> 44.62.1.11:22 1 48 1
> 2017-05-31 15:00:32.330 0.000 TCP 125.212.218.198:65415 ->
> 44.62.1.13:22 1 48 1
> 2017-05-31 15:00:36.520 0.000 TCP 213.32.7.73:44191 ->
> 44.62.1.10:22 1 40 1
> 2017-05-31 15:02:45.210 0.000 TCP 181.113.163.24:59150 ->
> 44.62.1.10:22 1 40 1
> 2017-05-31 15:03:08.697 0.000 TCP 186.134.5.194:51377 ->
> 44.62.1.12:22 1 40 1
> 2017-05-31 15:03:26.190 0.000 TCP 104.236.151.76:48281 ->
> 44.62.1.12:143 1 40 1
> 2017-05-31 15:03:28.222 0.000 TCP 117.9.45.58:47360 ->
> 44.62.1.11:22 1 40 1
> 2017-05-31 15:03:31.438 6.996 TCP 187.199.54.149:43075 ->
> 44.62.1.9:81 4 240 1
>
>
> 73,
>
>
> - Lynwood
> KB3VWG
>
> >44.62.1.8 / 29 Southern Virginia Gateway AB4MW
>
> _________________________________________
> 44Net mailing list
> 44Net(a)hamradio.ucsd.edu
> http://hamradio.ucsd.edu/mailman/listinfo/44net
Brian May you explain this error line apear in the errors of the gateways ?
169.228.34.84 44.0.0.1 702 [18] dropped: multicast inner destination address
All,
If your device runs Linux using the common script, and if you have a
desktop on AMPRNet, please test the following:
- run a speedtest at http://44.60.44.10/tools/mini/
- add Expedited Forwarding of IPENCAP packets by entering the following
on your router
'ip tunnel change tunl0 mode ipip ttl 64 tos B8 pmtudisc'
- run a speedtest again
*You MUST run this test on AMPRNet directly to my node.*
- Lynwood
KB3VWG
Hello everyone,
For the proposed experiment on creating a interactive dynamic map of the
ampr-ripd systems, I created a special version (2.2).
The daemon accepts a new parameter -L <string>. If this string is
defined, it will be sent every 5 minutes to my gateway 44.182.21.1 via
UDP to port 59001.
The format I will use is plain and simple gwcallsign@locator, case
insensitive e.g. -L yo2loj@kn05or.
If we will ned somehow more data, the string can be replaced wit
anything, it is just sent as it is and will be parsed by the backend.
For the moment there is only a simple listener monitoring that port, and
I am working on the server and interactive map which will be available at
http://yo2tm.ampr.org/ampr-map/
For those that do not want to participate, there is no need to upgrade.
And even if you do, not setting the -L parameter will not send any data,
the result being the same behavior like 2.1.1.
Download:
http://www.yo2loj.ro/hamprojects/ampr-ripd-2.2.tgzhttp://yo2tm.ampr.org/hamprojects/ampr-ripd-2.2.tgz
Have fun,
Marius, YO2LOJ
I do not see what all this tracerouting has to do with ToS/DSCP but I can add that we
have full support for ToS/DSCP in our local net and it works beautifully. We use the
top 3 bits of the ToS/DSCP to split the traffic in 8 queues in a Queue Tree (MikroTik feature)
on links with a defined bandwidth, and it is used in WiFi link equipment (Ubiquiti, MikroTik)
to split the traffic in 4 queues typically (WMM).
We mainly use EF (46) for voice, CS1 (8) for background traffic like backups, and have
CS2 (16) for a priority slightly above that. Default 00 is above that priority.
I see no latency effects of running a long backup over the same links used for the repeater audio
for our co-channel multi site repeaters.
Of course DSCP only works as long as it is not abused to get priority over fellow hams. It is like
using more power to wipe everyone else from the repeater... works until the others do it too.
Rob
