- 44net - mailman.ardc.net

by Rob Janssen

> I was wondering if the usual TCP window setting of 840 makes any sense in > our current mesh. > This setting was imposed by the assumption that our IP traffic will pass > over ax.25 connections, with their MTU and ACK limitations, and does not > affect AXIP, AXUDP or other transfer modes. I am using -w 0 to override this handling. Note that it does not work in the scenario you depict: the setting only has influence on an end-system (where tcp connections terminate), not on a forwarding gateway. Only when a gateway is an end-system as well, this setting has any effect. And in that case it is not likely it is operating over ax.25. I think it is the responsibility of end-systems on a slow ax.25 network to configure a proper window size. The gateway does not have a role in that. Rob

7 years, 11 months

1
0
0 0

Greetings All - Peculiar problem

by Tom Cardinal

This could be me or maybe not. I got online a few weeks ago with Lynwood's help without it I'd still be offline. Since then I've been attempting to take my script apart and put it back together in an attempt to understand what makes it work and what breaks it From a workstation on my segment I am able to ping, browse and pretty much do anything I'd expect to be able to do. The problem arises if I attempt to ping or traceroute on my gateway to anything in the AMPRnet. No matter what routes exist in my routing table (44) and what rules I create, any and all attempts to connect to an AMPR ip INSIST on going out through eth0 OR tries to use the external IP of my gateway box on the tunl0 interface. I'm using an ubuntu 16.04 lts box with the latest ampr_ripd (2.3). Configuration is: eth0 - isp provided address (DHCP) (IPTables Masqueraded interface for LAN) eth1 - home LAN on RFC 1918 IP space 192.168.1.254/24 eth2 - 44.98.63.6/29 My AMPR segment tunl0 - Tunnel to the rest of the AMPRNET. (no IP Address assigned) Asi Isaid earlier, from the gateway I can't initiate connections through the tunl0 interface even though everything works from an AMPR IP (listed in DNS) on my segment. I'm putting my start script up here. Firewall is in a separate script with nothing blocked at the moment (wide open), I normally run a pretty restrictive firewall and will re-lock it down when I get things sorted out. ---- startampr script ---- #!/bin/sh ### ENABLE IP FORWARDING ### sysctl -w net.ipv4.ip_forward=1 ### Allows traceroute to respond using 44net IP of tunl0 or br-amprlan echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr ### AMPRNet IPENCAP ### modprobe ipip ip tunnel add tunl0 mode ipip ### Bring the tunl0 interface up ### ip link set tunl0 mtu 1480 up ip tunnel change tunl0 ttl 64 pmtudisc ### ROUTING ### Set default route ip route add default dev tunl0 via 169.228.34.84 onlink proto 44 table 44 ### OPTIONAL LOCAL RULES ip rule add from 44.98.63.0/29 to 192.168.1.0/24 table main priority 22 ip rule add from 192.168.1.0/24 to 44.98.63.0/29 table main priority 23 ####REQUIRED RULES ### Handles routing between local AMPR segment and External AMPR network ip rule add to 44.98.63.0/29 table main priority 44 ip rule add dev tunl0 table 44 priority 45 ip rule add dev eth2 table 44 priority 46 ip rule add from 44.98.63.0/29 table 44 priority 47 ### RUN AMPR-RIPD /usr/sbin/ampr-ripd -i tunl0 -t 44 -a 44.98.63.0/29 -s -x '/etc/ampr/load_ipipfilter.sh' -p <password> #### End startampr script #### If I try to add a route to 44.0.0.0/8 with this command: ip rule add to 44.0.0.0/8 table 44 priority 48 and then I do "ip route get 44.0.0.1" I get the following output: root@blackjack:~# ip route get 44.0.0.1 44.0.0.1 via 169.228.34.84 dev tunl0 src 68.109.14.113 cache window 840 When the priority 48 rule in place, my workstation on my 44net segment loses connectivity through the tunnel... Perhaps my ip rule commands are incomplete. I know I'm close, but what am I missing? Are there any policy routing experts that can help explain what I'm missing and why what I have doesn't work if I try to ping/traceroute/mtr on the gateway? -- Tom Cardinal/N2XU/MSgt USAF (Ret)/BSCS/CASP, Security+ ce

7 years, 11 months

5
14
0 0

Mikrotik

by Jacek Grzona

Hello. Is there any probel for a few days with yo2loj script? For a few days I receive such a return in the logs of the mikrotik "Jun / 06/2017 13:21:00 script, error AMPR: To few RIP entries available" Regards SP2GCH

7 years, 11 months

8
24
0 0

tunnel window settings

by marius＠yo2loj.ro

I was wondering if the usual TCP window setting of 840 makes any sense in our current mesh. This setting was imposed by the assumption that our IP traffic will pass over ax.25 connections, with their MTU and ACK limitations, and does not affect AXIP, AXUDP or other transfer modes. The question is: Is there anyone forwarding TCP/IP over AX.25 at this moment? Because if not, we could drop that window setting in the routing daemons and get a more streamlined data flow. Marius, YO2LOJ

7 years, 11 months

3
2
0 0

AMPRNet DNS robot

by Brian Kantor

I'm planning on making some changes to the AMPRNet DNS robot that will significantly alter the transaction response format. It will still be human readable, but if you are analyzing the responses using software of some kind, you'll have some work ahead of you. How many of you who use the robot are using software to handle the responses? - Brian

7 years, 11 months

2
1
0 0

AmprNAT

by Brian

I have finished documenting and putting up on my website what I call AmprNAT. For those who attempting to get out via amprgate sourcing as their lan IPs, this not only will prevent this from occurring but also it will NAT you out as your gateway's IP... pending you're using a distro of linux. It requires a static route in your route pointing to your gateway, and then 3 lines of iptables rules. You may read about it at: https://n1uro.ampr.org/linuxconf/44nat.html I believe Lynwood is adding info on the wiki for this. -- I was reading a book about the history of glue... I couldn't put it down. ...think about it... -------- 73 de Brian - N1URO/AFT1BR email: (see above) Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode http://uronode.sourceforge.net http://axmail.sourceforge.net AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, New Jersey, Pennsylvania, Rhode Island, and Vermont.

7 years, 11 months

2
1
0 0

Reminder about Amprd for simple configurations

by Marius Petrescu

Hi, Since everyone seems to like to use the most unusual script with "original" settings without trying ever to understand what's happening, I would remind you that there is a more or less "plug-and-play" solution called amprd... Let's assume a system with: - 44net assignment: 44.128.1.0/24 - WAN on eth0 (let's assume 1.2.3.4) - LAN on eth0 (192.168.1.1/24) - AMPR on eth2 (44.128.1.0/24) - We choose our GW IP to be 44.128.1.1 and that the internet access from the system is already set up, with NAT and default gateway via WAN. Now: 1. compile (make) and install (make install) amprd 2. create the following /etc/amprd.cfg: ----------------------------------------------------------------- [ampr0] prefix = 44.128.1.1 rip_receive = yes rip_save = yes ----------------------------------------------------------------- 3. Set address 44.128.1.1/24 to your eth2 interface 4. Start amprd. And basically that's it: a fully functional mesh gateway. If you want access from the internet to your subnet, too, instead of just starting amprd, create the following ampr startup script: ----------------------------------------------------------------- amprd ip route add default via 169.228.34.84 dev ampr0 onlink table default ip rule add from 44.128.1.1 table default ip rule add from 44.128.1.1 to 44.128.1.0/24 table main ----------------------------------------------------------------- This should do the trick. Marius, YO2LOJ

7 years, 11 months

1
1
0 0

Portal IP hasn't changed in a few hours

by lleachii＠aol.com

All, Once again, my WAN IP and Subnet changed (about 5 hours ago now). I did reboot my GW; but my IP has not yet changed in the portal and I cannot reach other 44subnets or the Internet. I have logged in the Portal, removed the IP from the GW webform and hit save (leaving only the DDNS hostname). - Lynwood KB3VWG

7 years, 11 months

2
1
0 0

DDOS attack Monitor Sites

by R P

I think it might interest us as a users of a big network Maybe it has interest to you Brian as our network Manager http://www.digitalattackmap.com/#anim=1&color=3&country=ALL&list=0&time=173… http://map.norsecorp.com/#/

7 years, 11 months

2
1
0 0

Ampr-ripd experimental 2.3 version

by Marius Petrescu

Hello everyone, Since experimenting goes one, here a new ampr-ripd version that forces the sending of call home data to use the tunnel's IP as its source IP address. Tnx. Lynwood for pointing out that necessity. Interactive map which is 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.3.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.3.tgz Have fun, Marius, YO2LOJ

7 years, 11 months

6
19
0 0

Odp: Re: Ampr-ripd experimental 2.3 version

by Tomasz Stankiewicz

Marius et al. Presently my server employs ampr-ripd-2.3 Did not observed any issues so far. encap.txt file at the very beginning contains two entries: # # encap.txt file - saved by ampr-ripd (UTC) Mon Jun 5 03:20:34 2017 # route addprivate 44.0.0.1/32 encap 169.228.34.84 route addprivate 44.0.0.2/32 encap 169.228.66.251 RIP broadcast are coming through as before. Best regards. Tom - SP2L

7 years, 11 months

2
1
0 0

Odp: Re: Ampr-ripd experimental 2.3 version

by Tomasz Stankiewicz

An HTML attachment was scrubbed... URL: <http://hamradio.ucsd.edu/mailman/private/44net/attachments/20170605/f4bb34a…>

7 years, 11 months

1
0
0 0

Amprd v2.1 update

by Marius Petrescu

Hello everyone, To be in line with the latest ampr-ripd & co, here a new amprd version that forces the sending of call home data to use the tunnel's IP as its source IP address. Also, it supports multiple call home info's, one for each tunnel configured. Interactive map which is available at http://yo2tm.ampr.org/ampr-map/ For those that do not want to participate, there is no need to upgrade. Download: http://www.yo2loj.ro/hamprojects/amprd-2.1.tgz http://yo2tm.ampr.org/hamprojects/amprd-2.1.tgz Have fun, Marius, YO2LOJ

7 years, 11 months

1
0
0 0

Amprd 2.0 - map functionality and new GW IP

by Marius Petrescu

Hello, For those using amprd (like myself), here a small update: - added map notification every 5 min. There is a new config file parameter for it, check the example config - modified the default ampr gw address to the new IP. This has actually no effect until the RIP broadcasts for 44.0.0.1 will change to the new IP (44.0.0.1 still uses the old GW address). Older versions, like 1.5 and 1.6 will switch gateways automatically if presented with a new gw for 44.0.0.1 in the RIP data, so unless you want to be on the map with a blue dot, there is no urge to update (live map is at http://yo2tm.ampr.org/ampr-map/) As always: http://www.yo2loj.ro/hamprojects/ http://yo2tm.ampr.org/hamprojects/ Marius, YO2LOJ

7 years, 11 months

6
30
0 0

tcpdump

by gm4upx＠gb7jd.co.uk

Hello, With the changes taking place I have been monitoring both the " old " and the " new " addresses. I'm receiving rip broadcasts from both and additionally similar broadcasts to the two lines below on the " old " address only. amprgw.sysnet.ucsd.edu > 172.16.1.4: IP (tos 0x0, ttl 111, id 14685, offset 0, flags [none], proto UDP (17), length 90) 218-228-138-51f1.osk3.eonet.ne.jp.25465 > mb7njd.ampr.org.3544: [udp sum ok] UDP, length 62 I have little knowledge of the meaning of this and would appreciate someone explaining it to me. Thanks in advance. ( Monitored from eth0 at 172.16.1.4 which is in DMZ ) Regards, Ian..

7 years, 11 months

3
4
0 0

Re: [44net] hosts accessibility

by Rob Janssen

> Recently some important changes were > performed pertaining whole [44net] community. > Today I made few test in order to check > accessibility of [44net] hosts. Currently IPIP routing via the old amprgw is broken for our network. This is the result of several changes in the local config and at UCSD. I am not going to fix it, it should all be OK again after the change on monday. (it should not affect BGP routing of our network and traffic from other gateways) Rob

7 years, 11 months

1
0
0 0

No networks found in my region

by Quan Zhou

Hi 44net, I just signed up AMPRNet but wasn't able to find my country [China] in the list. So I tried to register a new region, am I doing it correct? Thanks. -- Regards, Quan Zhou E271C0D1BD90012B8D8EECF6F822BC9F8E1C35C8 quanzhou822(a)gmail.com https://keybase.io/qzhou

7 years, 11 months

2
2
0 0

Nevada coordinator

by James Sharp

I put in a request on 2017-05-18 for a netblock since I've moved to Nevada, but I haven't gotten the allocation. I can't seem to find a direct contact for the administrator.

7 years, 11 months

2
2
0 0

Map game for mikrotik routers

by Marius Petrescu

For those who want to join the map test with mikrotik routers: - create a new script containing a single line (replace the call and locator, of course): /tool fetch mode=http url="http://44.182.21.1:59001/mikrotik?id=yo2loj@kn05os" keep-result=no - in the scheduler get it to run every 5 minutes. That's it. ampr-ripd clients appear as green dots, MT routers as reddish ones. http://44.182.21.1/ampr-map/ Marius, YO2LOJ

7 years, 11 months

8
22
0 0

Gateways errors at amprgate

by R P

What is it ? 127.0.0.1 5.254.66.117 3 [19] dropped: non-44 inner source address 127.0.0.1 13.59.252.204 2 [19] dropped: non-44 inner source address 127.0.0.1 23.234.29.148 3 [19] dropped: non-44 inner source address 127.0.0.1 27.193.36.35 2 [19] dropped: non-44 inner source address

7 years, 11 months

3
21
0 0

Packet/protocol generator web page ?

by R P

Does anyone know if there is on the web place that i can give address and a protocol / port and it will send data according to the protocol / port i want ? Or has anyone the capability to do so ? I want to tests some firewall rules that i made ... Thanks Forward Ronen - 4Z4ZQ

7 years, 11 months

3
6
0 0

Re: [44net] mailing list security

by Rob Janssen

I think an adequate explanation for the URL-fetch mystery is that some people run a virus scanner or have their e-mail delivered to a mailservice that does scanning, and this scanner fetches all URLs in the message to check if they point to malware... No amount of validation of the subscribers will solve that problem. The only thing you can do is obfuscate the links, but that is incovenient for the reader. Similar problem: whenever you download a program, a second fetch is done by Microsoft/Google/Apple/whatever your favorite vendor to check what it is. I have seen this several times on a download server we run at work. Rob

7 years, 11 months

2
1
0 0

Map notification for generic systems.

by Marius Petrescu

I also added a notification method for generic systems (they will appear as grey dots). Schedule a 5 min cron job (or whatever is needed to get it done) with the following instruction: wget -O /dev/null http://44.182.21.1:59001/generic?id=test@AA00AA Replace test@AA00AA with your gateway_call@qth_locator This also will only work from 44net sources only. Have fun, Marius, YO2LOJ

7 years, 11 months

5
7
0 0

amprgw changeover schedule

by Brian Kantor

On Monday, around 0930 Pacific (1630 UTC), we'll be moving the inbound route for 44.0.0.0/8 from old amprgw to new. Shortly after, as soon as it's confirmed working, I'll turn off the RIP sender on old amprgw and you should stop seeing any more traffic from 169.228.66.251 (although the machine will stay up so we can archive it before turning it off). You'll continue to get RIP from 169.228.34.84, and that's where encap traffic will come from for the foreseeable future. This changeover will have the effect of moving the gw.ampr.org web site from old amprgw to new amprgw, so the graphs, charts, and tables will change to content as seen from new amprgw's view, thus we'll lose a few days history. Encap packets sent to old amprgw after the changeover will not be forwarded, as the machine will have no further routing to network 44. Gateways which have not updated their outgoing encap path will be unreachable. Everything else should just work. Wish us all good luck! - Brian

7 years, 11 months

1
0
0 0

mailing list format

by Brian Kantor

I got tired of seeing the 'please trim inclusions' header line on each message, and I don't think it was doing any good being there, and there were some negative comments about it, so I deleted it. If I did it right, this message won't have it. - Brian

7 years, 11 months

2
1
0 0

Re: [44net] mailing list security

by Steve L

Someone could create an email list only available on 44net, however I doubt there would be much activity on such a list. The biggest thing I wish this list had was a way to search the archives. I almost sometimes wish it was crawled by google etc. But at the same time that just welcomes more of the unwanted.

7 years, 11 months

4
3
0 0

Re: [44net] ampr-ripd special experimental release 2.2

by Marius Petrescu

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 >> >> >>

7 years, 11 months

5
11
0 0

Re: [44net] Gateways errors at amprgate

by lleachii＠aol.com

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:

7 years, 11 months

1
0
0 0

Re: [44net] Gateways errors at amprgate

by Brian Kantor

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

7 years, 11 months

1
0
0 0

Re: [44net] Gateways errors at amprgate

by lleachii＠aol.com

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

7 years, 11 months

1
0
0 0

AMPR Gateway error

by R P

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

7 years, 11 months

2
1
0 0

Those Running Linux - DSCP Test

by lleachii＠aol.com

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

7 years, 11 months

1
0
0 0

ampr-ripd special experimental release 2.2

by Marius Petrescu

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

7 years, 11 months

4
9
0 0

Re: [44net] ToS/DSCP

by Rob Janssen

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

7 years, 11 months

3
2
0 0

ToS/DSCP

by lleachii＠aol.com

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

7 years, 11 months

3
7
0 0

Re: [44net] Mapping experiment proposal

by Rob Janssen

> 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

7 years, 11 months

1
0
0 0

Mapping experiment proposal

by Marius Petrescu

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

7 years, 11 months

6
7
0 0

Tunnel keep allive

by R P

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

7 years, 11 months

3
3
0 0

Re: [44net] MikroTik uptime

by Rob Janssen

> 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

7 years, 11 months

1
0
0 0

Re: [44net] MikroTik uptime

by Rob Janssen

> Thanks Tom, yes, when I assume it's seconds, I get > uptime numbers like 22+02:22:54, which is 22 days, > 2 hours, and some minutes/seconds. Yes, it is in seconds. The latest software release was early may, so that is a uptime that can be expected. Rob

7 years, 11 months

2
1
0 0

Re: [44net] Tunnel keep allive

by Rob Janssen

> 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 ? Yes, that is probably the reason. You should simply turn it off. The tunnel keep alive packets are tunneled packets with source and destination address swapped. There is no standard for this, but it is a method used by other manufacturers as well. Apparently the expectation is that the remote end of the tunnel will just route the packets and return them on the same tunnel, just like a ping. However, in your case one of the addresses is a 192.168 (RFC1918) address. Likely you are running your MikroTik behind another router that does NAT. That is not a good idea, you should try to get the real internet address on the MikroTik. With some ISPs it may be difficult because the use of the provided router is mandatory and it cannot be put in transparent mode. Setting "DMZ mode" in the router often causes additional problems. Rob

7 years, 11 months

1
0
0 0

MikroTik uptime

by Brian Kantor

Rob or Marius, do you know what units the MikroTik reports its uptime in? Is it seconds? I get numbers like 1922575 or 1909374 for the two I have MNDP data for. - Brian

7 years, 11 months

2
2
0 0

MNDP packets

by Rob Janssen

Maybe one of the interesting "things to do" would be to write a small daemon that captures those UDP packets to 255.255.255.255 port 5678 (MNDP) and stores the latest one received from each source. It would have to have access to the outer IPIP header to do that. Then, it could regularly dump the collected "latest packets" in a tabulated text file with the fields that there are in these packets each in a column. When you look in wireshark (which knows about this format) you see it is quite easy to do. This table would present an overview of the MikroTik routers in use, and could help identify possible problems with the tunneling they do. You could also stop handling them as an error condition. How would such a daemon have to be written so it can run at the gateway? Could it just do a pcap with the appropriate filter? Rob

7 years, 11 months

7
19
0 0

Re: [44net] MNDP packets

by Rob Janssen

> Why my Mikrotik dont appear in this data ? When you are using Marius' automatic tunnel configuration script, you won't appear there. It disables the MNDP transmission on the tunnels. What you see in that list is only those routers where an IP tunnel to the new gateway was manually configured and MNDP was not turned off. Rob

7 years, 11 months

2
1
0 0

Re: [44net] MNDP packets

by Rob Janssen

> Researching, I believe I noticed 44.137.1.80/28 appear, and that you're > the coordinator. > Otherwise, there's already a route existing in the portal. I know, I will try to contact him to see if he has problems. (I guess he has only made a tunnel to amprgw. I cannot ping him from a Dutch AMPRnet IP) Some people apply for a subnet on IPIP and then find that it is not as easy as they would have guessed to get it working correctly. Probably they expected it would be a matter of configuring an IP tunnel in their router. We know there is a little more to it. Rob

7 years, 11 months

1
0
0 0

Re: [44net] MNDP packets

by Rob Janssen

> Well, what I wrote does this: > 68.100.10.100 44.62.5.1 5678 MikroTik 6.36.1 (stable) MikroTik 5RRB-VMWG RB750Gr3 UCSD > 84.106.126.184 44.137.1.92 5678 MikroTik 6.38.5 (stable) MikroTik V2P4-7CQK RB2011UiAS-2HnD ucsd-gw > As far as MikroTik router gateways go, that's pretty much all there is > to be learned from the MNDP broadcasts. Believe it or not, that already reveals 1 issue and one possible issue... That second entry has an unregistered address as the router address, and it is likely only having a single tunnel towards ucsd instead of a full mesh. Rob

7 years, 11 months

2
1
0 0

Re: [44net] MNDP packets

by Rob Janssen

> I forgot: the firmware version, too. And the router IP address. That is interesting information as it allows us to check if the gateway is up and actually functioning. The receiving of these MNDP packets in fact is some indication of that. Of course the number of gateways using MikroTik routers is low, but maybe when similar packets were sent by ampr-ripd there would be info from a lot of gateways. I thought it might be useful to have some status overview and maybe version information. It can help answer basic questions like "how many of the registered gateways are actually operational". Of course it has to be decided if it is worth the extra traffic and the trouble of writing the software. About gathering service information: there is some demand for an overview of services available on AMPRnet. People have suggested installing a search engine, and it has been done in some places, but IMHO a search engine, while useful, is not really the answer. When you do not know what to search for, a search engine has to be very clever to give useful results for queries like "show me an interesting service to try today". What I am looking for is more like a website that shows a table of services, one line per service and with a clickable link that expands one item into more detail, describing interesting services (not limited to websites!) on AMPRnet. Things that draw your attention and that you may want to try. The detail would include things like "how to get an account" (when relevant) etc. It could be constructed in a similar way to the neighbor table maintained by MNDP, except it would not be UDP broadcasts but e.g. some HTTP POST. When you have a service that is available on AMPRnet, you would do an automated daily POST of a small file describing the service (would be easy to install as a cron job using curl or wget) to the server, and the webpage shows all services that have recently been (re-)posted. The result would be similar to the Wiki page http://wiki.ampr.org/wiki/Services , but with the advantage that services that have become unavailable will disappear from the list automatically (assuming that the posting of the info is done from the system providing the service and stops at the same time). The beauty of a network of course is that anyone can make this and put it online. It does not have to run on amprgw or other parts of the network infrastructure, it can just be an experiment running on a Raspberry Pi at someone's home. When we have something like that, it is easier to get people going after they have connected to the network, and keeping them interested in exploring new things on the network. Maybe suitable software already exists, otherwise it should be quite easy to do on a LAMP server or similar. Rob

7 years, 11 months

1
0
0 0

need help in AMPRGW statistics PCAP decode (gateway errors)

by R P

I get the following error in the statistic file of amprgate 5.29.18.144 169.228.66.251 4122 [19] dropped: non-44 inner source address when i look on the PCAP file here is what I see #1 0.000000 169.228.66.251 -> 192.168.1.180 IPv4 20 #2 9.996091 169.228.66.251 -> 192.168.1.180 IPv4 20 #3 19.997040 169.228.66.251 -> 192.168.1.180 IPv4 20 #4 29.996386 169.228.66.251 -> 192.168.1.180 IPv4 20 #5 39.995885 169.228.66.251 -> 192.168.1.180 IPv4 20 #6 49.997226 169.228.66.251 -> 192.168.1.180 IPv4 20 #7 59.996845 169.228.66.251 -> 192.168.1.180 IPv4 20 #8 69.996284 169.228.66.251 -> 192.168.1.180 IPv4 20 #9 79.996422 169.228.66.251 -> 192.168.1.180 IPv4 20 #10 90.006277 169.228.66.251 -> 192.168.1.180 IPv4 20 #11 99.996794 169.228.66.251 -> 192.168.1.180 IPv4 20 #12 109.996173 169.228.66.251 -> 192.168.1.180 IPv4 20 #13 120.008209 169.228.66.251 -> 192.168.1.180 IPv4 20 #14 129.997756 169.228.66.251 -> 192.168.1.180 IPv4 20 #15 139.996572 169.228.66.251 -> 192.168.1.180 IPv4 20 inside the PCAP here is what I see Frame 1: 20 bytes on wire (160 bits), 20 bytes captured (160 bits) Encapsulation type: Raw IP (7) Arrival Time: May 29, 2017 08:59:04.652285000 CEST [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1496041144.652285000 seconds [Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds] Frame Number: 1 Frame Length: 20 bytes (160 bits) Capture Length: 20 bytes (160 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: raw:ip] Raw packet data Internet Protocol Version 4, Src: 169.228.66.251, Dst: 192.168.1.180 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 0000 00.. = Differentiated Services Codepoint: Default (0) .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 20 Identification: 0x0000 (0) Flags: 0x00 0... .... = Reserved bit: Not set .0.. .... = Don't fragment: Not set ..0. .... = More fragments: Not set Fragment offset: 0 Time to live: 255 Protocol: IPIP (4) Header checksum: 0x0caa [validation disabled] [Good: False] [Bad: False] Source: 169.228.66.251 Destination: 192.168.1.180 [Source GeoIP: La Jolla, CA, United States, AS7377 University of California, San Diego, 32.880699, -117.235901] [Source GeoIP City: La Jolla, CA] [Source GeoIP Country: United States] [Source GeoIP AS Number: AS7377 University of California, San Diego] [Source GeoIP Latitude: 32.880699] [Source GeoIP Longitude: -117.235901] [Destination GeoIP: Unknown] Collapse Tree I dont understand what is the problem May anyone help ? Thank Forward Ronen - 4Z4ZQ

7 years, 11 months

4
6
0 0

PCAP viewer ?

by R P

Hi Someone know if there is somewhere on the net something that (web page) can view PCAP file ? If not is there any Software that doesn't need to be installed (unlike WireShark) for PC ? Thanks for Any info Ronen - 4Z4ZQ

7 years, 11 months

2
1
0 0

Re: [44net] MNDP packets

by Rob Janssen

> there have only been 8 hosts sending broadcast destination packets Maybe some have turned this off (easy to do) because they are considered errors now. > I don't know if it would be worth the effort to decode them into a text > file since they are already available for download. > What information is in them that might be of general interest? Well, as also suggested by Lynwood, these packets (and others) can be used to maintain a table of software in use, and can be helpful when there is some problem that appears to affect part of the gateways, but it is not immediately clear what they have in common. Rob

7 years, 11 months

1
0
0 0

message to all gateway operators

by Brian Kantor

The following message is being queued for email delivery to everyone registered on the portal as operating a gateway. - Brian -------------------------------------------------------------------- From: Brian Kantor <Brian(a)UCSD.Edu> To: AMPRNet Gateway Operators:; Subject: AMPRNet - Important notice regarding your gateway system Hello. You are receiving this email because you are registered with portal.ampr.org as operating an IPIP encapsulating gateway, and there are changes coming that will affect the operation of your gateway. We are replacing the equipment at the UCSD Internet-AMPRNet gateway with a newer, more capable device. In the process, the new equipment will be assigned a NEW IP ADDRESS. You will have to make changes in YOUR gateway configuration for your gateway to continue functioning. The new equipment is already in service as amprgw.ucsd.edu and is on IP address 169.228.34.84. This replaces the old equipment, known as amprgw.sysnet.ucsd.edu, on IP address 169.228.66.251. What you have to do to maintain the operability of your gateway: 1. You must change the outgoing destination address of your gateway from 169.228.66.251 to 169.228.34.84. You may do this immediately; the new equipment at UCSD is already operational. 2. You must allow packets from the new address, 169.228.34.84, into your gateway router software configuration. If you are running with a firewall, you must open a new path through it to your equipment. Packets (RIP44 transmissions) are already being sent to you from this address. 3. You must continue to accept packets from the old address, 169.228.66.251, for a period of a few weeks as the changeover is being made. After a few weeks, packets will stop coming from that address and you may remove permission for them to enter your firewall, if you have one. These are simple changes, involving editing a few configuration parameters, but because there are so many different types of gateway in operation on AMPRNet, how to make these changes cannot be detailed here. You may find more information regarding your particular configuration on https://wiki.ampr.org/ or on the 44net(a)hamradio.ucsd.edu discussion mailing list, which you should join if you are not already a subscriber. Best wishes and 73, - Brian

7 years, 11 months

3
3
0 0

ampr-ripd 2.1.1 bugfix released

by Marius Petrescu

Hello everyone, Due to an cut instead of copy /paste error, there was a wrong tunnel interface index detection (it always got the last interface in the system). So here the a correted version of ampr-ripd (2.1.1) with the fix. Changelog: - Fixed a tunnel interface detection error - No functional changes Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.1.1.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.1.1.tgz Have fun, Marius, YO2LOJ

7 years, 11 months

4
4
0 0

Re: [44net] AMPRNet - Important notice regarding your gateway system

by jerome schatten

As regards preparing a jnos system: http://kf8kk.com/packet/jnos-linux/linux-jnos-setup-1.htm gives a 404 What port will the new gateway ip nee? Still 520 udp? Thanks, jerome - ve7ass > On May 28, 2017, at 20:56, Brian Kantor <Brian(a)UCSD.Edu> wrote: > > Hello. You are receiving this email because you are registered with > portal.ampr.org as operating an IPIP encapsulating gateway, and there > are changes coming that will affect the operation of your gateway. > > We are replacing the equipment at the UCSD Internet-AMPRNet gateway > with a newer, more capable device. In the process, the new equipment > will be assigned a NEW IP ADDRESS. You will have to make changes in > YOUR gateway configuration for your gateway to continue functioning. > > The new equipment is already in service as amprgw.ucsd.edu and is on > IP address 169.228.34.84. This replaces the old equipment, known as > amprgw.sysnet.ucsd.edu, on IP address 169.228.66.251. > > What you have to do to maintain the operability of your gateway: > > 1. You must change the outgoing destination address of your gateway > from 169.228.66.251 to 169.228.34.84. You may do this immediately; > the new equipment at UCSD is already operational. > > 2. You must allow packets from the new address, 169.228.34.84, into > your gateway router software configuration. If you are running with > a firewall, you must open a new path through it to your equipment. > Packets (RIP44 transmissions) are already being sent to you from > this address. > > 3. You must continue to accept packets from the old address, > 169.228.66.251, for a period of a few weeks as the changeover is being > made. After a few weeks, packets will stop coming from that address > and you may remove permission for them to enter your firewall, if you > have one. > > These are simple changes, involving editing a few configuration > parameters, but because there are so many different types of gateway in > operation on AMPRNet, how to make these changes cannot be detailed here. > You may find more information regarding your particular configuration > on https://wiki.ampr.org/ or on the 44net(a)hamradio.ucsd.edu discussion > mailing list, which you should join if you are not already a subscriber. > > Best wishes and 73, > - Brian > .

7 years, 11 months

4
3
0 0

ampr-ripd 2.1 released

by Marius Petrescu

Hello everyone, I released a new version of ampr-ripd (2.1) with fixes and additions. Changelog: - Fixed a segfault when using the -F option - Added the possibility to use interface names for the -g option - Interface used for raw RIP forwarding restarts on interface error Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.1.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.1.tgz Have fun, Marius, YO2LOJ

7 years, 11 months

4
7
0 0

Latency in various protocoles

by R P

Im experimenting two net cameras on the AMPRNET One is http streaming the other is RTSP streaming The http uses tcp port 80 the rtsp uses udp (dont remember the port now ) The http replace photo every 250 MS (i assume after it get ACK and then send the next image) ( i see about 4 frames per second) and make a traffic of about 1000 kbit/sec the RTSP send photos in about 10 frames per second and produce traffic of about 500-800 Kbit sec all this over the amprNet May someone explain this ? how come that the RTSP photo is like movie and the http is 4 frames per second (of course that if i view the http camera direct on the net i see the 10 frames per second i set the camera for) And why i tell you all of this ? Because i wonder how a DMR repeater connection will work on the amprNet ... If i can see in RTSP video without problems or frame loss should a VOIP (or more exact) data stream of the DMR work ? after all it is less data .... Is there anyone that can light my eyes on the subject ? Regards Ronen - 4Z4ZQ

7 years, 11 months

2
3
0 0

unreachable gateways and hosts

by Brian Kantor

I'm experimenting with a new technique in the routing daemon on amprgw: if during a send to a gateway, the router gets certain ICMP UNREACHABLE packets from the gateway it's sending to, it drops the host or gateway from the routing table for a time. This has the effect that if a gateway tells us that they don't want packets from us by means of sending us a HOST or NET unreachable ICMP response, we'll stop sending to them for a while. Specifically, PORT UNREACHABLE is ignored. We don't route based on ports. Any of the various HOST UNREACHABLE packets will defer just the one destination host that was being sent to from the routing table; any of the NET UNREACHABLE or PROTOCOL UNREACHABLE packets will defer the subnet from the routing table. The deferral period is currently set to 15 minutes. Watching this happen, one can observe that every 15 minutes, there are a number of hosts and a subnet or two deferred out of the table as packets are sent to them and rejected by the gateways. The number added to the deferral list drops in rate as time goes on. When a gateway changes its address, it is immediately removed from the deferral list. As with the ICMP response suppressing sending RIP transmissions, the purpose of this is to not bombard gateways with packets they don't want and aren't going to deliver anywhere. This is especially important with the number of dynamic gateways we have, where a change in the gateway address may wind up sending IPIP packets to an innocent host that has inherited the gateway's old address. Packets to unreachable destinations are dropped; we don't send UNREACHABLES ourselves. (With all the backscatter and probes, we'd be sending a LOT of them.) We're trying to be good net neighbors. - Brian This is what the log entries look like: May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.104 deferred May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.236 deferred May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.4 deferred May 28 03:54:37 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 97.84.0.85: subnet 44.102.132.0/24 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.153 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.210 deferred May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.210 deferred May 28 03:54:42 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 40.143.112.188: subnet 44.88.8.32/28 deferred May 28 03:54:43 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 216.161.250.190: host 44.22.128.10 deferred May 28 03:54:44 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 188.230.236.122: host 44.150.1.102 deferred May 28 03:54:45 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 78.226.112.146: host 44.151.67.67 deferred

7 years, 11 months

4
8
0 0

icmp redirects to the new router

by Brian Kantor

On Fri, May 26, 2017 at 04:04:24PM -0700, David Ranch wrote: > Hey Brian, > What about configuring an ICMP direct on the old IP to point to the new IP? > --David > KI6ZHD Well, after thinking about it a bit and reading the relevant RFCs, I thought I'd give it a try and wrote some code in the router daemon to do this. Unfortunately, the FreeBSD kernel prohibits a user-space process from sending ICMP Redirects - you get 'Permission denied' errors when you attempt to write one to the outgoing ICMP socket. Too bad, it would have been an interesting experiment. Maybe there's some way to fiddle the routing table so that the kernel itself sends them. I'll look into it, but a quick peek into the kernel source suggests it's not doable. - Brian

7 years, 11 months

2
2
0 0

ampr-ripd test version 2.1

by Gustavo Ponza

After Marius continued efforts [TNX] see the results of the new feature *raw AMPR-RIPD forwarding* at: http://44.134.32.240/www/tun0.html ampr-ripd traffic slowed down from 5.3 kb/s to 1.6 kb/s maintaining/obtaining the same effect. The blue peaks (outgoing traffic) denote the various kinda attacks on the structure. -- 73 and ciao, gus i0ojj A proud member of linux team Non multa, sed multum

7 years, 11 months

2
1
0 0

ampr-ripd-1.16.3 and saving routes?

by Steve L

Has anyone else had an issue where even though you use the -s option, you don't have a /var/lib/ampr-ripd/encap.txt file? I know this was working for me in prior versions.

7 years, 11 months

3
2
0 0

How to modify the mikrotik scripts to work in current "dual gateway" setup

by Marius Petrescu

Hi guys, I tried to set up my router so match the current situation, so here are the steps to get it working: 1. add a filter to Routing->prefix lists to drop 44.128.0.0/16, prefix length 16-32, similar to the one for 44.0.0.1 (IMPORTANT - the dynamic created ampr-169.228.34.84 would interfere with our tunnel base interface , having the same IP endpoint and taking precedence over it being newer) For the RIP protocol, you should now have drops on 44.0.0.1 pref len 32, 44.128.0.0 pref. len 16-32 and your local subnets (if any are there), accept the rest. 2. Change your endpoint in the current ucsd-gw interface from 169.228.66.251 to 169.228.34.84 3. Delete the interface ampr-169.228.34.84 in Interfaces 4. Delete the now invalid route to 44.128.0.0 in IP->Routes Wait a while for the first RIP update. Mesh access should work fully now and you should see RIP updates in Routing->RIP->Routes If you need access from internet to your 44net hosts, these are the additional steps: 3. Add a new IPIP interface, lets say 'ucsd-gw-old' with endpoint 169.228.66.251 (like the old one) 4. Add an unused 44 local ip other than your gateway IP witm mask /32 to the 'ucsd-gw-old' interface in IP->Addresses 5. Add similar connection marks as the ones for ucsd-gw for uscd-gw-old under IP->filter->mangle 6. Check your firewall filters to allow incoming connections from ucsd-gw-old like tho ones from ucsd-gw (input and forward) These latter changes will be removed after full switch to the new gateway. Marius, YO2LOJ

7 years, 11 months

2
3
0 0

Good News! and some changes coming

by Brian Kantor

Good News! Our friends in the CAIDA research group at UCSD have come up with a new machine for amprgw, quite a bit newer than the existing one, and with faster CPU, more cores, and more memory. It also has RAIDed disk and dual power supplies, although unlike the current amprgw, it won't be on a UPS. (There isn't a UPS in the new building where the new machine is located. Luckily our power is pretty reliable; besides buying utility power, UCSD also generates its own from solar and natural gas sources. And we don't have lightning storms very often here in the almost-desert.) There will be some minor differences between the machines, of course, although small enough that I hope to move all the services over from the old machine to the new one over the next several weeks. The primary difference is that the gateway will have a NEW ADDRESS and a slighly DIFFERENT NAME. Instead of being known as 'AMPRGW.SYSNET.UCSD.EDU' as the current one on address 169.228.66.251 is known, the new machine will be 'AMPRGW.UCSD.EDU' (no 'sysnet' in the name), and will be on address 169.228.34.84. You should probably adjust your firewalls soon, letting both machines in for a while, as they will both be operating at the same time as services are moved from old to new. Do not move your tunnel endpoints to the new machine quite yet; that won't work until the routing software is installed and reconfigured for the new address. I'll let you know what it's ready for that. - Brian

7 years, 11 months

8
27
0 0

documentation of gateway move

by Michael Fox - N6MEF

I can find where the new amprgw info is documented. Shouldn't the old/new hostname, external IP address and cut-over date appear prominently somewhere? Michael N6MEF

7 years, 11 months

3
4
0 0

Re: [44net] Good News! and some changes coming

by Rob Janssen

> Yes, it's on the same box, but because the two boxes are on physically > different networks, I can configure them both to be 44.0.0.1 without > conflict. One of them won't get any packets except those originating > on its own physical network, but they won't conflict. That's what I've > done; when the 44/8 route next hop is moved from old amprgw to new amprgw, > which machine serves 44.0.0.1 to the outside will automatically change. I think when you announce 44.0.0.1 with the new gw address on the gateways list (encap, RIP) and keep the 44.0.0.0/8 BGP pointed to the old box, users with a tunnel will connect to the new box and those connecting from internet will get the old box, without any conflict or need to re-route things inside the campus network. That makes it possible to test tunnels two-way. But it is not that important, it will probably work right away and obvious mistakes will be found and fixed within one or some days, which is good enough. I have been doing quite some rebuilding lately, short downtimes sometimes are unavoidable when working within hobby constraints. Rob

7 years, 11 months

1
0
0 0

Re: [44net] documentation of gateway move

by Michael Fox

Yes, thanks.M Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: Brian Kantor <Brian(a)UCSD.Edu> Date: 5/26/17 18:31 (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] documentation of gateway move (Please trim inclusions from previous messages) _______________________________________________ I assume you meant "can't". Updates to the wiki are in progress. I think there ought to be an 'amprgw' page on the wiki, but there isn't one yet. I'll try to get to writing one soon. - Brian old address: 169.228.66.251 old hostname: amprgw.sysnet.ucsd.edu New address: 169.228.34.84 New hostname: AMPRGW.UCSD.EDU Cutover date: TBD On Fri, May 26, 2017 at 06:20:34PM -0700, Michael Fox - N6MEF wrote: > I can find where the new amprgw info is documented. > Shouldn't the old/new hostname, external IP address and cut-over date appear > prominently somewhere? > Michael > N6MEF _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

7 years, 11 months

1
0
0 0

Re: [44net] Good News! and some changes coming

by Rob Janssen

> I've already tested the 44.0.0.1 address using loopback and it > works ok, and I've tested inbound using 44.128.0.1, and it > works ok too. I think things will be ok. > I don't like to bother the campus networking people more than I have to. Ah, I thought that 44.0.0.1 was running on the same machine as amprgw and would be moved as well... so that ciould be done before. Apparently it is a different box. Rob

7 years, 11 months

2
1
0 0

Re: [44net] Good News! and some changes coming

by Rob Janssen

> Don't most hosts and routers ignore ICMP Redirects > out of security concerns these days? Certainly for such external addresses. Locally on the LAN it usually works. (e.g. when you have two routers and one sends redirects to the address of the other, both in the local subnet) Rob

7 years, 11 months

1
0
0 0

Re: [44net] ampr-ripd 2.0 released Marius Petrescu marius at yo2loj.ro

by Rob Janssen

> - brought back option -r, to allow using multicast sockets by default > and raw sockets as a backup for systems with multicast issues. This will > hopefully sort out the firewall filtering inability on previous releases > since 1.13. I had to put back the -r option that I had cleaned up from my start script as it still does not work with the multicast socked on Debian Linux with kernel 3.16. I remember it failed after some kernel update and it apparenty is still broken. However, I do not mind using the -r option, only want to remind people that they may need to put it back. Rob

7 years, 11 months

4
22
0 0

Re: [44net] Good News! and some changes coming

by Rob Janssen

We do not send outgoing traffic via amprgw so no change is necessary, but I updated the address on our info page (that says "use our address instead of 169.228.66.251 as your default gw"). It would probably be a good idea to change the route for 44.0.0.1 before the incoming routes are switched over, so it can be tested from the inside. Rob

7 years, 11 months

2
1
0 0

Warning - Bad Startampr/Linux Scripts on Internet

by lleachii＠aol.com

All, It's my understanding that there are multiple copies of the original Startampr script on the Internet. What I have not noticed until alerted by two operators that attempted to implement those copies in their devices, are the following: - Scripts NOT distributed from my site at http://44.60.44.10 ON AMPRNET include the misuse of the -a argument to run the RIP44 daemon(s). - The syntax used on the Internet scripts ('use -a argument to remove your allocation from the table' by a. specifying WAN IP IN rip44d; vs b. specifying 44 allocation CIDR IP as in ampr-ripd, are reversed. - This appears to be a documentation bug made by a copier who used my original scripts (made for rip44d) and converted them to work for ampr-ripd. - if you use my scripts placing lookups for your local 44 LAN in the main table, this issue wouldn't affect you 73, -Lynwood KB3VWG

7 years, 11 months

1
1
0 0

Re: [44net] ampr-ripd 2.0 released Marius Petrescu marius at yo2loj.ro

by Rob Janssen

> >/Everyone is free to use the -g option if needed /> Yes, but is eth0.2 a valid entry? The parameter of -g is an IP address. It it not the IP address of an interface but of the gateway to the internet. So specifying an interface like eth0.2 does not make sense. You could use something like this: .... -g `ip route list | grep '^default' | sed -e 's/.*via //' -e 's/ .*//'` Rob

7 years, 11 months

2
1
0 0

Re: [44net] non-operational gateways

by Rob Janssen

> Thinking about this, I recall that I run an IPv6 tunnel with Hurricane > Electric in the same manner. They require that I allow ICMP - Echo > Request to the border. The tunnel doesn't come online at their end, > until they receive an Echo Reply from the IP I specified (either > statically or with DDNS). > Just a rule used by one ISP. I think it is not required to allow pings to the outside address, and it may be difficult for some people to fulfill that requirement (as it may be part of the setup of their ISP router to disallow these). Instead, I would like to see that pings to at least one of the gatewayed addresses are allowed (a net-44 address inside one of the subnet(s) routed to that gateway). This is also much more indicative of a functioning gateway. In the IPv6 tunnel example that would mean allowing ping to one IPv6 address. Of course our problem is that we never asked the gateway operators for the address of their gateway on net-44. So that would have to be added in the form, the database and the encap file (or some other file). Rob

7 years, 11 months

1
0
0 0

Wiki Content - How many tunnels?

by lleachii＠aol.com

All, It's my understanding that the operating systems we work with only need 1 tunnel, or one system declaration for it. Except those OSes listed under "Non-RIP44 Workarounds", does anyone else run an OS not on the list - that requires you to create more than one (1) tunnel, specify a remote IP other than "Any", or create a route for it before you receive traffic? All I have to do is tell tunl0 to be UP and I'll receive ANYTHING. OPs using other operating systems seem to have configuration differences (maybe that's why they don't understand security concerns). I'm not sure if there's a configuration difference in the Kernels, or what...? 73, - Lynwood KB3VWG

7 years, 11 months

2
1
0 0

brave volunteer needed

by Brian Kantor

It looks to me like the new amprgw is working. I'd like to ask for a brave volunteer who is willing to try changing his outgoing route from old amprgw (169.228.66.251) to new amprgw (169.228.34.84) to see if he's able to make connection with the outside world. The return path will still be via old amprgw as we haven't changed the nexthop for 44.0.0.0/8 from oldamprgw to new. If someone would try this and let me know if it worked I'd very much appreciate it. - Brian

7 years, 11 months

2
17
0 0

non-operational gateways

by Tom C

In just the past couple of days I got my gateway working. I have a CS degree, test software for a living and considered myself proficient on linux but found getting the gateway to work correctly difficult due to contradictions in documentation and examples. With KB3VWG's help I was able to get it working. I'll just say it was a little difficult to get it going, mostly due to understanding how it all works together. I'm using ubuntu linux as a gateway. On the subject of non-operational gateways I would consider attempting to send RIP broadcasts to them at a reduced rate instead of deleting them. In my case I'm on a dynamic address. It doesn't change often, longest I've had an address was about 5 months. It's most apt to change if I restart. I registered my gateway in January... it was down all of Jan and Feb. It's been intermittent but mostly down since until Monday evening of this week. Had my gateway been deleted or removed from the list I'd now be offline rather than online. Lynwood was a great help with understanding policy routing rules and I'd like to publically thank him here. He's patient and points things out that don't work. I plan to document my journey so others who wish to join the network can learn from my mistakes. I'm a firm believer in understanding how it works. --tom /n2xu -- 73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified

7 years, 11 months

6
5
0 0

netflow

by Brian Kantor

I'm now gathering netflow-like statistics from the router daemon. It's a lot of data. I've been unable to find a clear definition of the standard (v1 or v5) netflow disk file format, so I don't have input suitable for any of the good analysis tools. Does anyone have such a description? And what are your favourite analysis tools? - Brian

7 years, 11 months

6
20
0 0

Re: [44net] Traffic not routing to my gateway

by Rob Janssen

> IPIP is possible on the SRX but not in cluster (virtual chassis mode) Being able to setup a single or even multiple IPIP tunnels is not suffcient to be a member of the AMPRnet IPIP mesh. See what Brian wrote: > This is a mesh network, not a star, so there is no default route; you > need a separate tunnel route to each gateway you want to communicate with, Marius has written a very nice script to get it working on a MikroTik router, but most other commercial routers lack the scripting capabilities to pull this off on their own. Someone wrote a script to use a Cisco router but it requires a separate machine to run it. Rob

7 years, 11 months

5
9
0 0

Re: [44net] non-operational gateways

by Rob Janssen

> I've added code to the rip sender that watches for ICMP unreachable > packets coming back to amprgw during the rip sending cycle, which repeats > every 5 minutes. Make sure you act only on ICMP unreachables that refer to the protocol 4, not to the port 520! When protocol 4 is unreachable, it sure means the gateway is not operational, as it rejects operational traffic. When it rejects port 520, it could be that it is not using RIP to update its tables (it could be downloading encap files!) or even that it *is* using RIP but via raw sockets (ampr-ripd -r) and has a firewall that rejects the packets. ampr-ripd would still see and process them! That condition could be flagged in yet another status report, but it should not be a base to declare the gateway inactive. Also, we recently have seen some postings that indicate that some people operate a gateway that has tunnels to all other gateways, but explicitly have excluded a tunnel to amprgw. Because that brings mostly internet traffic and they don't want to have that. Of course another (not exclusively deciding) check on gateway activity could be to check if you actually receive any tunneled packets from them. I do have that as a byproduct of having an access list that accepts protocol 4 traffic only from addresses of registered gateways. At the moment it shows traffic from 34 different gateways (including amprgw). Of course, when the external address of a gateway changes, its history is lost. Rob

7 years, 11 months

6
14
0 0

Re: [44net] non-operational gateways

by Rob Janssen

> Sorry to ask but what has accepting RIP to do with the gateway IP? > RIP is encapsulated into IPIP, so no firewall will ever care about that. > And no sane firewall setup will accept RIP on its WAN. > From both the gateway's point of view it's just protocol 4, nothing else. What I mentioned in my earlier post is that a "protocol unreachable" (for protocol 4 packets) is a serious condition although it could still be valid when encountered by amprgw and not by the other gatways. A "port unreachable" for UDP port 520 indeed is not an error condition. The gateway may not be using RIP. Or, the firewall may have been configured to reject port 520 traffic while ampr-ripd -r is still processing it. (not likely because the RIP traffic is multicast so would not normally be replied to by the firewall) To do some better "gateway alive" testing I think some extra steps are required: 1. a mandatory field has to be added to a gateway registration entry, with an IP address inside the routed subnets that is pingable. (of course getting everyone to enter this data will be difficult) 2. a separate "monitoring station" has to be setup that acts as a gateway and pings that address regularly (but not overly often) and keeps stats on the returned pings. The monitoring station has to be separate from amprgw because some people choose not to tunnel to amprgw. Alternatively, a checkbox could be added to gateway registrations to specify if the gateway wants to receive internet traffic (to be handled by the amprgw firewall table) and it could be made mandatory to tunnel to amprgw. That would probably be preferable, as it would also make 44.0.0.1 reachable for those gateways that do not want to get internet traffic. Adding the fields to the gateway registration system should be straightforward, but of course getting everyone to enter them wouldn't be. Not responding to a request to enter information of course could be treated as an indication that the gateway is no longer active. Rob

7 years, 11 months

3
2
0 0

Re: [44net] non-operational gateways

by Rob Janssen

> There is also the question of how this data is to be transferred > from the portal to amprgw. We currently download the same encap > file that any gateway would use. Some new file format would also > be needed. It should be trivial to add another file, gateways.txt, that contains the per-gateway information. Or it could be added as comment lines into the existing encap.txt file. Maybe it would also make some tunnel creation scripts simpler when there is a section with gateway info (one line for each gateway, with a unique ID, the external IP, and info like proposed today: an internal IP and the "accept internet traffic" flag) ahead of the traditional route lines. It would allow the preparation of all required tunnel interfaces in environments where that is required before parsing the subnet routes. Rob

7 years, 11 months

1
0
0 0

Reported AX.25 repository 'bug' on OpenWRT/LEDE

by lleachii＠aol.com

All, FYI, I'm not sure if anyone may be interested in setting up a portion of their allocation with an AX.25 ports (I definitely am). I informed the LEDE developers that they provide the kmod-ax25 package and its dependency; but do not provide libax25, ax25-tools and ax25-apps. The bug report can be found here: https://bugs.lede-project.org/index.php?do=details&task_id=802 73, - Lynwood KB3VWG

7 years, 11 months

1
0
0 0

non-operational gateways

by Brian Kantor

I got to thinking about Ronen's question as to how to find non-functional gateway, and I've come up with a scheme. I've added code to the rip sender that watches for ICMP unreachable packets coming back to amprgw during the rip sending cycle, which repeats every 5 minutes. If an ICMP unreachable packet is received, the matching gateway is removed from that cycle, so with luck (if the unreachables get here quickly enough) we'll only send one or two packets to a gateway that's not reachable. The time and gateway address are logged; some future process should be able to analyze this log and do something about the gateway if it's out of service long enough. (What it will do about it isn't exactly clear right now.) This doesn't seem to have slowed down the rip sender much if at all. - Brian

7 years, 11 months

2
2
0 0

Re: [44net] RIP transmission question

by Rob Janssen

> That's actually a limitation on how multicast works. In usual > circumstances, a router does not listen to multicasts not originating > from the subnet its interface is connected to. Could that be the reason why ampr-ripd multicast mode does not work for me? I always put the local address /32 on the tunnel interface. Maybe it would work when that is changed to /8 ? Rob

7 years, 11 months

5
5
0 0

Re: [44net] RIP transmission question

by Rob Janssen

> I'm curious, what Router OS are you using? Debian Wheezy with backport kernel 3.16 Also Raspbian Wheezy with kernel 4.1.19+ Well, it probably is some setting. It has worked before but lately I have not seen any RIP packet in the iptables counters, even though I see them with tshark. Now I just use -r and that works. Not worth to spend effort on. Rob

7 years, 11 months

1
0
0 0

RIP transmission question

by R P

Hi there I understand that two ways optional to send RIP info 1) multicast (what now is operative) 2) direct transfer The multicast require that both interfaces AMPRGW and the ham gateway will have same netmask (in our case /8) is it the same with the direct transmit ? If yes why the multicast way was chosen ? what is the benefit ? Thanks for any info on the subject Ronen - 4Z4ZQ

7 years, 11 months

4
5
0 0

Re: [44net] Non BCP38 senders or dynamic blocking of scanners

by Rob Janssen

Well, when you implement it correctly a dynamic block of incoming scanners will not block the replies to your own outgoing connections. First allow ESTABLISHED,RELATED and then block the IPs of detected scanners. Rob

7 years, 11 months

1
0
0 0

netflow vs privacy

by Brian Kantor

I was in the process of selecting a netflow viewer -- most of them are web-based -- when it occured to me that someone using it could discover every connection that someone has made through the amprgw router. The flow data records source and destination address and ports, how much traffic was transferred, the time of day, and how long the connection lasted. Every flow record is about 50 bytes of data, and there can easily be a hundred of them per second. In aggregate, it's a lot of data. And it has privacy implications. I was originally considering making an interactive netflow inquiry tool available on the gateways section of the gw.ampr.org website so gateway operators could see what traffic their AMPRNet router is handling. But because there's no way to restrict it so that someone could only view flows involving their own endpoint or subnet, I think it's too much information to be made freely available for people to browse. And there is the consideration that inquiries could wind up presenting a significant load on the system. I think that presenting anonymized aggregate data wouldn't be a problem, so I'm going to look into that. Probably some traffic density graphs would be ok. And I'm willing, once the tools are installed and working, to make extracts of the data for a gateway operator who is having a problem with his traffic flow. What's people's opinion of this? - Brian

7 years, 11 months

6
8
0 0

probbing and attacks on my router

by R P

Hi I was "playing" with my AMPR Router yesterday I had a open user (on purpose) and saw that from that user few IP (not my ones) were logged in after some more research i have discovered that this users was opening connections to other hosts .... That made me suspicious on what going on .... I have checked one of the IP that was connected and back resolve showed customer.worldstream.nl comming via SSH I understand something not good happening i have closed this user rebooted the router (to clear the connection ) and then i started to get alot of connections to port 22 to my router from that host I had to put Firewall rule (drop) for that address and destination port (22)(although im against fire-walling) After less then 24 hours the traffic stopped from that host the trafic (Via UCSD (Encapped) went down from 19 KBytes/sec to less then 1 Kbyte/sec now. I know how to deal with the technical aspects (firewall .etc) What is not understand to me is what is the purpose ... If it is a robot what is the point of fluddling SSH connections is it brute force ? or anything else ? and how come that after 24 hours it stopped it supposed to be endless loop if it is an automated process Please light my eyes on that if you have more experience then me currently the router is "quiet" without non wanted users logged in and un necessary connections I see on the log here and there breake attempt mainly to Ports 23 22 and SIP from various hosts but it is few in a minute Regards Ronen - 4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com

7 years, 11 months

7
13
0 0

Non BCP38 senders or dynamic blocking of scanners

by lleachii＠aol.com

All, Consider the following - a virus, malicious person, or by accident, a source address is set to 8.8.8.8 - you run a port scan to your job, a test IP, etc. - They have intrusion detection - They use Google DNS It seems a DDoS attack could be very easily launched. Perhaps those folks could sill consider making an ipset of allowed outbound IP addresses. Also be careful how you block your own rules, an attacker spoofing the IP of common addresses could cause DoS. If you were attempting to connect to your IP, a man-in-the-middle attack (or someone who otherwise learns the destination IP and port) would make it seem as you were always blocked (but your firewall hits are greater than you expect). Theres probably common if you change the port and your corporate network team at work begin to see low bandwidth encrypted links on an unknown port. 73, -Lynwood KB3VWG

7 years, 11 months

1
0
0 0

ampr-ripd 2.0 -I -E questions

by lleachii＠aol.com

Marius at al, I'm wondering if anyone has tried the new feature that sends RIP44. If so I have a question. If you use the -a, does it remove those routes? I need to account for this in a script I'm writing depending on if the downstream device is on a WAN or if they have a private route/connection between themselves. Since I use policy-based routing, I can keep the false record for my own subnet on table 44 and encap file; but for others (and other projects for AMPRNet), I can see this used to be placed on a second device to provide a real-time looking-glass tool, etc. - Lynwood KB3VWG

7 years, 11 months

2
1
0 0

Traffic not routing to my gateway

by Craig Brauckmiller

Hey all, I recently got my gateway and ip block allocations all setup including the DNS piece thanks to Brian and others. I've got the tunnel defined on my router. When I run a TCPDUMP on the physical interface that is hooked up to m169.228.66.251y cable modem, I am not seeing any traffic from the 169.228.66.251 tunnel endpoint. Nor, obviously, am I seeing any traffic on my tunnel interface. How do I troubleshoot this? Thanks Craig KC1ETB

7 years, 11 months

7
20
0 0

Re: [44net] ampr-ripd 2.0 released

by Rob Janssen

> Do you have a firewall that drops by default? > On my machine, I have to allow 520/udp from 44.0.0.1 to 520/udp at > 244.0.0.9. I have a firewall rule but it remains at zero. It is unclear where this packet gets lost, when I run "tshark" the RIP transmission is seen, but when I insert a rule "iptables -I amprinp -p udp -s 44.0.0.1 --dport 520 -j ACCEPT" at the top of the list (this rule is selected by "iptables -A INPUT -i tunl0 -j amprinp") it too does not see any traffic. This worked OK in the past but it has suddenly stopped working some time ago, I think about two years. That happened when there was a kernel update, no other changes. Rob

7 years, 11 months

1
0
0 0

ampr-ripd 2.0 released

by Marius Petrescu

Hello everyone, I created a new ampr-ripd release according to some wishes of our members. Changes: - brought back option -r, to allow using multicast sockets by default and raw sockets as a backup for systems with multicast issues. This will hopefully sort out the firewall filtering inability on previous releases since 1.13. - added 2 new command line options, -F and -E (capital letters) which allow the forwarding of raw AMPR-RIP messages on a specific interface (-F) and optional to a specific address (-E), similar to the -f and -e options. These RIP messages are raw copies of the incoming ones: password it there and they appear every 5 minutes and will be missing if no data arrives from the AMPR gateway. - added the setting of the proper 44.0.0.1/32 route to conform to the latest gateway changes. Download: http://www.yo2loj.ro/hamprojects/ampr-ripd-2.0.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-2.0.tgz Have fun, Marius, YO2LOJ

7 years, 11 months

1
0
0 0

Re: [44net] Traffic not routing to my gateway

by Rob Janssen

> BTW, the encap file does not change much. On average, one line in it > will change per hour, as a gateway with a dynamic address updates its > address (and it's often the same gateway flipping between two or three > addresses), but gateways come and go at a much lower rate -- I'd guess > one or two a week. So you'd be pretty safe just FTPing and processing > a new encap file perhaps once a day if it winds up being a chore. The automation in the classic FTP client is a bit difficult to use, especially when you want to use it for different sites, but the "wget" and "curl" programs can easily fetch a fixed file from a fixed server with a fixed user/password by combining them all into a URL: ftp://user:pass@server.domain/path/to/file Of course when you fetch and process the file once a day, you will not be able to use those gateways that change IP address once a day due to local provider policy. But probably you'll never notice that... :-) Rob

7 years, 11 months

1
0
0 0

Re: [44net] Traffic not routing to my gateway

by Rob Janssen

> I expect you could have more luck by looking in to SLAX scripting as it > should not be to hard to do this fully from the junos api's > I did not check this but i don't think the ipip driver would be > standard. Well, it is not very straightforward so when it is your first script you are probably going to have a hard time... In Linux there is a point-to-multipoint IP tunnel, much as was the case in JNOS when this whole IPIP mesh was designed. You configure only a single IP tunneling interface, usually called tunl0, and you put a set of routes in the route table with the destination subnets, the tunl0 device, and the remote endpoint of the tunnel as the gateway address. Like this: 44.2.2.0/24 via 216.218.207.198 dev tunl0 onlink 44.2.7.0/30 via 73.185.12.233 dev tunl0 onlink 44.2.10.0/29 via 104.49.12.130 dev tunl0 onlink The onlink attribute is required to suppress the "gateway not reachable" warning you would normally get when the gateway is not directly reachable from the system. With this facility, the updating is relatively easy: just make sure the actual routing table agrees with the distributed information, by adding and deleting single routes. Without such point-to-multipoint tunneling, you will have to create a separate tunnel interface for each gateway, and setup routes to the remote subnets pointing to the correct gateway tunnel. Remember there are (way) more subnets than gateways, you need to find the routes with the same remote gateway, and create only a single tunnel device for those combinations, and point the matching subnet routes to that device. To obtain the information about the subnets, you either listen to the RIP broadcasts made by amprgw, or you regularly download the "encap.txt" which has this format: route addprivate 44.2.2/24 encap 216.218.207.198 route addprivate 44.2.7/30 encap 73.185.12.233 route addprivate 44.2.10/29 encap 104.49.12.130 so you need to parse that and get the subnet and gateway fields from it. (this format is the commandline format that JNOS used) There is no separate "list of endpoints" so you have to create that yourself from that list of routes (take the last field and put it in a list, removing duplicates). Now when you have written a script to transform this into commands to create the proper tunnel devices and add the routes, the real fun begins! The next time you get the information, you need to check if there are changes. When there are, there usually will be a change of tunnel endpoint address (for a gateway that is on a dynamic internet address). You will find several entries in the information that suddenly have a different next hop address, but of course they are not grouped together, they are scattered through the lines you received. You will need to locate the correct tunnel device (which you will need to look up using the *previous* table of received information) and change its endpoint. But, there are other possibilities, ocurring less often: a subnet could have been added or removed from a gateway (and maybe moved to another), a new gateway can be added, or a gateway can be removed (with all its subnets). And of course, combinations of the above, e.g. a gateway has its endpoint address changed and at the same time adds or deletes a subnet. That is probably a rare occurrence, but it should not cause disaster (like a crash). Of course you could simplify things by just deleting everything (routes and devices) and rebuilding it from zero whenever there is some change. But that could cause brief interruptions of the routing and/or high load on the CPU. Sure, it can be done. But for someone who is not experienced in programming in general, and has to learn the scripting language for the particular platform as well, it will be tough. I would certainly advise to look at Marius' script for MikroTik, as it of course has the algorithms described above. It would have to be rewritten in a different language and the constructs to add/delete tunnel devices and routes will have to be changed. Rob

7 years, 11 months

3
3
0 0

Re: [44net] Gateway in EC2?

by Rob Janssen

> I'm wondering of anyone has successfully got a gateway running in Amazon's EC2 service? > I was thinking of using a raspberry pi with a tinc VPN to the EC2 instance to tie into my RF connection regardless of my IP address. > I hit a wall when it came to getting ampr-ripd running. It is a bit difficult to help you with such a problem description, but in general (I have no experience with EC2) you should be aware that such services do not give you a fully virtualized machine where you can do what you want, but rather they use Xen Paravirtualization where a modified kernel is running, and it often does not include the module required for IPIP tunneling. That may be the wall you are hitting, but it would not be the problem of getting ampr-ripd running but to actually get the tunl0 interface working. So you need to explain better what your problem is. Maybe it can be worked around using another program by Marius: amprd. I have a Raspberry Pi running at a hosting company and running the usual configuration for a gateway under Linux, and of course that does not have that limitation. I have a VPN to it from home. Indeed it is a nice way to get a gateway running without the trouble of getting the IPIP traffic to your home system. (but it is not used much anymore as I now have a radio connection to the network) Rob

7 years, 11 months

2
1
0 0

inbound traffic

by Brian Kantor

I built a new inbound ports display https://gw.ampr.org/router/ports.svg which shows a significant amount of traffic that SANS and others identify as being aimed at vulnerable ports on various pieces of equipment. I don't want to just block them, as they have legitimate uses, but if you're running your own firewall, you might want to block them yourself if you don't have any need for the legitimate use. - Brian

7 years, 11 months

2
3
0 0

Connection Problem

by vk2tv

I'm trying to access one of Brian's help documents but the connection attempt to http://n1uro.ampr.org/linuxconf/amprnat.txt times out. Is there an issue somewhere that might impact on my attempts? Ray vk2tv

7 years, 11 months

3
10
0 0

What happened to the missing inbound encap traffic

by Brian Kantor

As you can see from the graph https://gw.ampr.org/router/encapinpkt.svg, there was a precipitous decline in inbound encap traffic about 19:00 UTC on May 16th. I've been wondering what happened to all that traffic. Well, it turns out that the amount of traffic coming in before that cutoff was anomalously high. There was a host called chocolate-nebula.mit.edu (18.96.0.110) which was sending over 95% of the inbound traffic to amprgw, and had been for several days, before the graph started. I jumped to the conclusion that that amount of traffic was normal, when in fact it was not. So what has really happened was that inbound traffic has returned to normal after 16 May at 19:10. chocolate-nebula.mit.edu is registered on the portal as amprnet-gateway1.amolbhave.com, the gateway for subnet 44.44.7.224/28, belonging to KC1EDX. I don't yet know why it was sending all that traffic, nor why it suddenly stopped. So most of the mystery is solved. Maybe KC1EDX will pop up here and explain what was going on. - Brian

7 years, 11 months

1
0
0 0

Gateway in EC2?

by Mark Scrano

Hey, I'm wondering of anyone has successfully got a gateway running in Amazon's EC2 service? I was thinking of using a raspberry pi with a tinc VPN to the EC2 instance to tie into my RF connection regardless of my IP address. I hit a wall when it came to getting ampr-ripd running. If anyone has such a configuration working I would love to pick your brain about your setup. Regards, Mark Scrano K2EXE -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

7 years, 11 months

1
0
0 0

Re: [44net] Traffic not routing to my gateway

by Rob Janssen

> Guys, I think I may be missing something here. I've seen a couple > references to RIP being required. I didn't see that mentioned in any of > the on-line docs. Perhaps I've missed it, and if so, I apologize. I'll go > look at the Wiki to see if it is there. > Is this required or optional? It is optional, but I think it will be very unpractical or even impossible to get the IPIP tunneling working on your SRX. Note that it is NOT sufficient to setup a single IPIP tunnel to the amprgw and route all net-44 traffic over that. You need to setup a tunnel to each of the (about 430) gateway systems and route the defined subnets (about 615) over those tunnels. And the IP addresses of some of the endpoints are changing all the time because users are on a dynamic internet IP. To keep that config uptodate in your router, you either need to do AMPR-RIP, or you need to setup elaborate scripting to reconfigure the router whenever required. (regularly downloading the encap.txt file and generating config for it) In practice, you need a Linux box to do the routing, or a MikroTik router that has scripting powerful enough to do the above on its own. With your SRX you will need a separate machine that does the updating. Rob

7 years, 11 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net