Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.
  • 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.

share|improve this question

2 Answers 2

up vote 1 down vote accepted

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.

share|improve this answer
    
Thanks, I will give this a try. –  Somantra Mar 16 '11 at 1:15
    
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? –  Somantra Mar 16 '11 at 4:21

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.

share|improve this answer
    
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. –  Somantra Mar 16 '11 at 2:18
    
Configured IP from terminal. Static DHCP did not seem to help. –  Barden Mar 20 '11 at 3:13

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.