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
All,
I've been doing some testing with the Type of Service and Differentiated
Services Code Point for tunl0. I've been working to determine if
connectivity to Ronen's camera's could be slightly improved from the
tunnel's perspective. I'm focusing on the improvements seen using hex
code 0xB8, known as High Priority Expedited Forwarding, or 'Virtual
Leased Line.'
I wanted you all to check your connections to me, and make sure that I'm
still reachable. Feel free to ping, or simply use my tool at
http://44.60.44.10/tools/trace/php-trace44.php/ to reach yourselves.
73,
- Lynwood
KB3VWG
> ip tunnel change tunl0 mode ipip ttl 64 tos B8 pmtudisc
> I can modify ampr-ripd (and amprd if needed) to periodically sent some
> data "home", locator and gateway callsign to 44.182.21.1.
> This would need an additional parameter, something like "-Lyo2loj at kn05or <http://hamradio.ucsd.edu/mailman/listinfo/44net>".
> This would allow me to put together a simple tracking database and show
> active nodes on a world map for everybody to gaze at :-)
Yes, it could send some fields like the software version and maybe the number of
routes it has put in the table, so it will be possible to debug things and be able
to notify users when a serious problem is discovered or protocol change is made that
requires update beyond some version number.
That could be done using MNDP or similar protocol sending to 44.0.0.1?
I would recommend having different fields for different information.
(sysop, locator, etc)
Way I the past I had something like this in my NET version. It used multicast to
224.0.1.31 which is a multicast address I registered for this purpose.
host 224.0.1.31
31.1.0.224.in-addr.arpa domain name pointer ampr-info.mcast.net.
You are welcome to use that address when required (probably not, just send over tunnel
to some real destination or 255.255.255.255)
Rob
If anyone is interested, I would propose an experiment.
I can modify ampr-ripd (and amprd if needed) to periodically sent some
data "home", locator and gateway callsign to 44.182.21.1.
This would need an additional parameter, something like "-L yo2loj@kn05or".
This would allow me to put together a simple tracking database and show
active nodes on a world map for everybody to gaze at :-)
Anyone interested?
Marius, YO2LOJ
So with Brians "pressure" on me (HI) i think i have found the problem ... it it the tunnel keep alive
and now the questions
1)Does it necessary to turn it on ?
2) why this uses source address of amprGW and destination of my local address maybe its a a bug in the Mikrotik tunnel ? what protocol keep alive uses ? is there anyone else here with mikrotik that have a keep alive open and know if he get same errors from AMPGW ?
I have changed the keep alive timing from every 10 to 610 seconds and the errors reduced to 2 every 15 minutes from about 100
Ronen - 4Z4ZQ
> Reverse engineering the protocol was a bit of a challenge. I couldn't
> find it documented in sufficient detail anywhere and wound up decoding the
> protocol format from the hex dump and decoding that wireshark provided.
Yes, that is kind of inconvenient. From the wireshark decoding I guessed that
it would be a float. Apparently not.
Wireshark shows that it is TLV data and what the types mean, and I knew that
you would be able to map the TLV to the hexdump.
Rob
