XMLRPC sync problems!

bubble1975 · Feb 10, 2012, 5:51 PM

Hi Y'all,

I recently noticed that XMLRPC sync doesn't seem to be working on my pfSense Master/Slave pair. For example, if I change a firewall rule on the master, I see this error message (in the logs and on the top right of the web page via the scrolling error banner):

php: : New alert found: A communications error occured while attempting XMLRPC sync with username admin https://192.168.100.2:443

Now, I think this used to work before I enabled port 443 (with a cert) for the web configurator on both sides, so that may have something to do with it? Not sure. The sync is using a dedicated CARP interface between the two machines, with master:192.168.100.1 and slave:192.168.100.2. Only the master is configured to sync, as instructed, and other items seem to be working like master/slave virtual IPs and such, so I know the network is working. It almost seems like it's having trouble authenticating to the slave or something.

I have:

2.0-RELEASE (amd64)
built on Tue Sep 13 17:33:40 EDT 2011

Any advice much appreciated!! Anything else I should be doing to troubleshoot?

cmb · Feb 20, 2012, 3:37 AM

your firewall rules not permitting sync since changing the port?

bubble1975 · Feb 20, 2012, 5:41 AM

Unfortunately no, it doesn't seem to be that. I still haven't solved it yet. But, if you have a minute to look at my setup, it looks like this:

fire01:

[2.0-RELEASE][admin@fire01]/root(1): ifconfig bce3
bce3: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=c00b8 <vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso,linkstate>ether d4:be:d9:a8:80:39
inet 192.168.100.1 netmask 0xffffff00 broadcast 192.168.100.255
inet6 fe80::d6be:d9ff:fea8:8039%bce3 prefixlen 64 scopeid 0x4
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active

fire02:

[2.0-RELEASE][admin@fire02]/root(9): ifconfig bce3
bce3: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=c00bb <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso,linkstate>ether d4:be:d9:a8:7e:65
inet 192.168.100.2 netmask 0xffffff00 broadcast 192.168.100.255
inet6 fe80::d6be:d9ff:fea8:7e65%bce3 prefixlen 64 scopeid 0x4
nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active

So the link seem up. The firewall rules for these interfaces are ALLOW ALL from ALL to ALL, completely open (on both sides). It's a dedicated crossover link, no switch involved, so I have the firewall rules wide open for those links. When I ping from fire01 to fire02 on this interface:

[2.0-RELEASE][admin@fire01]/root(2): ping 192.168.100.2
PING 192.168.100.2 (192.168.100.2): 56 data bytes
ping: sendto: Host is down
ping: sendto: Host is down
ping: sendto: Host is down
^C

Oddly enough, when I ping coming from the other direction, I get a slightly different response:

[2.0-RELEASE][admin@fire02]/root(10): ping 192.168.100.1
PING 192.168.100.1 (192.168.100.1): 56 data bytes
^C
–- 192.168.100.1 ping statistics ---
95 packets transmitted, 0 packets received, 100.0% packet loss

I just don't know what's up. The link light on both sides in blinking rapidly as if traffic is going back and forth. I've tried a different cable, thinking the first one went bad, but the new cable produced exactly the same results.</full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso,linkstate></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></vlan_mtu,vlan_hwtagging,jumbo_mtu,vlan_hwcsum,vlan_hwtso,linkstate></up,broadcast,running,simplex,multicast>

cmb · Feb 20, 2012, 6:06 AM

link light blinking rapidly wouldn't be indicating traffic (if it actually is the link light, should have a different light for activity if it has one at all), that's more likely to indicate link cycling on the NIC. I have seen NICs not play nicely when directly connected, does it behave better if you throw a small switch between? That'd at least confirm or deny that suspicion.