XMLRPC sync problems!



  • 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?



  • your firewall rules not permitting sync since changing the port?



  • 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>



  • 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.


Log in to reply