0

  • This has been an ongoing issue for a couple of weeks. The credit card terminal will lose the ability to connect to the processor server over SSL.

  • The IP config looks correct, the DHCP lease looks legit and it appears to
    have connectivity to the Internet,
    but transactions will not complete.

  • For a time we suspected a hardware failure, but the new terminal was fine for 3-4 days and then failed yesterday the same as the prior terminal.

  • I can netcat right into the processor host plugged into the same Cisco 2950 as the card terminal.

  • When the transaction is attempted I can see:

    Ethernet Session Error

    and then:

    Invalid address

  • In the error log I see that the Debug Buffer states

    VfyCertChain: NOT Verified! Reason 2 (CERT_SIGNATURE_FAILURE) VfyCertChain: NOT Verified! Reason 1 (UNABLE_TO_GET_ISSUER_CERT) VerifyDataBundle ERROR 112 Bus App Signer VerifyDDLSysSig: ERROR NOT TCMS Bundle

  • This was working yesterday, but today it does not work. This happened twice before in the past two weeks and never previously for 2+ years behind a lousy consumer router.

  • I don't see any blocked traffic in the pf logs that matches either the processor host IP or the terminal IP.

  • So it appears to be an issue with SSL Cert issuer verification but if I plug into my consumer router at home I have no issues completing transactions.

  • I can easily renew the IP address on the terminal and it always reports connectivity.

  • This particular model includes an IP Diagnostics utility which runs four tests:

    1. LAN Connection - Tests that Ethernet connection exists.
    2. Gateway Test - Tests that the GW is responsive(?)
    3. ISP Test - If there were a PPP connection directly involved, I might know what this tests exactly, as it stands no one can tell me what exactly is happening under the hood?
    4. Host Test - Tests that the connection to the processor server is successful(?)

  • I have restored the pfsense config to a previously known-good point but this did not clear the card terminal issue.

So my question is:

Does anyone have any experience resolving a similar situation?

Some other thoughts I had were that I was too hasty in configuring a local instance of BIND or that I have misconfigured pfsense (DHCP Server possibly). I am pretty new to pfsense and credit card terminals.

I am about to deploy another nameserver in this workgroup environment of ~16 total clients (mostly XP & Windows 7) in the hopes that I just got something wrong there.

I am pretty desperate for fresh insight into this issue. This should be a non-issue in 7-10 days when we go to a different processing system, but until then the retail area is without a card reader and that makes small business owners very sad.

: (

Please help.

Improve this question
0

2 Answers 2

Reset to default
1

I'll start off warning you that I have no experience with these devices at all. They're black boxes to me.

I'd start by sniffing the traffic between the device and the LAN on a "working" setup (the consumer router you talked about) and then again in the non-working setup.

Comparing the traffic logged should provide a lot of insight into what's going on. Presumably that device, being embedded, will act in a very similar manner each time it's powered-on and the differences between the two configurations ought to be at least somewhat apparent.

Improve this answer
1
  • Thanks, your suggestion led me to what I believe was the ultimate solution. I noticed from the pcap (at home) that it was speaking IPv6 and I had set pfsense to block IPv6 traffic (at client site). I reversed this setting, restarted the terminal and was successful. The device worked for three days out of the box with IPv6 blocked then as it is now, so I suppose the root cause would be faulty firmware in the terminal?
    – unhappyCrackers1
    Mar 16, 2011 at 4:21
1

I had a similar experience with a CC terminal (not the same model) that would not work even tho DHCP seemed to be handing it a valid address. The key to fixing it for me (and maybe for you) was to give it a local static ip. Once I setup the ip manually I never had another problem with it. The next terminal we got had the same problem until I gave it a static ip address so it seemed to be with all of the units and not just with one of them.

For what it's worth I believe they were Verifone Omni terminals and they were connecting to a Juniper Netscreen Router. DHCP & DNS was provided by a windows server 2003 box.

Anyway I'd give a local static ip a shot and see what happens.

Improve this answer
2
  • Did you do a static assignment from the DHCP server or a static IP configured from the terminal? I have configured a static assignment but not at the terminal. I might try that also. Thanks.
    – unhappyCrackers1
    Mar 16, 2011 at 2:18
  • Configured IP from terminal. Static DHCP did not seem to help.
    – Barden
    Mar 20, 2011 at 3:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .