I am coding a very simple DHCP client in C. I have trouble deciding whether it should use UDP or TCP, what basic commands should it support. I think it should be able to get at least DNS, SMTP, POP3 server information from server.
What else do I need to know? Is there a basic DHCP C implementation available which can help?
You shouldn't have trouble "deciding" whether to use TCP or UDP, you should rely on the actual DHCP spec to determine what protocol is used. In fact, reliance on that spec will be more or less critical to implementing a DHCP client that does what it's supposed to do... since "what it's supposed to do" is defined in the spec.
Related
I'm building a LoRa network where the server and the end-device need to communicate using a protocol which normally transmits data via UDP. Due to the fact that these two protocols act totally different I need to find a way to combine those two.
One solution I found is to create my own socket API which provides send, receive, bind, ... functions. But here I'm actually struggling.
In which scope do I need to write my socket? Is it enough to just edit the functions and rely on the other given parameters such as the address families? Or must I define my own AF and if so where/how is this achieved.
I'm looking forward to your answers / ideas.
According to the LoRaWAN specification and my limited experience, LoRaWAN is not suitable for such situation. If you still wanna use UDP packets over LoRaWAN, here are some tips for your question.
In which scope do I need to write my socket?
You may use sendUnconfirm function since this function does not need ACK from gateway. And port in LoRaWAN could play the role of bind in UDP socket.
Is it enough to just edit the functions and rely on the other given
parameters such as the address families?
LoRaWAN server has its own features and structure. Usually, a LoRaWAN server is consist of packet_forwarder, LoRaWAN server and LoRaWAN application server. You may use these features to build you own application on LoRaWAN applicaiton server. It could save your a lot of time.
It is highly recommended to read LoRaWAN specification (Get it here) and TTN LoRaWAN wiki to help you get a better understanding in LoRaWAN.
i am writing a peer-to-peer chat application in C and would like to extend it using TOR as transport medium. Since i have never used TOR before and i roughly know how it works; i have no idea how to achieve that.
By all means, both clients are listening for connection requests on a specific TCP port (defined by user). What do i have to do, so that e.g Client A connects to Client B (assuming both have TOR client installed)? Due to some research i found out that i have to connect to localhost:9050 where the TOR client is listening and then i think i have to craft a SOCKS4/5 pdu to connect to the proxy??
If that's right, could someone explain me this in detail? Furthermore are there any libs i can use for connecting to a socks proxy (for C, OS: GNU/Linux, BSD)?
Thanks in advance!
so, this is about at the limits of my technical understanding, so please be kind about any gross errors.
There are lots of articles on the web about how to give UDP some of the various great features of TCP. I have the opposite question: how much of TCP can be stripped away or deactivated to make it act like UDP?
This line of thought came from reading about how you can turn off Nagle's algorithm. I thought, gee, what else could you turn off?
For instance, can you turn off the requirement for guaranteed packet ordering?
Can you turn off the requirement for back-and-forth communication to verify a connection?
Would it make TCP act more like UDP if you only ever sent really small discrete packets and did all the ordering/reordering stuff yourself on the other end?
A reason one might want to do this is to simulate UDP over mobile networks, which tend to only reliably support TCP.
Any help or suggestions greatly appreciated.
For instance, can you turn off the requirement for guaranteed packet ordering?
No. It is possible to set the counter up. Than is not each packet confirmed but a paket loose will also be detected.
Can you turn off the requirement for back-and-forth communication to verify a connection?
You can set the time up to 2 minutes but not higher.
Would it make TCP act more like UDP if you only ever sent really small discrete packets and did all the ordering/reordering stuff yourself on the other end?
If you use for each message a new connection you will have a lord of overhead.
But all this operation are deep in the IP/TCP stack and not easy to configure.
A reason one might want to do this is to simulate UDP over mobile networks, which tend to only reliably support TCP.
You can use a VPN. So you have a TCP connection over the air and a UDP connection to your server but you will have the same latency.
Wireless connection are know about the packet lost. It is not a realy good idea to use UDP and mobile phone networks lose much more then wlan.
I believe that my question is:
Is there a simple user-mode TCP stack on PC operating systems that could be used to exchange data over a lossy serial link with a Linux-based device?
Here is more context:
I have a Linux-based device connected via a serial link to a PC. The serial link is lossy so data being sent between the two devices sometimes needs to be retransmitted. Currently the system uses a custom protocol that includes framing, addressing (for routing to different processes within the Linux device), and a not-so-robust retransmission algorithm.
On the Linux device side, it would be convenient to replace the custom protocol, implement SLIP over the serial link and use TCP for all communications. The problem is that on the PC-side, we're not sure how to use the host's TCP stack without pulling in general IP routing that we don't need. If there were a user-mode TCP stack available, it seems like I could integrate that in the PC app. The only TCP stacks that I've found so far are for microcontrollers. They could be ported, but it would be nice if there were something more ready-to-go. Or is there some special way to use the OS's built in TCP stack without needing administrative privileges or risking IP address conflicts with the real Ethernet interfaces.
Lastly, just to keep the solution focused on TCP, yes, there are other solutions to this problem such as using HDLC or just fixing our custom protocol. However, we wanted to explore the TCP route further in case it was an option.
It appears that the comments have already answered your question, but perhaps to clarify; No you can not use TCP without using IP. TCP is built on top of IP, and it isn't going to work any other way.
PPP is a good way of establishing an IP connection over a serial link, but if you do not have administrative access on both sides of the computer this could be difficult. 172.16.x, 10.x, and 192.168.x are defined as being open for local networks, so you should be able to find a set of IP addresses that does not interfere with the network operation of the local computer.
From the point of view of no configuration, no dependencies, comping up with your own framing / re-transmit protocol should not be too hard, and is probably your best choice if you don't need inter-operability. That being said kermit, {z,y,z}modem would provide both better performance and a standard to code against.
Lastly, you may be able to use something like socat to do protocol translation. I.e. connect a serial stream to a TCP port. That wouldn't address data reliability / re-transmission, but it may be the interface you are looking to program against.
my computer's IP is 192.168.1.101 over eth0.
I want to know what are other active/used IP under 192.168.1.*
I am expecting a list of IP address that is ping-able under 192.168.1.*
How can I do that in C? And preferably in linux platform.
Any C functions available?
There is no built-in function in C that sends ping packet. There is, however, function that just sends packet. There is also a lot of code in the internet that already implements ping.
What you have to do is just take one of them (this for example) and ping in a loop for all addresses in your network.
You should know, however, that ping is not a reliable way of saying which addresses are in use. RFC 792 - Internet Control Message Protocol says:
The Internet Protocol is not designed
to be absolutely reliable. The purpose
of these control messages is to
provide feedback about problems in the
communication environment, not to make
IP reliable. There are still no guarantees that a datagram will be
delivered or a control message will
be returned. Some datagrams may still
be undelivered without any report
of their loss.
which means that any message can be easily lost, with no notification. Furthermore, target does not have to respond.