What is the exact command line are you typing to run stunclient?

Why do you feel the results are inaccurate?

I'm not sure what server you are using, but if the dual ip/port mode of the service is not properly configured or has a firewall issue, then I would suspect that "address and port dependent" mapping will be the result of any client doing behavior or nat classification detection.

Example run from my end:

D:\stunserver\release>stunclient.exe stunserver.stunprotocol.org --verbosity 9 --mode behavior
Resolved stunserver.stunprotocol.org to 3.132.228.249:0
config.fBehaviorTest = true
config.fFilteringTest = false
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 3.132.228.249:3478
socketconfig.addrLocal = 0.0.0.0:0
Sending message to 3.132.228.249:3478
Got response (68 bytes) from 3.132.228.249:3478 on interface 192.168.1.38:49866
Other address is 3.135.212.85:3479

Preparing message for behavior test #2 (destination=AP)
Sending message to 3.135.212.85:3478
Got response (68 bytes) from 3.135.212.85:3478 on interface 192.168.1.38:49866
Binding test: success
Local address: 192.168.1.38:49866
Mapped address: 73.15.16.19:49866
Behavior test: success
Nat behavior: Endpoint Independent Mapping

Do the exact same command from your end using both stunserver.stunprotocol.org as the address as well as your own server and compare the differences.

Or did you imply that you were using the --protocol tcp flag? Results will be wildly different from UDP depending on ISP and NAT.

Or did you imply that you were using the --protocol tcp flag? Results will be wildly different from UDP depending on ISP and NAT.

yes, I'm trying to detect the TCP NAT type. Here are the exact commands:
./stunserver --mode full --primaryinterface 222.222.x.x --altinterface 110.242.x.x --primaryport 3478 --altport 3479 --protocol tcp --maxconn 10000 --verbosity 3 --ddp
./stunclient --mode full --protocol tcp --verbosity 3 222.222.x.x 3478

I did not get the expected results on multiple NAT networks, and I'm pretty sure what there exact NAT type are.

I just started a little project to detect TCP NAT type, since there do not have one stun project that can do the exact job.
Here is the link, in case you are interested.
https://github.com/zl21st/tcpstun

Don't run --mode full with the client (but do use that flag with the server). --mode full on client can generate some incorrect values. Use --mode behavior or --mode filtering to do the individual tests with stunclient

Now do for each NAT

./stunclient --mode behavior --protocol tcp --verbosity 4 222.222.x.x 3478
./stunclient --mode filtering--protocol tcp --verbosity 4 222.222.x.x 3478

./stunclient --mode behavior --protocol tcp --verbosity 4 stunserver.stunprotocol.org
./stunclient --mode filtering--protocol tcp --verbosity 4 stunserver.stunprotocol.org

I'd like you to compare the results and let me know what you see for each.

same result for 222.222.x.x

The box I used have NAT1 (full cone nat) network, here is the result of the tool I wrote:

Can your tcpstunc client connect to stunserver.stunprotocol.org? What happens when it does that?

I looked at your code for tcpstunc. Your code actually listens for an incoming TCP connection on the client side. That's not something stunclient.exe attempts to do. But perhaps it should...

tcpstunc can not connect to stunserver.stunprotocol.org, different protocol.

Maybe an independent issue, but I think stunclient's TCP behavior is broken.
If we use it without specifying --localport, it uses random port for each connection (to multiple addresses/ports, within a single execution), resulting in Address and Port Dependent Mapping in almost all situations.
I confirmed this in tcpdump.
Also, TCP testing fails with --localport in filtering mode. It may be trying to open multiple connection on the same port specified.
UDP is working well.