Bug #1414
closedFaceManager can create face from malformed tcp6 FaceUri
0%
Description
adding tcp6 uri results in the creation of 2 tcp6://[::1]: faces (different ports).
(Can it be the result of my setup? - our onl doesn't route ipV6, but the end hosts support ipv6 interfaces...)
$ build/bin/nfdc create tcp6://fe80::d6ae:52ff:fecd:23f3/64
Face creation succeeded: ControlParameters(FaceId: 13, Uri: tcp6://fe80::d6ae:52ff:fecd:23f3/64, )
$ build/bin/nfd-status
General NFD status:
version=1000
startTime=20140327T060027.596000
currentTime=20140327T061214.508000
uptime=706 seconds
nNameTreeEntries=4
nFibEntries=1
nPitEntries=1
nMeasurementsEntries=0
nCsEntries=33
nInInterests=13
nOutInterests=12
nInDatas=33
nOutDatas=12
Faces:
faceid=1 uri=internal:// counters={in={0i 34d} out={14i 0d}}
faceid=2 uri=udp4://224.0.23.170:56363 counters={in={0i 0d} out={0i 0d}}
faceid=3 uri=udp4://224.0.23.170:56363 counters={in={0i 0d} out={0i 0d}}
faceid=4 uri=ether://control/01:00:5e:00:17:aa counters={in={0i 0d} out={0i 0d}}
faceid=5 uri=ether://data0/01:00:5e:00:17:aa counters={in={0i 0d} out={0i 0d}}
faceid=13 uri=tcp6://[::1]:6363 counters={in={0i 0d} out={0i 0d}}
faceid=14 uri=tcp6://[::1]:47545 counters={in={0i 0d} out={0i 0d}}
faceid=15 uri=unix:///run/nfd.sock counters={in={2i 0d} out={0i 1d}}
FIB:
/localhost/nfd nexthops={faceid=1 (cost=0)}
Updated by Alex Afanasyev over 10 years ago
@Hila: Small suggestion. Do not use >, as in markdown it means quotation. Also, for terminal output, add four spaces in front, which in markdown means pre block.
Updated by Alex Afanasyev over 10 years ago
This is not valid tcp6 FaceUri tcp6://fe80::d6ae:52ff:fecd:23f3/64
... NFD should have bailed out, unless I misunderstand something
Updated by Junxiao Shi over 10 years ago
- Subject changed from nfdc / nfd-status: adding tcp6 face results to FaceManager can create face from malformed tcp6 FaceUri
- Category set to Management
- Target version set to v0.1
Confirmed.
FaceUri parser or FaceManager should reject this malformed FaceUri.
It's not surprising to see two faces created: face 13 is the outgoing face, and face 14 is the incoming face.
TCP channel SHOULD NOT forbid creating a face to loopback address, because it could be another instance of forwarder.
If feasible, FaceManager should forbid creating a face to an endpoint (IP + port) known to be owned by this NFD instance.
Updated by Alex Afanasyev over 10 years ago
- Status changed from New to In Progress
Updated by Anonymous over 10 years ago
- Status changed from In Progress to Code review
Please re-test using http://gerrit.named-data.net/#/c/617/ (this may have actually been solved by something else that was recently merged).
Updated by Junxiao Shi over 10 years ago
- Status changed from Code review to Resolved
Issue author should test the latest code, and Close this bug after verification.
Updated by Alex Afanasyev over 10 years ago
I forgot to write my comment on this. I have tested this today and can verify that the described problem does not exist anymore (I got error message that the address is invalid or prohibited).
Updated by Alex Afanasyev over 10 years ago
- Status changed from Resolved to Closed