Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 606
  • Last Modified:

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 :)


Regards,
EJ
0
EJ13
Asked:
EJ13
1 Solution
 
skianCommented:

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...

Stephane

0
 
bryanhCommented:
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.

0
 
EJ13Author Commented:
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 :)


Regards,
EJ
0
Visualize your virtual and backup environments

Create well-organized and polished visualizations of your virtual and backup environments when planning VMware vSphere, Microsoft Hyper-V or Veeam deployments. It helps you to gain better visibility and valuable business insights.

 
EJ13Author Commented:
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)?


0
 
bryanhCommented:
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.
0
 
EJ13Author Commented:
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 :)


Regards,
EJ
0
 
bryanhCommented:
>Does kernel 2.4.18 support MPLS ? For example, is there any mpls_send() ?

No, that's what you'd have to write.

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

A protocol driver sends a packet on a network interface by calling dev_queue_xmit()

By the way, I see the comments in the code are incorrect and my earlier statement about how netif_rx() works is wrong.  The device driver calls netif_rx() and netif_rx() causes it to get delivered to the protocol driver's receive routine.

>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)?

The header doesn't go in the sk_buff structure.  Only pointers to it.  Maybe you're referring to the fact that pointers exist in the structure for various specific protocols' headers, but none for MPLS.  Just use the "raw" pointers and a C type cast.  Define your own structures for MPLS headers.  It was poor programming practice for the author of skbuff.h to put that protocol-specific stuff in there anyway.

It occurs to me that if you want to learn how low level protocol drivers work, you should look at the packet protocol driver (in net/packet/af_packet.c) rather than the IP protocol driver.  It is much simpler.
0
 
EJ13Author Commented:
Thanks a million. At least now I know where should I begin from :)

Thanks Thanks Thanks :)
0
 
jmcgOwnerCommented:
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.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

jmcg
EE Cleanup Volunteer
0

Featured Post

Free learning courses: Active Directory Deep Dive

Get a firm grasp on your IT environment when you learn Active Directory best practices with Veeam! Watch all, or choose any amount, of this three-part webinar series to improve your skills. From the basics to virtualization and backup, we got you covered.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now