44net

44net@mailman.ampr.org

3196 discussions

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

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

04 Oct '13

> Subject: > Re: [44net] 44Net Digest, Vol 2, Issue 157 > From: > sp2lob <sp2lob(a)tlen.pl> > Date: > 10/03/2013 11:03 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Rob, > > I have already answer for you. > > Yes, my Pi is running Raspbian 3.6.11+ #538 > PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l > updated&upgraded as often as possible. > > Line from config.gz file you're asking about is as follow: > #CONFIG_IP_MROUTE is not set > > But here is my AMPRNet tunnel interface: > > tunl0 Link encap:UNSPEC > inet addr: 44.165.2.2 Mask: 255.255.255.248 > UP RUNNING NOARP MULTICAST MTU:1480 Metric:1 > > I've also 3 ax ifces, 3 nr ifces, 1 rose ifce and tun0 ifce from linux to my JNOS. > > Traffic flows in both directions IN&OUT just fine. > > Best regards. > Tom - sp2lob Hi Tom, Well, that is the same as what I have here except there is no MULTICAST on my tunl0 interface. The flag is only there on my eth0 interface. The kernel is the same version, config of that MROUTE option is also the same. Did you issue a command to get that MULTICAST on tunl0 switched on? Or is that supposed to be enabled by the application, rip44d in this case? I use this: ip addr add 44.137.40.2/32 dev tunl0 ip link set dev tunl0 up maybe I need "ip link set dev tunl0 multicast on"? That could be something to try... tomorrow I will add that command and change the ampr-ripd to use multicast socket instead of raw, and reboot to see what happens. Rob

3 2

Re: [44net] DMZ
by lleachii＠aol.com 04 Oct '13

04 Oct '13

All, Many stations are suggesting that those with devices behind firewalls simply add the device to the DMZ. This is an unsafe suggestion. I worked on this issue for many months and discovered how to route traffic through Linux Kernel, DD-WRT, OpenWRT and most D-Link based routers. IP Protocol Number Four (4 - IPENCAP) must be allowed. **In DD-WRT 1.) Browse to Administration > Commands 2.) Enter the commands either for either static or dynamic IP configuration 3.) Click "Save Firewall" **OpenWRT CLI 1.) Edit firewall "vi /etc/firewall.user" 2.) Enter the commands either for either static or dynamic IP configuration 3.) Save file and quit vi editor 4.) Reboot Device **OpenWRT LuCI GUI Option #1 (Recmmonded) 1.) Browse to: Network > Firewall > Port Forwards > New Port forward 2.) Enter the following information: - Name:<enter name> - Protocol:<select "other"> - External Port <leave blank, IPENCAP protocol does not use port numbers> - Internal Zone <lan> - Internal IP address <IP of you 44GW Device> - Internal Port <leave blank, IPENCAP protocol does not use port numbers> 3.) Click "Add" 4.) Browse to: Network > Firewall > Port Forwards 5.) Click "edit" on the new entry 6.) Change "protocol" to --custom-- 7.) The protocol dropdown will change to a textbox, enter "4" in the box 8.) Click "Save & Apply" **OpenWRT LuCI GUI Option #2 1.) Browse to: Network > Firewall > Custom Rules 2.) Enter the commands either for either static or dynamic IP configuration 3.) Click "Save & Apply" **On D-Link 1.) Browse to Network Settings > Advanced > Virtual Server 2.) Add name and IP address of 44GW, or select IP from the list and click the "<<" button 3.) Change Protocol to "Other" and enter "4" in the box under Protocol 4.) Click "Save Settings" **Command for Static IP (tested on DD-WRT and OpenWRT): iptables -t nat -I PREROUTING -p ipencap -d <GW Public IP> -j DNAT --to-destination <GW LAN IP> iptables -t filter -I FORWARD -p ipencap -d <GW LAN IP> -j ACCEPT **Command for Dynamic IP - (WAN is vlan1 in DD-WRT in OpenWRT it is usually eth0.1): iptables -t nat -I PREROUTING -p ipencap -i vlan1 -j DNAT --to-destination <GW LAN IP> iptables -t filter -I FORWARD -p ipencap -d <GW LAN IP> -j ACCEPT 73, Lynwood KB3VWG

3 2

Re: [44net] 44Net Digest, Vol 2, Issue 157
by sp2lob 03 Oct '13

03 Oct '13

Rob, I have already answer for you. Yes, my Pi is running Raspbian 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l updated&upgraded as often as possible. Line from config.gz file you're asking about is as follow: #CONFIG_IP_MROUTE is not set But here is my AMPRNet tunnel interface: tunl0 Link encap:UNSPEC inet addr: 44.165.2.2 Mask: 255.255.255.248 UP RUNNING NOARP MULTICAST MTU:1480 Metric:1 I've also 3 ax ifces, 3 nr ifces, 1 rose ifce and tun0 ifce from linux to my JNOS. Traffic flows in both directions IN&OUT just fine. Best regards. Tom - sp2lob

1 0

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

03 Oct '13

> Subject: > Re: [44net] 44Net Digest, Vol 2, Issue 156 > From: > <sp2lob(a)tlen.pl> > Date: > 10/03/2013 07:53 AM > > To: > "AMPRNet working group" <44net(a)hamradio.ucsd.edu> > > > Hello Rob et al, > > My Raspberry Pi is behing own TL-MR3420 router. > When I ran ripd44 for the very first time it didn't worked. > Following suggestion by one of U.S. hams, > I put Pi into DMZ zone - ripd44d automagically revived! Ok, but as I explained before, my Raspberry Pi is directly on the internet. I don't have problems with routers, NAT, DMZ zones or whatever. I have the issue that Hessu explains (Multicast socket not working; raw socket OK) but in my case it must be caused by something different than rp_filter. Is your Pi running Raspbian? What does it say when you enter: zgrep CONFIG_IP_MROUTE /proc/config.gz Rob

2 1

RIP question
by Lakenet 03 Oct '13

03 Oct '13

I run JNOS 2.0i with Ubuntu Linux 12.04. I am set up to receive RIP broadcasts and they are working fine. Along with the encapsulated RIP broadcast is coming non encapsulated data and JNOS is responding Unreachable Port Returned. Is this non encapsulated data something that I asked for in AmperNet registration or does it just come along or have to come along with the encap data? Jerry, N0MR

2 1

Attempting to contact 4Z4ZQ
by Assi Friedman 02 Oct '13

02 Oct '13

Folks: Apologies for the note, but I am trying to get in touch directly with Ronen Pinchook 4Z4ZQ, who is a member here. Ronen: do you mind contact me directly at assi(a)kiloxray.com regarding amprnet business. Thank folks, over and out. Assi KK7KX/4X1KX P.S: Brian, if you want to beat me over the head for this, you know where to find me :)

1 0

rip44d rp_filter problem fixed
by Heikki Hannikainen 01 Oct '13

01 Oct '13

I think I have found and fixed a problem which caused rip44d multicast reception to mysteriously fail on some systems. The workaround is present in rip44d version 1.4, which is available at: https://raw.github.com/hessu/rip44d/master/rip44d I just upgraded the Linux distribution on my gateway, and rip44d stopped working. After some slight hair-pulling I figured it out. The same thing will affect the C implementation, and doing the same workaround will remove the need to use a raw socket instead of the more optimal multicast socket. Some distributions/kernels (some of the new ones, and maybe some old ones too?) enable strict reverse path verification (rp_filter) by default. Reverse Path filtering looks at the source IP address of packets coming in on an interface, and checks that an outgoing packet destined to that same address would be routed out on that same interface according to your routing table. That's a nice feature as such - it drops spoofed packets, which is good for security. If someone on the Internet sends packets to you, and fakes the source address to be one of your internal addresses, it could save your day. Or, if a client/user on your network tries to send packets to the Internet with a fake source address (typically his computer is infected with a bot, and the bot is taking part in a DDOS attack), rp_filter will drop those packets with invalid source addresses. However, it affects multicast packets too. Our RIP packets come in on tunl0, with a source address of 44.0.0.1. Before your tunnel routing table is populated with RIP, there is no route to 44.0.0.1 pointing to tunl0. The RIP announcements do contain a route for 44.0.0.1, but we need to have it there to be able to receive any RIP packets. There are a couple of alternative workarounds to this: 1) Disable rp_filter on the tunl0 interface. sudo sysctl net.ipv4.conf.tunl0.rp_filter=0 (and put net.ipv4.conf.tunl0.rp_filter=0 in /etc/sysctl.conf) *or* 2) Set up a dummy route for 44.0.0.1/32 pointing to the tunl0 interface. It'll be replaced by the real one once the first RIP packets come in. I opted for option 2, rip44d 1.4 does that when starting up. If you have an asymmetric routing setup, rp_filter might cause some other surprises too. Good to keep it in mind. - Hessu, OH7LZB

1 0

Re: [44net] How to use my IP 44.xx.xx.xx
by Robbie De Lise 28 Sep '13

28 Sep '13

Andre, Please register a new subnet or ip at the portal first. If you like you can connect your new subnet/ip to the internet through hamnetbe vpn or 5ghz wifi link if a node is available in your area. We are currently not yet linked to the rest of ampr but are looking into it. https://portal.ampr.org/networks.php?a=region&id=304 Thank you Robbie ON4SAX 44.144 Coordinator Op 15 sep. 2013 12:58 schreef "on4hu" <on4hu.0(a)gmail.com> het volgende:

4 13

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net