Closed gengfeipeng closed 2 years ago
Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 0.0.0.0:0 Sending message to 0.0.0.0:0 delete StunClient object Address and Port Dependent Filtering
All stun packets are sent to one ip, shouldn’t it be sent to the other, so that we can judge whether it will be a symmetric nat.
Sstunclient sends a binding request to the server addresses specified on the command line. The server responds with both the "mapped address" of the local client as well as the "other address" of the service. When the behavior test is run, it will typically contact the "other address" after getting a binding response from the primary address.
Example:
C:\Users\jselbie\Downloads\stunserver_win64_1_2_16\release>stunclient.exe
stun.stunprotocol.org --verbosity 9 --mode behavior
Resolved stun.stunprotocol.org to 18.191.223.12:0
config.fBehaviorTest = true
config.fFilteringTest = false
config.timeoutSeconds = 0
config.uMaxAttempts = 0
config.addrServer = 18.191.223.12:3478
socketconfig.addrLocal = 0.0.0.0:0
Sending message to 18.191.223.12:3478
Got response (68 bytes) from 18.191.223.12:3478 on interface
192.168.1.14:50667
*Other address is 18.219.110.18:3479 <http://18.219.110.18:3479>*
Preparing message for behavior test #2 (destination=AP)
Sending message to *18.219.110.18:3478 <http://18.219.110.18:3478>*
Got response (68 bytes) from 18.219.110.18:3478 on interface
192.168.1.14:50667
Binding test: success
Local address: 192.168.1.14:50667
Mapped address: 11.22.33.44:50667
Behavior test: success
Nat behavior: Endpoint Independent Mapping
In the above run, the first server contacted was stun.stunprotocol.org (18.191.223.12). The response from the server provides the other IP address (and port) the cilent can connect to. In this case, 18.219.110.18. The second message of the behavior test is to make binding request to the alternate IP address without changing the port.
Everything you need to know about the tests for NAT classification is in RFC 5780 (sections 4.3 and 4.4) https://datatracker.ietf.org/doc/html/rfc5780#section-4.3
On Thu, Dec 16, 2021 at 7:25 PM gengfeipeng @.***> wrote:
https://blog.csdn.net/fivedoumi/article/details/8168882
I looked in the client source code and found that there is no other public network address.
— Reply to this email directly, view it on GitHub https://github.com/jselbie/stunserver/issues/44, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHNSF3NSWWQ2XSWRMD64BTURKUSVANCNFSM5KH3I6LQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
The "behavior test" will typically send to he alternate IP address. The "filtering test", which is what's being shown above, doesn't actually involve the client sending to the alternate address. Instead, it sends a special header (CHANGE-REQUEST) to indicate it wants to receive the response from the other IP address (and/or port). With most NATs implementing "address and port dependent" filtering, the response from the alternate address is dropped by the NAT and never reaches the client. Hence, the unusual number of retry messages in the verbose output. I'm not sure why your client is sending to 0.0.0.0 in the above output, but that dump doesn't look complete. It would benefit from you sharing the entire trace, including the command line parameters itself.
On Thu, Dec 16, 2021 at 7:29 PM gengfeipeng @.***> wrote:
Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 117.50.10.29:38413 Continuing to wait for response... Sending message to 0.0.0.0:0 Sending message to 0.0.0.0:0 delete StunClient object Address and Port Dependent Filtering
All stun packets are sent to one ip, shouldn’t it be sent to the other, so that we can judge whether it will be a symmetric nat.
— Reply to this email directly, view it on GitHub https://github.com/jselbie/stunserver/issues/44#issuecomment-996408344, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHNSF6MJO5XTZWHJXOG5QTURKVBLANCNFSM5KH3I6LQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
hello jselbie client: gengfeipeng@bogon stunserver % ./stunclient --mode full --localaddr 10.2.2.63 --localport 9999 --protocol udp --verbosity 2 117.50.10.29 Resolved 117.50.10.29 to 117.50.10.29:0 config.fBehaviorTest = true config.fFilteringTest = true config.timeoutSeconds = 0 config.uMaxAttempts = 0 config.addrServer = 117.50.10.29:3478 socketconfig.addrLocal = 10.2.2.63:9999 Sending message to 117.50.10.29:3478 Got response (68 bytes) from 117.50.10.29:3478 on interface 10.2.2.63:9999 Other address is 117.50.10.29:3479
Preparing message for filtering test #2 (ChangeRequest=AA) Sending message to 117.50.10.29:3478 Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Preparing message for filtering test #2 (ChangeRequest=AA) Sending message to 117.50.10.29:3478 Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Preparing message for filtering test #3 (ChangeRequest=PA) Sending message to 117.50.10.29:3478 Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Preparing message for filtering test #3 (ChangeRequest=PA) Sending message to 117.50.10.29:3478 Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Continuing to wait for response... Preparing message for behavior test #2 (destination=AP) Sending message to 117.50.10.29:3478 Got response (68 bytes) from 117.50.10.29:3478 on interface 10.2.2.63:9999 Binding test: success Local address: 10.2.2.63:9999 Mapped address: 106.120.244.138:32530 Behavior test: success Nat behavior: Endpoint Independent Mapping Filtering test: success Nat filtering: Address and Port Dependent Filtering
server: ./stunserver --mode full --primaryinterface 10.19.99.42 --altinterface 10.19.179.125 --primaryadvertised 117.50.10.29 --altadvertised 106.75.116.8 stunclient recieve len 800 stunclient recieve len 800 stunclient recieve len 800 stunclient recieve len 800 stunclient recieve len 800 stunclient recieve len 800
This is my entire process. What do you think is the reason why I can't send a message to the server's alternate ip?
https://blog.csdn.net/fivedoumi/article/details/8168882
I looked in the client source code and found that there is no other public network address.