Hi Albert, Apologies for the earlier email. It turned out that it is wireshark that is somehow displaying the pings as 2 requests and 2 replies but it is only one packet as I later confirmed with tcpdump on the MN and pcap on the access point. Changing rloc-probe-interval to 0 solves the problem. Regards, Musab Isah Research Student,School of Computing and Communications,D29, InfoLab21Lancaster University
On Tuesday, April 28, 2015 2:28 PM, MUSAB MUHAMMAD <[email protected]>
wrote:
Hi Albert,
No worries about the delay. I deactivated RLOC probing and I have 2 ping
requests sent at a time, one encapsulated to PETR, and another one sent
directly to the CN. Two replies are received as well, one via the PETR.
Regards, Musab Isah
Research Student,School of Computing and Communications,D29, InfoLab21Lancaster
University
On Tuesday, April 28, 2015 12:27 PM, Albert López <[email protected]>
wrote:
Hi Musab,
First of all, sorry for the delay, I have been quite busy these weeks. I think
that I found the problem. The PeTR is not replying to RLOC Probe , so the xTR
set the RLOC of the PeTR to down. As no PeTR is available (all has interfaces
down due to rloc probe), the xTR try to send packets natively. Could you try to
deactivate RLOC Probing in the xTR (rloc-probe-interval = 0) to check it?
Best regards
Albert
On 27/04/15 13:04, MUSAB MUHAMMAD wrote:
Hi Albert,
I am just wondering if I have missed your reply to this email. If not, are
you able to look into it please?
Regards, Musab Isah
Research Student, School of Computing and Communications, D29, InfoLab21
Lancaster University
On Friday, April 10, 2015 1:10 PM, MUSAB MUHAMMAD <[email protected]>
wrote:
Hi Albert,
What I meant by the statement "I receive all replies via the PETR" is in
communicating with a CN, the outgoing packets are sent without encapsulation
but the replies are always encapsulated as you will see in the capture file
attached.
Regards,
Musab Isah
Research Student, School of Computing and Communications, D29, InfoLab21
Lancaster University
On Friday, April 10, 2015 8:39 AM, Albert López <[email protected]>
wrote:
Dear Musab,
Could you send me logs with debug level 3? What do you mean by " I receive
all replies via the PETR"?
Regards
Albert
On 09/04/15 18:24, MUSAB MUHAMMAD wrote:
Hi Albert,
Yes I have and I receive all replies via the PETR. Please find attached,
the lispd.conf file.
Regards,
Musab Isah
Research Student, School of Computing and Communications, D29, InfoLab21
Lancaster University
On Thursday, April 9, 2015 2:18 PM, Albert López <[email protected]>
wrote:
Hi Musab,
Do you have a proxy-etr configured in your mobile node? If the destination is
non lisp, the only reason to send it natively is that no proxy-etr is
configured in LISPmon.
Best regards
Albert
On 08/04/15 18:26, MUSAB MUHAMMAD wrote:
Hi Albert,
I am using version 0.4.1.
Regards, Musab Isah
Research Student, School of Computing and Communications, D29, InfoLab21
Lancaster University
On Wednesday, April 8, 2015 9:37 AM, Albert López <[email protected]>
wrote:
Hi Musab,
Sorry for the delay. Could you tell me which version of LISPmob are you
using? 0.4.1 or experimental?
Regards
Albert
On 04/04/15 19:26, MUSAB MUHAMMAD wrote:
Hi Albert, all
I have read in section 5 'LISP Mobile Node Operation' of the the latest
LISP-MN internet draft
(https://tools.ietf.org/html/draft-meyer-lisp-mn-12#page-7) as follows: "Note
that one subtle difference between standard ITR behavior and LISP-MN is that
the LISP-MN encapsulates all non-local, non-LISP site destined outgoing
packets to a PETR.".
But I can see on wireshark capture that the MN sends packets to the
destination non-LISP node without the tunnels. Is this some form of
optimisation, or a bug in the program?
Regards, Musab Isah
Research Student, School of Computing and Communications, D29, InfoLab21
Lancaster University
accesspoint_capture.pcap
Description: application/vnd.tcpdump.pcap
