• Welcome to Andy's Workshop Forums. Please login or sign up.
 
April 28, 2024, 03:53:06 am

News:

SMF - Just Installed!


Obtaining the IP of the sender of a UDP packet

Started by Ozflip, November 09, 2014, 06:35:14 pm

Previous topic - Next topic

Ozflip

First - If I'm asking too many questions, please let me know and I'll quiet down!

I'm wondering what the correct (anticipated by you) means of getting the sender of a UDP packet is? We need the sender to know who to reply to!  ;D

For a TCP packet you have provided the sender in the event, but not for the UDP asynchronous receive event.

At the moment the only obvious way I can see is to subscribe one level down to the network layer onReceive and then decode the packet and verify the type and port manually, or modify the source for the UdpdatagramEvent and udp to include the source address.

Or (more likely) am I just thick and missing something obvious?

Thanks,

Phil

Andy Brown

Nope, you're right, this is an omission. The IP header information should have been made available by the UDP module to both the async event API and the sync method API. I've fixed both APIs and pushed to master. See issue and commit. The examples have been updated to report the sender IP address.

When you do send a reply, do make sure you're not doing it from the async UDP event handler because you're in an IRQ context there. It's best to take what you need from the incoming event and set a 'ready' flag for your main non-IRQ loop like the demo code does.

No such thing as too many questions; the library is improving because you're reporting your experiences. By all means keep them coming.
It's worse than that, it's physics Jim!

Ozflip

November 11, 2014, 12:28:25 am #2 Last Edit: November 11, 2014, 03:36:28 am by Ozflip
Fantastic - thank you. It works like a charm.

QuoteWhen you do send a reply, do make sure you're not doing it from the async UDP event handler because you're in an IRQ context there
Definitely, and the other concern is that (like any interrupt) you want to keep it quick. A slow handler runs the risk of losing the next packet, too.

Again - thank you. I really love this stack implementation.

Phil