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