I'm working on an embedded linux system in C, I'm looking for the source code to the equivalet of SendARP in Windows. Any pointers?
Take a look at arping. The quick and dirty way of sending an arp would be to do:
foo = system("/somepath/arping somehost");
But a look through the arping source should be able to give you a better solution.
For the all-out solution though, you can construct your own by hand and use either a raw socket or libpcap to send it.
btw. If all you're trying to do is force an arp to be sent (but necessarily from you) you could achieve that by deleting any arp entry that you already have for your host. The next access to that address will require an arp to be sent.
eg. /usr/sbin/arp -d destination_host_ip
This may be of interest: http://cvs.linux-ha.org/viewcvs/viewcvs.cgi/linux-ha/resources/heartbeat/SendArp.in?rev=1.4
It is an implmenetation in a Bourne Shell script.
I've never seen anything specifically for ARP, but I think you can send any kind of packet you want using libpcap and the appropriate RFCs.
Related
We used the library SimplePing, but multiple challenges of our network scanner sometimes some devices were not found. ie This scanner does not work reliably.
Prompt another library or a more reliable algorithm for IOS?
Perhaps I need to write a ping using sockets:
socket(AF_INET,SOCK_DGRAM,IPPROTO_ICMP)
But what further code?
You can see the implementation of ping utility in FreeBSD source code: https://svnweb.freebsd.org/base/release/10.1.0/sbin/ping/ping.c?view=markup
Don't be afraid to read source codes of existing implementations for any platforms, because they all use the same basis, and your app will not be an exception.
Btw, you can compile C-code for your app written in Objective-C.
Update.
And here is a good explanation about how to use sockets: http://www.linuxhowtos.org/C_C++/socket.htm
Not all devices respond to ICMP PING (which is what you're using). Are there specific devices that are never discovered? If so, do they respond to the "ping" command?
If it is more erratic, then you need to start with network traces (most commonly using wireshark). You need to determine if the pinged machine received the ping, and separately whether your device received the response. You will generally want to build a small, private network for this so you can control the hardware.
Generally speaking, it is easier to initially develop this kind of code in the simulator rather than a device. Does it work more reliably in the simulator?
Are you receiving errors? Are there firewalls involved? (Firewalls often swallow ICMP without generating errors.)
You're going to need a lot more specific diagnostic information beyond "does not work reliably." You need to know exactly which pieces do and don't work. Did you send the packet? Did they receive the packet? Did they send the response? Did you receive the response? Without those basic data, it's very hard to troubleshoot networking.
I am trying to specify the port when I am sending a trap via snmptrap.
Just in order to test my SNMP receiver I want to send traps to it, but I do not have access to port 162. How do I send the trap to another port?
As I see it the man-page does not describe this option.
(I do not fully understand what the parts of a snmptrap message is either, so if someone feels like explaining that it would be nice to)
In the net-snmp command line tools, you specify the port number in the host identifier, like so:
192.168.1.12:162
At least, that works on my machine.
I agree that this is not really apparent from the man page of snmptrap, so I understand why you couldn't figure it out. The rest of the format is, however, described in the man page to a somewhat satisfactory extent.
Edit: As was pointed out in the comment, the address format is described on the man page for snmpcmd:
http://www.net-snmp.org/docs/man/snmpcmd.html
Just curious to see if there is a lua way to ping a server without using os.execute. The purpose being to see if a server is up.
I checked the lua sockets library but I don't think ICMP is supported? Any idea?
You can use io.popen() to execute ping commands.
e.g.,
local handler = io.popen("ping -c 3 -i 0.5 10.10.10.10")
local response = handler:read("*a")
print(response)
To the best of my knowledge, no, you can't send ICMP raw packets without root access. That's not a Lua limitation, it's an OS restriction.
To get root access, the best way is to have a small well tested program that's SUID root rather than changing your entire application with Lua to be SUID root. This means you'll end up using os.execute(). And rather than writing your own program, the OS provided ping seems to be a nice command for solving your issue.
I agree it's not ideal (especially since this creates OS specific code to handle the various ping commands). But without a SUID function call, I don't think there's any better way.
I am trying to evaluate php code through erlang using erlang ports. The problem is when Data to be evaluated is bigger then I am getting parse error from php. But if data is smaller then I am getting the correct output. I think when the Data length is bigger erlang is truncating the data before it is being sent to php for evaluation. Is there any limit on data length which can be sent or received on erlang port. Or is this error due to some other reason ?
I am using open_port(PortName, PortSettings) to open a new port and in PortSettings I am setting [{packet,4},exit_status] as my port options.
The {packet, 4} tuple says the program launched to handle the other end of the port expects data in a 4-byte length-prefixed form. I don't see anything in the docs for the php(1) program that says it knows how to deal with such data. Probably the only reason it works for short inputs is that the length prefix looks kinda like ASCII if you squint, as long as the data you're sending is under 127 bytes. As soon as you go over that, PHP is probably running into a UTF-8 decoding error.
I'm pretty sure you want to say spawn here instead. This gets you standard Unix-like pipe interaction: data sent down the port goes to stdin on the launched process, and anything it sends to stdout comes back to your Erlang process.
The only problem doing it this way is that it re-launches php(1) on each transaction. This may seem expensive, but it's not too bad on any Unix type system, due to the relative efficiency of the fork(2) system call. If you're on Windows or you've benchmarked this and found that you really do need to build a FastCGI like system, you may be out of luck. There seems to be no libphp to embed PHP into a program you write to deal with packetized input, and no way to run php(1) in a way that lets it stay active on the other end of a port. You might be better off switching to a native Erlang templating system.
Also, note that the exit_status atom passed to open_port() does nothing unless you use spawn.
Packet sniffers generally do not capture localhost traffic. I need to inspect some post data in a localhost environment (being generated from a Ruby on Rails development). Do you know of any programs that expose localhost packets?
I use fiddler on my Windows box for http sniffing. Since its only looking at http traffic you don't get nearly the amount of noise you get with something like WireShark.
The trick to getting it to work with data sent and received locally is to use a different endpoint for your urls. Using http://127.0.0.1./YourServiceName instead of http://localhost/YourServiceName has always worked for me. Its important to include the trailing 'dot' in the IP address. Don't ask me why though.
If you use Firefox, you could use the HTTP Logging feature:
https://developer.mozilla.org/en/HTTP_Logging
If you just change your address from localhost to an assigned IP address (like 192.168.12.34 or whatever you may have), your packet sniffer should be able to see the packets.
These packets probably do not exist. There is no reason to packetize data when it is not leaving the host. The data should just go from socket to socket.
You might use something like Instruments or Dtrace to monitor the send system call.
I'm a satisfied user of HTTPScoop: http://www.tuffcode.com/
It's similar to the HTTP traffic analyzer addons you'll see for firefox etc. but works systemwide which is convenient and can be switched to observe any of your available network interfaces.
It is not free, nor does it observe HTTPS traffic, but other than that it's a worthwhile addition to your toolbox.