44net

44net@mailman.ampr.org

3194 discussions

Start a nNew thread

rip44d
by lleachii＠aol.com 17 Feb '14

17 Feb '14

Marius, Are you still maintaining perl based rip44d software? -Lynwood KB3VWG

3 6

Re: [44net] annual reminders
by William Lewis 15 Feb '14

15 Feb '14

Brian / Chris: I take some of that back..... Upon further testing, if I edit someone's region description, the portal tells me it saved it. But when I go back into the record, it is *not saved* at all. So, bug report of a different nature. Thanks Bill Lewis / KG6BAJ

5 5

Cisco IOS Example?
by Phil Pacier - AD6NH 15 Feb '14

15 Feb '14

Good day all. Does anyone have a rough example of a 44Net tunnel setup for Cisco IOS? I only have a /32 to play with and would like to put it on the WAN router. Thanks! -- Phillip Pacier - AD6NH APRS Tier2 Network Coordinator --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com

1 0

Re: [44net] ampr-ripd 1.9 released
by Rob Janssen 13 Feb '14

13 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] ampr-ripd 1.9 released > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 02/13/2014 05:14 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello OMs, > > Latest update, with improvements (again) sugested by Rob Jannsen (PE1CHL) - > tnx. Rob. > > - added option to adjust TCP window size on routes > - console is now detaching on daemon startup It works well, thank you! Rob

1 0

Re: [44net] ampr-ripd 1.8 released
by Rob Janssen 12 Feb '14

12 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] ampr-ripd 1.8 released > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 02/12/2014 06:15 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Rob, > > -w is a good idea and I will implement it. > > Regarding the daemon function, AFAIK it is not available on all systems and > does not have a standardized behavior. > I wrote the code as portable as possible (e.g. static memory allocations, > minimal needed libraries). > Since the only action on the parent is exit(), I don't think that waiting > time is relevant. > > Thank you for your input. > > Marius, YO2LOJ Ok. I think daemon is available on many Unix/Linux-like platforms. However, it is not a very complicated function. What you wrote in ampr-ripd is nearly the same, except for that daemon() closes stdin, stdout and stderr when going to daemon mode. At least on a debian system, when ampr-ripd is started from a shell script under /etc/init.d, and when it does not close the controlling tty, init keeps a process running (startpar) that waits until it does that. I think that is part of the logic that prints the OK or FAIL messages in the init procedure. So, you could add some fclose or close calls in that part of the code. (only when verbose=0) I used the following workaround before I discovered daemon(): ampr-ripd -options </dev/null >/dev/null 2>&1 Rob

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 34
by Rob Janssen 12 Feb '14

12 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] 44Net Digest, Vol 3, Issue 33 > From: > Steve Wright <stevewrightnz(a)gmail.com> > Date: > 02/11/2014 11:41 PM > > To: > 44net(a)hamradio.ucsd.edu > > >> > >> > >> > Any connects from ports >> >below 1024 are highly suspect for being reflection attacks so above I >> >block them all. > Another good trick is to block all outgoing connects to port 80 - this > makes it quite inconvenient for a virus to download its payload. In fact, > block all outgoing connects, and allow only what YOU want to do. Well, I do have that on the webserver at work. What those injection-attacks on PHP programs often do is include something that is fetched from a remote webserver. As the webserver cannot make outgoing connects, this always fails. However, for a typical hamradio computer that serves both as a server and a client, blocking outgoing port 80 is a bit unpractical. The attack is still/again going on, this time with source port 119: 21:49:23.716879 216.18.208.109 -> 44.137.41.97 TCP 52 nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:24.514385 216.18.208.109 -> 44.137.41.101 TCP 52 nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:24.819003 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:25.914034 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:25.927587 216.18.208.109 -> 44.137.41.101 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:27.009032 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:27.349359 216.18.208.109 -> 44.137.41.101 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 21:49:28.106015 216.18.208.109 -> 44.137.41.97 TCP 52 [TCP Port numbers reused] nntp > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 Rob

1 0

ampr-ripd 1.8 released
by Marius Petrescu 12 Feb '14

12 Feb '14

Hello OMs, Another addition and a new version. Added support for setting a specific route metric for the created routes using the -m option (regular routes until now had metric 0). This allows routes from other sources, e.g. BGP or OSPF to take precedence over those created by ampr-ripd. For those not needing "fancy" routing, there's no need to upgrade. Download from http://www.yo2loj.ro/hamprojects/ or http://yo2tm.ampr.org/hamprojects/ (as usual), or get it via github: https://github.com/yo2loj/ampr-ripd/ Direct links: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.8.tgz http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.8.tgz Have fun, Marius, YO2LOJ

2 2

Re: [44net] ampr-ripd 1.8 released
by Rob Janssen 12 Feb '14

12 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > [44net] ampr-ripd 1.8 released > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 02/11/2014 06:00 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello OMs, > > Another addition and a new version. > > Added support for setting a specific route metric for the created routes > using the -m option (regular routes until now had metric 0). > This allows routes from other sources, e.g. BGP or OSPF to take precedence > over those created by ampr-ripd. When you make another version, consider: - a -w option to set the window (now fixed at 840), setting 0 means no window setting. - in the section to become a daemon, make use of the daemon() function. e.g.: if (FALSE == debug) { if (daemon(0,verbose)<0) { PERROR("Can not become a daemon"); } } The advantage is that the program detaches from the terminal, which is required when you want to start it in a /etc/init.d script and do not want to keep init waiting for the program. Rob

2 1

Re: [44net] 44Net Digest, Vol 3, Issue 33
by Steve Wright 11 Feb '14

11 Feb '14

> > > Any connects from ports > below 1024 are highly suspect for being reflection attacks so above I > block them all. Another good trick is to block all outgoing connects to port 80 - this makes it quite inconvenient for a virus to download its payload. In fact, block all outgoing connects, and allow only what YOU want to do.

1 0

Re: [44net] 44Net Digest, Vol 3, Issue 32
by Rob Janssen 10 Feb '14

10 Feb '14

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] 44Net Digest, Vol 3, Issue 31 > From: > John Ronan <jpronans(a)gmail.com> > Date: > 02/10/2014 10:01 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hi Rob/all, > Well as long as it wasn't just me the packets were hitting, I'm happier :). I guess your 'firewall' is a chain you created yourself? Either that or my iptables/kernel is quite a bit older than yours. > > Thats a nice/handy ruleset actually, thanks for the reply. > > Oh, apologies for my slowness in replying, birthday party (my own) Saturday meant I was recovering yesterday. > > Regards > John > EI7IG Yes, "firewall" is a chain that is joined to the INPUT chain for some of the traffic. In a typical Linux tunneling server you first separate the raw input and the tunnel input, and then deal with that in separate chains. In my tunnel router I have 4 of them, one for internet traffic to the public IP address, one for traffic destined to the 44-net address of the router, one for 44-net traffic routed thu to systems behind my router, and one for traffic destined to my locally running copy of NETCHL (most others would use JNOS there). It gets kind of difficult to handle all of that in one INPUT chain. So my INPUT chain is built like this: iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -i eth0 -d 111.222.333.444 -j firewall iptables -A INPUT -i tunl0 -j firewall2 etc, and similar for the FORWARD chain. BTW, the "attack" on http (which probably was not sourced from the addresses in the packets, but was rather meant to be a reflection attack on some other party) continued through today and ended a few hours ago. The second example that I posted became the main attack later, and I added another rule below the first line in my example: iptables -A firewall -p tcp -m multiport --sport 0:1023 --syn -j DROP This blocks any incoming connects that are coming FROM port numbers below 1024. Those do not occur in normal practice. Port numbers below 1024 are "special" ports for protected system services and normally are never the source port for connects. Any connects from ports below 1024 are highly suspect for being reflection attacks so above I block them all. Rob

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net