Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I wrote a c code for ping command and for some reason it doesn't receive any reply. I spent couple of days trying to find problem with the code, but later I have checked packet sending with wireshark. I found that the reply was send to me (the destination is unreachable, as it should be with destination IP I entered). In Internet I found that my firewall could cause this problem, but I didin't find any solution for it. So please help me, how can I add some kind of exeption for my firewall for the certain code? Thank you.
EDITED
The iptables output:
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Wireshark output:
17 0.641636029 192.168.0.134 192.168.0.1 ICMP 120 Destination unreachable (Port unreachable)
Also I probably made a mistake and the problem may be not in the receiving, but in sending packet
Try to check firewall using the following command iptables -L -n And provide output
Consider using some library like liboping or libping
Be aware that ping uses ICMP (see icmp(7)). Your program is likely to require root privilege. So you need to run it as root, or use setuid techniques.
Check systematically against failure every system call that you are using (see syscalls(2) for a list). Read errno(3) and use perror(3) (or strerror(errno)).
Use also strace(1) on your program to understand what system calls are done (and which one is failing).
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I was trying to make REST calls from C; came across libcurl which was successful in doing that dynamically. But the code needs to be ported on to a Cortex M0 board, which need a lower footprint. Is there any workaround? All I need is to make a REST API call from C without any external library or overhead.
Well, how low do you want to go?
C doesn't know anything about REST, it doesn't know HTTP, not even TCP or something like a network interface. On bare metal, you'd start by reading the hardware specs of your network interface card and programming it (through ports, memory mapped registers, etc....) -- You'd have to understand ARP, IP, ICMP etc (and, of course, implement it), just to get a TCP connection on top of that.
Assuming there's an operating system in place, you'll be given some API, then the answer would depend on what this API allows. A typical level would be a "socket abstraction", like BSD sockets, which gives you functionality to establish a TCP connection. So, "all" you'd have to do is implement a HTTP client on top of that.
Unfortunately, HTTP itself is a complex protocol. You'd have to implement all the requests you need, with Content-Types, transfer encodings, etc and also handle all possible server responses appropriately. These are a lot. Bring content negotiation to the table, partial responses, etc ... it's "endless" work. That's exactly the reason there are libraries like curl that already implement all of this for you.
So, sorry to say that, but there's no simple answer possible giving you what you want here. If you want to get the job done, use a library. Maybe you can find something smaller than libcurl.
What you can do is to compile the library yourself, linking it statically and using compiler options like gcc's -ffunction-sections -fdata-sections and the linker option --gc-sections in an attempt to drop code from the library you don't use, this might help to reduce size.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have some doubt when taking D-bus IPC into my client program.
In my opinion, D-bus has its own way to manage the low-level socket.
The socket fd is packed into a 'DBusConnection', and then be used to communicate with daemon, write/read/dispatch/loop. That's ok.
But if the client needs to directly monitor/select another socket, such as monitor a tcp port, using its own way sometimes.
Is D-bus fit for this situation ? How could I select the two sockets at the time when using with D-bus ?
Is D-bus designed to communicate with other local processes only via 'DBusConnection' connecting with daemon ?
I just start to use D-bus, and really confused.
Any help will be appreciated ~
Sorry I did not present it clearly.
I'll take with an example to detail it.
Some guys familiar with D-bus may have looked up the source code of 'dbus-monitor', one tool attached to D-bus.
'dbus-monitor' uses 'dbus_bus_get' to create a connection with daemon,
and then call 'dbus_connection_get_object_path_data' to tell dameon which objects it support, and so forth( sth not cared here ),
finally, '_dbus_loop_run' for main loop.
With curiosity, I have done some diving work about the implementations of these D-bus APIs. ( It's not enough obviously. )
From my point of view, same with the usual IPC logic, the essential work of these steps looks like (May be it's not quite sure.) : open a local socket, connect to the server(daemon), read/write/select (the server uses epoll) socket fd.
Ok, thanks for your patience. fine~
In order to communicate with daemon, D-bus creates a socket and uses its own way(API) to manipulate the socket. ( the socket fd is encapsulated into
D-bus's connection structure -- 'DBusConnection', we can NOT directly operate it. )
Now my question is if I need D-bus to create a 'DBusConnection' (encapsulate a local socket fd) to talk to the daemon, like 'dbus-monitor'.
And at the same time, my client application also needs to create another socket fd to monitor a tcp port.
I wonder whether there is a way to simultaneously 'select' these two kind of socket fd? ( one encapsulated in D-bus's connection structure
which can NOT be select explicitly, another is a general socket fd. )
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I am experimenting reading (and eventually writing) serial ports in C. I want to be able to connect to a port on debian and read in some data but I need a port that is writing (speaking). I am new to linux programming.
What port, that will definitely be present and talking in debian, can I connect to to read some data in?
Can you also suggest a port I can eventually use to write to aswell?
I've tried connecting to /dev/ttyUSB1 that this example uses but that port doesn't exist.
I would suggest either open /dev/random (or /dev/urandom) as Paul suggests or create your own socket and read/write to that. Don't just pick an arbitrary socket and hope it has information that no other process needed.
If this is your first time working with sockets I would also suggest that you try playing around with things in a language like python simply because you don't need to recompile to see where you went wrong and the warnings are often more readable (take a look at https://docs.python.org/2/howto/sockets.html)
As a side note: If you have access to an arduino you might like to try connecting to that socket (usually something like ser = serial.Serial('/dev/ttyACM0', 9600) in python).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've been dying to implement a chat server in C and Winsock for a long time now, but I haven't taken the time. Partly, because I'm still unsure of some of the conceptual ideas about building a server on Windows OS'es for something like chat.
Here are some of the issues I've been thinking about :
How will user x connect to my server over a generic LAN
without me relying on them to type in a network address( e.g. address
could be invalid, redirected to a different server, etc. )
If I use broadcasting to solve the above problem, will that be reliable enough for chat?
Will that potentially DDos a LAN since the packets will be be forcibly handled on every machine and may take a lot of bandwidth if enough people join?
What is the difference between multicasting and broadcasting? Is multicasting truly superior?
Etc.
Per request, my definition of reliability would be that I can get most of the data consistently in sent packets. In other words, I don't mind a few dropped packets, but I do mind if the data gets messed up quite a lot along the way.
Currently, I have a lot more questions than answers, but the main point I'm getting at is this :
What is the safest and most reliable way of implementing a chat over a LAN in C and Winsock?
How will user x connect to my server over a generic LAN without me relying
on them to type in a network address( e.g. address could be
invalid, redirected to a different server, etc. )
Use a closed list of known servers, or use some broadcast based autodiscovery system.
If I use broadcasting to solve the above problem, will that be reliable
enough for chat?
Define your requirements for reliability.
Will that potentially DDos a LAN since the packets will be be forcibly
handled on every machine and may take a lot of bandwidth if enough
people join?
It's a chat... the amount of generated packets will be comparatively short and small.
What is the difference between multicasting and broadcasting? Is
multicasting truly superior?
Search the web. There are lots of resources and information about multicasting, most precisely, IP multicasting. In short:
Broadcast delivers to all hosts on a broadcast domain. Multicast delivers to all hosts that have explicity joined a multicast group, which may not be in the same broadcast domain (see last point).
Broadcast forces a switch to forward broadcast packets to all its interfaces. Intelligent switches can benefit from peeking at IGMP packets to know which interfaces multicast packets have to be forwarded to.
Broadcast cannot treepass a broadcast domain. Multicast packets can traverse a router, if it's configured to route multicast (search for M-bone)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
In my code for telnet client, I want to echo always. So I will send wont echo to the server.
Linux machines obey the command, but windows machines suppress the wont command and send do echo command instead [confirmed from wireshark and GDB].
What could be the possible reason?
If I understand correctly, WILL and WONT indicate the "local" state. If you want the other party to switch to another mode, you have to send a DO or DONT command.
So, I guess you have to sent a "WILL ECHO", and "DONT ECHO" (meaning: I will perform the echo, so you don't have to echo).
Maybe this document will help:
The Q Method of Implementing TELNET Option Negotiation: https://www.rfc-editor.org/rfc/rfc1143
In my code for telnet client, I want to echo always. So I will send wont echo to the server.
That's wrong for a start. If you will echo, you need to send DONT echo. WILL/WONT is a response, not a request. And in any case if you want to echo why would you say you won't? It doesn't make sense.
Linux machines obey the command
It's not a command, it's a request. The server is free to agree or disagree. If the server disagrees it will send you the opposite WILL/WONT response. If it agrees it will send you an agreeing WILL/WONT response.
but windows machines suppress the wont command and send do echo command instead [confirmed from wireshark and GDB].
That's what you want! You want to echo, and it is telling you to echo. You got it wrong in the protocol but the end result is exactly as you wished.
Note: to avoid loops, if the peer had already sent a WILL/WONT response before you sent your DO/DONT, it won't send you the same message after it receives yours, if it now agrees with you. This can happen when either side initially disagrees. Again see the Telnet RFCs. You particularly need to read the one about how to implement this feature ('Q method').