Hello Tommi,   
      
   On Saturday October 03 2015 20:14, you wrote to me:   
      
    MV>> It does not work from my point 1. This may have to do with the   
    MV>> fact that PE are enabled on my laptop running Win 7 pro?   
      
    TK> My brand new callbacksystem reads the ip address where the call is   
    TK> coming and tries to call back. Your .1 call was coming from ipv6   
    TK> address which couldn't backresolv for dns name. That caused the   
    TK> callback to fail:   
      
   You will see lots of IPv6 addresses that won't backresolve in future...   
      
    TK>   03 Oct 15:24:33 [1360] creating a poll for 2:280/5555.1@fidonet (`d'   
    TK> flavour) 03 Oct 15:24:33 [1360] clientmgr started + 03 Oct 15:24:33   
    TK> [4068] call to 2:280/5555.1@fidonet ? 03 Oct 15:24:33 [4068]   
    TK> 470:1f15:1117:2d20:ebc3:3d83:dd77: incorrect port (getaddrinfo:   
    TK> Servname not supported for ai_socktype) ? 03 Oct 15:24:33 [4068]   
    TK> 2001:470:1f15:1117:2d20:ebc3:3d83:dd77: 1: error parsing host list 03   
    TK> Oct 15:24:33 [1360] rc(4068)=0 03 Oct 15:24:33 [1360] the queue is   
    TK> empty, quitting...   
      
    TK> Maybe Binkd needs []'s around the IPv6 address. Let's see.   
      
   Yes. Binkd accepts literal IPv6 addresses, but they must be encased in square   
   brackets.   
      
    MV>> O wait. When I tried it on my main system, I saw that the reply   
    MV>> did not come from *::f1d0:2:221:6 but from a PE address. So there   
    MV>> is no channel opened in my firewall voor that.   
      
    TK> That's because Win2003 always sets (and defaults outgoing) slaac   
    TK> address even if I have set manually 2001:470:1f15:cb0:f1d0:2:221:6.   
      
   Oh?  No way to tell it to use the manually set address?   
      
      
   Cheers, Michiel   
      
   --- GoldED+/W32-MSVC 1.1.5-b20130111   
    * Origin: 2001:470:1f15:1117::1 (2:280/5555)