UDP Server won't respond to client

[mynameisfiber]

Hey... I'm having a strange problem.
I'm trying to run a sample of the fragment code which starts a UDP echo server but the response never goes through,

s=net.createServer(net.UDP) 
s:listen(5683) 
s:on("receive",function(s,c) 
    print(c) 
    s:send("echo:"..c) 
end)

The board is fine and doesn't throw an error but my client (echo 'hello' | nc -u <ip> 5683) never sees the reply. This problem seems to have been reported in the past, but their solution doesn't seem applicable.

Any ideas?

NodeMCU custom build by frightanic.com
        branch: master
        commit: c8037568571edb5c568c2f8231e4f8ce0683b883
        SSL: false
        modules: node,file,gpio,wifi,net,i2c,tmr,uart
 build  built on: 2016-01-23 06:07
 powered by Lua 5.1.4 on SDK 1.4.0

[marcelstoer]

This problem seems to have been reported in the past, but their solution doesn't seem applicable.

It can't be considered "reported" unless there's an issue here on GitHub for this. Also, why do you consider the "solution" described in the blog post by @reischle not applicable for you? After all, default LUAL_BUFFERSIZE is still unchanged.

[pjsg]

This code works for me with the latest dev build. There is a more interesting question as to whether it ought to work!

In order for the s:send to send the packet back to the originator, the socket must have that destination address attached to it. The question is when does this happen (and it doesn't appear to be in the lua interface code, so it must be in the lwip stack or (more likely) the esp sdk). if you run

s=net.createServer(net.UDP) 
s:listen(5683) 
timer = 0
s:on("receive",function(s,c) 
    print(c) 
    s:send("echo:"..c) 
    timer = timer + 1
    tmr.alarm(timer % 4, 1000, 0, function()
      s:send("echodelay:" .. c)
      end)
end)

and do two nc connections to the nodemcu, and enter (say) 'one' in one session and 'two' in the order and hit enter within a second, then you get both of the delayed echos in one nc output.

However, running under a stress test with this code

s=net.createServer(net.UDP) 
s:listen(5683) 
timer = 0
s:on("receive",function(s,c) 
    tmr.delay(10) 
    print(c) 
    s:send("echo:"..c)
end)

showed that (at least for me) that the s:send from the receive callback always went to the address that the original packet came from.

[mynameisfiber]

@marcelstoer Yea, I didn't mean reported as in a ticket was filed... just that someone had seen something like this in the past. I don't consider it the same problem as what I'm having though because the firmware version I'm using already has the change he suggests.

@pjsg That is interesting! I'll flash with the new firmware as soon as possible. I wonder, is there a way to do a s:on("recievefrom", function(s, data, sender) so that I can manually send back some packets to the sender? At least on my current firmware, c:getpeername() gives me errors which leads me to believe that the c socket isn't connected. (Also, I have to warn you that this is my first lua project and I'm not sure if the nodemcu net.socket library returns a lua socket or it's own thing, so getpeername may not be a valid method of c to begin with) (EDIT: looking at the source I see the function is c:getpeer())

[devyte]

Just curious... shouldn't the s:listen(blah) call be done after the s:on("receive") setting for UDP servers? I saw that somewhere and found it curious, but here it's listen() and then on() (the other way around).

Or does the order not really matter?

[TerryE]

Yup, the documentation is wrong BTW. In the case of UDP the function argument to the listen command is ignored since a UDP session is connectionless. The on and send methods are bound to the net.server object not the net.socket one since a socket is never actually returned. The whole issue of the sendto IP is a botch. the sk:send() replies to the last IP address for a IP packet received. Since only one receive is processed within one task, if you so the send in the same task then it will go to the correct IP, but you can only do one send per task, so there is no guarantee that the second will go to the same IP. Here is my variant of Philips last example, which I connect to from two hosts through nc. If I send from HostA then HostB within the 5 sec dwell, then HostB receives both replies.

tmr.alarm(1,5000,0,function()
  print("IP:", wifi.sta.getip())
  s=net.createServer(net.UDP)
  local on,send,n=s.on,s.send,0
  s:listen(5683)
  on(s,"receive", function (sk,r)
    n = n%4 + 1
    tmr.alarm(n,5000,0,
      function() send(sk,"echo:"..r..tostring(sk))  end)
    end)
  end)

Just curious... shouldn't the s:listen(blah) call be done after the s:on("receive") setting for UDP servers?

It doesn't make a damn bit of difference so long as they are done in the same task.

[pjsg]

I took a look at the net code hoping to be able to add a getpeer call on a udp server socket, but it appears (to me) as though the espconn layer hides this information. I could add a new api to get this data, but that seems nasty,,,,,

[TerryE]

Phil, I am going through the net module, so the is little point in us both doing this unless we work together. I'd be interested in you comments on this latest GPIO low trigger issue though -- #1078

[TerryE]

I think that we've explained this issue, and addressing it will be a matter for #1080 anyway.