I was interacting with my ChromeCast over UDP. Last week the discovery requests were working just fine. This week the responses I'm getting back are different than they were last week. Last week things were working as described in the DIAL spec. This week I am missing the LOCATION parameter. Whereas before I would receive LOCATION: 192.168.0.103:8008/ssdp/ssdp/device-desc.xml (or something similar) this week I am only getting back dp/device-desc.xml without the LOCATION or IP address and port prefix. I tried using a different Chromecast on a different network and I got similar but not identical results. I received ssdp/device-desc.xml on one and dp/device-desc.xml on the other. Chrome seems to be able to detect the ChromeCast just fine. Did something change in the last few days?
Here is an example response that I received:
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 1
ST: urn:dial-multiscreen-org:service:dial:1
ssdp/device-desc.xml
OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
01-NLS: 2bd4c9f6-1dd2-11b2-a755-8a9e9d005953
SERVER: Linux/3.8.13, UPnP/1.0, Portable SDK for UPnP devices/1.6.18
X-User-Agent: redsonic
ST: urn:dial-multiscreen-org:service:dial:1
USN: uuid:d47145ab-0bd2-d115-9d19-d93a7cb7ae80::urn:dial-multiscreen-org:service:dial:1
BOOTID.UPNP.ORG: 20
CONFIGID.UPNP.ORG: 1
To me, it looks like a bug in your code doing udp receiving.
You should verify the response packet using tcpdump or other tools other than your code.
Related
Hey guys well i'm working on a project.
Basically i need to be able to retrieve result of a SSDP packet to find the IP of my Pioneer VSX AVR. It responds to SSDP to be used with the official apps and i am working on a windows application to do the same sort off thing.
Source: http://github.com/cyanlabs/vsxremote
What i know so far...
the packet need to be sent to the ip 239.255.255.250
The port is 1900 and the AVR responds to Telnet/TCP on 23/8102
The description.xml is located at 192.168.0.111:8080/description.xml
I tried to figure this code out but it didn't seem to work. http://social.msdn.microsoft.com/Forums/vstudio/en-US/d7f53b79-80dc-46f7-96dd-fc3b7a28f8d4
The request i need to send is
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
ST:urn:schemas-upnp-org:device:MediaRenderer:1
MAN: "ssdp:discover"
MX: 1
Any help would be great. Thanks.
Based on the wireshark output and the linked code (both of which really should be in the post):
CONTENT-LENGTH header should not be part of a M-SEARCH message. You are also missing an empty line (vbCrLf) in the end -- and that's in addition to the CrLf that is missing from end of CONTENT-LENGTH line. In other words, every line including the last line must end with "\r\n" and then there must be an extra "\r\n" in the end. Omitting the empty line typically results in devices ignoring your message (as they can't really know it is complete).
See UPnP Device Architecture part 1 for the de facto spec on SSDP.
I am currently working on getting a location of a vehicle to a server. I am using TK103 as my GPS device. It is sending ##,imei:<my_imei>,A; to the server when the server is started.
This is the only document of the protocol I could find on internet: https://web.archive.org/web/20140401000000*/http://www.zhyichina.com/en/gpstracking/gprs-data-protocol.xls
I followed it. But it does not work properly. It needs to send "ON" command many times to work and any of other commands did not work. Could you please help me to identify the problem.
When you get message like ##,imei:123456789012345,A; you need to respond with LOAD.
When you receive just IMEI number like 123456789012345; you need to respond with ON.
Here you can find the source code of the decoder for this protocol:
https://github.com/tananaev/traccar/blob/master/src/org/traccar/protocol/Gps103ProtocolDecoder.java
I am trying to understand, why does Netty SSL mode work on strange way?
Also, the problem is following, when any SSL client(https browser, java client using ssl, also any ssl client application) connects to Netty server I get on beginning the full message, where I can recognize correctly the protocol used, but as long the channel stays connected, any following messages have strange structure, what is not happening same way with non-ssl mode.
As example on messageReceived method when the https browser connects to my server:
I have used PortUnificationServerHandler to switch protocols.. (without using nettys http handler, it is just example, because i use ssl mode for my own protocol too)
first message is ok, I get full header beginning with GET or POST
than I send response...
second message is only one byte long and contains "G" or "P" only.
third message is than the rest beginning either with ET or OST and the rest of http header and body..
here again follows my response...
fourth message is again one byte long and again contains only one byte..
fifth message again the rest... and on this way the game goes further..
here it is not important, which sub protocol is used, http or any else, after first message I get firstly one byte and on second message the rest of the request..
I wanted to build some art of proxy, get ssl data and send it unencoded on other listener, but when I do it directly without waiting for full data request, the target listener(http server as example) can not handle such data, if the target gets one byte as first only (even if the next message contains the rest), the channel gets immediately closed and request gets abandoned..
Ok, first though would be to do following, cache the first byte temporarily and wait for next message and than join those messages, and only than response, that works fine, but sometimes that is not correct approach, because the one byte is sometimes really the last message byte, and if i cache it and await wrongly next message, i can wait forever, because the https browser expects at this time some response and does not send any data more..
Now the question, is it possible to fix this problem with SSL? May be there are special settings having influence on this behavior?
I want fully joined message at once as is and not firstly first byte and than the rest..
Can you please confirm, that with newer Netty versions you have same behaving by using PortUnificationServerHandler (but without netty http handler, try some own handler.)
Is this behavior Ok so, I do not believe, it was projected so to work..
What you're experiencing is likely to be due to the countermeasures against the BEAST attack.
This isn't a problem. What seems to be the problem is that you're assuming that you're meant to read data in terms of messages/packets. This is not the case: TCP (and TLS/SSL) are meant to be used as streams of continuous data. You should keep reading data while data is available. Where to split incoming data where it's meaningful is guided by the application protocol. For HTTP, the indications are the blank line after the header and the Content-Length or chunked transfer encoding for the entity.
If you define your own protocol, you'll need a similar mechanism, whether you use plain HTTP or SSL/TLS. Assuming you don't need it only works by chance.
I had experienced this issue and found it was caused bu using JDK1.7. Moving back to JDK1.6 solved it. I did not have time to investigate further but have assumed for now that the SSLEngine implementation has changed in the JDK. I will investigate further when time permits.
I'm using a TK102 GPS localizer. Along with it, I got only simple end-user docs. No API, dev specs or similar for writing code that will use this localizer.
I was told that it uses UDP. So I wrote a simple PHP listener. But either localizer is not using UDP or something is wrong in communication between it and server. Listener works fine (gets UDP packets from other clients) and localizer is sending something (I'm being charge by GSM operator for GPRS transmission), but the data it sends, doesn't reach server.
I asked about server or networking issues on Unix/Linux and SuperUser. Here I would only ask, if someone knows any API/dev-specs for this localizer, so I can check, if it really uses UDP or if I haven't made any other error (in configuration for example).
The localizer and its clones
We're talking about Xexun TK102 Tracker here. The original one, because there are many clones under other companies from China, selling similar GPS localizer, with the same cover and logo, but with:
less performance electronics on-board (for example -- able to report location once per 20 or 30 seconds, not once per 5 seconds like in original one),
the ones that are sending lesser information (lack of direction/bearing, altitude, number of satelites used for location fix and many more),
units using different format of data or non-standard transmission protocol for sending it (for example, cheaper units are unable to use UDP protocol and are transmiting data through TCP protocol, using packets that not always follows standards or definictions.
Coban and Kintech are only two of many clones sold on eBay and in e-shops, claiming to be original Xexun trackers.
On the other hand, original Xexun and some clones (like Coban for example) are harder to control from own script, because they require a correct answer from the server, where data is sent over GPRS. If unit does not receive such reply, it breaks connection. The cheapes unit does not have this checking and will always sent location data to specified IP address over provided port.
Product description
Here is product description of original Xexun localizer (and here is a clone under Kintech name).
Possible buyer must be very careful (and should secure return policy, for which buying directly in China is not recommended) as there are many reports about sellers claiming to sell original Xexun device and sending a clone actually.
Though this device is five years old, it is still sold at many places (including eBay), but even at theses sources it is very hard to get anything worth for developers, except some simple, very basic user guide.
I have confirmed information (from two different sources) that there is no official API available for this device. The only option is to Google around, ask other users or use forums (see below).
If you own original Xexun localizer, you may try to contact company international departament and ask their technicians to include some changes to device source code and to send you updated firmware, with your changes - wow! That was confirmed by company itself.
Forum
I found a perfect forum for TK102 device, with a lot of questions and answers:
here is a general forum on TK102 device (kept alive for 4,5 year with 171 pages and 2000+ posts!),
here you'll find more specific topic on receiving data from this localizer,
this forum is also about TK102 unit, but it is entirely in French.
There are many other devices dissussed and in general, this is the biggest forum in the world, with topics for localizers and simillar information.
GPRS Protocol Specs
In general, any TK102 related devices is opening a socket for a direct TCP transmission (original one can be switched to use UDP protocol). Data is being transsmited over port specified by user, in configuration and using GPRS only (requires SIM card with enabled GPRS, there is no way to use WiFi).
Sending frequency, format and amount of data being send, entirely depends on kind of device is being used -- it is more extensive and more configurable in original one than in clones.
Using FileDropper I shared GPRS Protocol Specification for TK102 Geolocalizer. It contains basic information on how to setup TK102 (and possible all its clones) to send location over GPRS. And what sort of data you should except to receive from in, on server side. This could be useful for someone.
BTW: If links goes dead, contact me for a reupload or sending it over e-mail
Correct server response problem
Make sure, if you're using correct data transmission protocol! Many (really many) cheap clones uses TCP, while only original TK102 allows switching to UDP. This is convenient, because you need really basic server configuration to handle TCP connections, while you have to use specific server-side software (like node.js) or specific configuration (open to certain ports) to handle UDP. But the key thing is to determine correct protocol, as listening to TCP data, while your localizer sends UDP, will most certainly fail.
Take into consideration, that many TK102 clones requires a correct response from the server after each data, it send. It breaks connection after sending some welcome garbage UDP packet, as it does not receive response, it waits for.
It is quite hard (quite impossible?) to find any guide to many of these clones, on what kind of responses server should sent. This often leads into situation of developer being unable to estabilish two-way communication between server and localizer. Many localizers are sold to be used only via SMS communication or throughs paid services that had signed and agreement with producer and received protocol specification that contains valid responses server should generate for particular TK102 clone.
Double check, if this is not source of problem, if you can't communiacte with your localizer from your app.
You can check some models protocol specs here:
http://www.traccar.org/docs/protocol.jsp
I know there are various programs that sniff packets like WireShark, but I'm pretty sure you can only view the data. I want to know if it's possible to edit incoming packets. I'm not sure if packets are the right term. I just want to edit incoming data that is recieved through the internet and who's destination is a specific application. Let's say I am playing an online game. As it loads my computer, it is recieving information like "This person has 10 coins in their money pouch". Obviously not exactly like that but you get the point. I would like to be able to change the data so it is say 100 instead of 10. I know something like this would be possible if you were to do this: Imagine my computer is connected to the internet with an ethernet cord. There is a device attached to the ethernet cord which recieves the data and changes it and then lets it continue to my computer. I would just like to know if this is possible, and how it could be accomplished.
Thanks!
The way I do it, is one of 2 ways:
1.
If your application supports it set up a HTTP Proxy on your machine and you could software like burp / Fiddler to mess with the data
If not (the protocol is not HTTP) you could use either one of 2 options i'v tried [Both based on Hooking the API calls from the application to the OS]:
EchoMirage software that allow messing around with the packets
[Bit more advanced: ] There is a debugger named OllyDbg which has a plugin named Universal Hooker; it enables to hook any window API function and execute a python script on demend. the uHooker contains examples for how to hook WSASend and WSARecive (which are the API functions used in windows sockets).