44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] Strange Broadcasts...
by Rob Janssen 14 Jun '15

14 Jun '15

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Strange Broadcasts... > From: > Nigel Vander Houwen <nigel(a)k7nvh.com> > Date: > 06/13/2015 09:30 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Rob, > > Thank you for making my point. The reason you cant use a 44/8 address for a tunnel endpoint is because routing is broken. > > Nigel > I don't agree with you. There is a problem with routing inside UCSD in that case, but there are other reasons why that should not be done. When you run an IPIP gateway on a source-address-filtered system (and in my opinion, ALL user connections should be soirce-address-filtered!! ISP's that don't to that just suck!) you need to route back traffic from net-44 to internet via the gateway. The only viable way of setting up policy routing rules to do that falls apart when tunnel endpoints are inside 44.0.0.0/8. So that should just be prohibited. (As Marius also explained, it is even worse when tunnel endpoints exist within subnets that are also advertised as being gatewayed) Rob

1 0

Re: [44net] Strange Broadcasts...
by Rob Janssen 14 Jun '15

14 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Bryan Fields <Bryan(a)bryanfields.net> > Date: > 06/13/2015 09:40 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > I agree, however the configuration of a single gateway announcing 44/8 without > the ability to reach more specific networks is_broken_ routing. Let me say > this again: > > _The UCSD Gateway has BROKEN ROUTING affecting the REACHABILITY of IPIP users._ > > If BGP users announce a subnet that 99.99999% of the internet can see, but > IPIP users behind the UCSD gateway can't reach it, it's not BGP users that > have broken routing, it's the silly UCSD gateway. This is INCORRECT, it is actually your own system that is broken. When you put up a system that announces a BGP route on Internet, you should also make that system part of the IPIP mesh for the same subnet that you advertise on BGP. Then, those that want to reach you on IPIP do not need to go via the UCSD gateway but can directly reach you on IPIP. Remember IPIP is a mesh, there is no "central gateway" other than that it has the largest subnet and attracts all traffic that is not otherwise routed. Routing the IPIP traffic is your own responsibility, don't shift it to UCSD or Brian. Rob

7 22

Radius
by Rob Janssen 13 Jun '15

13 Jun '15

44net-request(a)hamradio.ucsd.edu wrote: > Subject: > Re: [44net] Strange Broadcasts... > From: > "Sam VK4AA" <vk4aa(a)vk4aa.com.au> > Date: > 06/13/2015 01:27 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Morning Gang > > Has anyone done authentication for paket stations connecting to our network > by using radius? > > > Sam > VK4AA I have tried, although not very persistently, but until now I have not succeeded. I thought it would be easy (having some experience with radius in combination with VPN routers), but until now I have not succeeded in getting a configuration with WiFi APs operating in EAP mode and freeradius server on Linux to actually work. It should be possible, though. Rob

1 0

Re: [44net] Strange Broadcasts...
by Rob Janssen 13 Jun '15

13 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Tom Hayward <esarfl(a)gmail.com> > Date: > 06/11/2015 08:45 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > Forget about this; it's just syntax. Who cares if we have to have > hundreds of P2P interfaces instead of a single P2MP? The script > creates them, so the burden of both methods is equivalent. > Well, I think it is much better (at least, cleaner) to have a single IPIP interface (P2MP) and have a route table (separate or merged with the main table) updated by a routing protocol. What you have made will work, but requires frequent downloading of a file and patching of the configuration to process changes. I did that before on Linux, but after having installed ampr-ripd I would not want to go back to that method... About routes: in Linux it is possible to have routes bound to an interface that has a broadcast nature (e.g. ethernet) and with a gateway that is outside the subnet served by the system itself. So you can partition a subnet and still have only a single gateway. This can be useful on ham networks where everyone in a local area has a Point-to-Point link to a node, and everyone routes to others via the node, but the node does not have an address in each subnet. RouterOS cannot handle this, but Linux can. E.g.: node has subnet 44.137.40.0/23 and has address 44.137.41.254 user has subnet 44.137.41.96/28 and has address 44.137.41.110 on eth0 then: ip route add 44.0.0.0/8 dev eth0 gw 44.137.41.254 onlink To do this in RouterOS (and in many other routers) you need to set the subnet mask to /23 on the eth0, but that means it will try to contact the others directly, not routing via the node. This will work when the local area is switching/bridging. Otherwise you will need to have a node address in everyone's subnet. The same situation occurs when setting up the P2MP IPIP tunnel interface: you assign it the subnet of your local system, so all the routes are outside the interface's subnet and need the "dev" and "onlink" parameters. RouterOS does not support them. But Linux does. Rob

7 10

Re: [44net] Strange Broadcasts...
by Rob Janssen 13 Jun '15

13 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > "Marc, LX1DUC" <lx1duc(a)laru.lu> > Date: > 06/12/2015 05:06 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > > I do think that regardless of the OS it is much more important that anybody using 44net addresses shall support the IPIP mesh, regardless of any other routing procedures (e.g. direct BGP announcement, etc) in use. I have the "luxury" to be able to > do direct BGP announcements, so I can reach BGP-only 44networks without NATing my 44net to my commercial IP address, others don't have this luxury but would eventually like to reach those 44etworks without the requirement for NAT. Our country gateway is BOTH on BGP and on the IPIP mesh. It advertises the entire 44.137.0.0/16 network on both BGP and IPIP. My systems at home are on net 44.137.41.96/28 and are linked to a local node for 44.137.40.0/23 via RADIO (unusual, I know...) and that node is again linked to the gateway system via our HAMNET. So my system is reachable both for BGP and for IPIP systems (and radio-connected systems) without me running IPIP myself. Hence I don't need to do that at home. When my radio link fails, I can setup an IPsec or OpenVPN VPN connection to our gateway, and routing in the network will automatically adapt (the gateway and the nodes talk BGP on a private ASN# on the HAMNET side and the gateway will advertise my 44.137.41.96/28 subnet when I setup an IPsec or OpenVPN link). So there is no need to worry! Rob

2 1

Re: [44net] Strange Broadcasts...
by Rob Janssen 12 Jun '15

12 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > Jeroen Massar <jeroen(a)massar.ch> > Date: > 06/11/2015 09:03 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > >Forget about this; it's just syntax. Who cares if we have to have > >hundreds of P2P interfaces instead of a single P2MP? > ntpd cares about it and also the Linux and FreeBSD kernels. > > ISC ntpd listens on each interface automatically, hence after ~200 > interfaces it breaks as it runs out of file descriptors (each interface > gets a separate socket as it uses it that way to be able to properly > select the interface to reply to packets on that interface). I know about that problem! Silly ntpd listens on a separate socket for every address, instead of just listening on a wildcard socket. It caused havoc on our gateway because it has over 200 addresses assigned to a dummy0 interface, used by an EchoLink proxy farm running on the machine. Fortunately in recent versions of ntpd it can be solved by config like this: interface ignore all interface listen lo interface listen eth1 interface listen tun0 interface listen tunl0 i.e. you can direct ntpd what interfaces to watch and to ignore the rest. I think it would be better when it listened on 0.0.0.0 instead (of course you CAN set the source address of outgoing packets on a wildcard socket, at least in Linux you can), but I saw there already has been a heated debate about that on the mailinglist so I chose not to suggest that and use the abovementioned workaround. Rob

1 0

Re: [44net] Strange Broadcasts...
by Rob Janssen 11 Jun '15

11 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 06/06/2015 09:48 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > Hi Rob, > > I was quite active in the Mikrotik community and tried to push a little our > ampr tunnel stuff. > But the results are actually null. People are friendly but not interested. Ok... at the moment I am reading the forum to see how change requests actually are to be posted and how they are handled, as I have some other requests. > The missing element is a way to create an IPIP interface without a specific > peer IP, and add routes to specific peers on a given IPIP interface to get > it in multipoint mode. That is clear, yes. I already found that the do not support static routes being bound to interfaces, let alone "onlink" routes. So even when you would want to load routes using a script, it still cannot be done. They must have a reason for this (probably they want to keep the routing entirely clean according to common practices), as the Linux kernel can do a lot more than what they expose via the config interface. > > The easiest way to get ampr up fully is actually to set up a metarouter on a > mipsbe routerboard (they have a xen virtualization on those), and run a > OpenWRT in it, to do IPIP encap and run ampr-ripd. I have tried that, it > works, but at the moment I use a PPC based routerboard which doesn't offer > virtualization. > But your RB2011 is a good candidate for this kind of setup, being mipsbe > based. Others would be the RB45x, the RB75x, the RB95x and the OmniTik > series. As I wrote, I have no need for this because my RB2011 has a radio link to HAMNET and as a backup I can setup an IPsec VPN to our gateway. So I don't need to be on the IPIP mesh. And I still have a Linux system in colocation (a Raspberry Pi) that is on IPIP. But for others, this approach can be interesting. Some systems e.g. www.pe1chl.ampr.org and hampi.pe1chl.ampr.org are routed over this radio link and the MikroTik (but there is no useful content on them). > > Regarding to linux: They run a proprietary distribution on a 3 kernel, but > shell access is unfortunately not available, and there is no way to add 3-rd > party extensions. > The device can be "rooted", though. You get a busybox shell. I have not done that yet, it will probably make it difficult to get support in case I encounter some bug I want to be fixed. Rob

4 5

My talk from Dayton 2105
by Bryan Fields 09 Jun '15

09 Jun '15

The hamradionow guy the videos of the 2015 TAPR forum at Dayton up. Thought it may be of interest to the group. https://www.youtube.com/watch?v=eAzkSP2nt0M&feature=youtu.be&t=85 73's W9CR -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

1 0

Re: [44net] Strange Broadcasts...
by Steve L 07 Jun '15

07 Jun '15

Maybe we should recommend some outbound firewalling for such known nuisances? To reduce traffic, drop neighbor discovery and smb as well as MikroTik Neighbor Discovery Protocol on tunl0 (optional, but a good idea): iptables -A OUTPUT -o tunl0 -p udp --dport 10001 -j DROP iptables -A OUTPUT -o tunl0 -p udp --dport 137:139 -j DROP iptables -A OUTPUT -o tunl0 -p udp --dport 5678 -j DROP 81.174.253.193 2014-02-23 11:14:58 G7UOD 24.85.103.226 2014-05-22 15:26:56 VE7ASS

6 5

Re: [44net] Strange Broadcasts...
by Rob Janssen 06 Jun '15

06 Jun '15

> Subject: > Re: [44net] Strange Broadcasts... > From: > "Marius Petrescu" <marius(a)yo2loj.ro> > Date: > 06/06/2015 08:54 AM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > The iptables solution doesn't apply to Mikrotik equipment since they don't > run Linux. Of course they are! It is easy to add iptables rules like that to a MikroTik router. But even easier to just turn off the sending of the MNDP packets. > The Mikrotik Neighbor Discovery Protocol (MNDP) is enabled by default on > newly created IPIP interfaces. > And since there is such an interface for each mesh partner, they are > probable programatically generated by a script. Well, running IPIP mesh on a MikroTik may not be a good idea. At least not until it supports ampr-ripd so you can run just a single IPIP interface for the entire mesh, and use a separate routing table updated by RIP messages. (similar to the situation with other commercial routers like Cisco and Juniper) Did anyone ever try to get such a change incorporated by the MikroTik people? I have no idea how friendly they are to such specialized requests, but on the other hand they have a very broad collection of exotic protocols and configuration items. (I just got a 2011UiAS-2HnD this week, and I am impressed. I will use it as my home router, but not on the IPIP mesh, it will be connected to my Ubiquiti Airgrid with a link to the local HAMNET which again is linked to our gateway) Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net