My goal is to exchange packets between my PIC18F67j60 microcontroller (it has a Ethernet module) and my host computer.
I programmed the PIC18F using MPLABX IDE (C language, pickit3) and on the computer side, I programmed a simple application on CODE::BLOCKS (C language). The application running on my computer works (I tested it). The goal is to establish a TCP communication between the PIC18 and the computer (I know TCP is not that good for embedded devices like microcontrollers cause it takes memory space).
I already managed to establish a UDP communication and I could send and receive any data from both sides.
The issue takes place with TCP communication. The issue is the following : my computer sends a TCP PDU to my microcontroller (to start a connection process, so sets SYN Flag) and my micontroller receives it. Then I decided to display on a screen(using UART) the data received by the microcontroller.
I finally noticed I'm getting a TCP option field added to the TCP "regular" header (in this TCP regular header, the OFFSET byte is "0x80", which means the whole TCP header is 8 * 4 bytes = 32 bytes long or 256 bits long if you want, also 32 = 20 + 12, it means I have 12 more bytes in addition to TCP 20 regular bytes).
The last byte of the TCP Header is the "Urgent Pointer" and right after begins the TCP option that is : TCP option field = " 02 04 05 B4 01 03 03 08 01 01 04 02"
What does this option field means ? I understand that "02 04 05 B4" is for MSS field, but then I'm clueless, I dont understand what the other bytes represent... Any help please ?
Thank you for the help provided.
TCP option field = " 02 04 05 B4 01 03 03 08 01 01 04 02", represents some of the fields appearing in TCP option field with their order.
Atleast, the tcp option values found through pyshark packet analyzer, represents encoding for some values:
MSS - 02:04:05:b4,
NOP - 01,
Window Scale - 03:03:08 or 03:03:02,
SACK perm - 04:02.
Related
I have a simple TCP client/server arrangement (running on Windows 10/11) used to transfer binary data from multiple remote clients to a single server. This works 99% of the time. However, whenever the following hexadecimal sequence appears in the data (being sent from the client to the server) the TCP connection drops and the client generates a 10053 error.
6C 74 01 00 08 00 00 00
Running the server application on a local network has slightly different results... the connection does not drop but the client receives no ACK from the server.
Is it possible for a certain sequence of bytes to drop, or otherwise interfere with, a TCP connection?
I've been working on a project which involves sending DNS requests with information (not actual domains) in the questions (2 of them). I've been tracking the packets with wireshark.
Here is the tcp dump of the packet created.
00000000 00 02 01 00 00 02 00 00 00 00 00 00 01 32 03 65
00000010 6e 64 03 63 6f 6d 00 00 01 00 01 01 32 04 73 61
00000020 76 65 03 63 6f 6d 00 00 01 00 01
........ .....2.e
nd.com.. ....2.sa
ve.com.. ...
The i.d. and qdcount should be 2, recursion desired, and the domains shown are correct. Wireshark is saying that it is a malformed DNS packet. Any idea what is wrong with the packet?
OK, so:
If you're doing the transport-layer networking yourself, your code will determine whether it's going over UDP or TCP, by specifying, when creating the socket on which to send the packet, whether it's a UDP or TCP socket;
TCP is used if the packet won't fit in a maximum-sized UDP packet;
if you're sending it over TCP, you need to precede it with a header, as per section 4.2.2 "TCP usage" in RFC 1035.
"Maximum-sized" is a bit vague. RFC 791, the IPv4 specification, says, in section 3.1 "Internet Header Format":
Total Length: 16 bits
Total Length is the length of the datagram, measured in octets,
including internet header and data. This field allows the length of
a datagram to be up to 65,535 octets. Such long datagrams are
impractical for most hosts and networks. All hosts must be prepared
to accept datagrams of up to 576 octets (whether they arrive whole
or in fragments). It is recommended that hosts only send datagrams
larger than 576 octets if they have assurance that the destination
is prepared to accept the larger datagrams.
The number 576 is selected to allow a reasonable sized data block to
be transmitted in addition to the required header information. For
example, this size allows a data block of 512 octets plus 64 header
octets to fit in a datagram. The maximal internet header is 60
octets, and a typical internet header is 20 octets, allowing a
margin for headers of higher level protocols.
However, these days, the old networking hardware that would impose a maximum packet size limit as low as 576 bytes is mostly if not completely gone, and the real-world "maximum packet size" would generally be the Ethernet packet size - a total length of 1518 bytes, with 14 bytes of Ethernet header and 4 bytes of FCS, leaving 1500 bytes of payload. For UDP, with a typical IPv4 header length of 20 bytes and a UDP header length of 8 bytes, that's 1472 bytes of data, so it's probably good enough to use TCP rather than UDP for DNS messages larger than 1472 bytes (IP fragmentation and reassembly will happen if any hop in the network route can't handle a 1500-byte IPv4 packet; that does increase the chances of the packet not getting through, as, if one fragment gets through but the other doesn't, the entire packet doesn't get through).
I have the following 2 TCP packets I'm picking up on winpcap:
http://pastebin.com/FUAs3UZ7
or in a pcap format https://www.dropbox.com/s/0ss4j0weszy92no/SO.pcap
Those 2 packets are to be reassembled, but their IP flags are "010", meaning "Don't Fragment", and the fragment offset is on 0. They do have a consecutive identification number, but if I understand correctly this alone is not enough to define a fragmented packet.
Wireshark does reassemble those packets, and I can't really understand why.
What am I missing here? How does Wireshark know to reassemble those 2 packets?
First packet:
00 80 f4 09 e6 a5 - Ethernet destination address
00 50 56 26 ab 04 - Ethernet source address
08 00 - Ethernet type, which is IPv4
45 - IP version (4, for IPv4) and header length (5, for 5*4 = 20 bytes)
00 - DSCP/ECN (or TOS, in the old days)
02 40 - total length (576 bytes)
74 ff - identification
40 00 - flags and fragment offset; DF, and a fragment offset of 0
80 - time to live
06 - protocol, which is TCP
When you say "Wireshark does reassemble those packets", are you referring to IP reassembly or TCP reassembly? Those take place at different layers, and I suspect what Wireshark is doing is reassembling all or part of the TCP segment in the first packet and the TCP segment in the second packet to make a packet for the protocol running on top of TCP; TCP is a byte-stream protocol, so there is no guarantee that TCP segment boundaries (which turn into link-layer frame boundaries in almost all cases) correspond to packet boundaries for protocols running on top of TCP.
how can i build the serialforwarder or use it to forward the received data to another program to make some process?
how to parse the data and use it as input data to another program such as Matlab or c# or java application.
which protocol used to parse the recieved data ?
last question: it is just for motes which is base station mote ? can i build one for any mote ?
You have to read thoroughly the serial stack...its not very easy but its do able.
You can directly read from serial port. You don't need serial forwarder in this case. There are few things to take care of.
For example if you want to read a serial message that is being send to serial port of your PC (usb sensorboards just work like serial, since they are using usb to serial converters lik FTDI chip).
in C# (same for Java, etc...) you can read byte streams that are coming in the serial port. You can parse this byte streams to extract a standard serial message of tinyos.
This is somehow explained in TEP #113 although it has some problems, but you should be able to find those problems and make your program work.
As it stated in TEP 113, a standard serial packet is something like:
7e 40 09 00 be ef 05 7d 5d 06 01 02 03 04 05 7e
That means, a packet starts with hex 7E ( I believe its 126 or 127) and ends also with 7E. The last 2 bytes are CRC of the packet. So you can in your c# program start reading from serial port when you encounter 7E and stop reading when you reach the next 7E in the stream. Everything in between will be your packet.
You have to be careful of escaping that is if a 7E is part of your packet content, to be not be confused with start and end dilimeters, it will be escaped to something else...that's also is explained in that TEP 113.
I believe there were some C++ code fro calculating the CRC that you can easily convert it to C# or Java code.
Also check the source code of Serial.h which contains some details about how a serial packet is being formed in TinyOS.
I'm currently working on a project in which I use antennas such xbee XBee 2mW Wire Antenna - Series 2 (ZigBee Mesh).
how can I get my antenna64bit address so I can set it up using my software automatically?
Can I send zigbee message to antenna so that it returns a message that contains it`s antenna address, then I decode the message and know the address of my antenna.
thanks.
If you want an easy way of doing this, you can send one message from the Router/End-Device to the Coordinator in your ZigBee network. You can use the special 16-bit Network Address 0x0000 to address the Coordinator.
This message should contain the 16-bit Network Address (or the 64-bit Address), so later the Coordinator can use this address in order to communicate back with this node. That is how you can do if you work with AT Mode. If you work with API Mode, the "Receive Packet" already contains the address of the sender, so you do not need to explicitely add it to your message.
When you press one time the commission button: the module sends a node identification broadcast transmission.
Thus, I assume you are using the API mode, so from your Coordinator API (software side) you can send a Remote AT Command Request, in broadcast, which set the CB (commission button) to 1. This is the same of press the commission button virtually at one time. Here is the packet:
7E 00 10 17 00 00 00 00 00 00 00 FF FF FF FE 00 43 42 01 67
Then, when all your devices receive this packet, they should answer to the coordinator with a Node Identification Indicator, which contains their 16-bit and 64-bit address. This way, you can automatically set up your network on software.