Subject: Re: [dtn-users] TCA problems
From: "Zahir Koradia" <[email-masked]>
To: [email-masked]
Date: Thu, 1 Feb 2007 12:06:36 +0530
List-Id: discussion/answers list for users of the dtn reference implementation <dtn-users.mailman.dtnrg.org>

Hi Janico,
That seems to be strange. I just  used dtnsend to send the add_route bundle
and it seemed to have the wildcard character in the routing table.

Try this.
In TcaController.cc, in function gate_reg just after the line
printf("TcaController: ignoring re-registration with same"
                    " gateway\n");

add

if (!route_reg(spec, cb)) return false;

This is not a permanent thing; it's just to make sure that add_route
forcefully takes place in our testing. We will remove this line later on.

Then send me the debug level log. Also check in "route dump" whether the
destination has the wildcard character. If it does have it then go ahead and
try sending the bundle.

One simple suggestion. Add the option -r  120 when running tca_admin. That
will restrict the period for which your entry remains in DHT to 2 minutes.
This helps while testing.

Zahir

On 1/31/07, Janico Greifenberg <[email-masked]> wrote:
>
> Hi Zahir,
>
> there is no match, because the entry in the routing table has no
> application tag or wildcard. If I send a bundle to tca://correspondent
> instead of tca://correspondent/myapp, the bundle is successfully
> delivered. But it does not work with an application tag.
>
> Cheers,
> Janico
>
> Zahir Koradia wrote:
> > Ideally a DHT lookup is done by a gateway when a node (mobile or router)
> > has registered through another gateway. Since over here the destination
> > has registered (by sending the register bundle) through the gateway a
> > DHT lookup should not happen. I am sorry I should have noticed this
> > earlier itself. If you notice there is already an entry in the routing
> > table for the destination
> >
> > tca://correspondent -> 134.102.201.174:39960
> > <http://134.102.201.174:39960> (FORWARD)
> >
> > you can do "route dump" at dtnd prompt to see the routing table entries.
> >
> > Now the problem is that when the gateway searches its routing table it
> > is not able to match the destination of the bundle with this route entry
> > and as a result goes to do a DHt lookup thinking it must be registered
> > through another gateway.
> >
> > [1170173715.605384 /dtn/tca debug]
> TcaRouter::handle_tca_unbound_bundle...
> > [1170173715.605407 /dtn/tca debug] TcaRouter::fwd_to_matching_r:
> owner=''
> > [1170173715.605449 /dtn/tca debug] TcaRouter::fwd_to_matching_r:
> fwd_rule=3
> > [1170173715.605473 /dtn/routing/TcaRouter/table debug] get_matching
> > tca://correspondent/myapp
> > [1170173715.605494 /dtn/routing/TcaRouter/table debug] check entry
> > tca://correspondent -> 134.102.201.174:39960
> > <http://134.102.201.174:39960> (FORWARD)
> > [1170173715.605538 /dtn/routing/TcaRouter/table debug] check entry
> > tca://streetcar3 -> 134.102.201.183:46540 <http://134.102.201.183:46540>
> > (FORWARD)
> > [1170173715.605575 /scheme/dtn debug] match(tca://correspondent/myapp,
> > tca://streetcar3/) failed: url hosts not equal ('streetcar3' !=
> > 'correspondent')
> > [1170173715.605604 /dtn/routing/TcaRouter/table debug] get_matching
> > tca://correspondent/myapp done, 0 match(es)
> > [1170173715.605630 /dtn/tca debug] fwd_to_matching_r
> > dest='tca://correspondent/myapp': 0 matches
> >
> > This matching takes place in the function get_matching in the file
> > RouteTable.cc. I can't see any obvious reason for this problem. If you
> > could gdb through it (or use some printfs in the function) to find out
> > why the the matching to that particular route entry fail then we could
> > move a little ahead.
> >
> > Thanks,
> > Zahir
> >
> >
> >
> >
> > On 1/31/07, *Janico Greifenberg* <[email-masked] <mailto:[email-masked]>>
> > wrote:
> >
> >     Hi Zahir,
> >
> >     Zahir Koradia wrote:
> >     > Hi Janico,
> >     > From what I could see a route and a link tca://correspondent/myapp
> and
> >     > jgre.openvpn.informatik.uni-bremen.de:5000
> >     <http://jgre.openvpn.informatik.uni-bremen.de:5000>
> >     > <http://jgre.openvpn.informatik.uni-bremen.de:5000> respectively
> are
> >     > created and a bundle with source and destination
> >     tca://mobile3/myapp and
> >     > tca://correspondent/myapp respectively and with 9 bytes payload is
> >     being
> >     > transmitted successfully. Is this the bundle you are talking
> about. If
> >     > not then I think you need to tell me which bundle had you send
> >     what was
> >     > the source and destination of the bundle.
> >     >
> >
> >     Yes, this is the bundle. jgre.openvpn.informatik.uni-bremen.de:5000
> >     <http://jgre.openvpn.informatik.uni-bremen.de:5000> is
> >     the gateway itself (this is what I pass to tca_admin as the -l
> >     parameter). But the bundle does not reach tca://correspondent/myapp
> and
> >     does not appear in the bundle lists of any dtnd.
> >
> >     Cheers,
> >     Janico
> >
> >     > Thanks
> >     > Zahir
> >     >
> >     > On 1/30/07, *Janico Greifenberg* < [email-masked]
> >     <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]
> >>>
> >     > wrote:
> >     >
> >     >     Hi Zahir,
> >     >
> >     >     we seem to be getting somewhere! I think the problem is in
> >     >     get_payload_str(). The data buffer is zeroed out so the result
> >     string
> >     >     does not know where it ends. Applying the attached diff fixes
> the
> >     >     strange characters.
> >     >
> >     >     But still my bundle does not reach the intended recipient. It
> >     seems to
> >     >     get stuck in a loop at the gateway instead of being forwarded
> >     over the
> >     >     opportunistic link that the dtnd lists as open. So, once
> again, I
> >     >     send a
> >     >     debug level logfile of the gateway.
> >     >
> >     >     Cheers,
> >     >     Janico
> >     >
> >     >     Zahir Koradia wrote:
> >     >     > Hi Janico,
> >     >     > The problem seems to happen even before we reach parser of
> >     control
> >     >     messages.
> >     >     >
> >     >     > [1170144963.989308 /dtn/tca debug] TcaRouter: tca bundle
> >     received
> >     >     > [tca://homeagent/admin] -> [tca://localhost/bundlelayer] :
> >     >     > 'add_route:tca://correspondent10/myapp
> >     >     > tcp://jgre.openvpn.informatik.uni-
> >     bremen.de§Eahr ²¶F°œ/'
> >     >     >
> >     >     > This line is printed as soon as we enter the function
> >     >     > handle_bundle_received called on a bundle received event.
> >     The function
> >     >     > get_payload_str is used to get the bundle payload. I have a
> >     feeling
> >     >     > that's where the problem lies. My guess is that the payload
> size
> >     >     > returned by b->payload_.length() is faulty.
> >     >     >
> >     >     > Could you just print it and check if the length is more than
> the
> >     >     number
> >     >     > of characters sent. If this is the case then we can ask Mike
> if
> >     >     anything
> >     >     > has changed in the treatment of bundle payload over the past
> >     >     revisions.
> >     >     >
> >     >     > Thanks
> >     >     > Zahir
> >     >     >
> >     >
> >     >
> >     >
> >
> >     _______________________________________________
> >     dtn-users mailing list
> >     [email-masked] <mailto:[email-masked]>
> >     http://mailman.dtnrg.org/mailman/listinfo/dtn-users
> >     <http://mailman.dtnrg.org/mailman/listinfo/dtn-users>
> >
> >
>
>
> _______________________________________________
> dtn-users mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-users
>