Avatar of EJ13
 asked on

Dealing with network packets

Dear Experts,

In the Linux networking stack , we know that when there is a packet "enter" the network interface card (NIC), the packet will be parse and eventually reach a function called "netif_rx()". And from there, the packet will keep on "traverse" to the upper protocol level and different processing on the packet will be carried out by the kernel depending on its packet protocol types before it is being sent out on the reverse way (correct me if I am wrong in concept, thanks :) )...

Currently I am doing a project on linux networking stack. I was required to "intercept" the packets whenever they are received and reach the "netif_rx()", processing them, and send them out again. May I know, if I am to do this task in the application level, what should I do? I know socket programming can get the packets for me into the application level, but where does actually socket programming "intercept" the packets from? If not using socket programming, any other way that I can "divert" those packet to the application level? And would also like to know how can i send those packets out from application level, other than socket programming.

Hope you guys can give me some advice or hint. :)
Thanks a lot :)

Linux OS Dev

Avatar of undefined
Last Comment

8/22/2022 - Mon

1) "before it is being sent out on the reverse way"

Well, actually, packets received are usually not sent out
(except when the host is requested to forward ip traffic,
i.e. is a router or a gateway).

2) There are 2 ways to capture packet from user-land
(application level)
- linux specific : create a packet socket (see man packet)
  then use recvfrom/sendto.
- platform independant : use libpcap (see man pcap on linux)
  tutorial here : http://www.tcpdump.org/pcap.htm

3) Depending on what you want to do, the user-land approch
may not be possible. For example, do you want to implement
you own protocol (using your own protocol-type code) or do
you want to intercept packets for a std protocol (eg IP) ?
Also, do you want to modify/filter the packets
or just read them ? If you want to modify packets, you
need to have a kernel implementation (well, at least
I think so).

4) Anyway, are you sure you can't use an existing mecanism
to solve your problem ? What is your problem exactly ?
Linux already addresses most of the needs concerning
security, routing, etc...



Actually, the packet socket (and libpcap library, which uses a packet socket) don't intercept the packets.  It just gets copies of them.  The packets still go wherever they would have otherwise gone.

The very wording of the problem -- intercepting packets at netif_rx() -- says to me this is kernel code.  netif_rx() is inside the kernel.  Deep inside.

The packet reaches netif_rx() as soon as it has left the device driver.  This is before Linux knows it is an IP packet, for example.

I guess intercepting at the netif_rx() level means writing a replacement protocol driver for the IP protocol driver (which you find in the directory net/ipv4 in the Linux kernel source tree).  That's a pretty heavy-duty job.


For my project, it is just a simple implementation of a MPLS router on the linux platform. Only the forwarding is to be done (just for a demo purposes). Basically what I need to do is just to receive the Eth packets, append an appropriate MPLS header (and of course a new L2 header), and forward them to an output port.

So, can I instead do it in this way (in the kernel level):
In the netif_rx(), i "divert" the packets received to a kernel module that I implemented. And in that kernel module, I perform those things that I need to perform on a packet. When everything is done, I send the packet out through the ip_send().

Since I only dealing with forwarding, there is no need for non-ip processing (routing protocol, ICMP, ARP ...etc)(in fact is just for a demo purposes), so I decide to divert the path of the packet to
netif_rx() -> ( processing on packets in my own kernel module) -> ip_send()

Can this achieve what I want? If this model is workable, for my project purposes, then can advice me on what I should becareful with (memory, interrupt, etc)?? I am a beginner in kernel programming with minimun knowledge in kernel programming.

Please guide me. Thanks :)

All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck

By the way, is socket the only way to deal with packets in the application level (since libpcap library also using packet socket) ?? No other way(s)?


So it is very similar to a traditional IP router. An IP router is implemented in the IP protocol driver, which is the code in net/ipv4 in the Linux source tree.  To do this in the kernel, you would just make something analogous to that.

By the way, as you will see in the ipv4 code, you don't divert the packets within netif_rx().  The protocol driver calls netif_rx() to fetch a packet from the network.  Whoever calls netif_rx() gets the packet.

I don't see why you would use ip_send().  It's MPLS, not IP.

At application (user) level, a socket is the only way to get and send network packets.  I don't know why you'd want anything else, though.

Dear bryanh,

Does kernel 2.4.18 support MPLS ? For example, is there any mpls_send() ?

I roughly browse through the sk_buff structure, it seems that there is no room for MPLS header. So if I am to do it at the kernel level, does it mean that I have to modified the sk_buff (for my project purposes)?

And for the sending part, I no idea to call which function to send out my MPLS packet. Can you give me some hint?

Thanks a million :)

Try out a week of full access for free.
Find out why thousands trust the EE community with their toughest problems.

View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
See Pricing Options
Start Free Trial
Ask your own question & get feedback from real experts
Find out why thousands trust the EE community with their toughest problems.

Thanks a million. At least now I know where should I begin from :)

Thanks Thanks Thanks :)

No comment has been added lately, so it's time to clean up this TA.
I will leave the following recommendation for this question in the Cleanup topic area:

Accept: bryanh {http:#8004248}

Please leave any comments here within the next seven days.

EE Cleanup Volunteer