<div dir="ltr"><div dir="ltr">> At least earlier versions of ergw had support for the kernel GTP-U plane, why > not simply use that code?<br>My experience with erlang is very limited so far, that's why I was attracted with libgtpnl, because I was able to create a GTP tunnel by invoking only 2 lines <br>  # ./gtp-link add</div><div dir="ltr"># ./gtp-tunnel add<br><br>> They created <a href="https://github.com/travelping/gen_netlink">https://github.com/travelping/gen_netlink</a> to talk netlink from > erlang, including gtpnl support.<br>Yes, I saw it. but even trying to build it from tetrapak, I have made some search but I'm struggling:<br># tetrapak build check (don't even know what is tetrapak :-) )<br><br>The creators of these libraries already answer some questions from me in the public erlang mailing list, but about general erlang related questions. I didn't find any public mailing list to these libraries, so I gave up.<br><br>> You cannot do that, sorry.<br>> This will obviously not work.  <br></div><div dir="ltr">> You need to manage the socket from your program.<br>> You are asking for the impossible.<br><br>I totally agree with you but I've got some idea this afternoon as a workaround.<br>I think I can forward the echo-request that I received on my network interface (owned by gtpnl at GTP-U) to my Erlang program by using some Linux helper like <br>  # tcpdump<br>     # replay the traffic by tcpreplay to another interface owned by my Erlang program<br>     # or I can Write them to a Linux named pipe fifo, and get it from Erlang<br>      <br>By this way, I would be able to craft an echo-response for GTP-U I think.</div><div dir="ltr"><br>Those steps are not related to libgtpnl anymore, so would be off-topic.<br><br>But Clarifications regarding libgtpnl is very clear for me now.<br><br>Thank you,</div><div dir="ltr"><br></div><div>P.S: I will update here if this echo-response at GTP-U side from my erlang works for me. Have a nice day.</div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 21 août 2020 à 15:40, Harald Welte <<a href="mailto:laforge@gnumonks.org">laforge@gnumonks.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Aug 21, 2020 at 09:53:34AM +0300, Papa Tana wrote:<br>
> But for GTP-U, I was trying to listen in port 2152 several times, and it<br>
> yields an error that I cannot listen on it, port 2152 is already used.<br>
<br>
You cannot do that, sorry.<br>
<br>
> > You manage all your UDP sockets.<br>
> > your application is responsible for receiving and responding to any GTP-U<br>
> packets there.<br>
> As I said, I am using Erlang as a userspace program.<br>
> And when I create a tunnel, I "just" send a basic command exec to the Linux<br>
> by open_port like this:<br>
<br>
This will obviously not work.  You need to manage the socket from your program.<br>
<br>
IF it's erlang, you either have to speak netlink directly from within Erlang,<br>
or you need to add some native functions for calling libgtpnl.<br>
<br>
> So I don't have any idea on how to listen to 2152 as my Erlang program is<br>
> forbidden to listen on it when libgtpnl is invoked.<br>
<br>
You are asking for the impossible.  You need to open the socket from within your<br>
program. You cannot crate a second socket for what you are trying to do.<br>
<br>
At least earlier versions of ergw had support for the kernel GTP-U plane,<br>
why not simply use that code?<br>
<br>
They created <a href="https://github.com/travelping/gen_netlink" rel="noreferrer" target="_blank">https://github.com/travelping/gen_netlink</a><br>
to talk netlink from erlang, including gtpnl support.<br>
<br>
-- <br>
- Harald Welte <<a href="mailto:laforge@gnumonks.org" target="_blank">laforge@gnumonks.org</a>>           <a href="http://laforge.gnumonks.org/" rel="noreferrer" target="_blank">http://laforge.gnumonks.org/</a><br>
============================================================================<br>
"Privacy in residential applications is a desirable marketing option."<br>
                                                  (ETSI EN 300 175-7 Ch. A6)<br>
</blockquote></div></div>