Project

General

Profile

Bug #632

Change type of Virtual IP not work.

Added by Mike Stupalov almost 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Virtual IPs
Target version:
Start date:
05/31/2010
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.0
Affected Architecture:

Description

Used:

Current version: 2.0-BETA2
       Built On: Sun May 30 22:58:14 EDT 2010

I configured "Virtual IP" with type "Proxy ARP". If try to change the type of Virtual IP to another (IP Alias), I get an error:

Warning: Illegal offset type in isset or empty in /etc/inc/interfaces.inc on line 812 Warning: Cannot modify header information - headers already sent by (output started at /etc/inc/interfaces.inc:812) in /usr/local/www/firewall_virtual_ip_edit.php on line 221

Associated revisions

Revision 5523fa3d (diff)
Added by Ermal Luçi almost 9 years ago

Fixes #632. Actually pass the interface and not the vip configuration to the function.

Revision e03b0a03 (diff)
Added by Ermal Luçi almost 9 years ago

Fixes #632. Use the correct function to handle vip destory.

Revision bd414316 (diff)
Added by jim-p almost 9 years ago

Fix typo. Ticket #632

Revision 962fd685 (diff)
Added by Ermal Luçi almost 9 years ago

Fixes #632. When bringing down a vip of proxyarp use the new pidfile introduced. Also teach about interface argument to proxyarp function so it can start only a instance of an interface.

Revision e8471084 (diff)
Added by Ermal Luçi over 8 years ago

Ticket #866 #632. Save old settings or actions to be taken for reconfiguring a route/vip on a tmp file and make use that information when apply settings buttons is clicked. This makes the gui behave as expected.

History

#1 Updated by Chris Buechler almost 9 years ago

  • Target version set to 2.0

#2 Updated by Erik Fonnesbeck almost 9 years ago

I think it is saying the error occurred on this line in interface_bring_down:

if (!isset($config['interfaces'][$interface]))

Maybe the caller is giving it bad data, like a blank string for the interface name.

#3 Updated by Ermal Luçi almost 9 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#4 Updated by Mike Stupalov almost 9 years ago

Well, now the error does not occur. But now at change of type virtual IP the previous is not deleted.

I have replaced type from IF alias to ProxyARP and have received at once 2 virtual addresses simultaneously:

# ifconfig em0
em0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC>
    ether 00:30:48:8b:4f:2c
    inet6 fe80::230:48ff:fe8b:4f2c%em0 prefixlen 64 scopeid 0x2 
    inet 192.168.168.2 netmask 0xffffff00 broadcast 192.168.168.255
->>> inet 192.168.168.3 netmask 0xffffffff broadcast 192.168.168.3
    nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active

# ps auxw |grep choparp
root   24758  0.0  0.0  3316  1008  ??  Is    2:06PM   0:00.00 /usr/local/sbin/choparp em0 auto 192.168.168.3/32

#5 Updated by Mike Stupalov almost 9 years ago

...and if again to change back, are deleted all IP addresses from the interface, except the virtual. Even the main IP:

# ifconfig em0  
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC>
    ether 00:30:48:8b:4f:2c
    inet6 fe80::230:48ff:fe8b:4f2c%em0 prefixlen 64 scopeid 0x2 
    inet 192.168.168.3 netmask 0xffffffff broadcast 192.168.168.3
    nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active

192.168.192.1/24 - Main IP
192.168.168.2/24 - virtual IP (1)
192.168.168.3/32 - virtual IP (2) - changed

#6 Updated by Chris Buechler almost 9 years ago

  • Status changed from Feedback to New

#7 Updated by Ermal Luçi almost 9 years ago

  • Status changed from New to Feedback

#8 Updated by Ermal Luçi almost 9 years ago

#9 Updated by Mike Stupalov almost 9 years ago

if (preg_match("/^vip/^tun|^ovpn|^gif|^gre|^lagg|^bridge|vlan/i", $realif))
                     ^
                     ^-- error can here?

#10 Updated by Mike Stupalov almost 9 years ago

I have tested again.

Now Virtual IP (IfAlias) on the interface correctly is added and deleted.
But at change from ProxyARP to IfAlias, choparp remains running.

# ps auxww|grep choparp
root   57326  0.0  0.0  3316  1024  ??  Ss    9:43AM   0:00.01 /usr/local/sbin/choparp em0 auto 192.168.168.3/32

#11 Updated by Chris Buechler almost 9 years ago

  • Status changed from Feedback to New

#12 Updated by Ermal Luçi almost 9 years ago

  • Status changed from New to Feedback

#13 Updated by Mike Stupalov almost 9 years ago

Now with one virtual IP really works.

But :)
If to change at once 2 virtual IP (and more)..

Before tests (VIP: 192.168.168.3/32, 192.168.168.4/32)

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC>
    inet 192.168.192.1 netmask 0xffffff00 broadcast 192.168.192.255
    inet 192.168.168.2 netmask 0xffffff00 broadcast 192.168.168.255
    inet 192.168.168.3 netmask 0xffffffff broadcast 192.168.168.3
    inet 192.168.168.4 netmask 0xffffffff broadcast 192.168.168.4

  • Change from If to ARP.
    • IfAliases were deleted before I have pressed the button 'Apply changes'
      em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
          options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC>
          inet 192.168.192.1 netmask 0xffffff00 broadcast 192.168.192.255
          inet 192.168.168.2 netmask 0xffffff00 broadcast 192.168.168.255
      
    • After button 'Apply changes' pressing, there were 2 processes choparp, both with identical IP.
      root   36529  0.0  0.0  3316  1052  ??  Ss   11:13AM   0:00.00 /usr/local/sbin/choparp em0 auto 192.168.168.4/32
      root   36693  0.0  0.0  3316  1052  ??  Ss   11:13AM   0:00.00 /usr/local/sbin/choparp em0 auto 192.168.168.4/32
      
  • Change back from ARP to If.
    • Again changes have occurred before button 'Apply changes' pressing. One process 'choparp' was deleted and one remained.
      root   36529  0.0  0.0  3316  1052  ??  Ss   11:13AM   0:00.01 /usr/local/sbin/choparp em0 auto 192.168.168.4/32
      
    • After button 'Apply changes' pressing, one process 'choparp' still remained, but IfAliases have normally formed.
      em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
          options=219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC>
          inet 192.168.192.1 netmask 0xffffff00 broadcast 192.168.192.255
          inet 192.168.168.2 netmask 0xffffff00 broadcast 192.168.168.255
          inet 192.168.168.3 netmask 0xffffffff broadcast 192.168.168.3
          inet 192.168.168.4 netmask 0xffffffff broadcast 192.168.168.4
      --------
      root   36529  0.0  0.0  3316  1052  ??  Ss   11:13AM   0:00.01 /usr/local/sbin/choparp em0 auto 192.168.168.4/32
      root   51330  0.0  0.0  3524  1240   0  S+   11:26AM   0:00.00 grep arp
      
      

#14 Updated by Chris Buechler almost 9 years ago

  • Status changed from Feedback to New

Some things do change before you apply changes.
1) When deleting a PARP entry, choparp is killed before clicking apply changes (which does nothing). This behavior is the same when changing a PARP entry to another VIP type, it kills it before applying changes (then adds the IP Alias or CARP IP when applying changes).
2) When changing from IP Alias to CARP type, the alias is deleted before applying changes.

Testing the same scenarios as Mike above, I never saw two instances of choparp running (which is the cause of the two issues noted in his last update).

#15 Updated by Ermal Luçi almost 9 years ago

Well the problem with changing the type of alias is that you do not have anymore the information on the previous type.

It would be possible that when resetting a vip alias we try to delete every possible vip type we know, though that might spam logs a bit.
But if you think that is more correct than current behavior than i will try to implement it!

#16 Updated by Ermal Luçi over 8 years ago

  • Status changed from New to Feedback

#17 Updated by Chris Buechler over 8 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF