Socks-server Dante or as one letter can "eat" a couple of days time

Every time I encounter such a “working moment”, I wonder whether it is necessary to give his decision to the world or it is petty for others, but this time I decided to post it. This article is more from the discharge of the notes on the cuffs and is written only because of the scarcity of information about setting up Dante in nete and limping on both legs of official documentation.
On Friday morning, the customer asked to raise a socks-server for ~ 100 users, with authorization by login / password, IP binding and sending requests from the same IP to which the user is connected. At the same time, the customer inquired about the deadline for the work and, although I do not like to make predictions about the installation / setup time, I assured him that in 3-4 hours the alpha version would be ready. Well, the truth is: by googling, choose the appropriate socks-server, install, read mana, correct the default config for yourself ... should be invested at 4 o'clock.
OS FreeBSD 9.2, but everything described below is also true for 10.

Strangely enough, there were only two socks-servers suitable for customer requests: 3proxy 0.6.1 and Dante (in ports 1.3.2). Maybe I missed something, of course, but either there is no authorization or there is no int_ip mode -> ext_ip. Perhaps these requests correspond to squid, but did not want to set this monster for the sake of a simple task.
I have nothing against 3proxy, I have been working with it for several years in port mapping mode, there are no particular complaints, but it has been developed since 2009, the code is dirty and I have heard numerous reviews about its voracity under a heavy load.
So, Dante.
Prior to version 1.3, support for int_ip -> ext_ip Dante did not have, or rather there is a similar implementation in the paid version at a very undemocratic price of EUR400, however, Lysenko Konstantin added this functionality in the form of the same-patch in Dante 1.2.2 and it was included release 1.3.0.
I don’t presume to say whether this construct worked in 1.3.0, but in 1.3.2 the queries persist with the first external-ip found in the config. Shoveled mang I turned to the developer page. There is a little more information there, but I didn’t manage to start the same-same one. However, since November 2013, the site has version 1.4, which for some reason is not included in the ports. We swing, we collect.
It should be noted that the config in 1.4 has undergone cosmetic changes, although in the manes there are still examples with the parameters of previous versions, to which Dante swears as deprecated and, sometimes, suggests the correct new parameters.

Test config:

And ... contrary to expectations, 1.4 didn’t work either. This time, unlike 1.3, errors like

 warning: getoutaddr(): using external.rotation = same-same, local address 21.22.23.48 was selected for forwarding from our local client 21.22.23.48.45980 to target 77.72.80.15.80, but that local address is not set on our external interface(s). Configuration error in /usr/local/etc/sockd.conf? 

where 21.22.23.48 is the address of my local machine while there should be the internal-IP of the server to which the client connects. Embarrassed by the phrase “Configuration error in /usr/local/etc/sockd.conf?”, I chose the config and shuffled mana, but, since there is little information in them, I climb into the best mana source files. Smiling comments in the form

  /* * Just return the first address of the appropriate type from our internal * list and hope the best. */ 

I find the source of the problems (./sockd/sockd_request.c, line 4173):
/ *
* Find address to bind for client. First the ipaddress.
* /
if (getoutaddr (& io-> dst.laddr,
& io-> src.raddr,
req.command,
target,
emsg,
emsglen) == NULL)
return -1;
')
Changing & io-> src. r addr on & io-> src. l addr , reassemble, run and finally see what I want:

 info: pass(1): tcp/connect [: username%chaturanga@21.22.23.48.46050 11.12.13.3.1080 -> 11.12.13.3.27819 77.72.80.15.80 

Quietly swearing, draw up a bug report to the developers.
As a result, instead of the stated 3-4 hours of reading, refining configs, trying to run Dante not in jail, tests for Centos instead of FreeBSD and digging into the source code killed a couple of days ... So promise after that ...

UPD1 : While the note was being written the developer answered:

Hello, thank you for the bug-report. You are correct, there is an
error here. Your proposed solution is basically correct, though
we will probably implement the fix slightly differently.

UPD2 : And in the course of further correspondence:

Depending on the current workload, I doubt I will be able to provide
at least another month.

Well, thanks for that.

UPD3 (2014-09-03) :
The developer reported that the bug was fixed (v.1.4.1).
Checked, everything works as expected.