i want to know my nat type, i was trying with this command "netsh interface Teredo show state" however someone suggested me that i should ie a stun server or client to have a better idea of my nat. But i dont have any idea of this, i just want to have an open nat to play games, so please be patient with me :)
By the way i have enabled DMZ and UPNP on my modem.
Server Name : win1910.ipv6.microsoft.com.
Client Refresh Interval : 20 seconds
Client Port : unspecified
State : qualified
Client Type : teredo client
Network : unmanaged
NAT : symmetric (port)
NAT Special Behaviour : UPNP: Yes, PortPreserving: Yes
I googled for stun clients or servers but they dont have any info on how to install them or use them, like this one https://github.com/moien007/STUN so if someone can help me with an app that is easy to install or some instructions on how to install a stun server or client please.
Thank you very much.
Edit runing stuntcode.exe got this
Result of CTestDataStream: PASS
Result of CTestReader: PASS
Result of CTestBuilder: PASS
Result of CTestIntegrity: PASS
Result of CTestMessageHandler: PASS
Result of CTestCmdLineParser: PASS
Testing detection for DirectMapping
Testing detection for EndpointIndependent mapping
Testing detection for AddressDependentMapping
Testing detection for AddressAndPortDependentMapping
Testing detection for EndpointIndependentFiltering
Testing detection for AddressDependentFiltering
Testing detection for AddressAndPortDependentFiltering
Result of CTestClientLogic: PASS
Result of CTestRecvFromEx(IPV4): PASS
Result of CTestRecvFromEx(IPV6): PASS
Result of CTestFastHash: PASS
Result of CTestPolling: PASS
Result of CTestAtomicHelpers: PASS
Result of CTestRateLimiter: PASS
You can get a STUN client application for all platforms at https://www.stunprotocol.org (prebuilt EXE clients for Windows and Mac command line apps are up there too!)
Demonstration:
C:\StunServer> stunclient.exe stunserver.stunprotocol.org --mode behavior
Binding test: success
Local address: 192.168.1.7:52707
Mapped address: 101.102.33.44:52707
Behavior test: success
Nat behavior: Endpoint Independent Mapping
C:\StunServer> stunclient.exe stunserver.stunprotocol.org --mode filtering
Binding test: success
Local address: 192.168.1.7:39843
Mapped address: 101.102.33.44:39843
Filtering test: success
Nat filtering: Address Dependent Filtering
Running the two test modes, reveals Endpoint Independent Mapping and Address Dependent Filtering as described in RFC 5780 for classifying NATs.
Related
Our project has a few GRPC servers defined as go_binary targets. We develop client SDKs for Java and Python applications and we would like to use java_test and py_test. Is any way to start a specific go_binary target before java_test or py_test?
You can create a test harness that starts the gRPC server before running the tests. For example, you could add the binary to the data attribute of the test, and then started it beforehand:
go_binary(
name = "my_grpc_server",
[...]
)
py_test(
name = "my_test",
[...]
data = [":my_grpc_server"],
)
and then inside the test file:
class ClientTestCase(unittest.TestCase):
def setUp(self):
r = runfiles.Create()
self.server = subprocess.Popen([r.Rlocation("path/to/my_grpc_server")])
def tearDown(self):
self.server.terminate()
self.server.wait()
This example is very simple, you'll probably run into issues regarding the availability of the port the server listens on, or waiting for the server to start up. You could add flags to your gRPC server to allow communication over a domain socket, or make it listen on an unused port and have the test parse the port number from the server's log output.
For details on finding the server with runfiles: https://github.com/bazelbuild/bazel/blob/a7a0d48fbeb059ee60e77580e5d05baeefdd5699/tools/python/runfiles/runfiles.py#L16-L58
If you find yourself copy-pasting this pattern a lot, or having to implement it in multiple languages, you could try using an sh_test() rule to wrap the underlying py_test or java_test, and to start the server, then start the test with an environment variable telling it how to reach the server (eg MY_GRPC_SERVER_ADDRESS=localhost:${test_port}.
I have a simcom7600 modem which I am trying out via AT commands.
I was able to use AT commands to setup the modem, and connect to an MQTT broker and exchange messages. Now I am trying to figure out how I can do something similar, but then with my own TCP/IP stack. Before diving into the deep there, I would like to confirm that I can get into data mode (PPP) which I am not able to, it seems.
I attached my modem (AT+CGATT=1), and activated it (AT+ACACT=1,1). I verified that I have a carrier/provider (AT+COPS?).
So I thought I was all set to send the ATO (online) commands. But it returns NO_CARRIER every time I try. I have no idea what I am doing wrong.
The logging that confirms above statements:
AT+COPS?
Sending command: AT+COPS?
AT+COPS?[CR][CR][LF]+COPS: 0,0,"NL KPN simyo",7[CR][LF][CR][LF]OK[CR][LF]
AT+cgatt?
Sending command: AT+cgatt?
AT+cgatt?[CR][CR][LF]+CGATT: 1[CR][LF][CR][LF]OK[CR][LF]
AT+cgact?
Sending command: AT+cgact?
AT+cgact?[CR][CR][LF]+CGACT: 1,1[CR][LF]+CGACT: 2,0[CR][LF]+CGACT: 3,0[CR][LF][CR][LF]OK[CR][LF]
ATO
Sending command: ATO
ATO[CR][CR][LF]NO CARRIER[CR][LF]
PS: the [CR][LF] stand for resp. \r and \n, I replace them before I log for ease of reading.
I obviously have to supply more info to the modem, but from this manual I can't seem to figure out which commands I miss, and how I could validate step by step that I am on the right track.
I found this nice document. I'll share it here in case somebody else struggles with this as well.
When I send the following commands:
ATZ (reset)
ATE0 (disable echo)
AT+CGREG? (check registration to PDP network)
AT+CGDCONT=1,"IP","internet" (set APN for my provider, they expect the string "internet")
ATD*99# (start data mode, aka PPP)
then I can break out and move back into PPP with the following commands:
+++ (send + character, wait for 700ms, send + character, wait for 700ms, send + character) => back to AT command mode
ATO (back to data mode)
NOTE: the APN your provider expects, is I think in all cases an easy Google. Your provider will most likely explain how to manually set your APN in case your phone won't do it automatically.
We are setting up a federated scenario with Server and Client on different physical machines.
On the server, we have used the docker container to kickstart:
The above has been borrowed from Kubernetes tutorial. We believe this creates a 'local executor' [Ref 1] which helps create a gRPC server [Ref 2].
Ref 1:
Ref 2:
Next on the client 1, we are calling tff.framework.RemoteExecutor that connects to the gRPC server.
Our understanding based on the above is that the Remote Executor runs on the client which connects to the gRPC server.
Assuming the above is correct, how can we send a
tff.tf_computation
from the server to the client and print the output on the client side to ensure the whole setup works well.
Your understanding is definitely correct.
If you construct an ExecutorFactory directly, as seems to be the case in the code above, passing it to tff.framework.set_default_context will install your remote stack as the default mechanism for executing computations in the TFF runtime. You should additionally be able to pass the appropriate channels to tff.backends.native.set_remote_execution_context to handle the remote executor construction and context installation if desired, but the way you are doing it certainly works, and allows for greater customization.
Once you have set this up, running an example end-to-end should be fairly simple. We will set up a computation which takes a set of federated integers, prints on the clients, and sums the integers up. Let:
#tff.tf_computation(tf.int32)
def print_and_return(x):
# We must use tf.print here, as this logic will be
# serialized and run on the clients as TensorFlow.
tf.print('hello world')
return x
#tff.federated_computation(tff.FederatedType(tf.int32, tff.CLIENTS))
def print_and_sum(federated_arg):
same_ints = tff.federated_map(print_and_return, federated_arg)
return tff.federated_sum(same_ints)
Suppose we have N clients; we simply instantiate the set of federated integers, and invoke our computation.
federated_ints = [1] * N
total = print_and_sum(federated_ints)
assert total == N
This should cause the tf.prints defined above to run on the remote machine; as long as tf.print is directed to an output stream which you can monitor, you should be able to see it.
PS: you may note that the federated sum above is unnecessary; it certainly is. The same effect can be had by simply mapping the identity function with the serialized print.
I'm trying to connect to an RN42, module through python. When the RN42 pairs with W10 it creates two virtual COM ports(outgoing and incoming). I need to connect to the outgoing port.
I'm trying to do this automatically. I've tried:
import serial
import serial.tools.list_ports as port_lst
ports = list(port_lst.comports())
bluetooth_ports = []
for p in ports:
if 'Bluetooth' in p.description:
bluetooth_ports += [p.device]
bluetooth_com = serial.Serial(bluetooth_ports[0],115200)
I thought that the first port was usually the outgoing one, but I've paired the module to another computer, and this didn't apply (the second port was the outgoing one). Is there a way to find out the direction of the COM ports?
Thanks!!!
Although this is an antique question, I have been searching for the answer to this for some time myself and since I finally figured it out I wanted others to be able to find the answer. With help from a blog entry at in the hand and its accompanying gist:
The trick is to acquire the hwid using pySerial, then parse the address. The incoming port in a pair has an address of zero and the outgoing port has a nonzero address. Here is some ugly Python code that decodes it:
import serial.tools.list_ports
cp=serial.tools.list_ports.comports()
for p in cp:
if "BTHENUM" in p.hwid:
start_of_address=p.hwid.rfind("&")
end_of_address=p.hwid.rfind("_")
address=p.hwid[start_of_address+1:end_of_address]
if int(address,16)==0:
port_type="incoming"
else:
port_type="outgoing"
print(p.hwid)
print(p.name, address, port_type)
And the output:
BTHENUM\{00001101-0000-1000-8000-00805F9B34FB}_LOCALMFG&0000\7&CC47540&0&000000000000_000000A8
COM4 000000000000 incoming
BTHENUM\{00001101-0000-1000-8000-00805F9B34FB}_LOCALMFG&0002\7&CC47540&0&209BA5420081_C00000000
COM5 209BA5420081 outgoing
I am communicating with CUPS using IPP protocol. I have all drivers for my printers installed in CUPS (using .ppd file) and printers got latest firmware.
When I query a job which a printer printing right now it says that the job's state is 'complete' before the printer even finish printing. It seems that the CUPS marks the job as 'complete' when it finish 'uploading' the file.
I would not expect this behaviour and I basically need to know when exactly the printer printed last paper for a job.
The code looks as follow. The self.printer().ippPrinter() is an instance of node-ipp and it points to a printer. To read the the state of the job I am using attribute 'job-state'.
var msg = {
"operation-attributes-tag": {
'job-id': id
}
};
self.printer().ippPrinter().execute("Get-Job-Attributes", msg, function(err, res){
var attributes = res['job-attributes-tag'];
self.setAttributes = attributes;
callback.call(self, attributes);
});
Does anyone know why I am having this issue or .. how to make it working?
Thank you!
CUPS can only forward job-states received from the printer. A lot of printer drivers and protocols work like 'fire and forget'.
Usually IPP printers allow CUPS and other clients to monitor the current job-state until it's finished/printed. Some manufacturers don't implement IPP properly and classify submitted jobs as printed - even if the printer has a paper jam!
Conclusion:
If your printer does not fully support IPP you probably won't be able to check for 'printed successfully'.
RFC 8011 5.3.7.1
If the implementation is a gateway to a printing system that never provides detailed status about the Print Job, the implementation MAY set the IPP Job’s state to ’completed’, provided that it also sets the ’queued-in-device’ value in the Job’s "job-state-reasons" attribute
#Jakub, you may well be communicating with CUPS using IPP... But are you sure that CUPS is communicating with the print device via IPP?
You can check this by running
lpstat -h cupsservername -v
This should return the device URI assigned to each print queue, which CUPS uses to address the actual printing device:
If that URI does contain ipp://, ipps://, http:// or https:// CUPS indeed talks IPP to the print device and you should be able to get actually correct status messages.
But if you see socket:// then CUPS is configured to use the AppSocket method (sometimes also called 'HP Jet Direct' or 'IP Direct Printing') to forward jobs. This is a "fire and forget" protocol. Basically it is the same as if you did run netcat print-device 9100 < myprintfile to shovel the printable data to port 9100 of the printer. The CUPS socket backend handling this spooling to the printer will not get any other acknoledgement from the printer than what TCP/IP provides confirming that the last packet was transfered. Hence it has to close down its process and report to the CUPS daemon successful-ok, even if the printer is still busy spitting out lots paper and will maybe never complete the full job because it runs into a paper jam...
If you see lpd:// the situation is similar (but uses port 515).
You may have success with a full status reporting by switching the CUPS-to-printdevice path from AppSocket or LPD to IPP like so:
sudo lpadmin -p printername ipp://ipaddress-of-printer
or
sudo lpadmin -p printername http://ipaddress-of-printer:631