Modify

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#14032 closed defect (fixed)

Problem with getting 6in4 up

Reported by: anonymous Owned by: developers
Priority: high Milestone: Barrier Breaker 14.07
Component: packages Version: Trunk
Keywords: Cc: josef.semler@…, cyrus@…

Description

Im working on the ipv6-implementation for a wireless community here in Vienna. Since a couple of weeks (the last kernel update?) i´ve troubles getting the 6in4 interface up. (See my attached debug.log)
The builts from winter worked perfect.

Joe

Attachments (1)

6in4.debug-log.txt (16.7 KB) - added by anonymous 4 years ago.

Download all attachments as: .zip

Change History (21)

Changed 4 years ago by anonymous

comment:1 Changed 4 years ago by cyrus

Sorry, that report is hardly useful.

At first which version are you using now and back then? Compiled from trunk? Or Attitude Adjustment branches? Or using precompiled builds?

What went wrong? What does ifstatus 6in4 (or whatever you called your 6in4 interface) report?

What is your network configuration in general(/etc/config/network)? what do you want to achieve with it? Where should the tunnel prefixes go? etc.

comment:2 Changed 4 years ago by cyrus

  • Cc cyrus@… added

comment:3 Changed 4 years ago by cyrus

  • Resolution set to no_response
  • Status changed from new to closed

comment:4 Changed 4 years ago by anonymous

Hi Cyrus,
Since 37763 it's working again. I'm always using trunk for our images.
Sorry for not answering, had troubles to connect to dev.openwrt.org. When I've checked service was down.
Joe

comment:5 Changed 4 years ago by josef.semler@…

  • Resolution no_response deleted
  • Status changed from closed to reopened

Hi Cyrus,
Im opening this ticket again because we found the reason for our troubles with 6in4. 6in4 needs a STANDARD GATEWAY on ONE OF THE other INTERFACES to come up!
We are beliving, that this behaviour is not a bug, but its a blocker for IPv6-Deployment in our Mesh-Network. So it would be fine, if you could use another criteria for aktivating the 6in4 Interface.

Tnx 4 your great support
Joe

comment:6 Changed 4 years ago by anonymous

Acc your questions: We are compiling the trunk. Tests has been done on 9/11/13 together with LuCI 9902

comment:7 Changed 4 years ago by cyrus

Could you try replacing:
( proto_add_host_dependency "$cfg" 0.0.0.0 )
with
( proto_add_host_dependency "$cfg" "$peeraddr" )
in /usr/lib/netifd/proto/6in4.sh and see if that works better for you?

If that works well I will commit it upstream.

Last edited 4 years ago by cyrus (previous) (diff)

comment:8 Changed 4 years ago by anonymous

Replacement had no visible effect. 6in4-Interface ist after reboot down and can only "motivated" by adding a standardGW.
I guess that there is no GW defined by OLSR, when netifd will start 6in4. Maybe we can fake a GW at this time. Silly idea?

comment:9 Changed 4 years ago by anonymous

Hmm ah it is probably because olsrd isn't really well integrated (e.g. sets its routes by itself and not through netifd). Well you could try to remove the line from above entirely and see if that works better.

comment:10 Changed 4 years ago by anonymous

Its working by removing ( proto_add_host_dependency "$cfg" 0.0.0.0 ) from
/lib/netifd/proto/6in4.sh

Has the removement any influence in other behaviour?
If not I´m askin´ Cyrus to commit it upstream and say manny tnx for your support

JoeSemler, Funkfeuer Vienna

comment:11 Changed 4 years ago by jow

It will most likely break existing setups.

comment:12 follow-ups: Changed 4 years ago by cyrus

We cannot upstream this unfortunately.
The proto_add_host_dependency makes sure the 6in4 interface is started only once there is a route to the 6in4 gateway. Removing that line starts the tunnel asap, resulting in the tunnel being a blackhole for IPv6 traffic until there is a valid IPv4-route to the gateway.

The better solution would be to properly patch OLSRd so that it sends routing-information through netifd and not mainpulate routing by itself - or - make netifd listen on kernel routing events as well which could be even more tricky in the long run.

Last edited 4 years ago by cyrus (previous) (diff)

comment:13 in reply to: ↑ 12 Changed 4 years ago by anonymous

Replying to cyrus:

We cannot upstream this unfortunately.
The proto_add_host_dependency makes sure the 6in4 interface is started only once there is a route to the 6in4 gateway. Removing that line starts the tunnel asap, resulting in the tunnel being a blackhole for IPv6 traffic until there is a valid IPv4-route to the gateway.

Sounds clear 4 me, but I´ll take it as a WorkAround to proceed with our tests.

The better solution would be to properly patch OLSRd so that it sends routing-information through netifd and not mainpulate routing by itself - or - make netifd listen on kernel routing events as well which could be even more tricky in the long run.

Maybee Henning can help us patching OLSR in a right way. Shall I inform him or will you (jow or cyrus) will do that?

comment:14 in reply to: ↑ 12 Changed 4 years ago by Henning

Replying to cyrus:

The better solution would be to properly patch OLSRd so that it sends routing-information through netifd and not mainpulate routing by itself

Is this even the purpose of netifd? From the description of the thing (http://wiki.openwrt.org/doc/techref/netifd) I get that its responsible for the OpenWRT configuration... and that it CAN listen to netlink.

OLSRd is not manipulating any kind of configuration.

(yes, it is possible that OLSR informs other processes about setting/reverting routes or even offload the whole thing... the Quagga plugin does it for example)

make netifd listen on kernel routing events as well which could be even more tricky in the long run.

I think this would be the right solution, because it would also work with all other programs that set routes in the kernel.

comment:15 follow-up: Changed 4 years ago by cyrus

The thing is we don't really want every program to mess with the routing table. Especially with IPv6 and source-routing and in general in connection with multiple routing tables and policy rules this gets messy very fast.

It is much saner to send any routing information you want to netifd and let it take care of setting / deleting / changing the routing table. This way we can also manipulate the settings coming from the daemon (e.g. we can disable default-routes sent by the daemon).

comment:16 in reply to: ↑ 15 Changed 4 years ago by Henning

Replying to cyrus:

The thing is we don't really want every program to mess with the routing table.

I would disagree, its a two-edged sword... its the JOB of the routing protocol to write into routing tables.

Especially with IPv6 and source-routing and in general in connection with multiple routing tables and policy rules this gets messy very fast.

I don't see what IPv6 and source-specific routing has to do with this (nobody would do true source-routing I think ).

It is much saner to send any routing information you want to netifd and let it take care of setting / deleting / changing the routing table. This way we can also manipulate the settings coming from the daemon (e.g. we can disable default-routes sent by the daemon).

Might be right... might be a good way to break your routing. Disabling a default route by the routing agent will most likely just create a black hole for everyone else.

But if someone would be willing to write a plugin for OLSRd, the routing part of this integration should be possible. I am not sure this would be sufficient, because we might still get interference from the interface up/down events.

comment:17 follow-up: Changed 4 years ago by cyrus

  • Resolution set to fixed
  • Status changed from reopened to closed

I see your point. However to build a (compliant) IPv6 router you need to do source routing for several reasons (e.g. filtering ULA/local traffic or if you have multiple uplinks). Of course you can break your routing if you mess with it but for that you don't need netifd.

Anyway this is getting off-topic. Either someone has to implement a better OLSR integration for OpenWrt or submit a patch for netifd that properly reads the routing table dependencies from netlink.
6in4 itself is working as expected and there is no good work-around or solution for this situation.

comment:18 in reply to: ↑ 17 Changed 4 years ago by Henning

Replying to cyrus:

Anyway this is getting off-topic. Either someone has to implement a better OLSR integration for OpenWrt or submit a patch for netifd that properly reads the routing table dependencies from netlink.

I think both can only be done by the people who wrote netifd at the moment, because netifd is not documented (at least I didn't found any documentation). I am also not sure netifd already contains any code to handle kernel routes, I only found code for policy rules inside the current repository.

comment:19 Changed 4 years ago by cyrus

I agree it might needed to be done at least partly by one of the netifd maintainers. However I'm not sure when it could be done at the moment.

comment:20 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.