Topic: OpenVPN-Bridge/BridgeInterface on 8.0b7 problem

[n9yty]

Hi, I am not sure if this is a problem locally or more globally, although the Wiki page for OpenVPN-Bridge shows a status for 8.0 as being tested and working, so I'm afraid it may be a local problem.

I am thinking, though, that the problem is with the BridgeInterface and not necessarily OpenVPN.  According to the notes for BridgeInterface after /etc/init.d/bridge runs the eth0/tap0 interfaces should have no IP address and be in PROMISC mode.  However, my eth0 ends up with the main IP assigned to it as well as the br0 interface and it is causing problems, obviously.

If I run `/etc/init.d/bridge restart; ifconfig` to get an ifconfig dump as soon as the script is finished things look proper, but if I then run ifconfig again the eth0 interface has the main IP assigned to it again.  I ran `bash -x /etc/init.d/bridge restart` to monitor the commands it issues and everything looks good, and as shown above things look good as soon as the script exits, but the almost immediately afterwards the primary IP gets put back on eth0. In fact, if I do something like this....

/etc/init.d/bridge restart; ifconfig; sleep 1; ifconfig; sleep 1; ifconfig; sleep 1; ifconfig; sleep 1; ifconfig; sleep 1; ifconfig; sleep 1; ifconfig

It looks like the main IP is reasserted on eth0 in about five seconds.  However, if I manually issue the command `ifconfig eth0 0.0.0.0 promisc up` it sets it properly and then does NOT get overwritten (then I have to also set the default gateway manually as well)... Clearly I am missing something, hopefully not something too obvious.

Is anyone else using this setup on 8.0b7 that could share some tips?

[johnp]

First thing to determine is what you are trying to accomplish? If you think that this will stop the external interface from obtaining a true routable value, I believe you are mistaken.

[n9yty]

I just want it to work.    From reading the Wiki page on installing openvpn-bridge it says I had to install bridge interface, which I did.  After doing this the system could no longer access the outside world because the IP was assigned to both the br0 and eth0 interfaces.  The Wiki page clearly stated that eth0 should NOT have an address, so this was my first tip-off that something was not as it was supposed to be.

I am not trying to "hide" anything, the br0 should have the IP address and eth0 unassigned but eth0 is part of the br0 bridge and therefore it should just work.

After I remove the IP address from eth0 and assign the default gateway everything works as it should - the OpenVPN works as expected and the system can access the internet again.

Also, I see this in the log file after completion of the `/etc/init.d/bridge restart` call.


I have subbed out the IP addresses, but IPAddress is my main IP for the SME Server and all the others are as they should be...  Looks like it is flip-flopping the config between eth0 and br0, but I didn't see anything here that tips me off as to why it is resetting after five seconds.


Jan 25 23:43:35 cccrockford kernel: br0: port 2(eth0) entering disabled state
Jan 25 23:43:35 cccrockford kernel: br0: port 1(tap0) entering disabled state
Jan 25 23:43:35 cccrockford kernel: br0: port 2(eth0) entering disabled state
Jan 25 23:43:35 cccrockford kernel: br0: port 1(tap0) entering disabled state
Jan 25 23:43:35 cccrockford /sbin/e-smith/db[21536]: /home/e-smith/db/configuration: OLD InternalInterface=interface|Broadcast|MY.MAIN.BCAST.ADDR|Configuration|static|Driver|atl1e|HWAddress|MY:MA:CA:DD:RE:SS|IPAddress|MY.MAIN.IP.ADDR|NICBondingOptions|miimon=200 mode=active-backup|Name|br0|Netmask|MY.NET.MASK.VAL|Network|MY.NET.WORK.VAL
Jan 25 23:43:35 cccrockford /sbin/e-smith/db[21536]: /home/e-smith/db/configuration: NEW InternalInterface=interface|Broadcast|MY.MAIN.BCAST.ADDR|Configuration|static|Driver|atl1e|HWAddress|MY:MA:CA:DD:RE:SS|IPAddress|MY.MAIN.IP.ADDR|NICBondingOptions|miimon=200 mode=active-backup|Name|eth0|Netmask|MY.NET.MASK.VAL|Network|MY.NET.WORK.VAL
Jan 25 23:43:35 cccrockford kernel: device eth0 left promiscuous mode
Jan 25 23:43:35 cccrockford kernel: type=1700 audit(1327556615.793:14): dev=eth0 prom=0 old_prom=256 auid=4294967295 ses=4294967295
Jan 25 23:43:36 cccrockford kernel: New device tap0 does not support netpoll
Jan 25 23:43:36 cccrockford kernel: Disabling netpoll for br0
Jan 25 23:43:36 cccrockford kernel: device eth0 entered promiscuous mode
Jan 25 23:43:36 cccrockford kernel: type=1700 audit(1327556616.340:15): dev=eth0 prom=256 old_prom=0 auid=4294967295 ses=4294967295
Jan 25 23:43:36 cccrockford /sbin/e-smith/db[21814]: /home/e-smith/db/configuration: OLD InternalInterface=interface|Broadcast|MY.MAIN.BCAST.ADDR|Configuration|static|Driver|atl1e|HWAddress|MY:MA:CA:DD:RE:SS|IPAddress|MY.MAIN.IP.ADDR|NICBondingOptions|miimon=200 mode=active-backup|Name|eth0|Netmask|MY.NET.MASK.VAL|Network|MY.NET.WORK.VAL
Jan 25 23:43:36 cccrockford /sbin/e-smith/db[21814]: /home/e-smith/db/configuration: NEW InternalInterface=interface|Broadcast|MY.MAIN.BCAST.ADDR|Configuration|static|Driver|atl1e|HWAddress|MY:MA:CA:DD:RE:SS|IPAddress|MY.MAIN.IP.ADDR|NICBondingOptions|miimon=200 mode=active-backup|Name|br0|Netmask|MY.NET.MASK.VAL|Network|MY.NET.WORK.VAL
Jan 25 23:43:36 cccrockford kernel: br0: port 2(eth0) entering learning state
Jan 25 23:43:36 cccrockford kernel: br0: port 1(tap0) entering learning state
Jan 25 23:43:51 cccrockford kernel: br0: port 2(eth0) entering forwarding state
Jan 25 23:43:51 cccrockford kernel: br0: port 1(tap0) entering forwarding state

[n9yty]

Still puzzled and not making progress, but I thought it should be noted that the steps I took in setting the eth0 interface to 0.0.0.0 is something done by the bridge script itself...  In fact, looking at it as it runs shows that it is doing everything I would expect, but yet five seconds after it completes the eth0 interface is set back to the previous IP address.

I thought that there was some background process monitoring for changes to eth0 and resetting them, but that is not the case because when I do set it manually outside the bridge script they do not get set back.

The only thing I am left with is the fact that the bridge interface script does change the configuration db to change the InternalInterface from eth0 to br0.  Could it be something monitoring THAT change and then re-setting eth0 to what it thinks it should be?

Just FYI, here is the bridge script run output for the start operation:

+ start
+ /usr/sbin/brctl addbr br0
+ for t in '$TAP_IF'
+ /usr/sbin/openvpn --mktun --dev tap0
+ /sbin/ifconfig tap0 0.0.0.0 promisc up
+ /usr/sbin/brctl addif br0 tap0
+ /sbin/ifconfig eth0 0.0.0.0 promisc up
+ /usr/sbin/brctl addif br0 eth0
+ /sbin/e-smith/db configuration setprop InternalInterface Name br0
+ /sbin/ifconfig br0 MY.MAIN.IP.ADDR netmask MY.MAIN.NET.MASK
+ routes
++ /sbin/e-smith/db networks keys
+ for NET in '$(/sbin/e-smith/db networks keys)'
++ /sbin/e-smith/db networks getprop MY.MAIN.LOCAL.NETWORK SystemLocalNetwork
+ SYSTEM=yes
+ test yes
+ '[' serveronly == serveronly ']'
++ /sbin/e-smith/db configuration get GatewayIP
+ GW=MY.MAIN.GW.ADDR
+ /sbin/route add default gw MY.MAIN.GW.ADDR
+ firewall
+ /sbin/e-smith/expand-template /etc/rc.d/init.d/masq
+ /sbin/service masq restart
+ dhcpd
+ /usr/bin/sv t dhcpd
+ RETVAL=0
+ '[' 0 -eq 0 ']'
+ echo_success

[n9yty]

{sigh} I had problems that just go away...

Even though I had rebooted and did a reconfigure-reboot several times, this problem remained.  However, I was ready to take this over to the site where it will live and went into the 'console' program to change the hostname and when it rebooted everything is fine now, even after additional reboots.  I am at a loss as to what the problem was or what fixed it. 

[n9yty]

More software updates appeared - not kernel, just a regular update - and after applying them and hitting the reconfigure button in the web interface, then rebooting, and I was right back where I was before with both the br0 bridge and the eth0 interface having the same IP address assigned.  Bother.  I tried a reconfigure from the web interface manually, another reboot, no change.

I then did a reconfigure/reboot from the shell using `console` and when it came back up everything was OK.

Spooky, since I would be locked out if I did a remote software update, at least until I got onsite.

I don't know how to troubleshoot this further.