Thanks Owen - that worked quite nicely.  I integrated it directly into
proto_mytun_setup() and now it’s working as expected.

Ken




On 2/22/14, 6:44 PM, "Owen Kirby" <o...@exegin.com> wrote:

>Hey Ken,
>
>I seem to recall running into some similar issues the last time I found
>myself writing some interface scripts for a custom tunnel. Our
>particular protocol was tunnelling some IPv6 stuff over a serial port,
>and we ran into the following two issues in getting the netifd scripts
>to work as expected:
>
>1) I had to set no_device=1 to tell netifd that the network connection
>didn't depend on a physical network interface, otherwise netifd wouldn't
>bring up the connection because it couldn't find the physical interface
>that it depended on.
>
>2) After bringing up the tunnel daemon, netifd and ubus still wouldn't
>show the connection as up. We had to get our tunnel daemon to run some
>scripts after bringing the interface up that would poke netifd and tell
>it that the interface had come up. Our script is as follows:
>
>#!/bin/sh
># IFNAME is the name of the physical network interface
># It shows up if you invoke "ifconfig $IFNAME"
>#
># STATE is passed by the daemon to tell us what it's doing.
># In this case, it has the value of "ROOT" or "JOINED" if it's running
># properly, or "IDLE" if it has been disconnected.
>#
># DEVNAME is the name of the interface described in UCI
># For example, you would start the interface with "ifup $DEVNAME"
>IFNAME="$1"
>STATE="$2"
>DEVNAME=$(echo $IFNAME | sed -e 's/^zbip-//')
>
>. /lib/netifd/netifd-proto.sh
>case "$STATE" in
>"ROOT" | "JOINED")
>proto_init_update "$IFNAME" 1 1
>proto_set_keep 1
>proto_send_update "$DEVNAME"
>;;
>"IDLE")
>proto_init_update "$IFNAME" 0
>proto_send_update "$DEVNAME"
>;;
>esac
>
>Cheers,
>Owen
>
>P.S. I figured most of this out by examining what the ppp packages do to
>get their network interfaces up and running with netifd. I couldn't find
>any documentation for this stuff.
>
>On 14-02-21 07:31 PM, Ken Bantoft wrote:
>>
>> Hi Developers,
>>
>> A quick question - how does ubus know a network connection is actually
>>up?
>> I have a tunnel interface, which is available at boot time (so always
>> available basically) and then a userland daemon that manages it -
>>assigns
>> IP address to the interface, authentication, etc
>>
>> I¹ve written a /lib/netifd/proto/mytun.sh file, with
>>
>> proto_mytun_init_config() {
>>      # Have tried without these, doesn’t seem to make a difference
>>      available=1
>>      no_device=0
>> }
>>
>>
>> proto_mytun_setup() {
>> local config="$1"
>> local iface="$2"
>>
>> /etc/init.d/mytun start
>>
>> # Attempt to tell everyone it¹s up - doesn¹t seem to work
>> uci_toggle_state network "$1" up 1
>> uci_toggle_state network "$1" connect_time $(sed -ne 's![^0-9].*$!!p'
>> /proc/uptime)
>>
>>
>> }
>>
>> proto_mytun_teardown() {
>> local interface="$1"
>> /etc/init.d/mytun stop
>>
>> proto_kill_command "$interface"
>> }
>>
>> add_proto mytun
>>
>>      
>> With the above, LuCI seems to know the state (shows up/down correctly in
>> the GUI) and ifup/ifdown seem to work consistently, but ubus does not
>>think
>> it is up, and the Online for: counter never changes:
>>
>>
>> root@OpenWRT:~# ubus call network.interface.mytun status
>> {
>>      "up": false,
>>      "pending": false,
>>      "available": true,
>>      "autostart": false,
>>      "proto": "mytun",
>>      "device": "mytdev",
>>      "data": {
>>              
>>      }
>> }
>>
>> root@OpenWRT:~# ifup mytun
>>
>> root@OpenWRT:~# ubus call network.interface.mytun status
>> {
>>      "up": false,
>>      "pending": true,
>>      "available": true,
>>      "autostart": true,
>>      "proto": "mytun",
>>      "device": "miydev",
>>      "data": {
>>              
>>      }
>> }
>>
>> devstatus on mytun returns as expected:
>> {
>>      "external": true,
>>      "present": true,
>>      "type": "Network device",
>>      "up": true,
>>      "link": true,
>>      "mtu": 1340,
>>      "macaddr": "0:0:0:0:0:0",
>>      "txqueuelen": 0,
>>      "statistics": {
>> // trimmed for length
>>      }
>> }
>>
>> Can someone point me in the right direction?
>>
>>
>> Thanks,
>>
>> Ken
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>_______________________________________________
>openwrt-devel mailing list
>openwrt-devel@lists.openwrt.org
>https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to