Description of problem: Afeter upgrading to NetworkManager-0.9.8.2-4.fc19.x86_64 my server external network is not accessible. The external network is not reachable anymore but the internal network is ok if NM is enabled and working. The shown setup does not work with network service anymore. Version-Release number of selected component (if applicable): NetworkManager-0.9.8.2-4.fc19.x86_64 How reproducible: A server with two NICs (on-board and attached). HW: ASRock H67M-GE + I3-2120 + 8GB + 1TB (hdd, sata) [root@physics network-scripts]# cat ifcfg-enp4s0 IPV6_PEERDNS="yes" IPV6INIT="yes" UUID="b43c0128-ec02-4793-98c9-f396fb9438d2" IPADDR1="192.168.1.1" IPADDR0="172.16.0.1" PREFIX1="24" PREFIX0="16" DEFROUTE="yes" IPV4_FAILURE_FATAL="yes" HWADDR="64:70:02:14:43:EF" BOOTPROTO="none" IPV6_DEFROUTE="yes" IPV6_AUTOCONF="yes" IPV6_FAILURE_FATAL="no" IPV6_PEERROUTES="yes" TYPE="Ethernet" ONBOOT="yes" NAME="enp4s0" [root@physics network-scripts]# cat ifcfg-enp5s0 TYPE=Ethernet BOOTPROTO=none DEFROUTE=yes IPV4_FAILURE_FATAL=yes IPV6INIT=yes IPV6_AUTOCONF=yes IPV6_DEFROUTE=yes IPV6_FAILURE_FATAL=no NAME=enp5s0 UUID=fc903246-75fa-4680-86f8-b5132fc891c5 ONBOOT=yes IPADDR0=193.x.y.130 PREFIX0=26 GATEWAY0=193.x.y.129 DNS1=193.x.y.254 DOMAIN=central.ucv.ro IPADDR1=193.x.y.162 PREFIX1=26 IPADDR2=193.x.y.163 PREFIX2=26 HWADDR=00:25:22:F9:71:3D IPV6_PEERDNS=yes IPV6_PEERROUTES=yes [root@physics ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default g129.central.uc 0.0.0.0 UG 0 0 0 p5p1 link-local * 255.255.0.0 U 1002 0 0 p4p1 link-local * 255.255.0.0 U 1003 0 0 p5p1 172.16.0.0 * 255.255.0.0 U 1 0 0 p4p1 192.168.1.0 * 255.255.255.0 U 0 0 0 p4p1 193.x.y.128 * 255.255.255.192 U 1 0 0 p5p1 [root@s194 sysconfig]# cat iptables # Custom file edited on 02-Jul-2013 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate NEW -m tcp -p tcp --dport 22 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j ACCEPT -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT # Completed on 2013-07-02 11:48 *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A PREROUTING --dst 193.x.y.162 -p tcp -j DNAT --to 192.168.1.73 -A OUTPUT --dst 193.x.y.162 -p tcp -j DNAT --to 192.168.1.73 -A PREROUTING --dst 193.x.y.163 -p tcp -j DNAT --to 192.168.1.200 -A OUTPUT --dst 193.x.y.163 -p tcp -j DNAT --to 192.168.1.200 -A POSTROUTING -s 192.168.1.0/24 -p tcp --dst 192.168.1.73 --dport 22 -j SNAT --to 192.168.1.1 -A POSTROUTING -s 192.168.1.0/24 -o p5p1 -j SNAT --to-source 193.x.y.130 -A POSTROUTING -s 172.16.0.0/16 -o p5p1 -j SNAT --to-source 193.x.y.130 COMMIT Actual results: With F19 install (no updates) it is the same with NM or with network service. 1) Why "route" shows iface=p4p1, p5p1 instead enp4s0, enp5s0 ? 2) Why "ifconfig" does show only the IPADDR0 without aliases? 3) All is working as expected when 192.168.1.73 is on-line. If ...73 not on-line, the address 193.x.y.162 is assigned to the the server, it responds to "ping 193.x.y.162" but it should be unreachable (or something equivalent) because 192.168.1.73 is off. Similar for 193.x.y.163 . Expected results: Additional info: From /var/log/messages when starting NM: Jul 3 11:02:51 physics rsyslogd: [origin software="rsyslogd" swVersion="7.2.6" x-pid="306" x-info="http://www.rsyslog.com"] rsyslogd was HUPed Jul 3 11:03:44 physics systemd[1]: Stopping Network Manager... Jul 3 11:03:44 physics NetworkManager[1704]: <info> caught signal 15, shutting down normally. Jul 3 11:03:44 physics NetworkManager[1704]: <info> exiting (success) Jul 3 11:03:44 physics systemd[1]: Starting Network Manager... Jul 3 11:03:44 physics NetworkManager[1924]: <info> NetworkManager (version 0.9.8.2-4.fc19) is starting... Jul 3 11:03:44 physics NetworkManager[1924]: <info> Read config file /etc/NetworkManager/NetworkManager.conf Jul 3 11:03:44 physics NetworkManager[1924]: <info> WEXT support is enabled Jul 3 11:03:44 physics NetworkManager[1924]: ifcfg-rh: Acquired D-Bus service com.redhat.ifcfgrh1 Jul 3 11:03:44 physics NetworkManager[1924]: <info> Loaded plugin ifcfg-rh: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. Jul 3 11:03:44 physics NetworkManager[1924]: <info> Loaded plugin keyfile: (c) 2007 - 2010 Red Hat, Inc. To report bugs please use the NetworkManager mailing list. Jul 3 11:03:44 physics NetworkManager[1924]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-lo ... Jul 3 11:03:44 physics NetworkManager[1924]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-enp5s0 ... Jul 3 11:03:44 physics NetworkManager[1924]: ifcfg-rh: read connection 'enp5s0' Jul 3 11:03:44 physics NetworkManager[1924]: ifcfg-rh: parsing /etc/sysconfig/network-scripts/ifcfg-enp4s0 ... Jul 3 11:03:44 physics NetworkManager[1924]: ifcfg-rh: read connection 'enp4s0' Jul 3 11:03:44 physics NetworkManager[1924]: <info> monitoring kernel firmware directory '/lib/firmware'. Jul 3 11:03:44 physics NetworkManager[1924]: <info> WiFi enabled by radio killswitch; enabled by state file Jul 3 11:03:44 physics NetworkManager[1924]: <info> WWAN enabled by radio killswitch; enabled by state file Jul 3 11:03:44 physics NetworkManager[1924]: <info> WiMAX enabled by radio killswitch; enabled by state file Jul 3 11:03:44 physics NetworkManager[1924]: <info> Networking is enabled by state file Jul 3 11:03:44 physics NetworkManager[1924]: <warn> failed to allocate link cache: (-10) Operation not supported Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): carrier is ON Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): new Ethernet device (driver: 'r8169' ifindex: 2) Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): exported as /org/freedesktop/NetworkManager/Devices/0 Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41] Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): preparing device. Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) starting connection 'enp4s0' Jul 3 11:03:44 physics NetworkManager[1924]: (nm-device.c:3894):nm_device_activate: runtime check failed: (priv->state == NM_DEVICE_STATE_DISCONNECTED) Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): device state change: unavailable -> ip-config (reason 'none') [20 70 0] Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 3 of 5 (IP Configure Start) scheduled. Jul 3 11:03:44 physics NetworkManager[1924]: <warn> failed to allocate link cache: (-10) Operation not supported Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): carrier is ON Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): new Ethernet device (driver: 'r8169' ifindex: 3) Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): exported as /org/freedesktop/NetworkManager/Devices/1 Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): device state change: unmanaged -> unavailable (reason 'connection-assumed') [10 20 41] Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): preparing device. Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) starting connection 'enp5s0' Jul 3 11:03:44 physics NetworkManager[1924]: (nm-device.c:3894):nm_device_activate: runtime check failed: (priv->state == NM_DEVICE_STATE_DISCONNECTED) Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): device state change: unavailable -> ip-config (reason 'none') [20 70 0] Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 3 of 5 (IP Configure Start) scheduled. Jul 3 11:03:44 physics NetworkManager[1924]: <warn> /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring... Jul 3 11:03:44 physics NetworkManager[1924]: <warn> /sys/devices/virtual/net/lo: couldn't determine device driver; ignoring... Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 3 of 5 (IP Configure Start) started... Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 5 of 5 (IPv4 Configure Commit) scheduled... Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Beginning IP6 addrconf. Jul 3 11:03:44 physics avahi-daemon[303]: Withdrawing address record for fe80::6670:2ff:fe14:43ef on p4p1. Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 3 of 5 (IP Configure Start) complete. Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 3 of 5 (IP Configure Start) started... Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 5 of 5 (IPv4 Configure Commit) scheduled... Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Beginning IP6 addrconf. Jul 3 11:03:44 physics avahi-daemon[303]: Withdrawing address record for fe80::225:22ff:fef9:713d on p5p1. Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 3 of 5 (IP Configure Start) complete. Jul 3 11:03:44 physics NetworkManager[1924]: <warn> error monitoring device for netlink events: error processing netlink message: Object busy Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 5 of 5 (IPv4 Commit) started... Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): device state change: ip-config -> secondaries (reason 'none') [70 90 0] Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 5 of 5 (IPv4 Commit) complete. Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 5 of 5 (IPv4 Commit) started... Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): device state change: ip-config -> secondaries (reason 'none') [70 90 0] Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 5 of 5 (IPv4 Commit) complete. Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p4p1): device state change: secondaries -> activated (reason 'none') [90 100 0] Jul 3 11:03:44 physics systemd[1]: Started Network Manager. Jul 3 11:03:44 physics NetworkManager[1924]: <info> Policy set 'enp5s0' (p5p1) as default for IPv4 routing and DNS. Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p4p1) successful, device activated. Jul 3 11:03:44 physics NetworkManager[1924]: <info> (p5p1): device state change: secondaries -> activated (reason 'none') [90 100 0] Jul 3 11:03:44 physics dbus-daemon[314]: dbus[314]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Jul 3 11:03:44 physics dbus-daemon[314]: dbus[314]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details. Jul 3 11:03:44 physics dbus[314]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Jul 3 11:03:44 physics dbus[314]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details. Jul 3 11:03:44 physics NetworkManager[1924]: <info> Activation (p5p1) successful, device activated. Jul 3 11:03:44 physics dbus-daemon[314]: dbus[314]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Jul 3 11:03:44 physics dbus-daemon[314]: dbus[314]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details. Jul 3 11:03:44 physics dbus[314]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' Jul 3 11:03:44 physics NetworkManager[1924]: <warn> Dispatcher failed: (32) Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details. Jul 3 11:03:44 physics dbus[314]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details. Jul 3 11:03:44 physics NetworkManager[1924]: <warn> Dispatcher failed: (32) Unit dbus-org.freedesktop.nm-dispatcher.service failed to load: No such file or directory. See system logs and 'systemctl status dbus-org.freedesktop.nm-dispatcher.service' for details. Jul 3 11:03:45 physics avahi-daemon[303]: Registering new address record for fe80::225:22ff:fef9:713d on p5p1.*. Jul 3 11:03:46 physics avahi-daemon[303]: Registering new address record for fe80::6670:2ff:fe14:43ef on p4p1.*. Jul 3 11:03:55 physics NetworkManager[1924]: <warn> error monitoring device for netlink events: error processing netlink message: Object busy Jul 3 11:04:04 physics NetworkManager[1924]: <info> (p4p1): IP6 addrconf timed out or failed. Jul 3 11:04:04 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 4 of 5 (IPv6 Configure Timeout) scheduled... Jul 3 11:04:04 physics NetworkManager[1924]: <info> (p5p1): IP6 addrconf timed out or failed. Jul 3 11:04:04 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 4 of 5 (IPv6 Configure Timeout) scheduled... Jul 3 11:04:04 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 4 of 5 (IPv6 Configure Timeout) started... Jul 3 11:04:04 physics NetworkManager[1924]: <info> Activation (p4p1) Stage 4 of 5 (IPv6 Configure Timeout) complete. Jul 3 11:04:04 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 4 of 5 (IPv6 Configure Timeout) started... Jul 3 11:04:04 physics NetworkManager[1924]: <info> Activation (p5p1) Stage 4 of 5 (IPv6 Configure Timeout) complete.
Mainly, this bug is due to kernel-3.9.8-300.fc19.x86_64 and downgrading to kernel-3.9.5-301.fc19.x86_64 solve the networking accessibility. The other points are still valid.
Created attachment 768819 [details] Tests to debug the reported problem Different tests regarding network and NetworkManager services
As Adam Williamson suggested biosdevname=0 on the kernel line solve the interface name (as shown in the test case file already attached). Anyway, this parameter should not be needed if some bug is not present.
Installing F19 Gnome Desktop in VirtualBox-4.2.14 under Win7_x64: route gives p2p1 and we have ifcfg-enp0s3 !!! [root@localhost ~]# uname -a Linux localhost.localdomain 3.9.9-301.fc19.x86_64 #1 SMP Thu Jul 4 15:10:36 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux [root@localhost ~]# rpm -q NetworkManager NetworkManager-0.9.8.2-5.fc19.x86_64 [root@localhost ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 193.x.y.193 0.0.0.0 UG 0 0 0 p2p1 193.x.y.192 * 255.255.255.224 U 1 0 0 p2p1 [root@localhost ~]# ls /etc/sysconfig/network-scripts ifcfg-enp0s3 ifdown-eth ifdown-post ifdown-tunnel ifup-eth ifup-isdn ifup-ppp ifup-wireless ifcfg-lo ifdown-ippp ifdown-ppp ifup ifup-ippp ifup-plip ifup-routes init.ipv6-global ifdown ifdown-ipv6 ifdown-routes ifup-aliases ifup-ipv6 ifup-plusb ifup-sit network-functions ifdown-bnep ifdown-isdn ifdown-sit ifup-bnep ifup-ipx ifup-post ifup-tunnel network-functions-ipv6
On installs where iface reported by "route" command is not the same with ifcfg-iface (pxpy instead of enpxsy or ethx) fail2ban will not start. Does not matter if biosdevname=0 or net.ifnames=0 on the kernel line. Tested this on real hardware and on VirualBox too. From /var/log/messages: fail2ban-client[2804]: ERROR Directory /var/run/fail2ban exists but not accessible for writing Fail2ban is ok on any other install.
(In reply to Cristian Sava from comment #0) > With F19 install (no updates) it is the same with NM or with network service. > > 1) Why "route" shows iface=p4p1, p5p1 instead enp4s0, enp5s0 ? > 2) Why "ifconfig" does show only the IPADDR0 without aliases? > 3) All is working as expected when 192.168.1.73 is on-line. If ...73 not > on-line, the address 193.x.y.162 is assigned to the the server, it responds > to "ping 193.x.y.162" but it should be unreachable (or something equivalent) > because 192.168.1.73 is off. > Similar for 193.x.y.163 . > 1) because the interface names are p4p1 and p5p1 The interface names are handled by biosdevname/udev. 2) IP aliases and ifconfig are obsolete now. Interfaces can handle multiple IPs easily. So instead of creating interface aliases, all addresses are added to the same interface. 'ip' command is recommended instead of ifconfig. $ ip addr 3) not sure what you mean or trying to achieve TL;DR What is the actual problem?
(In reply to Cristian Sava from comment #5) > On installs where iface reported by "route" command is not the same with > ifcfg-iface (pxpy instead of enpxsy or ethx) fail2ban will not start. > Does not matter if biosdevname=0 or net.ifnames=0 on the kernel line. > Tested this on real hardware and on VirualBox too. > From /var/log/messages: > fail2ban-client[2804]: ERROR Directory /var/run/fail2ban exists but not > accessible for writing > Fail2ban is ok on any other install. Announced as fixed in selinux (selinux was not complaining with AVC and I thought there was a networking problem).
(In reply to Jirka Klimes from comment #6) > (In reply to Cristian Sava from comment #0) > > With F19 install (no updates) it is the same with NM or with network service. > > > > 1) Why "route" shows iface=p4p1, p5p1 instead enp4s0, enp5s0 ? > > 2) Why "ifconfig" does show only the IPADDR0 without aliases? > > 3) All is working as expected when 192.168.1.73 is on-line. If ...73 not > > on-line, the address 193.x.y.162 is assigned to the the server, it responds > > to "ping 193.x.y.162" but it should be unreachable (or something equivalent) > > because 192.168.1.73 is off. > > Similar for 193.x.y.163 . > > > 1) because the interface names are p4p1 and p5p1 > The interface names are handled by biosdevname/udev. > 2) IP aliases and ifconfig are obsolete now. Interfaces can handle multiple > IPs easily. > So instead of creating interface aliases, all addresses are added to the > same interface. > 'ip' command is recommended instead of ifconfig. > $ ip addr > 3) not sure what you mean or trying to achieve > > TL;DR > What is the actual problem? 1) Iface name reported by "route" is different from ifcfg-Iface (p5p1 vs. ifcfg-enp5s0) on some installs. All is correct on others (iface=enp5s0 and we have ifcfg-enp5s0). 2) OK, you're right 3) See my iptables. If an addres is used to DNAT: -A PREROUTING --dst 193.x.y.162 -p tcp -j DNAT --to 192.168.1.73 -A OUTPUT --dst 193.x.y.162 -p tcp -j DNAT --to 192.168.1.73 I think it's logical that if pinging 193.x.y.162 from outside when 192.168.1.73 is off to receive something like "unreachable" or similar (I know that the ip is the kernel's property) but I receive an answer from 193.x.y.162 (it forgot that is set DNAT). Maybe that is only my wish. The main point is 1) because it is potential source of trouble (e.g. using iptables "-o p5p1" is not "-o enp5s0" if debugging with biosdevname=0, etc.) I saw that on real hardware and in VirtualBox too.
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.