| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hi,
I sent a less knowledgeable question about avahi-daemon and
point-to-point links a few days ago,
http://lists.freedesktop.org/archives/avahi/2011-January/001969.html.
When I didn't get a response to this, I decided to build avahi from
source and step through it and see how it builds its list of interfaces
and their addresses.
This is in iface-linux.c, netlink_callback(). It looks for a RTM_NEWADDR
message, then extracts the payload of type IFA_ADDRESS.
Short story: I think it should be using the payload of type IFA_LOCAL,
not the payload of type IFA_ADDRESS.
In the VM where I was running these experiments, there are 3 interfaces
-- lo, eth0 and tun0. I printed out the IFA_ADDRESS and IFA_LOCAL for
all 3 of these; for lo and eth0 these are the same address; for tun0
(IFF_POINTOPOINT), IFA_ADDRESS is the remote end and IFA_LOCAL is the
local end.
I'm no expert on Linux rtnetlink or these IFA fields, but quoting
/usr/include/linux/if_addr.h:
/*
* Important comment:
* IFA_ADDRESS is prefix address, rather than local interface address.
* It makes no difference for normally configured broadcast
* interfaces,
* but for point-to-point IFA_ADDRESS is DESTINATION address,
* local address is supplied in IFA_LOCAL attribute.
*/
See also this stackoverflow question/answer:
http://stackoverflow.com/questions/4678637/what-is-difference-between-ifa-local-and-ifa-address-in-rtnetlink-linux
Does anyone know why avahi is looking for IFA_ADDRESS here, and whether
there's any reason not to use IFA_LOCAL instead?
Assuming there's not a specific reason to use IFA_ADDRESS here, I
propose the patch attached at the end of this message, which works for
me. (The bug this fixes is described in the earlier message linked above
-- avahi chooses the wrong address to associate with the P-t-P
interface, and if you enable avahi's reflector, avahi tries to call
sendmsg() using that as the source address and the kernel always,
correctly, fails the sendmsg() call with EINVAL.)
(And when/why this changed -- I was able to use avahi over P-t-P
interfaces on Linux several years ago; I don't know what avahi version I
was using at the time.)
thanks,
Matt
|
|
|
|
| |
Do not reflect cache entry with ipv6 link-local addresses on query.
|
|
|
|
|
|
|
| |
Else, we end up with an infinite loop with 100% CPU.
http://www.avahi.org/ticket/325
https://bugzilla.redhat.com/show_bug.cgi?id=667187
|
|
|
|
|
|
|
|
|
| |
The avahi-daemon uses a wrong flag combination to operate with
rtnetlink. This patch fixes the problems.
No need to set NLM_F_ACK since the dump operation already includes
the trailing NLMSG_DONE message that informs about the end of the
dump operation.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there is a service name collision and the entry group callback calls
avahi_s_entry_group_reset or avahi_s_entry_group free on the group in
question, the entries were released. This could cause a crash in
withdraw_rrset as it is walking a list of entries at this time.
The fix for this issue is to schedule a cleanup event to clean up
entries after a a short timeout (currently one second). If a cleanup
occurs for any other reason the event is cancelled.
http://avahi.org/ticket/302
|
|
|
|
|
|
| |
registered
Fixes http://avahi.org/ticket/276
|
|
|
|
|
|
| |
This might happen if an iface goes away while we are querying.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548952
|
| |
|
|
|
|
|
|
|
|
| |
Newer Bonjour implementations add EDNS0 extensions to the query packets.
We currently consider those corrupted or invalid. This patch drops the
check, and accepts them as valid.
http://avahi.org/ticket/284
|
|
|
|
| |
http://avahi.org/ticket/211
|
| |
|
| |
|
|
|
|
| |
again and some applications need the high values
|
| |
|
|
|
|
|
|
|
|
| |
Fix a regression introduced by commit
2ea7e99ed0dcfd371fef5aeecd3de77da1dfcd4f that caused the mDNS response
handler to completely ignore records with link-local addresses.
Fixes #300
|
| |
|
|
|
|
|
|
| |
zero size is reported for corrupt packets. recvmsg() later could
nevertheless get data from a good packet that followed the bad one.
So get out early to avoid hitting an assertion.
|
| |
|
| |
|
|
|
|
|
|
| |
Patch contributed by "oc3an".
http://avahi.org/ticket/267
|
|
|
|
| |
http://avahi.org/ticket/287
|
| |
|
|
|
|
|
|
| |
Modify avahi-daemon so that it doesn't advertise patently useless
link-local addresses on the wrong interfaces when reflecting mDNS
responses.
|
|
|
|
| |
Fixes rhbz #488314.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quoting Joe Marcus Clarke:
"There are two problems in the iface-pfroute.c IPv6 detection
code. The first is that the KAME stack embeds a scope ID into
IPv6 addresses. This can cause certain hosts not to be able to
recognize the address. The second is that global_scope is always
set to 1 even for link-local addresses.
The attached patch fixes both problems. The KAME fix was
submitted by Hajimu UMEMOTO."
Patch from Joe Marcus Clarke/Hajimu UMEMOTO.
|
|
|
|
|
|
| |
Original patch from Skinkie. Heavily modified by Lennart Poettering.
Closes #212.
|
| |
|
|
|
|
|
|
| |
This is a fix for rhbz 475394.
Problem identified by Hugo Dias.
|
|
|
|
|
|
| |
Include the source host in warning messages about invalid packets.
This is a result of rhbz #438013
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
at least one second apart are observed. This reduces the likelyhood of false
positives a lot.
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1746 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
|
|
| |
Patch from zml. Closes #166
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1591 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
|
|
| |
IP_SENDSRCADDR. Patch from zml. Closes #163
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1590 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
|
|
| |
David C Thompson
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1560 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
| |
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1544 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
| |
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1543 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
| |
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1513 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
| |
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1509 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
| |
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1508 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
|
|
|
|
|
| |
records, so it is consistent with the network conflict detection. This
allows you to publish shared services from the same machine not just
different machines.
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1499 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
| |
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1497 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
|
|
|
| |
conflicting records.
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1496 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
| |
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1494 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
|
|
|
|
|
|
| |
we must remove all compressed labels from the name table that are inside
the removed section. Add avahi_dns_packet_cleanup_name_table and call in appropriate places where packet is shrunk.
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1493 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
|
|
| |
should think of something better way to work around this problem.
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1463 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
| |
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1420 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|
|
|
|
|
|
| |
(closes #130)
git-svn-id: file:///home/lennart/svn/public/avahi/trunk@1407 941a03a8-eaeb-0310-b9a0-b1bbd8fe43fe
|