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.
Related
if I malfunctioned my computer TCP stack in kernel just commenting out single important line of code or compiling with excluding TCP stack and install. Then What are the steps in I need to take in coding. Do I need to Implement Ethernet (if creates layer 2 Socket in my stack implementation) then do I need to implement IP because that comes with if I am using layer 2 socket then implement TCP (this is what final code will be)
If that's so
Then what are the supported protocols I need to implement to cover ethernet layer, Ip layer and (TCP layer -- that I can know I may have used it in code)
Can anyone please tell the machining protocols with each layer
whats before?-->ethernet --> ip -- tcp --> http <--protocol names please that may be needed
the whole thing is just for as a research thing or learning for my self or just may be programming
I'll assume you want to be able to do something like request https://example.com from a web server.
For this the following procotols are diretly necessary:
HTTPS (i.e. HTTP and TLS), but that's usually already implemented in user space, no change here
DNS to resolve example.com to an IP address. Usually implemented in user space as well, based on UDP
UDP to run DNS on top of. Usually implemented in the kernel on top of IP.
TCP to run HTTPS on top of. Usually implemented in the kernel on top of IP.
IP to run both TCP and UDP on top of. Usually implemented in the kernel on top of Ethernet.
Ethernet to send/receive IP packages. Usually implemented in the kernel, with the help of hardware-specific NIC drivers.
But even if you had implemented those, you wouldn't be done. For example, you wouldn't know what your local IP address is.
To do this, you'd implement DHCP. You could get away without implementing this, if you just configured your IP address to a fixed value (as long as it's within the allowed range of your network and doesn't conflict with other devices, this is not a problem).
But when you try to send your first IP packet to the DNS server, you'd realize that you don't know what Ethernet address you should send that to. So you'd need to implement ARP as well. Again, you could theoretically have a static routing table and "fake" the ARP responses by your router this way, but this could be way trickier than just hard-coding the IP adress.
I may have missed some protocol (and I'm sure comments will pop up, if I did), but that should be roughly everything that you'd need to get going.
I want to be able to simulate an incoming packet on a certain physical network interface.
Specifically, given an array of bytes and an interface name, I want to be able to make that interface think a packet containing those bytes arrived from another interface (most likely on another machine).
I've implemented the code that prepares the packet, but I'm unsure what the next step is.
I should point out that I actually need to feed the interface with my bytes, and not use a workaround that might produce a similar results in other machines (I've seen answers to other questions mentioning the loopback interface and external tools). This code is supposed to simulate traffic on a machine that's expecting to receive traffic from certain sources via specific interfaces. Anything else will be ignored by the machine.
I'm going to stick my neck out and say this is not possible without kernel modifications, and possibly driver modifications. Note that:
There are plenty of ways of generating egress packets through a particular interface, including libpcap. But you want to generate ingress packets.
There are plenty of ways of generating ingress packets that are not through a physical interface - this is what tap/tun devices are for.
If you modify the kernel to allow direct injection of packets into a device's receive queue, that may have unexpected effects, and is still not going to be an accurate simulation of the packets arriving in hardware (e.g. they will not be constrained to the same MTU etc). Perhaps you can build an iptables extension that fools the kernel into thinking the packet came from a different interface; I'm not sure that will do what you need though.
If all you need is simulation (and you are happy with a complete simulation), build a tap/tun driver, and rename the tap interface to eth0 or similar.
Depending on which network layer you're trying to simulate, there may be a work-around.
I have had success getting ip packets into the ingress queue with an ethernet 'hairpin'. That is, by setting the source and destination MAC address to the local interface, sending the packet results in it first appearing as an egress packet, then being 'hairpinned' and also appearing as an ingress packet.
This at least works under linux using pcapplusplus (libpcap under the hood), with my wireless interface. Your millage may vary.
This will obviously only suit your needs if you're OK with modifying the ethernet header, ie only simulating a higher layer.
Here is a snippet of c++ where I spoof a rst tcp packet for a local socket:
//always use the actual device source MAC, even if we're spoofing the remote rst
// this produces a 'hairpin' from the egress to the ingress on the interface so the tcp stack actually processes the packet
// required because the tcp stack doesn't process egress packets (at least on a linux wireless interface)
pcpp::EthLayer eth(localMAC,localMAC);
pcpp::IPv4Layer ip(remoteIP, localIP);
pcpp::TcpLayer tcp(remotePort, localPort);
pcpp::Packet pac(60);
ip.getIPv4Header()->timeToLive = 255;
tcp.getTcpHeader()->rstFlag = 1;
tcp.getTcpHeader()->ackFlag = 1;
tcp.getTcpHeader()->ackNumber = pcpp::hostToNet32(src.Ack);
tcp.getTcpHeader()->sequenceNumber = pcpp::hostToNet32(src.Seq);
pac.addLayer(ð);
pac.addLayer(&ip);
pac.addLayer(&tcp);
pac.computeCalculateFields();
dev->sendPacket(&pac);
EDIT: the same code works on windows on an ethernet interface. It doesn't seem to do the same 'hairpin' judging from wireshark, but the tcp stack does process the packets.
Another solution is to create a new dummy network device driver, which will have the same functionality as the loopback interface (i.e. it will be dummy). After that you can wrap up a creation of simple tcp packet and specify in the source and destination addresses the addresses of the two network devices.
It sounds a little hard but it's worth trying - you'll learn a lot for the networking and tcp/ip stack in linux.
just as title says.
Let's assume this situation:
I have a network and I need to know IP adresses and everything else related of all computers connected to mantain socket sending via Winsock under Windows.
Is there better way than looping throught IP Adresses range and sending something like:
"Are You there?" and waiting for answer from client?
Performing an ARP scan would tell you which devices are active on the network, regardless of device type or operating system. So this would include PCs, laptops, phones, routers, and any other devices with a NIC. This is the most reliable way of scanning for live hosts on a network.
ARP is the protocol that translates IP addresses into MAC addresses, or vice versa. It allows routing devices to translate between the logical network and the physical network. When you send a packet to, say, 192.168.1.99, your system first sends out an ARP request for 192.168.1.99, saying something along the lines of "Who has 192.168.1.99? Tell [my MAC]". Other devices on the network see this packet, and the owner of that IP address will reply "Hi [MAC], I'm 192.168.1.99, my MAC is 00:12:34:56:78:90".
You can (ab)use this protocol to discover network devices. If you know you're on 192.168.1.x, you send ARP requests for 192.168.1.1 through 192.168.1.254, and record the results. Every reply you get indicates a live system at the defined IP address.
Keep in mind that not all your users will be on 192.168.1.0/24, so you'll need to check the current network configuration first.
As far as doing this in C goes, it's not a simple task. However, you can take a look at this example which implements ARP scanning.
An alternative to the ARP scan suggested by #Polynomial is the PING scan.
Same concept, PING each address in your subnet, and record the results.
Just as an ARP scan may give you false positives (because there is a router saying "I'll deal what that address" whether there is a device on it or not), so too, PING can give you false negatives (as some systems disable the ICMP/PING command).
There is a tool called fping that implements this kind of PING scan in a massively parallel way. Fping is originally a *NIX program, but there are Windows versions out there. You should be able to find the source to peruse if you want to learn the gory details.
I've got a little program that needs to communicate between two computers on the same LAN. I'm rather new to networking, but from what I've read it sounds like I want UDP multicasting so that the two computers can discover each other, after which I can establish a TCP connection for actual data communication. I've found this little example for UDP multicasting which I can follow. However, I'm wondering about the multicast group (HELLO_GROUP in that example, which is 225.0.0.37).
How can I know the group I should use? This program will be running on various networks, so I can't hard code one (as far as I know). Do I get the group from the router, and if so, how do I do that?
You can choose any multicast address (224.0.0.0 to 239.255.255.255) that isn't listed as reserved by IANA.
Its possible (if unlikely) that another program will also be using the same address. You can minimise the chances of this causing any confusion by making the announcement messages your program sends out suitably specific. e.g.
CORNSTALKS-DISCOVERY
HOST: {address:port}
[newline]
This would inform your recipients of the address to use for their TCP connection but should find its first line rejected by any other recipients.
You understood wrong.
What are you talking about is broadcasting. A broadcast UDP datagram is sent to every computer in the subnet. (Technically you send a datagram to the address 255.255.255.255.)
UDP broadcast work inside a specific subnet, but don't cross the subnet boundaties. That is, most of the routers are configured not to route broadcast datagrams (reduce spamming).
OTOH multicast is something completely different. The purpose of multicast is to avoid using TCP (or any other unicast) for data transmission. It's good when you need to send something to many other recipients "at once". Those machine agree preliminary on a specific multicast address (like 225.0.0.37 in your example), and "join" this multicast group. Within a specific subnet everything works pretty similar to broadcast, however in contrast to broadcast the multicast may also cross the subnet boundaries. This is due to the fact that when machines join a multicast group the appropriate routers are notified, and they are capable to route multicast datagrams appropriately.
EDIT:
Conclusion (for clarification).
In order to use a multicast one has to pick a multicast address. This is like choosing a port for the application.
The main purpose of multicast is to deliver content (transmit data) to a number of recipients. It's more efficient than unicast in this case.
A "network discovery" is usually done via broadcast. A multicast can theoretically be used for this as well, but this is like killing a fly with a cannon (because routers should also track the lifetime of the multicast session).
I would suggest you don't use multicast directly.
Rather, use zero-configuration networking. This, in its mDNS/DNS-SD incarnation, is available through Apple's Bonjour library on OS X and Windows, and Avahi on unices (and possibly on OS X and Windows too, not sure).
With DNS-SD, you define a name for your service, then use the library to advertise its availability on a given host, or to browse for hosts where it's available. This is how Macs discover printers, file shares, etc - exactly your use case, i believe. It's a simple but very effective technology. And it's an open standard with a good open source implementation, so it's not some proprietary Apple scarytime.
I am currently working on a programming assignment. The assignment is to implement a client,network emulator, and server. The client passes packets to a network emulator, and the network emulator passes to the server. Vice-versa applies as well. The prerequisite for the assignment is that I may only use raw sockets. So I will create my own IP and UDP headers. I have tested my packets with wireshark. They are all correct and in the proper format(it reads them properly).
Another requirement is that the emulator, client and server all have specific ports they must be bound to. Now, I do not understand how to bind a raw socket to a specific port. All my raw sockets receive all traffic on the host address they are bound to. According to man pages, and everywhere else on the internet, including "Unix Network Programming" by Richard Stevens, this is how they are supposed to work. My teacher has not responded to any of my emails and I probably will not be able to ask him until Tuesday.I see two options in front of me. First I can use libpcap to filter from a specific device and then output to my raw socket. I feel this is way out of scope for our assignment though. Or I can filter them after I receive them from the socket. This apparently has a lot of overhead because all the packets are being copied/moved through the kernel. At least, that is my understanding(please feel free to correct me if i'm wrong).
So my question is:
Is their an option or something I can set for this? Where the raw socket will bind to a port? Have I missed something obvious?
Thank you for your time.
--
The man page for raw(7) says:
A raw socket can be bound to a specific local address using the bind(2) call. If it isn't bound all packets with the specified IP protocol are received. In addition a RAW socket can be bound to a specific network device using SO_BINDTODEVICE; see socket(7).
Edit: You cannot bind a raw socket to a specific port because "port" is a concept in TCP and UDP, not IP. Look at the header diagrams for those three protocols and it should become obvious: you are working at a lower level, where the concept of port is not known.
I would think you're expected to filter the packets in your software. It sounds like the exercise is to learn what the different components of the IP stack do by recreating a simplified piece of it in user space. Normally in the kernel, the IP code would process all packets, verify the IP headers, reassemble fragments, and check the protocol field. If the protocol field is 17 (udp), then it passes it to the UDP code (every UDP packet). It's up to the UDP code to then validate the UDP header and determine if any applications are interested in them based on the destination port.
I imagine your project is expected to more or less mimic this process. Obviously none of it will be as efficient as doing it in the kernel, but since the assignment is to write (part of) an IP stack in user-space, I'd guess efficiency isn't the point of the exercise.