This supports EDNS0 with the "owner" draft, which is the only one that appears on my network. There are still issues in that "Unprocessed rr in Additional Section" shows up in debug mode. I'm not sure why.
Support EDNS0 (RFC 2671), initially recognising draft-cheshire-edns0-…
Sorry, the pledge(2) bits are in here too. I'm new to git.
Make pledge and exit consistent with other usages.
I can review this today sadly, I'll have a look tomorrow.
But I've added a few ideas.
Can you squash the two mdnsctl commits into one:
it's quite simple:
git branch bkp
git rebase -i HEAD^^^^^^^^^^
You then change the order of the commits and squash one into the other.
This way you have both commits into one.
This reads good to me but I didn't have time to check the RFC yet.
It would be a bit more clean to do something like:
if (rr->rrs.type == T_OPT)
then on the
case T_OPT you do this whole block and return.
This way you can escape the stuff you don't want, and code still looks like a switch
Um, except for the rebase thing---I tried and it gave me errors.
why casting plen and code to llu ?
%u and no cast should be enough.
Because plen and code are u_int16_t, which should use the % PRIu16, but usually people shit bricks when they see that. Yes, I know that on openbsd, this is %hu or just %u for u_int32_t. But do you really want to discard portability like that? Fixing it later will be a PITA.
Address comment that T_OPT handling should be in the switch statement.
Allow for compilation.
Move locals into main function body.
I make it a point to print for the type and not assume (pulling in inttypes.h and using the silly PRIu16 modifiers isn't such a bit deal). Hence the up-cast. IIRC all of the BSDs are ILP32 or I32LP64, but still... I can change to %hu and %u for u_int16_t or u_int32_t with caveat emptor, cast up, or use PRIu16 and PRIu32. (I prefer the latter.) It's up to you!
Use %u instead of up-casting to long long unsigned. Make some error
messages more meaningful, too.
This should be a return, if you break you do an extra *len -= rdlen; *pbuf += rdlen; outside the switch on line 1124.
This is new behaviour as your previous diff returned
Note I set rdlen to be zero in the heading, then jump to the switch before it's set otherwise. So it should be zero.
I just can't figure out where the Unprocessed rr in Additional Section comes in to play after it processes the EDNS0 packets.
Unprocessed rr in Additional Section
Ok, I passed the struct pkt into pkt_parse_rr and can verify that the EDNS0 packets are MDNS_QUERY. Since the pkt_parse_rr is being invoked from the AR RR handler and always inserting into the arlist, should I just not have T_OPT be inserted?
Edit: included in the current version. This obviously gets rid of the warnings; but as it is a query, I'm not sure if that's the correct approach. I just don't know mdns well enough.
Don't append to AR list if the RR is a T_OPT.
I've cherry-picked the mdnsctl bits for now, they're in master now.
So as not to leak the rr, remove it later. It's not known whether
this is the correct approach, though.
So I've cherry-picked the following:
I've not merge the commit that caused the leak, neither the fix. I came with something else, please take a look at: 1196417
Can you confirm that now ESDN0 still gets parsed, but you don't get any warning messages ?
If that works for you I'll close this pull request, with I'd like to close v0.7
@kristapsdz could you confirm that ESDN0 is still parsed and you don't get the errors now ?