44net

44net@mailman.ampr.org

3194 discussions

Re: [44net] net-44 source address spoofing?
by Rob Janssen 13 Oct '13

13 Oct '13

> Subject: > Re: [44net] net-44 source address spoofing? > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 10/13/2013 08:20 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Rob, > > I also get a some strange unrelated traffic: ping replies, SYN-ACK on > various ports, pings and SYN targeted to random IPs on my subnets. > So nothing new here. > I studied the source addresses for some time: china, russia, and alot of > "this IP range is really wold wide" according to RIPE. > Since they achieve nothing, I choose to ignore them, along with some tight > stateful firewall rules. > > Marius, YO2LOJ > Yes, it is required to have a firewall in front of everything these days... Of course I always firewalled malicious attempts to make incoming connects to my systems, this unrelated traffic usually does no real harm. It was only the ping replies that triggered me to look what was really happening. It is unfortunate that the amprgw has to carry all that unnecessary traffic... (and the amsat.org mailserver as well. the vast majority of what I receive is discarded immediately as spam, mostly Korean. And I cannot even read Korean) Rob

2 1

Re: [44net] net-44 source address spoofing?
by lleachii＠aol.com 13 Oct '13

13 Oct '13

I've also noticed the strange traffic and am working on discovering its origins. This is common and should be expected on any public IP address. It's mostly pings and attempts to seek vunerable machines accessable by Remote Desktop Protocol. 73, -Lynwood KB3VWG

1 0

Fwd: [nos-bbs] encap.txt
by Don Moore 12 Oct '13

12 Oct '13

---------- Forwarded message ---------- From: Don Moore <ve3zda(a)gmail.com> Date: Sat, Oct 12, 2013 at 4:20 PM Subject: Fwd: [nos-bbs] encap.txt To: gw <gateways(a)ampr-gateways.org>, gateways(a)ampr.org ---------- Forwarded message ---------- From: Don Moore <ve3zda(a)gmail.com> Date: Sat, Oct 12, 2013 at 4:14 PM Subject: Re: [nos-bbs] encap.txt To: TAPR xNOS Mailing List <nos-bbs(a)tapr.org> Hi Dave, let me know what the address is and I can input it into jnos for now.. 73, Don On Sat, Oct 12, 2013 at 2:41 PM, Michael E. Fox - N6MEF <n6mef(a)mefox.org>wrote: > I certainly hope so. There are a bunch of us that use encap.txt instead > of the RIP process.**** > > ** ** > > M**** > > ** ** > > *From:* nos-bbs-bounces(a)tapr.org [mailto:nos-bbs-bounces@tapr.org] *On > Behalf Of *Wars > *Sent:* Saturday, October 12, 2013 11:14 AM > > *To:* TAPR xNOS Mailing List > *Subject:* Re: [nos-bbs] encap.txt**** > > ** ** > > Hi Don,**** > > I do not know if anyone is going to fix the encap.txt file. **** > > My IP address changed and without a new encap.txt file I can only use the > RF with my JNOS. **** > > ** ** > > 73 Dave wa8rsa**** > > ** ** > > ** ** > > > > **** > > ** ** > > Dave**** > > Cell : 616-836-1214**** > > Sent from my iPhone**** > > > On Oct 12, 2013, at 2:01 PM, Don Moore <ve3zda(a)gmail.com> wrote:**** > > thanks for the info, do you know if it's being fixed?**** > > ** ** > > On Sat, Oct 12, 2013 at 11:54 AM, wa8rsa <wa8rsa(a)charter.net> wrote:**** > > Don,**** > > **** > > You are correct. The encap.txt file is out of date.**** > > **** > > 73 Dave wa8rsa**** > > **** > ------------------------------ > > *From:* nos-bbs-bounces(a)tapr.org [mailto:nos-bbs-bounces@tapr.org] *On > Behalf Of *Don Moore > *Sent:* Saturday, October 12, 2013 7:03 AM > *To:* TAPR xNOS Mailing List > *Subject:* [nos-bbs] encap.txt**** > > **** > > Have those of us not using the RIP process noticed that the encap.txt file > is not updating or is it my problem?**** > > I went so far as to check the gateway file and it too appears to be out of > date...**** > > 73, Don - ve3zda**** > > > > > > > ======= > Email scanned by PC Tools - No viruses or spyware found. > (Email Guard: 9.1.0.2900, Virus/Spyware Database: 6.21600) > http://www.pctools.com<http://www.pctools.com/?cclick=EmailFooterClean_51> > ======= **** > > > > > > > ======= > Email scanned by PC Tools - No viruses or spyware found. > (Email Guard: 9.1.0.2900, Virus/Spyware Database: 6.21600) > http://www.pctools.com<http://www.pctools.com/?cclick=EmailFooterClean_51> > ======= **** > > > _______________________________________________ > nos-bbs mailing list > nos-bbs(a)tapr.org > http://www.tapr.org/mailman/listinfo/nos-bbs**** > > ** ** > > _______________________________________________ > nos-bbs mailing list > nos-bbs(a)tapr.org > http://www.tapr.org/mailman/listinfo/nos-bbs**** > > > _______________________________________________ > nos-bbs mailing list > nos-bbs(a)tapr.org > http://www.tapr.org/mailman/listinfo/nos-bbs > >

2 1

Re: [44net] Announcement: ampr-ripd new version 1.6
by Rob Janssen 11 Oct '13

11 Oct '13

> Subject: > [44net] Announcement: ampr-ripd new version 1.6 > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 10/10/2013 09:22 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hello XYLs and OMs, > > The modified version of ampr-ripd according to Rob's sugestion to use > MCAST_JOIN_GROUP and be interface specific is available for download at > atwww.yo2loj.ro under hamprojects. > > Direct links: > http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.6.tgz > http://www.yo2loj.ro/hamprojects/ampr-ripd-1.6.tgz > > Download, compile and have fun. > > Marius, YO2LOJ Thank you Marius! I compiled and installed it, and it works OK in my environment even when I have two interfaces with the same address. It assigned the multicast group to the correct interface and it receives the multicast OK. Finally this hair-pulling about "why doesn't this work???" is finished! Rob

1 0

Re: [44net] 44Net Digest, Vol 2, Issue 162
by Rob Janssen 10 Oct '13

10 Oct '13

> Subject: > Re: [44net] 44Net Digest, Vol 2, Issue 159 > From: > sp2lob <sp2lob(a)tlen.pl> > Date: > 10/07/2013 09:49 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hello Rob et al, > > Quote: > "...by default mcast routes will be associated with an interface > the kernel picks (usually the first to come up)." > > There is something what you're looking for, I believe. > Small, nifty & powerfull program to install: *smcroute* > > The *smcroute* <http://www.cschill.de/smcroute/> utility provides a command line interface to manipulate > the multicast routing tables via a method other than *mrouted*. Tom, I looked in the source and this tool is not going to fix it. It uses exactly the same setsockopt call that ampr-ripd is already using to join the multicast group. The problem is that this setsockopt has 2 IP address parameters, one is the address of the local interface and the other is the multicast group to join. This is of course wrong. The first should not be an IP address but an interface name. But this kernel interface appears to be very old, dating back from BSD Unix. Given is situation, there is no way to uniquely identify the interface where the multicast group has to be joined, and the problem cannot be solved. Either all interfaces have to use a different address, or the multicast group must be joined before a duplicate address is created (I do that now). Or, when you don't mind using undefined implementation details, it will probably also work when tunl0 is created as the last interface. (because it appears the kernel has preference for the last interface in the list when a duplicate is found) W.r.t. multicast routing not being enabled: that does not appear to matter. Probably this is only required when you want the Pi to do actual forwarding of multicast traffic, not for just receiving it. Rob

3 4

Re: [44net] 44Net Digest, Vol 2, Issue 159
by Rob Janssen 08 Oct '13

08 Oct '13

> Subject: > Re: [44net] 44Net Digest, Vol 2, Issue 159 > From: > sp2lob <sp2lob(a)tlen.pl> > Date: > 10/06/2013 12:43 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Hello Rob et al, > > In my system I've similar setup. > > 1. tun0 - tunnel to my JNOS > 2. tunl0 - tunnel to AMPRNet > > Both have assigned same IP - 44.165.2.2 > I do not observe anything suspicious. > > What kind of issue do you encounter, please? > > Best regards. > Tom - sp2lob Tom, Check this: cat /proc/net/igmp Idx Device : Count Querier Group Users Timer Reporter 1 lo : 1 V3 010000E0 1 0:00000000 0 2 eth0 : 1 V3 010000E0 1 0:00000000 0 3 tunl0 : 2 V3 090000E0 1 0:00000000 0 010000E0 1 0:00000000 0 4 net0 : 1 V3 010000E0 1 0:00000000 0 As you can see, the 224.0.0.9 address is at the tunl0 interface. When I start the daemon after the net0 interface is created (tun0 in your case) the address gets added to net0 only, and not to tunl0. Therefore the daemon does not receive the 224.0.0.9 multicasts (only 224.0.0.1 which everyone gets). I don't know what the algorithm is to select the interface when there are multiple interfaces with the same address. It looks like it picks the one with the highest index. The function to add a multicast address cannot specify the interface directly. Rob

4 6

Re: [44net] no more 44-net routing through amprgw?
by Rob Janssen 06 Oct '13

06 Oct '13

> Subject: > Re: [44net] no more 44-net routing through amprgw? > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 10/06/2013 05:31 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Ron, > > Ampr-gw doesn't route anything to other ampr hosts. It allows only the > routing to internet hosts. > To reach ampr hosts you need to have a tunnel established with each host... > So the behavior is as expected. > > Marius, YO2LOJ Ok, I think in the past it worked when used as a default route. Maybe too many users made a lazy setup that routed everything through amprgw and did not setup the tunnel mesh, thus overloading amprgw. Anyway it is not a real problem as the multicasting is now working and the RIP daemon adds the routes. Rob

1 0

no more 44-net routing through amprgw?
by Rob Janssen 06 Oct '13

06 Oct '13

During my tests yesterday (to get RIP working with a multicast socket) there was an extended period where there was only a default route in my table 44 which is used to send network-44 traffic. This default route sends the traffic to amprgw as tunneled traffic (ipip). This route is normally used only for traffic leaving net 44 to the internet, and more specific tunnels are used for all gateway stations. But this temporarily did not work while I was debugging and the RIP packets were not being processed. What I noticed was that I lost connectivity to the other network-44 stations during that interval. I would expect that amprgw would forward the traffic to the other stations. Of course this is not a desirable permanent situation, but I think it worked in the past. Has this forwarding been blocked in amprgw? Or is this something that must be caused by a local configurarion error here? (like a firewall issue) Rob

3 2

Re: [44net] 44Net Digest, Vol 2, Issue 159
by Rob Janssen 05 Oct '13

05 Oct '13

> Subject: > Re: [44net] 44Net Digest, Vol 2, Issue 158 > From: > <sp2lob(a)tlen.pl> > Date: > 10/04/2013 10:32 PM > > To: > "AMPRNet working group" <44net(a)hamradio.ucsd.edu> > > > Hello Rob et al, > > What Brian just suggested is EXACTLY what I've in my startup scripts, Hi! > > # > modprobe ipip > ifconfig tunl0 44.165.2.2 netmask 255.255.255.248 multicast up > # > > Best regards. > Tom - sp2lob Well, after a long debugging session I finally found what is going wrong! It is not this multicast bit. In fact, ampr-ripd sets it while initializing in multicast mode. The cause of my problems was that the same IP address is used on different interfaces. I have my address 44.137.40.2 on tunl0 but also on a tun interface that provides a tunnel to locally running KA9Q software, which uses address 44.137.40.1 When initializing, ampr-ripd joins multicast group 224.0.0.9 with address 44.137.40.2, but I finally found that this is happening on the tun interface and not on the ipip tunl0. This can be seen using "cat /proc/net/igmp". When I start ampr-ripd after creating tunl0 and before the tun is brought up, it works OK. The 44.137.40.2 address still is unique at that point, and the group is joined on the correct interface. I still have to decide what permanent strategy to use. Maybe I need to allocate another address... Rob

2 1

Re: [44net] 44Net Digest, Vol 2, Issue 156
by Rob Janssen 04 Oct '13

04 Oct '13

> > From: > Heikki Hannikainen <hessu(a)hes.iki.fi> > Date: > 10/01/2013 10:01 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > I think I have found and fixed a problem which caused rip44d multicast > reception to mysteriously fail on some systems. Interesting story. I thought it might be the reason for my battle with the multicast socket on the Raspberry Pi, and I have checked the setting of rp_filter on it, but when I do: cat /proc/sys/net/ipv4/conf/*/rp_filter I get: 0 0 0 0 0 0 So it looks like the rp_filter is off for all interfaces on this system. It could be a good idea indeed to turn it on, although I have some DROP rules for obviously spoofed traffic in my firewall, but that is not going to help solving the multicast problem. Apparently there is more than one reason why it could fail... still have not found what is going wrong here. Rob

3 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net