[OOR-Users] [LISPmob-users] LISPMob-0.5.0

Sat Jun 25 17:58:41 CEST 2016

Hi Alberto,
This is a conversation started last year on LISPMob-0.5.
As a recap, it is was a question about 'ping request from the lisp-mn no more encapsulated to PxTR but sent directly to the correspondent node'. I recently tried to run some experiments on the lispmob-based network but realised that, the outbound packets are not encapsulated but send directly to the CN. We thought back then, as answered by you, that "it is a bug in the PxTR implementation. It discards Map Request Probe from LISPmob 0.5 and as a consequence the MN set the locator of the PeTR to down." but what I just realised is that, the Map-Request (RLOC-probe) from the MN to the PxTR has no source EID specified as you will notice in the attached screenshot. The only record it contains is an all zeros IP address, hence the reason why the pxtr cannot respond leading the MN to start sending packets without tunnelling.
It is likely that the problem is from the lispmob code (or the configuration file) and not the pxtr itself.
Could the OOR implementation interact with the pxtr?
Regards, Musab Isah
Research Student,School of Computing and Communications,D29, InfoLab21Lancaster University

      From: Alberto Rodriguez-Natal <arnatal at ac.upc.edu>
 To: MUSAB MUHAMMAD <nmusabu at yahoo.com> 
Cc: Albert López <alopez at ac.upc.edu>; "users at lispmob.org" <users at lispmob.org>
 Sent: Tuesday, November 24, 2015 11:03 AM
 Subject: Re: [LISPmob-users] LISPMob-0.5.0

Hi Musab,

Thanks for letting us know. Glad to see that it works for you now :)

Best,
Alberto

On Tue, Nov 24, 2015 at 10:55 AM, MUSAB MUHAMMAD <nmusabu at yahoo.com> wrote:

Hi Albert,
Apologies to all. I actually messed up the routes on my testbed after a reboot of some nodes on the testbed. I got it back working now.
Thanks for your prompt response. Musab Isah
Research Student,School of Computing and Communications,D29, InfoLab21Lancaster University 

    On Monday, November 23, 2015 11:15 AM, Albert López <alopez at ac.upc.edu> wrote:

  If I understood correctly,  it works until you turn down the MN and turn up it again isn't it?  Does the MN start with a new RLOC when it starts again? If you don't turn down the MN the communication is maintained or it starts to send native packets after some seconds? Could you provide log files?

 Best regards

 Albert

 On 23/11/15 09:00, MUSAB MUHAMMAD wrote:

  Hi Alberto, 
  I have downloaded the zip file of the updated pxtr and ran it (didn't use git at the onset, git pull wouldn't work for me I suppose) but seem to be having the same issue of packet being sent to the CN directly without tunnelling. Actually, this time the pxtr is not even responding to any LISP-MN's packet. It worked for sometime but stopped after restarting the mobile node. I can see from the logs that the pxtr is receiving messages from the mn but couldn't respond back to them. Could you please advise? 
  Thanks,       Musab Isah
  Research Student, School of Computing and Communications, D29, InfoLab21 Lancaster University     

      On Friday, November 6, 2015 10:27 AM, Albert López <alopez at ac.upc.edu> wrote:

    Hi Musab,

 Regarding Map Register,  is the normal behaviour in 0.5. When LISPmob starts, it sends a map register for each EID and then it starts a SMR  procedure to notify PiTR. The SMR process include a second Map Register. May be we will change this behaviour in a next release to only send one Map Register at the begining.
 The second problem is a bug in the PxTR implementation. It discards Map Request Probe from LISPmob 0.5 and as a consequence the MN set the locator of the PeTR to down. I have fixed this problem so I recommend to do a "git pull"  of the PxTR. Thanks for notify us this problem :-)

 Best regards

 Albert

 On 05/11/15 20:51, MUSAB MUHAMMAD wrote:

  Hi Alberto, 
  I resorted to adding default route (with a global address) manually using a script and I am able to  get it to run. 
  Just few more questions though, from my wireless interface pcap file (attached), you can see that 'Map-Register' messages (from packet No. 6) were sent twice by the lisp-mn and hence the two 'Map-Notify'  replies. What could be the reason please? And from packet No. 145, ping request from the lispmn were no more encapsulated to PxTR but sent directly to the correspondent node. I assume that the  lisp-mn somehow understand that there is no ingress-filtering on the default gateway and decided to optimise its routing. But what is your take on that please? I attached the log file as well. 
  Thanks, 
  Musab 

        Musab Isah
  Research Student, School of Computing and Communications, D29, InfoLab21 Lancaster University     

       On Thursday, November 5, 2015 5:29 PM, MUSAB MUHAMMAD <nmusabu at yahoo.com> wrote:

     Hi Alberto, 
  By wlan0, I believe you meant wlan2. I believe there is a  default route for wlan2 in the table that reads 'default via fe80::fa1a:67ff:fec1:8af5 dev wlan2  proto ra  metric 1024  expires 4sec hoplimit 64'. 
  And I run lispmob-0.4.0 with the current configuration. 
  Regards,       Musab Isah
  Research Student, School of Computing and Communications, D29, InfoLab21 Lancaster University     

        On Thursday, November 5, 2015 8:51 AM,  Albert López <alopez at ac.upc.edu> wrote:

    Hi Musab,

 You have to add a default route  for wlan0 in order it to work. Try it and  let me know if it solve the  problem.

 Best regards

 Albert

 On 04/11/15 16:57, MUSAB  MUHAMMAD wrote:

  Hi, 
  I downloaded and ran the latest  version of LISP but couldn't get  it to work as expected.  There don't seems to be any activity  on the wireless interface defined in the configuration  file. Perhaps I got something  wrong in my setting/configuration.  Please see attached log, configuration, and route files. 
  Thanks.       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/20160625/8fbadea4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot from 2016-06-25 16:49:04.png
Type: image/png
Size: 302356 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20160625/8fbadea4/attachment-0001.png>