[OOR-Users] [LISPmob-users] Modifying LISPMob Code
Albert
alopez at ac.upc.edu
Tue Mar 15 11:15:00 CET 2016
Hi Musab,
You probably see a Map-Referral because you are reusing the
buffer(lbuf_t). When you call the function to send the packet, the ip
and udp packets are added to the buffer of the message so when you try
to reuse the packet, the pointers of the buffer have been modified and
results in a packet that is different from what you expect. To
understand what I am explaining, have a look on lbuf_t,
tun_control_dp_send_msg which use the function pkt_push_udp_and_ip.
Best regards
Albert
El 14/03/16 a les 13:13, MUSAB MUHAMMAD ha escrit:
> Hi Albert,
>
> Just an update to the questions I sent earlier. I realised that
> immediately duplicating the existing 'send_msg(&xtr->super, mrep,
> uc)', i.e.:
>
> send_msg(&xtr->super, mrep, uc);
> send_msg(&xtr->super, mrep, uc);
>
> ...produces a Map-Reply followed by a Map-Referral, so the problem is
> not necessarily related to using the alternative uconn_t nuc. A
> lisp_msg_hdr_to_char(mrep) call between them suggests that mrep hasn't
> changed. If we duplicate the whole code that builds up mrep, the
> second message is a Map-Reply, but with 0 records.
>
> There seems to be state in xtr->super and/or xtr->local_mdb that
> changes the interpretation/creation of mrep. Maybe we should just try
> to send a non-LISP message (to our location server), if we can get
> hold of the right socket that send_msg is using, and use
> send_raw_packet on it...?
> Regards,
>
> Musab Isah
> Research Student,
> School of Computing and Communications,
> D29, InfoLab21
> Lancaster University
>
>
> ------------------------------------------------------------------------
> *From:* MUSAB MUHAMMAD <nmusabu at yahoo.com>
> *To:* Albert López <alopez at ac.upc.edu>; "users at openoverlayrouter.org"
> <users at openoverlayrouter.org>
> *Cc:* Steven Simpson <ss at comp.lancs.ac.uk>
> *Sent:* Friday, March 11, 2016 7:16 PM
> *Subject:* Re: [LISPmob-users] Modifying LISPMob Code
>
> Hi Albert,
>
> I have added the code below on line 442 of
> lispmob-0.5.1/lispd/control/lisp_xtr.c:
>
> /* SEND MAP-REPLY */
> if (map_reply_fill_uconn(xtr, itr_rlocs, uc) != GOOD){
> LMLOG(LDBG_1, "Couldn't send Map Reply, no itr_rlocs reachable");
> goto err;
> }
> LMLOG(LDBG_1, "Sending %s", lisp_msg_hdr_to_char(mrep));
> send_msg(&xtr->super, mrep, uc);
> +++++++++++++++++line 441
> uconn_t nuc = *uc;
> nuc.ra = *xtr->loc_server;
> assert(!xtr->signal_dropping);
> if (xtr->signal_dropping) {
> /* Send Map-Reply(NULL locator) to loc-server. */
> lisp_msg_put_neg_mapping(mrep, deid, 0, ACT_NO_ACTION,
> A_NO_AUTHORITATIVE);
> } else {
> /* Send same Map-Reply to loc-server as sent to PiTR. */
> }
> send_msg(&xtr->super, mrep, &nuc);
> +++++++++++++++
>
> Note that xtr->signal_dropping is false.
>
> The intention is to duplicate the map-reply message sent to the PiTR
> by sending it to our loc-server. But after observing the packets on
> wireshark (see attached, filter 'lisp'), I realised that the second
> map-reply packet is actually sent as map-referral packet. What could
> be possibly the reason for that please? Are there any issues using the
> auto uconn_t nuc? Will send_msg attempt to de-allocate it? Can such
> an object created ad-hoc be used, or does some other component need to
> be informed before hand that the loc-server address is a potential peer?
>
> Regards,
> Musab Isah
> Research Student,
> School of Computing and Communications,
> D29, InfoLab21
> Lancaster University
>
>
> ------------------------------------------------------------------------
> *From:* Albert López <alopez at ac.upc.edu>
> *To:* MUSAB MUHAMMAD <nmusabu at yahoo.com>;
> "users at openoverlayrouter.org" <users at openoverlayrouter.org>
> *Cc:* Steven Simpson <ss at comp.lancs.ac.uk>
> *Sent:* Thursday, March 3, 2016 2:53 PM
> *Subject:* Re: [LISPmob-users] Modifying LISPMob Code
>
> Hi Musab,
>
> First I would like to let you know that we are now OpenOverlayRouter
> <http://www.openoverlayrouter.org/>. If possible use the new OOR
> mailing lists to contact us from now on :)
>
> I will try to give you some answers inline:
>
> On 01/03/16 18:40, MUSAB MUHAMMAD wrote:
>> Hi all,
>>
>> I want to introduce a new network entity, Location Server (LS) for
>> some reason, and have MNs and PITRs interact with it as follows:
>>
>> * When an MN detects its interface signal dropping (which is going
>> to be determined by an external program), /MN should issue
>> Map-Reply(LS) to PITR, and Map-Reply(NULL) to LS/.
>> * When an MN's interface comes back up after binding to a new
>> address RLOC, and the MN (eventually) issues Map-Reply(RLOC) to
>> PITR, /MN should also issue Map-Reply(RLOC) to LS/.
>>
> Are you trying to modify the SMR process to also send a Map Reply to
> the LS with the specified RLOCs of the previous point, or you are
> sending directly map replys?
>
>> As we know, a Solicit-Map-Request (SMR) is sent to PITR at interface
>> up, and the PITR sends a Map-Request to the MN, which then sends a
>> Map-Reply with its new RLOC. tr_recv_map_request() in
>> control/lisp_xtr.c appears to handle the incoming Map-Request and
>> respond with a Map-Reply, so I intend to modify this function to deal
>> with both interaction, and supply it through the lisp_xtr_r structure
>> with a flag to distinguish the two behaviours, and the LS address.
>> The flag will be set if the signal drop has been detected, and
>> cleared if the interface has come back up. There are two modifications:
>>
>> * If the flag is set, Map-Reply(LS) will be sent to PITR instead of
>> Map-Reply(RLOC).
>> * An additional Map-Reply(flag ? NULL : RLOC) will be sent to LS.
>>
> The SMR process not only affects to the PiTR but also all the entries
> of the map cache.
>> For the first change, can someone explain how the RLOC currently gets
>> set in the new message? Is it uc->la, for example? Or do I need to
>> build a new mapping_t?
> uc is just used to indicate the IPs and the udp ports to be used to
> send the packet. You will probably have to generate a mapping with the
> new RLOCs you want to use
>>
>> For the second change, I don't strictly have to use a Map-Reply, as
>> my code will be talking to my LS, but it would be nice to re-use the
>> message type. What could I do to express some sort of
>> Map-Reply(NULL)? Use lisp_msg_put_neg_mapping, perhaps? Or just an
>> all-zero IP address?
> Yes, using a negative map reply (locator_count = 0) will be useful.
> Other possibilities could be to use priority 255 in order to indicate
> to not use the locators. When you create the mapping you also add a
> locator for the LS and then you change priority to 255 of the locators
> you don't want to be used.
>>
>>
>> It looks like send_all_smr_and_reg() sends SMR, so that will result
>> in a later invocation of tr_recv_map_request(). It is only invoked
>> from send_all_smr_cb(), which appears to be invoked by a timer. Is
>> that timer set as a result of a new binding, i.e., so that SMR will
>> be sent a short moment after the new binding is established? IOW,
>> does the invocation of send_all_smr_cb() imply that the lisp_xtr
>> object has learned of the new binding? If so, I intend to clear the
>> flag inside send_all_smr_cb(), so that the subsequent (indirect)
>> invocation of tr_recv_map_request() will behave normally to PITR (as
>> well as send an additional message to LS). I will also add a
>> non-static function to set the flag, and then call
>> send_all_smr_and_reg(). I will later arrange to call this new
>> function when the signal drop is detected.
> We have a structure for each interface (iface_locators) which contain
> the changes produced in the interface. When we receive a netlink
> message we update this structure and we program the SMR timer. If we
> receive a new netlink message before the timer expires, we reprogram
> the timer again. When timer expires we call send_all_smr_cb where we
> check the iface_locators structures to decide if we have to do a SMR
> or if we had a flapping situation and we don't need to initiate the SMR.
>
> I hope with this information you can proceed with your development.
>
> Best regards
>
> Albert
>
>>
>> Regards,
>> Musab Isah
>> Research Student,
>> School of Computing and Communications,
>> D29, InfoLab21
>> Lancaster University
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20160315/6e0a7f1d/attachment-0001.html>
More information about the Users
mailing list