Malformed Router Advertisment packet in DHCPv6 (with patch) #5840
Labels
needs investigation
Needs to be reproduced reliably.
Comments
|
Hi @yamanq, are you still experiencing this in the latest version? |
|
@jslawler-gh The linked PR hasn't been merged and I don't see any changes in the relevant code on the master branch. Is there a reason why you suspect that the bug has been resolved? |
|
It's been 11 months since this was raised and many versions have been released since then which may have impacted that result in one way or another from other pr's. I'm confirming that you're still able to reproduce this issue or whether it has changed in some way, or is no longer there. |
|
I no longer have AdGuard installed but I am confident that the bug still exists given that the code has not changed. The PR to fix this bug has been waiting for approval for about 11 months as well. |
ghost
added
needs investigation
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Prerequisites
I have checked the Wiki and Discussions and found no answer
I have searched other issues and found no duplicates
I want to report a bug and not ask a question
Operating system type
Linux, Other (please mention the version in the description)
CPU architecture
AMD64
Installation
GitHub releases or script from README
Setup
On one machine
AdGuard Home version
v0.107.29
Description
What did you do?
I am using AdGuard for a couple DNS rewrites and as a DHCP server in order to provide AdGuard as the DNS server (my router has no options to override the DNS server). For IPv4, this worked perfectly, and my server was set as the DNSv4 nameserver. For IPv6, the router was still used as the DNS server. I used wireshark to analyze the packets and discovered that the packets are malformed due to the MAC address being padded by zeros (See images)
Original packet:
Router Advertisement packet from Adguard. Note that the MAC address is suffixed by 2 empty bytes before the next ICMPv6 option (which is the DNS option). (MAC address has been replaced with XX)
The packet after the Source Link-layer Address packet is then malformed since it begins with zeros.
Edited packet:
If I edit that packet to remove those zeros, the packet is detected properly:
Additional information
I believe that the cause of this is
hwAddrToLinkLayerAddrwhich converts MAC addresses to 8 bytes. While the RFC says that the length of the packet must be 8 bytes, I believe that is: Option Type (1 byte) + Length (1 byte) + address (6 bytes) = 8 bytes. Based on my inspection of Router Advertisement packets of my router, the address is 6 bytes. The RFC linked at the start of the function matches this interpretation:I have written a pull request that fixes this issue: #5841
The text was updated successfully, but these errors were encountered: