Closed niallfleming closed 3 years ago
does the other side send on the same port as it expects the response? try to send the replay to constant port number instead of Udp.remotePort()
Like this?
Udp.beginPacket(Udp.remoteIP(), 6454); //Udp.remotePort()
Serial.println(ReplyBuffer);
Udp.write(ReplyBuffer);
Udp.endPacket();
Same behaviour.
OK so it was related to line endings in the library. Once I had eradicated all the ^M dos line endings it seems to work with the original code.
Can you say why I don't see any serial console prints from the library - I defined
#define UIPETHERNET_DEBUG_UDP 1
prior to including EthernetENC and so on?
Oh I see. Thanks.
So I've got further, I want it to listen on the broadcast (network address) as well as it's own IP, it does respond on unicast, but that's not what I need in this situation. I see that you're limiting broadcast to ARP in Enc28J60Network.cpp
// For broadcast packets we allow only ARP packtets
// All other packets should be unicast only for our mac (MAADR)
Is there a way to override this behaviour? I presume that there is too much broadcast traffic so it was limited for this reason? -- ArtNet packets are defined here: https://art-net.org.uk/how-it-works/streaming-packets/artdmx-packet-definition/
Here's a trace of the packet emitted from the controller (Mac) to the broadcast address:
192.168.0.104.6454 > 192.168.0.255.6454: [udp sum ok] UDP, length 530
0x0000: 4500 022e 6204 0000 4011 9403 c0a8 0068 E...b...@......h
0x0010: c0a8 00ff 1936 1936 021a 9d31 4172 742d .....6.6...1Art-
0x0020: 4e65 7400 0050 000e 3000 0000 0200 ffff Net..P..0.......
0x0030: ffff ffff ffff ffff ffff ffff ff00 0000 ................
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
size of the receive buffer is only 2 kB. to process broadcast every broadcast packet must be stored to receive buffer and then handled by the library. the library handles the packets by default every 100 milliseconds (only if some library function is called).
you can enable receiving of broadcast packages in Enc28J60Network.cpp
writeReg(ERXFCON, ERXFCON_UCEN|ERXFCON_CRCEN|ERXFCON_PMEN|ERXFCON_BCEN);
This is the not the code I want to run, but I was trying to attack it from another angle.
This is being run on a nano with an enc28j60 ethernet shield. I receive the udp message to the serial console as expected, but the client never receives the ack in response. local firewall is disabled.
I confirmed that the theory works with a python version, in case it was netcat being weird, but it behaved the way I expected, I sent text, and I received it back.
Here's my test code, ultimately I'm trying to work out why I wasn't seeing the subscription coming back from the nano to my ArtNet server. I tried removing the line suggested in #3 in case it was a similar thing, but no dice.