I have a GPS Tracker (TK303G) that can send data to a server by GPRS with an IP and Port, but if I change the IP and try to set it to GPRS mode it turns back to GSM automatically.
If I use the default IP or the vendor server IP it works just fine.
Anyone knows why is that? Is there something I'm missing? Maybe I have to send something back from my server?
Related
I am trying to make video calls with WebRTC and Janus. I am able to make calls using the video call demo page supplied by Janus as well as through an iOS app - this is all working perfectly fine.
However, when inspecting the network flow through both wireshark and chrome://webrtc-internals/ the connection does not seem to be directly to the public IP of the other device. Instead the data is directed to my Janus signaling server. It seems that the IP of the remoteIceCandidate is equal to the IP of my signaling server - shouldn't this should be equal to the public IP of device 2?
Is this correct behavior or not? If so, why is the remote IP not equal to the public IP of device 2? If not, what am I doing wrong?
This is correct behavior and a mistake on my part. The Janus video call plugin documentation says the following:
The idea is to provide a similar service as the well known AppRTC demo (https://apprtc.appspot.com), but with the media flowing through a server rather than being peer-to-peer.
Therefore, the media data is supposed to go to the server instead of over a peer-to-peer connection.
sorry if this is the wrong "stack". I could not find a better suited.
I bought a GPS tracker for my dog, which came with a subscription, a SIM card and a poorly developed app.
I have cancelled my subscription and want to use the device to send location info to my own server.
The device has a micro USB input and a SIM card slot. There is not much more I know, but if you have questions which may help find the answer, I can try to take it apart a little more.
So basically, is there some way I can reprogram this device to use my own SIM-card and app?
Plugging the device into my computer does nothing(as expected) however it does register in devmgmt.
Do not worry about the actual reprogramming, I can handle that myself.
Thanks in advance
Edit:
Thank you for feedback.
Image provided.
It does not, as I first thaught, register in the device manager.
I do have an IMEI number for it, but I cannot see a manufacturer anywhere on it. It might be on the underside, but the battery is glued on there.
Based on the Model Number LK120 After some Googling I found a documentation with the following SMS commands. Link to documentation LK209
Note send the commands without Square Brackets
// I guess you've already done 1 and 2.
1 - Set Admin Number - admin123456 [YOUR_PHONE_NUMBER]
2 - Set APN - apn123456 [APN_DETAILS]
//123456 seems to be the password - If the company you got the tracker from provided a different password - try that.
3 - SET the IP and Port Number - adminip123456 [IP_ADDRESS] [PORT_NUMBER]
As this Tracker is either TCP or UDP based - Can't really tell without the actual protocols and User Manual - you will have to setup a TCP and UDP Server and see which Protocol the Tracking Device connects via.
There are a few free software that can setup a TCP/UDP Server on your local machine for testing. [https://packetsender.com/]
Note that the IP address you set on the Tracker must be your Public IP Address, not Local LAN IP Address. You can get the Public IP from here - https://www.whatismyip.com/
Also you will need to open the port of your choosing on your Router and forward the Port to your PC make sure the port is not in use by another application e.g. 9999. This is possible for most Routers. You should be able to access your router admin panel using a browser, details should be on your router.
Also open the port on your PC firewall.
You can always check if it is possible to connect to your Server by going to CMD and running the following command (or use the Packet Sender software to test)
telnet [PUBLIC_IP_ADDRESS] [PORT]
If you can connect via the above command then the tracker should also be able connect.
Note Let us know if the SMS commands work, you should get a response if they work.
I am trying to send a UDP packet to a device that is behind a NAT. Using a 3rd party program it is possible to send packets to this device no problem, and the packets show up in wireshark fine.
Using my own UDP client to send a packet to the device doesn't work... but if the device sends ME a packet, in the onReceive() method, sending directly back to the device in this method DOES work...but interestingly if I take the EndPoint and connect to this using a new UDP client, then it doesn't work again.
It seems like only when the device connects to me can I send messages downstream (like reverse connecting in TCP) and even taking the EndPoint as a reference to the 'connection' is not enough.
Can anyone think of reasons why I can't send directly to the device, even though I know it is possible to do so because the 3rd party software can do it?
Sending directly to other IP's such as my local computer works fine too, it is just this device that I cannot contact. My local computer is on an address like 192.168.10.2 and the device is on an address like 12.0.1.5 (when connected it creates its own LAN)
Many thanks
Basically, I want to check to see if a game server is online/offline but the server is hosted through a port, how would I go about pinging it to check this. For testing purposes the server I want to ping is fr7.mooshroom.net:25667, however eventually I will be importing the server IP and port from an online plist so could the ip address and port be separated
If you could give me a step by step guide on how to do this, that would be much appreciated.
I am using the Reachability by tonymillion because the apple one doesnt work with iOS 5.
First, it depends on if you are talking about TCP or UDP.
If it's TCP, then the answer may be simple: try to open a TCP connection to the server at that port. If the connection opens, drop the connection and report success. Otherwise, failure. This is the simplistic view. It's possible if there are load balancers or firewalls in front of the server, the TCP connection may open but the backend server is down.
UDP would be harder. There is no way to know when you send UDP data that the server got the data unless it sends you some kind of response. It's possible that if the UDP server is down and you sent a message to the port, your computer might get an ICMP Error message back. That would definitely let you know the server is down. But firewalls may block this message getting back to your device, so that might not be reliable.
Otherwise, you need to send a properly formatted message to the server to get some kind of response. This is protocol-dependent but is the most reliable.
The traditional "ping" message is an ICMP echo query and response message. As such, there is no "port" associated with ICMP.
I'm sniffing between two devices which communicate in a duplex fashion via udp. I'm using wireshark to sniff. The config file for the first device (a piece of hardware under test) states that the client port is 54718 and the server is 54717. In the config file for the second device (a simulator written years ago), only one port is specified. That of 54718.
The two devices communicate without any problems.
But how does the second device manage to connect and send to 54717 when it has no knowledge of it?
In wireshark I can see that the first device is sending to the second device such that the source port is 54717 and the destination is 54718. I can also see that the second device is sending to the first device such that the source port is 54718 and the destination is 54717.
The first device sends first and the protocol is described as that of UDP in Wireshark. The simulator replies, also via UDP. Subsequent exchanges are described as being STUN ChannelData TURN Messages. I've no knowledge of this protocol but maybe it explains why I don't see 54717 in the simulators config file.
Thanks for your help,
Barry
First, in UDP communication, there is no "connect" action. UDP is not connection-oriented.
Second, the second device will get the peer address and port from recvfrom() api call.
In all probability, the first device's use of the terminology "client port" and "server port" do not refer to two different ports within the client device. Instead, the "client port" refers to the port to be used as the point of origin within the first device, and the "server port" refers to the remote destination port on the far device, to which the first device's outgoing traffic will be sent.
The second device, on the other hand, is probably fundamentally a "listening" device. It only knows the UDP port it needs to listen on, and waits for any queries destined to that port to arrive from anywhere.
So, I will refer to the "first device" as the client, and the "second device" as the server.
Each datagram sent from the client to the server contains two sets of address information:
1) The destination IP address and port, and
2) The return IP address and port.
The server can use recvfrom() to extract the complete return address (including port number) from each incoming request.
This way, we really only need one port number to be predfined and agreed upon by both the server and the client ahead of time: The server's port number.
The client could conceivably choose to use any random port number as its origin port (but by convention it would likely choose to avoid any of the well-known reserved ports to avoid potential interoperability problems), and the server could dynamically read the return address information from each incoming request and send its responses to the correct destination dynamically.
But how does the second device manage to connect and send to 54717 when it has no knowledge of it?
UDP is connectionless, and your program likely gets the 54717 as a default fallback value if nothing else is specified (e.g. in a config file).