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
> [email protected]
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to