No saddr, daddr, dport for udp.recvmsg, udp.sendmsg

No saddr, daddr, dport for udp.recvmsg, udp.sendmsg

[AZX AMN]

I'm running systemtap version "2.8/0.163, Debian version 2.8-2ubuntu1"
on Ubuntu 15.10, installed from the standard ubuntu packages and I'm
trying some of the examples for probing udp.recvmsg and udp.sendmsg.
I'm running this:

probe udp.recvmsg, udp.sendmsg  {
  printf(" %15s %15s  %5d  %5d  \n",
         saddr, daddr, sport, dport)
}

and most of the time only sport has a correct value while dport is 0
and saddr and daddr are 0.0.0.0. Occasionally they will have correct
values though, so it's not completely consistent.  Sometimes only
saddr and sport have correct values and the destiation is 0's. But
almost all of the time only sport is there. When I probe TCP it all
appears correctly. Are there any known reasons for this behavior for
UDP?

Thanks

Re: No saddr, daddr, dport for udp.recvmsg, udp.sendmsg

[Frank Ch. Eigler]

az1029az1029az wrote:

(Wow, that's a mouthful!)

> [...]
> probe udp.recvmsg, udp.sendmsg  {
>   printf(" %15s %15s  %5d  %5d  \n",
>          saddr, daddr, sport, dport)
> }
>
> and most of the time only sport has a correct value while dport is 0
> and saddr and daddr are 0.0.0.0. [...]

I'm seeing similar behaviour here on Fedora 22 (kernel 4.3-ish).  It
appears that the incoming $sk, in its inet_sock cast, sometimes passes
within the kernel without that data.  For example, I get 0.0.0.0 IP
addresses for some broadcast traffic such as mdns / rwho.

Does this match your observations?  Are you sure there is a problem?

Compare also to this script, which operates at a different layer in the
kernel:

probe netfilter.ipv*.* {
    if (protocol==ipproto_udp)
        printd(" ", pp(), saddr, sport, daddr, dport, "\n") 
}


- FChE

Re: No saddr, daddr, dport for udp.recvmsg, udp.sendmsg

[AZX AMN]

> I'm seeing similar behaviour here on Fedora 22 (kernel 4.3-ish).  It
> appears that the incoming $sk, in its inet_sock cast, sometimes passes
> within the kernel without that data.  For example, I get 0.0.0.0 IP
> addresses for some broadcast traffic such as mdns / rwho.
>
> Does this match your observations?  Are you sure there is a problem?
>

I'm seeing this for regular unicast traffic although it does seem to
depend on the application. For example traffic of the OpenVPN
application always has only sport and so do DNS lookups from nslookup.
However lookups from dnsmasq have both saddr and sport (and still no
daddr or dport) and the same goes for ntp. Traffic from netcat ("nc -u
...") shows all fields properly.

> Compare also to this script, which operates at a different layer in the
> kernel:
>
> probe netfilter.ipv*.* {
>     if (protocol==ipproto_udp)
>         printd(" ", pp(), saddr, sport, daddr, dport, "\n")
> }

Indeed, this shows it all properly. But shouldn't recvmsg and sendmsg
also do it for normal unicast traffic?