[LEDE] 17.01.4 GRE Tunnel and babeld

[Loosely Rigorous]

Hello,

Following our meeting today, we moved the uocradio node to

the new labaki room. Now, in my infinite wisdom, I additionally

decided to upgrade the router (henceforth known as “blacky”)

to LEDE. This initially went without a hitch, up to the point of

setting up the GRE tunnel.

It proved to be a _massive_ pain in the ass, as a lot of things have

changed between 14.07 (OpenWRT) and 17.01 (LEDE). The gist is:

1. The iproute2 found in the old versions has been replaced by the

BusyBox ip which evidently supports a very rudimentary subset of

features. In our case, “ip tunnel” is omitted, and subsequently, the

script that had been setup some time ago is no longer working.

2. (Un)fortunately, this missing functionality has been replaced by

a uci compatible /etc/config/network stanza, which is actually fairly

neat. You can find more info at [1]. Before I continue, however, I have

a few words about this.

Now take note. As you may or may not know, interfaces in linux

have a hard limit (see [2]). The information from [1] tells us that

the interface name for a GRE tunnel will be the logical name

(the one you set in LEDE), prepended with “gre4-” or “gre6-”

(depending on IP version). It is therefore quite trivial to actually

overcome this limit (if you used a logical name like, oh, I don’t know,

“tunuoclabaki”. wc yields 17 total characters).

At that point, LEDE’s venerable netifd will shit itself and go in an

endless loop of failing to bring up the interface and flooding the logs

with “Unknown Error”. So if that ever happens to you, you know what

to check first.

Now, having overcome this, we naturally end up at:

3. it appears that for some reason LEDE’s babeld doesn’t seem to like

this new setup. After finally correctly setting up the interfaces in babel, it

appears that babeld is having a hard time to correctly propagate the routes.

Interestingly, on whitey’s route table the routes from the other side can actually

be seen.

Only problem is, they’re unreachable. Don’t really know why. I should note that

blacky does not have any routes in it (from whitey).

Sample output from whitey:

unreachable 10.176.35.0/26  proto 42  metric 4294967295 onlink

unreachable 10.176.35.248/30  proto 42  metric 4294967295 onlink

unreachable 10.176.35.252/30  proto 42  metric 4294967295 onlink

unreachable 10.176.39.0/26  proto 42  metric 4294967295 onlink

unreachable 10.176.39.224/29  proto 42  metric 4294967295 onlink

unreachable 10.176.39.232/29  proto 42  metric 4294967295 onlink

unreachable 10.176.39.240/29  proto 42  metric 4294967295 onlink

unreachable 10.176.39.248/29  proto 42  metric 4294967295 onlink

ICMP seems to work:

root@whitey:~# ping -c2 10.176.4.254

PING 10.176.4.254 (10.176.4.254): 56 data bytes

64 bytes from 10.176.4.254: seq=0 ttl=64 time=0.901 ms

64 bytes from 10.176.4.254: seq=1 ttl=64 time=0.736 ms

But SSH not so well

root@whitey:~# ssh ro...@10.176.4.254

ssh: Couldn't set SO_PRIORITY (Bad file descriptor)

ssh: Exited: Error connecting: Connection refused

Now initially this might seem like a configuration issue, but the thing is:

1) The firewall is in it’s default setup where only

    a. WAN to LAN forward is rejected

    b. LAN to WAN forward is accepted

2) Only forward chain is rejected by default.

3) Dropbear’s default behaviour of listening on all interfaces was left unchanged.

The packets should be ending up in the input chain, and dropbear should be

listening so it makes no sense that the connection is refused. It may be that

the tunnel itself is broken, or maybe the packets don’t end up in the input chain

for some reason unapparent to me.

That’s it for now. I’m very tired and out of ideas for the day. Any and all help

will be appreciated.

Danke schön.

[1] https://lede-project.org/docs/user-guide/tunneling_interface_protocols#common_options_for_gre_protocols

[2] https://stackoverflow.com/questions/24932172/what-length-can-a-network-interface-name-have

- looselyrigorous
PGP: 5E98 CBF2 4498 1991 4A41  5252 E63A 5B38 3165 BD72

[Loosely Rigorous]

Well, this is embarrassing.

It turns out the problem was two-fold.

1) The subnet 10.176.35.0/24 I was told was _not_ taken, was

actually used by danmilon! Now this was the minor of the two,

and it only meant that danmilon wasn’t accessible by the rest of

the network.

2) Of course the primary issue was that that the firewall default

 action in the forward chain was reject. This was already a known

quantity, but I still managed to write it off as unimportant.

(╯°□°）╯︵ ┻━┻

So anyway. It’s all working now. I should note, we reverted the

node to temporarily use uocradio's 10.176.24.0/24 subnet. Will

get around to changing it to something that’s not already allocated,

once we clean up WiND and the Wiki and establish an updated

IP allocation table.

o/

- looselyrigorous
PGP: 5E98 CBF2 4498 1991 4A41  5252 E63A 5B38 3165 BD72

[Orfeas Kalipolitis]

\ο

--
Λάβατε αυτό το μήνυμα επειδή έχετε εγγραφεί στην ομάδα "Heraklion Wireless Metropolitan Network" των Ομάδων Google.
Για να απεγγραφείτε απ' αυτή την ομάδα και να σταματήσετε να λαμβάνετε μηνύματα ηλεκτρονικού ταχυδρομείου απ' αυτή, στείλτε ένα μήνυμα ηλεκτρονικού ταχυδρομείου στη διεύθυνση connect-herakl...@googlegroups.com.
Για περισσότερες επιλογές, επισκεφτείτε τη διεύθυνση https://groups.google.com/d/optout.