NFD » ndn-cxx

FaceUri parser is not recognizing the device name part correctly.
Device name rules are quite relaxed, see dev_valid_name.
There’s probably additional encoding when converting to IPv6 link local address.

Junxiao Shi wrote:

FaceUri parser is not recognizing the device name part correctly.

Yes, we're only accepting [a-zA-Z0-9]+, which is wrong.

There’s probably additional encoding when converting to IPv6 link local address.

I don't understand this sentence.

There’s probably additional encoding when converting to IPv6 link local address.

I wonder what happens if interface name contains % ] or other characters that cannot appear in URI. I couldn’t find answers in kernel, libpcap, or getsockaddr (of Python) sources.

Eventually we should canonize zone index to the numeric form, but that’s left for another issue.

Junxiao Shi wrote:

There’s probably additional encoding when converting to IPv6 link local address.

I wonder what happens if interface name contains % ] or other characters that cannot appear in URI. I couldn’t find answers in kernel, libpcap, or getsockaddr (of Python) sources.

That's an URI encoding issue. Kernel, libpcap, getsockaddr don't deal with URIs.

According to the URI RFC, all reserved chars should be escaped. IIRC however, Alex decided to ignore this rule at least for '%'.

In any case, change 4474 is intended to be a quick fix, since the FaceUri parser is being completely rewritten in #4324 anyway. We can decide to reject weird characters in interface names (only accept e.g. '-' and '_') if that simplifies things for now. If anyone is using weird characters to name interfaces, they should be shot.

We can decide to reject weird characters in interface names (only accept e.g. '-' and '_') if that simplifies things for now.

Yes rejecting some chars is fine.

they should be shot.

See https://github.com/named-data/NFD/blob/97a010178c0bd340babb3dfabcc6f8f6abbaef42/CODE_OF_CONDUCT.md "our standards" section.