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.
Related
I am currently working on an application to change my RGBWW light strips by a Java application.
Information has to be sent via UDP packages in order to be understood by the controller.
Unfortunately, the hex number 0x80 has to be sent - which is causing some problems.
Whenever I send a byte array containing only numbers fron 0x00 to 0x79 (using DataPacket and a DataSocket), I do get an UDP Package popping up on my network monitor.
As soon as I include the number 0x80 or any other higher, I see two things Happen:
1: I do not longer get only UDP protocols, but messages are displayed as RTP / RTCP most of the time
2: The method Integer.hexToString() does not display "80", but gives me a "ffffff80".
My question: Is there something I am missing when it comes to sending hex info by UDP? Or is there another way of sending it, possibly avoiding the annoyingly signed bytes?
I unfortunately did not find any information that would have significantly helped me on that issue, but I hope you can help me!
Thanks in advance!
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 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.
I am working with pcap in an OS X application to understand packet analysis.
I am working with a app https://github.com/jpiccari/MacAlyzer
but I am getting only raw data but I want to differentiate every domain request into separate and clear way to read request and response value. Please guide me the way to how to develop an application with pcap.
I have tried some code but they translate data into hex format. How do I convert that data into meaningful request and response objects like Charles and Fiddler show?
MacAlyzer wasn't developed for your needs. I know because I'm the author. As already stated, Charles and Fiddler are web proxies and work entirely different (and serve different purposes).
Diving a bit deeper into your question, communication between client and server happens IP-to-IP and not domain-to-domain. Domain information is not contained in the packets at the either the IP or TCP level. Instead computers request domain-to-IP lookup information which is then stored and communication is carried out using the client and server IP addresses.
MacAlyzer, and really libpcap, don't have sophisticated packet dissection (like say Wireshark) and cannot display packet information as verbosely as other programs. Before I lost interest in the project I was planning a library that would allow much richer packet dissection and analysis, but free time became very limited.
As for adding domain information to MacAlyzer, I'll explain at a high-level since it seems you know what you're doing. To include domain information instead of IP address in the Source and Destination columns you could edit function ip_host_string() in ip.m. This function controls how the client and server addresses are displayed. Modifying it to lookup the hostname from IP address and returning the resulting string would cause the domains to be displayed instead of IP addresses.
If you come up with some nice updates, consider submitting a pull request.
Here is the food for thoughts:
http://www.binarytides.com/packet-sniffer-code-c-linux/
Anyway, you will need to use C. Therefore, check the codes of the includes, for example:
http://www.eg.bucknell.edu/~cs363/2014-spring/code/tcp.h
Here is the documentation of "pcap":
http://www-01.ibm.com/support/knowledgecenter/#!/ssw_aix_71/com.ibm.aix.basetrf1/pcap_close.htm
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.