Recently I've been working on raw ethernet support in embedded system. Mostly for educational purposes and know-how. Using some data found on google i was able to implement ARP support, and separate UDP/TCP transport layer support.
Unfortunately, I have a problem with supporting them both (UDP/TCP) at the same time. Basically i cannot recognize incoming frame protocol, therefore cannot decide if send it to UDP or TCP handler. Cannot send it to both without risk of getting malformed data.
I expected some bitfield denoting that information, but cannot find it.
I am looking for this information for several days but cannot find any source, propably because i am missunderstanding something.
Can i ask some more experienced IT for help by explaining subject/hinting where to look? I feel like i am in dead end.
Thank You in advance.
TCP/UDP shouldn't be directly embedded into an Ethernet frame.
A TCP segment should be inside an IP packet with Type = 6, and the IP packet should be inside the Ethernet Frame with EtherType= 0x800 (for IPv4):
Ethernet EtherType=0x800 (IPv4)
+----------------------------------+
| IP Type=6 (TCP) |
| +-------------------------+ |
| | | |
| | +---------------+ | |
| | | TCP | | |
| | | | | |
| | +---------------+ | |
| | | |
| +-------------------------+ |
| |
+----------------------------------+
For UDP, it's the same, only the IP type is 17 instead of 6.
Related
I have a TCP server that listens for an incoming client, then sends it one packet of data every second. I was wondering, does the SYN/ACK packet only get sent on initial connection, so it looks like this:
<client connect>
SYN
ACK
DATA
DATA
DATA
<client disconnect>
Or does it get sent with every packet, like this?
<client connect>
SYN
ACK
DATA
SYN
ACK
DATA
SYN
ACK
DATA
<client disconnect>
Also, if it's the first case, are there any benefits of UDP over TCP if you just keep the connection open over a long period of time?
It's kinda like:
+-------------------------------------------------------+
| client network server |
+-----------------+ +--------------------|
| (connect) | ---- SYN ----> | |
| | <-- SYN,ACK -- | (accepted) |
| (connected) | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
when client sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| (send) | ---- data ---> | |
| | <---- ACK ---- | (data received) |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
when server sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| | <--- data ---- | (send) |
| (data received) | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
...and so on, til the connection is shut down or reset
SYN starts a connection; you'll usually only see it when the connection's being established. But all data being sent via TCP requires an ACK. Every byte sent must be accounted for, or it will be retransmitted (or the connection reset (closed), in severe cases).
Actual connections aren't usually exactly like the diagram above, though, for two reasons:
ACKs can build up, so one ACK can acknowledge everything received up to that point. That means you can acknowledge two or more sends with one ACK.
An ACK is simply a flag and field in a TCP header. Sending one requires at least a header's worth of bandwidth, plus whatever the lower layers tack on. But data segments already include all that...so if you're sending data, you can send an ACK at the same time for free.
Most TCP/IP stacks try to reduce the number of naked ACKs without unduly risking retransmission or a connection reset. So a conversation like this one is quite possible:
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| | <--- data ---- | (send) |
| (data received) | | |
| (send) | -- data,ACK -> | |
| | | (data received) |
| | <- data,ACK -- | (send) |
| (data received) | | |
| (wait a bit) | <--- data ---- | (send) |
| (data received) | | |
| (send) | -- data,ACK -> | |
| | | (data received) |
| (send) | ---- data ---> | (wait a bit) |
| | | (data received) |
| | <- data,ACK -- | (send) |
| (data received) | | |
| (wait a bit) | (dead air) | |
| | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
As for UDP, there's no built-in concept of SYN and ACK -- UDP is by nature "unreliable", and not connection-oriented, so the concepts don't apply as much. Your acknowledgement will usually just be the server's response. But some application-layer protocols built on top of UDP will have some protocol-specific way of acknowledging data sent and received.
SYN is only at the beginning.
ACK is on subsequent segments in either direction. The ACK will also define a window size. If the window size is 100 for example, the sender can send 100 segments before it expects to receive an ACK. E.g If sender sends 100 segments but segment number 50 gets lost, then receiver will get 1-49 & 51 -100. Receiver will then ACK for 50 (next segment it expects) and set window size to 1. Sender will resend 1 segment with sequence number 50. Receiver will then ACK for 101 and set the window size back up to a higher number.
Both are actually fields in the TCP header and can be sent with data, though the SYN and the first ACK typically are data-less.
So neither of the scenarios you describe is quite correct. The first is actually closer to reality, but all the data packets after the SYN do have to include an ACK, and also an acknowledgement number field which identifies the number of the next packet expected.
The end of a session also involves handshakes with FIN flagged packets and ACKs relating to them.
The exchanged sequence numbers are used to identify lost packets and enable a retry mechanism, and also to reassemble the entire stream of packets in the correct order.
Also, if it's the first case, are there any benefits of UDP over TCP if you just keep the connection open over a long period of time?
With UDP you can't just keep the connection open over a long period of time. There is no connection.
This sequence of SYN/ACK/FIN flags is what makes a connection.
With UDP, there are no SYNs or ACKs, so communication is one-way, delivery is not guaranteed and order is not preserved. But it has less overhead, so it's useful when speed is more important than reliability, as for example in streaming media.
This is a bit simplified yet, but it's the best I can do at the moment.
There's much more on this in the wikipedia entry on TCP and of course in the RFCs.
Picture this:
The original TCP standard RFC 793 allowed data to be sent with the first SYN packet though. However, that's not the case today. What you get is a separate SYN packet during initiation of the Three-Way-Handshake from the requestor of the connection. Suppose A requests to connect with B, thus A sends a packet with a SYN bit set. B responds with an ACK to acknowledge receipt and sends A the ACK + SYN packets. Data can then be transmitted henceforth.
Dordal has a very good explanation on this matter. Click this link here.
RFC1323 defines the TCP timestamp option. It does not define a limit on the number of options you can have present.
Would a firewall drop a packet that has more than one TCP timestamp option header present?
Would a router drop a packet with more than one TCP timestamp?
e.g.
TCP Header | Timestamp option | Timestamp option | NOP | EOL
The system that I am attempting to set up consists of several PLCs hooked up via Ethernet to a Raspberry Pi. The Pi is then connected to Hamachi VPN (I use hamachi because we do not have and external ip to use for other VPN solutions. If there is another alternative I an open to trying). On the other end there is a PC connected to the Hamachi network. I need to be able to talk (ping and connect) with the PLCs hooked to the Pi. I have been able to use iptables to get the PC to talk to one PLC but not through its own ip but buy pointing the software at the hamachi ip. I can get it to the point of pinging the PC from the PLC using iptables but not the other way around. My endgame is to be able to access the PLC from the PC using the PLC's ip over hamachi vpn. Any ideas or direction?
------------- ------------- -----------
| PLC |_____(eth0)___| RasPi |____(ham0)____| PC |
| | (eventually | | | |
------------- will have ------------- -----------
switch here) | (eth1) |
| |
------------__________________|
| Internet |
------------
You could try installing OpenWRT on your pi, then attempt to configure it to do some NAPT routing where it picks a specific PLC to communicate with based on the port number that the pi was accessed with. I'm not sure you can use a hamachi VPN to connect using a manually configured port number, but you could certainly do that with a regular TCP connection.
Also, it might be worth looking at some of the answers in this post:
https://raspberrypi.stackexchange.com/questions/243/is-it-possible-to-set-up-a-raspberry-pi-as-a-wireless-router
Instead of installing OpenWRT, you can just implement a few routing features that suit your needs.
Hamachi
Ok guys, latest working version is 2.1.0.8.6, newer versions will get you segmentation fault errors.
I uploaded it for you, it is a debfile
http://ul.to/ppisqm61
Instead of install.sh I used the following, install.sh might also work but that's the way I did it:
sudo dpkg -i --force-depends --force-architecture logmein-hamachi_2.1.0.86-1_armel.deb
Is it possible to test an TCP stack using TUN / TAP interfaces ?
I'm thinking of a mechanism like this:
+--------------------------------+
| TCP Client / Server |
| socket(AF_INET, SOCK_STREAM) |
| e.g. HTTP Server / Client |
+----------+---------------------+
|
| +---------------------+
| | TUN Device |
| | ( kernel does TCP ) |
| +---------------------+
|
+------------+----------------------+
| Linux Kernel + Forwarding Magic |
+-----------------------------------+
|
| +---------------------+
| |TAP Device |
| |Raw ethernet frames |
| +---------------------+
|
+----------+----------------------+
| Raw Socket API |
| socket(AF_PACKET, SOCK_RAW) |
| User mode TCP Stack over raw API|
| a HTTP client/server over it |
+---------------------------------+
The top box, is (say) a standard unmodified HTTP server, listening on a IP address,
which has been routed to the TUN device.
The bottom box is a custom TCP/IP stack, which works on the raw ethernet frames.
Questions:
Is it possible to connect two TAP/TUN devices back to back like this
?
Is 'bridge' needed here ? How else they talk
back-to-back ?
And finally : Is there a better way to do this ?
Thanx in advance.
PS: I'm going to run all of them on same machine. The 'Box' are more like process or set or processes here.
I'm not sure if this is a reasonable design. It depends on what you are trying to achieve, exactly.
You can certainly send the traffic into a TUN device on the top box... but then you have to have some kind of process that runs on that box to collect the traffic coming through the TUN device. That process could be your actual custom TCP/IP stack, or it could be something that tunnels the packets to your bottom box. I assume you'd want it to be a tunnel since you want to run your custom TCP/IP stack on a different machine (the bottom box). In that case you might even find it advantageous for the tunnel software in question on the top box to be something that already exists, like OpenVPN.
However, my guess is that your needs are more likely to be served by running a standard TCP/IP stack with no tunnels on the top box, and having the bottom box act as a router that routes packets between a real ethernet interface (where the packets arrive from the top box) and a TUN device. And at the userspace end of the TUN device sits your custom TCP/IP stack.
In neither case would you need to use any raw sockets or indeed any sockets at all. Either way, your custom TCP/IP stacks receives frames out of the TUN device (possible tunnelled from tophost, possibly directly on bottomhost) and injects the frames it originates back into the same TUN device.
I have a TCP server that listens for an incoming client, then sends it one packet of data every second. I was wondering, does the SYN/ACK packet only get sent on initial connection, so it looks like this:
<client connect>
SYN
ACK
DATA
DATA
DATA
<client disconnect>
Or does it get sent with every packet, like this?
<client connect>
SYN
ACK
DATA
SYN
ACK
DATA
SYN
ACK
DATA
<client disconnect>
Also, if it's the first case, are there any benefits of UDP over TCP if you just keep the connection open over a long period of time?
It's kinda like:
+-------------------------------------------------------+
| client network server |
+-----------------+ +--------------------|
| (connect) | ---- SYN ----> | |
| | <-- SYN,ACK -- | (accepted) |
| (connected) | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
when client sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| (send) | ---- data ---> | |
| | <---- ACK ---- | (data received) |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
when server sends...
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| | <--- data ---- | (send) |
| (data received) | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
...and so on, til the connection is shut down or reset
SYN starts a connection; you'll usually only see it when the connection's being established. But all data being sent via TCP requires an ACK. Every byte sent must be accounted for, or it will be retransmitted (or the connection reset (closed), in severe cases).
Actual connections aren't usually exactly like the diagram above, though, for two reasons:
ACKs can build up, so one ACK can acknowledge everything received up to that point. That means you can acknowledge two or more sends with one ACK.
An ACK is simply a flag and field in a TCP header. Sending one requires at least a header's worth of bandwidth, plus whatever the lower layers tack on. But data segments already include all that...so if you're sending data, you can send an ACK at the same time for free.
Most TCP/IP stacks try to reduce the number of naked ACKs without unduly risking retransmission or a connection reset. So a conversation like this one is quite possible:
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
| | | |
| | <--- data ---- | (send) |
| (data received) | | |
| (send) | -- data,ACK -> | |
| | | (data received) |
| | <- data,ACK -- | (send) |
| (data received) | | |
| (wait a bit) | <--- data ---- | (send) |
| (data received) | | |
| (send) | -- data,ACK -> | |
| | | (data received) |
| (send) | ---- data ---> | (wait a bit) |
| | | (data received) |
| | <- data,ACK -- | (send) |
| (data received) | | |
| (wait a bit) | (dead air) | |
| | ---- ACK ----> | |
\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/
As for UDP, there's no built-in concept of SYN and ACK -- UDP is by nature "unreliable", and not connection-oriented, so the concepts don't apply as much. Your acknowledgement will usually just be the server's response. But some application-layer protocols built on top of UDP will have some protocol-specific way of acknowledging data sent and received.
SYN is only at the beginning.
ACK is on subsequent segments in either direction. The ACK will also define a window size. If the window size is 100 for example, the sender can send 100 segments before it expects to receive an ACK. E.g If sender sends 100 segments but segment number 50 gets lost, then receiver will get 1-49 & 51 -100. Receiver will then ACK for 50 (next segment it expects) and set window size to 1. Sender will resend 1 segment with sequence number 50. Receiver will then ACK for 101 and set the window size back up to a higher number.
Both are actually fields in the TCP header and can be sent with data, though the SYN and the first ACK typically are data-less.
So neither of the scenarios you describe is quite correct. The first is actually closer to reality, but all the data packets after the SYN do have to include an ACK, and also an acknowledgement number field which identifies the number of the next packet expected.
The end of a session also involves handshakes with FIN flagged packets and ACKs relating to them.
The exchanged sequence numbers are used to identify lost packets and enable a retry mechanism, and also to reassemble the entire stream of packets in the correct order.
Also, if it's the first case, are there any benefits of UDP over TCP if you just keep the connection open over a long period of time?
With UDP you can't just keep the connection open over a long period of time. There is no connection.
This sequence of SYN/ACK/FIN flags is what makes a connection.
With UDP, there are no SYNs or ACKs, so communication is one-way, delivery is not guaranteed and order is not preserved. But it has less overhead, so it's useful when speed is more important than reliability, as for example in streaming media.
This is a bit simplified yet, but it's the best I can do at the moment.
There's much more on this in the wikipedia entry on TCP and of course in the RFCs.
Picture this:
The original TCP standard RFC 793 allowed data to be sent with the first SYN packet though. However, that's not the case today. What you get is a separate SYN packet during initiation of the Three-Way-Handshake from the requestor of the connection. Suppose A requests to connect with B, thus A sends a packet with a SYN bit set. B responds with an ACK to acknowledge receipt and sends A the ACK + SYN packets. Data can then be transmitted henceforth.
Dordal has a very good explanation on this matter. Click this link here.