NSIS-ka
A free C++ implementation of NSIS protocols

Opened 8 years ago

Closed 8 years ago

#123 closed defect (fixed)

Refreshing/MA re-use Response via MA and w/o Stack Proposal causes MA re-use failure

Reported by: bless Owned by: bless
Priority: major Milestone:
Component: GIST Version:
Keywords: Cc:

Description

A refreshing or re-use Response via an existing MA causes the Querier to fail in MA re-use. The symptom is that he can't find the existing MA, though it is active and the Response was received over it.

2009-08-07 14:01:44.178-15244- DEBUG /4: GIST Routing    Active Routing Entries: 1 MAs: 1 SII handles: 1
2009-08-07 14:01:44.179-15244- DEBUG /4: GIST Routing    ******* Returning entry for Session-ID 00000000-00000000-00000000-00000000 with state QN_AWAITING_REFRESH
2009-08-07 14:01:44.179-15244- DEBUG /4: GIST Routing    MA not found / not usable
2009-08-07 14:01:44.179-15244- DEBUG /4: GIST Routing    There is no active Message Association to maintain
2009-08-07 14:01:44.179-15244- DEBUG /4: GIST Processing Evaluating current routing state
2009-08-07 14:01:44.179-15244- DEBUG /4: GIST Processing GIST Response received, processing (QN Awaiting Refresh)
2009-08-07 14:01:44.179-15244- DEBUG /4: GIST Routing    MA not found / not usable
2009-08-07 14:01:44.179-15244**ERROR**2: GIST Processing No existing MA found and no Stack proposal/config given, cannot figure out where to send Confirm in C-Mode.
2009-08-07 14:01:44.179-15244- DEBUG /4: GIST Processing Error Message Sender called
2009-08-07 14:01:44.179-15244**ERROR**2: GIST Processing ERROR_GIST_MISSING_OBJECT
2009-08-07 14:01:44.179-15244- DEBUG /4: GIST Processing IP Source IS last GIST hop, sending to it.

Change History (2)

comment:1 Changed 8 years ago by bless

Problem seems to be caused by Responses that use IPv4-mapped addresses in the NLI. This should not happen if IPv4 is used for a session/flow. For Max Laier's implementation this was probably a non-issue since he only concentrated on IPv6. This needs fixing.

2009-08-10 16:45:55.648-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:::ffff:141.3.71.26
2009-08-10 16:46:15.279-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:::ffff:141.3.71.26
2009-08-10 16:46:23.727-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:46:23.739-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:46:23.740-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:46:44.304-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:46:44.314-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:47:30.550-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:47:30.558-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:47:30.559-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:47:38.930-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:47:38.938-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:47:49.712-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:141.3.71.26
2009-08-10 16:47:49.722-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:::ffff:141.3.71.26
2009-08-10 16:47:50.224-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:::ffff:141.3.71.26
2009-08-10 16:47:51.224-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:::ffff:141.3.71.26
2009-08-10 16:47:53.224-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:::ffff:141.3.71.26
2009-08-10 16:47:57.225-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:::ffff:141.3.71.26
2009-08-10 16:48:05.225-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:::ffff:141.3.71.26
2009-08-10 16:48:21.227-26242- DEBUG /4: GIST Signaling  MOBILITY: Sending from:::ffff:141.3.71.26

comment:2 Changed 8 years ago by bless

  • Resolution set to fixed
  • Status changed from new to closed

Cause was the mixed use of IPv4 mapped addresses in NLIs which was caused by using reverse path forwarding lookups for v4mapped addresses that returned v4mapped source addresses. Should now be fixed by changes in r4220:4222 and r4225.

Note: See TracTickets for help on using tickets.