44net

44net@mailman.ampr.org

1 participants
3200 discussions

Re: [44net] AMPRNet DNS robot
by Rob Janssen 08 Jun '17

08 Jun '17

> How many of you who use the robot are using software to handle > the responses? I don't parse the responses, but I do have automated software to generate the request mails. When that format changes, I like to know beforehand. Rob

2 1

Re: [44net] tunnel window settings
by Rob Janssen 08 Jun '17

08 Jun '17

> 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

1 0

Greetings All - Peculiar problem
by Tom Cardinal 08 Jun '17

08 Jun '17

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

5 14

Mikrotik
by Jacek Grzona 08 Jun '17

08 Jun '17

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

8 24

tunnel window settings
by marius＠yo2loj.ro 08 Jun '17

08 Jun '17

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

3 2

AMPRNet DNS robot
by Brian Kantor 07 Jun '17

07 Jun '17

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

2 1

AmprNAT
by Brian 07 Jun '17

07 Jun '17

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.

2 1

Reminder about Amprd for simple configurations
by Marius Petrescu 07 Jun '17

07 Jun '17

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

1 1

Portal IP hasn't changed in a few hours
by lleachii＠aol.com 07 Jun '17

07 Jun '17

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

2 1

DDOS attack Monitor Sites
by R P 06 Jun '17

06 Jun '17

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

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net