Nothing happen after receiving LLMNR Query request
Hello
first of all thanks for fixing CentOS compilation error. Now I have successfully running xllmnrd daemon in my environment. As I can see from "ip maddr" output the daemon is listinening on (on all interfaces):
inet6 ff02::1:3
Also I am able to see it in netstat output:
$ netstat -anp | grep 5355
udp 0 0 :::5355 :::* 22883/xllmnrd
Also the ip6tables are configured correctly:
$ ip6tables -L -vn | grep 5355
150 10788 ACCEPT udp * * ::/0 ::/0 udp dpt:5355
But the problem is, that after receiving LLMNR Query response I am not getting any answer. This is from strace process output:
recvmsg(4, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(56852), inet_pton(AF_INET6, "fe80::15cc:81ac:91ab:abe7", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=if_nametoindex("eth3.100")}, msg_iov(1)=[{"\344j\0\0\0\1\0\0\0\0\0\0\7TR1-PC9\0\0\377\0\1oa\220\236\177\0\0\21\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0P\16\364\2\377\177\0\0I\254\200/<\0\0\0\210\21\242/<\0\0\0 ka\220\236\177\0\0P\16\364\2\377\177\0\0\333y\200/<\0\0\0\200\16\364\2\377\177\0\0I\254\200/<\0\0\0\210"..., 1500}], msg_controllen=40, {cmsg_len=36, cmsg_level=SOL_IPV6, cmsg_type=, ...}, msg_flags=0}, 0) = 25
recvmsg(4, {msg_name(28)={sa_family=AF_INET6, sin6_port=htons(56852), inet_pton(AF_INET6, "fe80::15cc:81ac:91ab:abe7", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=if_nametoindex("eth3.100")}, msg_iov(1)=[{"\344j\0\0\0\1\0\0\0\0\0\0\7TR1-PC9\0\0\377\0\1oa\220\236\177\0\0\21\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0/\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0P\16\364\2\377\177\0\0I\254\200/<\0\0\0\210\21\242/<\0\0\0 ka\220\236\177\0\0P\16\364\2\377\177\0\0\333y\200/<\0\0\0\200\16\364\2\377\177\0\0I\254\200/<\0\0\0\210"..., 1500}], msg_controllen=40, {cmsg_len=36, cmsg_level=SOL_IPV6, cmsg_type=, ...}, msg_flags=0}, 0) = 25
recvmsg(4, <unfinished ...>
From the syslog:
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth0
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth1
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth2
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth3
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth4
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth5
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth6
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth2.10
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth2.1000
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth2.11
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth2.12
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth2.2
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth2.502
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth3.100
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth3.101
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth3.102
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth3.103
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth3.104
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth3.120
Feb 17 12:35:43 gateway1 xllmnrd: Joined the LLMNR multicast group on eth3.122
selinux I putted into permissive mode (for any case)
thanks for help
Comments (4)
-
repo owner -
Account Deleted yes, sorry, my fault. I have read rfc4795 and now I know that responders respond to LLMNR queries for names and addresses for which they are authoritative. The request with asking about TR1-PC9 was sent by computer to check if this name is used in network or not - as this is its own computer name. firstly I thought that LLMNR is some kind of DNS service to be able to respond to any requests and that xllmnrd is cooperating with nmbd and/or nameserver daemon in order to get records from wins or relevant DNS zones. But it looks like much more simpler and purpose is to identify peers each other on same network and not to provide another name service using link-local addressing.
-
repo owner - changed status to invalid
Theoretically, it could be extended to act as a proxy for other devices, but it would need extra discussions whether it is really needed or not.
-
repo owner -
assigned issue to
-
assigned issue to
- Log in to comment
Is your server, on which xllmnrd is running, named TR1-PC9? xllmnrd just answers to its host name and ignores other names by design.