#20729: proto 'none' overwriting tun interfaces
--------------------------+--------------------------------
Reporter: openwrt@… | Owner: developers
Type: defect | Status: new
Priority: normal | Milestone:
Component: base system | Version: Chaos Calmer 15.05
Resolution: | Keywords:
--------------------------+--------------------------------
Comment (by risa2000):
I would like to add another take on this issue. As the OP I have been
using `option proto none` for my `tun0` in `/etc/config/network`. This has
been working for years (e.g. in r45715).
Now, on the build from the trunk (r47874), I am getting exactly same
behavior, although I am using `ip` instead of `ifconfig`. So after boot
what I see is:
{{{
root@risa-wrt:~# ip addr
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel
state UNKNOWN group default qlen 100
link/none
}}}
While the `/tmp/openvpn.log` from the startup shows that the addresses
were correctly attached:
{{{
root@risa-wrt:~# cat /tmp/openvpn.log
Sat Dec 12 14:03:19 2015 us=935399 OpenVPN 2.3.7 mips-openwrt-linux-gnu
[SSL (PolarSSL)] [LZO] [EPOLL] [MH] [IPv6]
Sat Dec 12 14:03:19 2015 us=935639 library versions: PolarSSL 1.3.15, LZO
2.08
Sat Dec 12 14:03:19 2015 us=936670 Diffie-Hellman initialized with 1024
bit key
Sat Dec 12 14:03:19 2015 us=993689 WARNING: file '/etc/openvpn/risa-
wrt.key' is group or others accessible
Sat Dec 12 14:03:20 2015 us=5046 crypto_adjust_frame_parameters: Adjusting
frame parameters for crypto by 40 bytes
Sat Dec 12 14:03:20 2015 us=5358 TLS-Auth MTU parms [ L:1541 D:138 EF:38
EB:0 ET:0 EL:3 ]
Sat Dec 12 14:03:20 2015 us=5640 Socket Buffers: R=[163840->131072]
S=[163840->131072]
Sat Dec 12 14:03:20 2015 us=33935 TUN/TAP device tun0 opened
Sat Dec 12 14:03:20 2015 us=34242 TUN/TAP TX queue length set to 100
Sat Dec 12 14:03:20 2015 us=34515 do_ifconfig, tt->ipv6=0,
tt->did_ifconfig_ipv6_setup=0
Sat Dec 12 14:03:20 2015 us=34859 /sbin/ip link set dev tun0 up mtu 1500
Sat Dec 12 14:03:20 2015 us=41064 /sbin/ip addr add dev tun0 local
192.168.100.1 peer 192.168.100.2
Sat Dec 12 14:03:20 2015 us=49949 /sbin/ip route add 192.168.4.0/24 via
192.168.100.2
Sat Dec 12 14:03:20 2015 us=57522 /sbin/ip route add 192.168.100.0/24 via
192.168.100.2
Sat Dec 12 14:03:20 2015 us=66189 Data Channel MTU parms [ L:1541 D:1450
EF:41 EB:12 ET:0 EL:3 ]
Sat Dec 12 14:03:20 2015 us=66495 UDPv4 link local (bound): [undef]
Sat Dec 12 14:03:20 2015 us=66729 UDPv4 link remote: [undef]
Sat Dec 12 14:03:20 2015 us=66969 MULTI: multi_init called, r=256 v=256
Sat Dec 12 14:03:20 2015 us=67303 IFCONFIG POOL: base=192.168.100.4
size=62, ipv6=0
Sat Dec 12 14:03:20 2015 us=67565 IFCONFIG POOL LIST
Sat Dec 12 14:03:20 2015 us=68051 Initialization Sequence Completed
Sat Dec 12 14:03:22 2015 us=987040 event_wait returned 1
Sat Dec 12 14:03:22 2015 us=987747 UDPv4 read returned 53
}}}
Which confirms the OP's observration that they are probably attached, but
lost afterwards.
I guess `proto none` was something like ''do not touch'', which seems to
be no longer the case.
Is the suggested `static + auto=0` the right way to do it now, or was
something broken in `proto none` handling?
--
Ticket URL: <https://dev.openwrt.org/ticket/20729#comment:7>
OpenWrt <http://openwrt.org>
Opensource Wireless Router Technology
_______________________________________________
openwrt-tickets mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-tickets
