I wanted to access the original value from the ethernet, actully by some hardware programming i am sending a value to system via ethernet ,but it's not possible to access what exactly i'm going to send
You could use a packet sniffer like Wireshark, running on either source or destination system. This will let you examine packets as they leave or enter, respectively.
It sounds like what you need is a protocol analyzer. On Windows, look at Microsoft's Network Monitor.
Related
I am implemneting a code based on Raw sockets. In order to receive coming Ethernet frames I have to bind the socket I created to an Ethernet interface. The only way to do that, as far as I am concerned, is via setsockopt() function with the option SO_BINDTODEVICE.
The problem is that I am using FreeBSD which does not support such option. Is there any patch to use in order to enable this feature or any other trusted alternative?
You can use sendto if you are working with IPv6, see this example.
Unfortunately this doesn't work with IPv4.
As antiduh said, you can use libpcap to capture packets, provided you have access to /dev/bpf (which is usually restricted to root).
I'm trying to create a small PPPoE Access Concentrator to learn the inner workings of PPPoE.
This requires me to send non-IP packets, I need to be able to set the ETHER_TYPE and eventualy the destination mac fields in the ethernet frame header, but as far as I can tell, raw WinSock sockets give me the ability to supply my own IP header, but not the ethernet header.
Is this true? And if so, is there any way of circumventing this?
I am well aware of WinPcap, and will use it ONLY as a last resort.
I believe that you are correct. Winsock will allow a raw IP socket but does not allow you to get beneath layer 3 and send non-IP packets. For this I believe you would need to pursue the WinPcap / TDI option . More information.
(Apologies: I uninstalled and reinstalled WinPcap and now I can see the extra interface! Suggestion found in Wireshark FAQ. I leave the original question below.)
I use WireShark to examine ethernet packet contents at the byte level (in/out of custom FPGA-based hardware). I have a USB-Ethernet adapter to add a second Ethernet port to my laptop. It was a cheap Chinese device bought on Ebay but now that I've found an appropriate driver, it works OK. However, I see that, on Windows, WinPcap/WireShark doesn't support Ethernet capture over USB.
While it would be nice if WireShark could be made to work on USB capture, I'm really looking for an alternative way to grab the raw ethernet bytes. I have some perl scripts set up that operate on the raw frames output from tshark, (Wireshark command line) and I could easily feed it from any stream of frames/bytes.
Is anyone doing something similar or is there a tidy way to output the raw bytes?
Sniffed raw USB bytes would be OK, but it would be nicer if someone has already programmed/scripted extracting the Ethernet frames. I'm using perl but any compiled app or python or C# or C++ or .. would be fine.
You mentioned python, scapy can do a LOT of raw packet things, might want to look at that. From their git:
Scapy is a powerful Python-based interactive packet manipulation
program and library.
It is able to forge or decode packets of a wide number of protocols,
send them on the wire, capture them, store or read them using pcap
files, match requests and replies, and much more. It is designed to
allow fast packet prototyping by using default values that work.
It can easily handle most classical tasks like scanning, tracerouting,
probing, unit tests, attacks or network discovery (it can replace
hping, 85% of nmap, arpspoof, arp-sk, arping, tcpdump, wireshark, p0f,
etc.). It also performs very well at a lot of other specific tasks
that most other tools can't handle, like sending invalid frames,
injecting your own 802.11 frames, combining techniques (VLAN
hopping+ARP cache poisoning, VoIP decoding on WEP protected channel,
...), etc.
Scapy supports Python 2.7 and Python 3 (3.3 to 3.6). It's intended to
be cross platform, and runs on many different platforms (Linux, OSX,
*BSD, and Windows).
Check them out at https://github.com/secdev/scapy
I don't have a Windows PC readily at hand to test, but as far as I can tell, there is no problem capturing Ethernet frames in Wireshark on Windows, from a USB-Ethernet adapter.
What you can't do, is capturing USB bus traffic, but that is not what you wanted, right?
To clarify, just select the USB-Ethernet device as you would any other, and you are set.
I wanted to know if we could find out what type of switch our machine is directly connected to ..
For instance if I am connected to a Cisco,Brocade,foundry and Force10 switch .
Is it possible to write a perl script to find out the management address of the switch [without logging in]
Is it possible to write a perl script to find out the switch vendor and model number ...
Thanks for your suggestions.
EDIT: Wanted to add that I am directly connected to the switch .. I can disable the firewall on my machine ...
nmap is what you want. If that doesn't do it, the answer is probably "no". If you need the IP address of the switch, run traceroute/tracert to see what the next hop is.
There is no guaranteed way of being able to achieve this. It depends very much on how your switch has been configured and how open your network admins have made it.
If everything is completely open then the best way of finding out the type of switch is to use snmp. The net-snmp library for perl (see docs here) is a good place to start.
But that assumes that the management interface is exposed to your box.
There is no guarantee that it will be.
If it is then nmap (as suggested by others) may work. At least it might tell you if the management interface is accessible at which point you can use snmp to tell you the rest.
Traceroute might yield some more information, but only if the address used for it's routing is the same as the management address. (and assuming that your "switch" is really a "router". If not then this won't yield any useful information.)
ping might yield some information about the manufacturer, but only if it hasn't been configured to proxy-arp.
On Cisco switchs if CDP is activated you should be able to see CDP traffic on your wire which will indicate switch model, name and switch port you are connected to.
Don't know for other brands.
Not really. In the modern world of firewalled, packet-modifying, NATed subnetworks, you really can't do anything reliably to inspect a network from a client machine.
That said, trying nmap on your router might tell you something interesting. Or it might not. The results are entirely up to the admins of your network.
follow the wire
You can ping it to get its Ethernet address, and then look it up in one of the vendor code lists.
Is it possible to have libpcap remove a packet instead of just sniff it as it passes through? I'm wanting to intercept each packet and encapsulate it into a new packet along with measurement data, but both packets (mine and the original) both reach the destination.
It's not possible. You need to write a driver (for your operating system) to make the networking stack filter out packets.
The only way you could do this is by being the only physical path between the sender and receiver and turning off packet forwarding on the interceptor.
If you're capturing wireless traffic, there's nothing you can do. No software library can remove radio waves from the ambient air.
No, libpcap cannot "remove a packet".
It's not quite clear what you want to achieve, but it looks like you want to receive data, add some additional information to it, and republish it. If you are working with a datagram protocol such as UDP, then you might be able to simply resend your augmented data to a different UDP port.
In response to Ben S, you can't remove packets off the air, but you can stop them reaching their destination - using ARP cache poisoning etc.
As others mentioned, you can not use libpcap. libpcap is a passive listener. If you are on Linux, you can use a netfilter, which hooks into iptables. Here is an example of how to do that.
http://www.linuxjournal.com/article/7184