I'm new on work with linux. I want capture the ethernet packets above the device drivers layer.
I know that all the packets pass through the functions "dev_queue_xmit" to transmit the packet to the upper layer and the function "netfi_rx" for recieving the packet.
How can i "hook" this function to control the ethernet traffic?
what should i work with to accomplish this task?
You might want to check out libpcap (a portable C/C++ library for network traffic capture). There is also an example.
You might want to use raw sockets. http://aschauf.landshut.org/fh/linux/udp_vs_raw/ch01s03.html
See also this question
Related
Recently I encountered several questions on SO regarding working with sockets on a very low level. Here's an example. While looking for an answer, I realised that sockets have relatively low capabilities on OSI Level 2. On Linux, we can specify a protocol when creating a socket, but obviously not all Level 2 protocols are present in the list.
While it is possible to assemble and send an ethernet frame, it's (presumably) not possible to send a 802.11 packet - though it looks like wifi device drivers do convert ethernet frames to wifi packets and vice versa.
This made me wonder, if there are more possibilities in reading and writing directly to device files like eht0, ath0? Is it a socket implementation who usually writes to these files, or a device driver? And who's on receiving side - a NIC driver, a peripheral bus controller?
I want to implement a driver in Linux, that has a Ethernet stack but the data going out on hardware will be a serial port. Basically, I want to register my serial port as a Ethernet driver. Does anyone have any idea if this is possible?
I want to be able to push IPv6 and/or UDP packets out of the serial port and in a similar way receive the packets via a serial port and pass it up the Ethernet stack.
I do not want to use the solution of serial-to-ethernet convertors(external hardware that convert a serial port to a ethernet port) but have that in my PC itself.
I tried PPP over the serial port and it works well. I am also told that I can do FTP, HTTP etc using the PPP. Reference to this - http://www.faqs.org/docs/Linux-HOWTO/Serial-Laplink-HOWTO.html
I have tried to hack the code from a RealTek Ethernet driver with a serial driver but not able to gain much success. Rather I do not know the stack of either to actually do anything meaningful. Any advice, guidance or tutorials would be helpful.
Thanks
Aditya
You need to get back to de basics on networking, the way I understand you question is: "I have a serial port and I want to use is an Ethernet link". Sorry to crush your dreams but you don't have the real hardware to do so, I'll elaborate on it.
A serial connection is a physical connection that requires 3 wires (at least) tx, rx and ground. On the logical side you have an IC that coverts binary data into signals that are represented by discrete voltage ranges.
Ethernet is a layer 2 protocol, the layer 1 is provided by the technology used to transmit the signals (coax, up, fiber etc.) As you might see by now, you need a different set of hardware to convert the logical Ethernet frames into a stream of digital numbers, in fact this is call framing.
Since Ethernet has been an easy to use protocol it has been implemented as e preferred protocol for many network operators, of course one of the biggest is PPPoE where you have a PPP session over an Ethernet link. Of course this won't work with your example neither since you're trying the opposite.
If you're just learning and have all the time in the world you can attempt to write your own Ethernet framer over serial lines. This means you need to implement IEEE802.3 into the driver and then you need to serialize the data to push it as a stream of bits over the serial line. Of course note the following drawbacks:
Your driver won't be able to fully support Ethernet, you need some support at hardware level to implement some signaling (example, auto negotiation, CSMA/CD, etc)
You driver will be pretty much useless unless you back in time where 115.2kbps is top speed in data transfers
IMHO there are more exciting projects that you can pick up in the networking field for device drivers. You can for example attempt to buy a NIC and develop the device driver for it from scratch and you can optimize certain areas. Finally, remember that most of the Ethernet implementations are now done in hardware so you don't have to do anything but filling a few registers on the MAC and voila!
SLIP and PPP do already what you want.
I've been playing around with an ethernet protocol (not IP) constructed using
socket(PF_PACKET, SOCK_RAW, ether_type)
I have a small problem. I've got a packet constructed that has the source and destination mac set to my local cards mac that I've also bound the socket to with bind.
I can receive packets fine from the network.
I'm able to send packets to the degree where I see them appear in wireshark.
However, my listening app doesn't see those packets. It is able to see packets from other sources on the network however.
I should point out that my mac addresses do appear to be being sent in the correct byte order.
Can you send packets to yourself?
Do network cards not loopback?
Does the linux kernel do something special at the IP level for loopback and because I'm below that, ignore me?
Yes, IP "loopback" packets, as you put it, are treated specially. They're looped back internally, not sent out through the interface. So ethernet-level loopback, in this sense, is a special case that doesn't normally need to be supported. Some old 10Mbit ethernet cards were even half-duplex, so it couldn't have worked on that hardware :).
On the other hand, you can buy/make loopback adaptor cables to test network cards. So it must be possible on (hopefully all) modern hardware. And people have used them under linux with AF_PACKET (evidence, though no more details, here).
I guess the next question would be whether your switch supports this. A dumb hub would have to support it, but there's room for a modern switch to get confused. Or maybe disallowing it in fear of an infinite loop of packets.
I would like to simulate packets reordering for UDP packets on Linux to measure the performance and fault tolerance of my application.
Is there a simple way to do this?
look into WANEM
WANem thus allows the application
development team to setup a
transparent application gateway which
can be used to simulate WAN
characteristics like Network delay,
Packet loss, Packet corruption,
Disconnections, Packet re-ordering,
Jitter, etc.
You can use the "netem" feature built-into the Linux kernel. It is shipped with most modern distributions. netem is a traffic control discipline module which deliberately delays, drops and reorders packets and is highly configurable.
This only works for sending packets (because the queues are outbound only), so you may wish to place a router host with netem between the two test machines, and run netem on both interfaces (with differing parameters if you like).
The easiest way to achieve this is to run netem in a VM to route between two VM networks. I've found this to be quite handy.
You could try scapy. It's a python library to manipulate packets. You could capture a pcap session, with tcpdump, wireshark, whatever, and then replay the captured packets in arbitrary order with scapy.
a=rdpcap("/spare/captures/isakmp.cap")
for pkt in a.reverse():
sendp(pkt)
Depending on how you catpured the packets you may need send(layer 3) rather than sendp(layer 2)
Is there some way to get the Frame Check Sequence (FCS) from an ethernet frame when using Wireshark to capture packets under Linux?
The FCS is generated by the sender's ethernet device and decoded by the recipients ethernet device. If the FCS is correct, the payload is passed up to higher layers. If it's not, then the potential frame is discarded.
Because it's added for the exclusive use of the ethernet layer, there's no reason to pass the data up to the operating system. There's no reason for the hardware to include additional capabilities of moving that data out of the card. All modern ethernet devices do onboard FCS processing (and often much more). The only exception would be devices intended to analyze ethernet performance and function.
The Ethernet wiki page on Wireshark states:
Most Ethernet interfaces also either don't supply the FCS to Wireshark or other applications
so I assume the answer is a no.