I've been reading the rfc 7252 for a while and I am probably blind but I can't find how can I send a simple number (integer or float) when you answer a get request for a ressource (for example the sensor /light, where do you write it in the packet.
I think it's in the payload, so I tried to send this packet :
the option content-format text/plain, charset=utf-8, length 1
then I write 255(0xff) in the packet
then I write 0x34 in the packet (payload part).
But obviously it's not working, first I don't think I should use this option (probably another one but I can't find the good one to send either integer or float number), I'm not sure though if I'm in the right way and not sure anymore of what I am doing tbh, so that's why I'm asking.
Thanks for help,
Good bye
EDIT : Here are more info :
I'm using microcoap on arduino, using an ethernet cable between computer/arduino mega 2560.
wireshark info
After reviewing your Wireshark trace and seeing the response in Copper I think I see the problem. When you say that the Content-format is text/plain you are saying that you are sending ASCII data across. You say you send [0xFF 0x34] in your post, but in the trace you are actually sending is [0xFF 0x33]. Copper is showing you exactly what you are sending: 0xFF doesn't resolve as ASCII here and 0x33 is the ASCII for 3, which is shown in the Wireshark trace and in your Copper output window. If you want to send 2 raw bytes of data that shouldn't be interpreted as text you want to set your Content-format to be application/octet-stream.
Related
I'm working with raw-socket (a node module for sending raw data out on the network) and playing with their Ping example.
I have Wireshark set up to monitor traffic. I can see my ICMP packet go out, and a response comes back.
Here's where things get strange.
Wireshark shows the following packet:
IP: 4500003c69ea00004001e2fec0a85647c0a85640
ICMP: 00004b5200010a096162636465666768696a6b6c6d6e6f7071727374757677616263646566676869
However, the node event handler that fires when data comes in is showing:
IP: 4500280069ea00004001e2fec0a85647c0a85640
ICMP: 00004b5200010a096162636465666768696a6b6c6d6e6f7071727374757677616263646566676869
The ICMP components match. However, bytes 0x02 and 0x03 (the Length bytes) differ.
Wireshark shows 0x003c or 60 bytes (as expected).
Node shows 0x2800 or 10kB... which is not what is expected.
Notably, the checksum (bytes 0x18 and 0x19) are the same in each case, although it's only valid for the Wireshark packet.
So, here's the question: what might lead to this discrepancy? I'm inclined to believe Wireshark is correct since 60 bytes is the right size for an ICMP reply, but why is Node wrong here?
OSX note
The docs for this module point out that, on OSX, it will try to use SOCK_DGRAM if SOCK_RAW is not permitted. I have tried this with that function disabled and using sudo and got the same responses as before.
Github issue
It looks like https://github.com/nospaceships/node-raw-socket/issues/60 is open for this very issue, but it remains unclear if this is a code bug or a usage problem...
This is due to a FreeBSD bug (feature?) which subtracts the length of the IP header from the IP length header field and also flips it to host byte order.
https://cseweb.ucsd.edu//~braghava/notes/freebsd-sockets.txt
I'm writing a small app to test out how torrent p2p works and I created a sample torrent and am seeding it from my Deluge client. From my app I'm trying to connect to Deluge and download the file.
The torrent in question is a single-file torrent (file is called A - without any extension), and its data is the ASCII string Test.
Referring to this I was able to submit the initial handshake and also get a valid response back.
Immediately afterwards Deluge is sending even more data. From the 5th byte it would seem like it is a bitfield message, but I'm not sure what to make of it. I read that torrent clients may send a mixture of Bitfield and Have messages to show which parts of the torrent they possess. (My client isn't sending any bitfield, since it is assuming not to have any part of the file in question).
If my understanding is correct, it's stating that the message size is 2: one for identifier + payload. If that's the case why is it sending so much more data, and what's that supposed to be?
Same thing happens after my app sends an interested command. Deluge responds with a 1-byte message of unchoke (but then again appends more data).
And finally when it actually submits the piece, I'm not sure what to make of the data. The first underlined byte is 84 which corresponds to the letter T, as expected, but I cannot make much more sense of the rest of the data.
Note that the link in question does not really specify how the clients should supply messages in order once the initial handshake is completed. I just assumed to send interested and request based on what seemed to make sense to me, but I might be completely off.
I don't think Deluge is sending the additional bytes you're seeing.
If you look at them, you'll notice that all of the extra bytes are bytes that already existed in the handshake message, which should have been the longest message you received so far.
I think you're reading new messages into the same buffer, without zeroing it out or anything, so you're seeing bytes from earlier messages again, following the bytes of the latest message you read.
Consider checking if the network API you're using has a way to check the number of bytes actually received, and only look at that slice of the buffer, not the entire thing.
I'm trying to communicate with a bluetooth thermometer. It's not BLE, it uses serial ports. I've made it as far as receiving REQ signals from the device, but it requires a ACK signal or it cuts the connection after a few seconds.
The problem is, I can't decipher what the ACK signal is supposed to be. Going off the documentation, it says:
<ACK Format> ADH,01H
<REQ Format> ADH,00H,n
The third byte of REQ is the can be multiplied by 0.01310547 to get the voltage of the battery
<Data Format> ADH,03H,1EH," IRSTP3xx.yyy.HhhSss,nnn,tt.t"+0D+0A
xx: LotNo.(base 16) "01"~"FF"
yyy: S/N(base 16) "001"~"FFF"
...
...
Nothing in the Data Format mentions the first 3 bytes(?) either.
That's pretty much all I've got to work with. I'm trying decoding REQ with different encodings like ascii and utf-8 to see if I can get it to match the REQ format, and then use that same encoding to format and send ACK, but I haven't had any luck.
Is the format just in some kind of standard notation that I'm not familiar with?
The H apparently stands for hexidecimal.
ADH is a two byte message, the first byte being a hex A and the second a hex D. I have not seen that notation before.
This question suggests that the Node.js Net module doesn't handle ip-fragmentation:
Node.js how to handle packet fragmentation with net.Server
I can almost not imagine it's true, but I can't find any documentation about this (please forgive me if it shouldn't be too hard to find information about this :-) ). Is it true?
If not: thank you, that's a real day-safer to me :-).
If it is true: how to handle this problem if I don't know how large the whole datagram is?
Situation:
I have a TCP connection with an embedded system (Wiznet W5500). The MSS (Maximum Segment Size, mostly equal to MTU - 40) will be set to 536 and data packages are a variable size and may be over 4kb in size. So the data package will be send in multiple segments. Will the 'on data' event be triggered once a segment is received or only when the whole package is received?
Side question: Am I right that the data segment (about what Wiznet is talking in the explanation of the MSS register) equel is to a ip-fragment?
So if I have to send 4000byte (ie payload) and the MSS is set to 536 I will receive consecutively:
segment1: 536bytes payload
segment2: 536bytes payload
segment3: 536bytes payload
segment4: 536bytes payload
segment5: 536bytes payload
segment6: 536bytes payload
segment7: 536bytes payload
segment8: 248bytes payload
May the 'on data' event only be triggered after segment 8 an will the 'data argument' contain the whole package or may it happen that the 'on data' event will be triggered after every separately received segment?
How can I make 100% sure that I get the whole package before I continue to process it?
Solution I thought of:
First 2 byte of the data package is the byte length of the whole length, I keep concattenating received data until I have received as many bytes. If I received more than the package size, I'll assume these successive bytes are the start of a subsequent data package.
I do believe this 'solution' is somewhat tricky and I hope it's not required.
Thanks in advance! If any information is missing: I'm sorry, please feel free to ask for it :-).
I am a big fan of nodeJS, but in this case you should use python with scapy :)
http://www.secdev.org/projects/scapy/
Does anyone know,how to get single packet information through nDPI or any other DPi libraries.
Does anyone know,how to get single packet information through nDPI
For nDPI, call ndpi_detection_process_packet() - as the documentation generated from its comment says, it "will processes one packet and returns the ID of the detected protocol", as it's "the main packet processing function" in nDPI. As my other answer indicated, it won't give you a detailed dissection of the packet, but that's not what it's designed to do; it's designed to quickly recognize packet types (quicker than a detailed packet dissector such as the ones in Wireshark) rather than to show you the detailed packet headers.