1. Home
  2. Embedded Linux
  3. path of packets through network stack

path of packets through network stack

Hello

I'm trying to study and understand operations of the Linux tcp/ip stack, specifically how 'ping' sends packets down and receives them. Ping creates raw socket in AF_INET family, therefore I placed printk in inet_sendmsg() at net/ipv4/af_inet.c to print out the socket protocol name (RAW, UDP etc.) and the address of protocol specific sendmsg function which correctly appears to be raw_sendmsg() from net/ipv4/raw.c

Now, I'm sending a single packet and observe that I'm getting printk form inet_sendmsg() twice.This puzzles me -- is it normal (has something to do with interrupts etc. ?) or there's something broken in the kernel?

Platform - ARM5te, kernel 2.6.31.8

Looking forward to hearing from you !

Mark

Reply to
Mark
Loading thread data ...
[...]

Presumably, the phenomenon you observed is 'normal' and it is certainly not related to 'interrupts'. Interrupts are used for controlling/ driving devices. This happens 'below' the network stack. sendmsg is something which happens at the top of the latter.

Reply to
Rainer Weikusat

The first sendmsg() may be for name resolution of the target. Try again with a numeric target address.

--

Tauno Voipio
Reply to
Tauno Voipio

I'm not certain, but

formatting link
may get into a bit of that.

rick jones

--
The glass is neither half-empty nor half-full. The glass has a leak. 
The real question is "Can it be patched?"
 Click to see the full signature
Reply to
Rick Jones

I was assuming it may haev something to do with "soft" interrupts.

Mark

Reply to
Mark

Well, to avoid any name resolution whatsoever, I'm pinging with numeric addresses. Also I've checked ping with strace, it's calling send exactly once (ping -c1 10.10.10.1), so it's unlikely a bug of busybox's ping.

Mark

Reply to
Mark

This doesn't make any more sense.

Reply to
Rainer Weikusat
[skip]

Could you elaborate on why you believe this phenomenon is normal ?

Mark

Reply to
Mark

Considering the following possible explanations:

- you found an unknown, major kernel error in the interface parts of the networking stack which can be triggered in an extremely simple way

- your code doesn't really do what you think it does

- this is either coincidence or part of the 'normal' processing but the exact reason for it is unknown

the first seems the least likely to me. This doesn't mean that I'm necessarily right but I'm not going to investigate this phenomenon in the kernels I'm responsible for because I'm afraid that it could be something serious which could affect other stuff I'm also responsible for in some negative way.

BTW: You aren't per chance doing this on a system you're acessing over the network?

Reply to
Rainer Weikusat

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.