Why doesn't udp_recv callback contain the received netif?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Why doesn't udp_recv callback contain the received netif?

wayne.uroda@tridentrfid.com
Hi,

Please forgive me if this is a stupid question.

I am writing a DHCP server and using udp_recv functionality to handle incoming broadcast messages on a udp pcb.
I have enabled the BROADCAST flag on the PCB and I can receive the incoming packets just fine. The udp pcb is bound to ip_addr_any.

When it comes time to respond to the DHCP discover message, I must use udp_sendto_if function. Without specifying the interface, any send fails with a routing error because all addresses associated with this first message are either 0.0.0.0 or 255.255.255.255 (the only genuine address available is the source hardware address, which is useless for determining the associated netif).

Here is where I am confused. In order to call udp_sendto_if, I need to know the netif. If I look at the udp_input function, the netif is available there and could easily be passed as a simple parameter to the recv callback function.

Any time I get the urge to modify lwip itself my first thought is, I must be missing something simple, or doing something wrong. I assume there is some foundational piece of information I am missing?
If not, should we add the netif as a parameter to the udp recv callback?

Thanks
- Wayne

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't udp_recv callback contain the received netif?

Dirk Ziegelmeier-2
Simply call ip_current_netif() to get it

Ciao
Dirk


On Tue, Jun 25, 2019 at 5:11 AM Wayne Uroda <[hidden email]> wrote:
Hi,

Please forgive me if this is a stupid question.

I am writing a DHCP server and using udp_recv functionality to handle incoming broadcast messages on a udp pcb.
I have enabled the BROADCAST flag on the PCB and I can receive the incoming packets just fine. The udp pcb is bound to ip_addr_any.

When it comes time to respond to the DHCP discover message, I must use udp_sendto_if function. Without specifying the interface, any send fails with a routing error because all addresses associated with this first message are either 0.0.0.0 or 255.255.255.255 (the only genuine address available is the source hardware address, which is useless for determining the associated netif).

Here is where I am confused. In order to call udp_sendto_if, I need to know the netif. If I look at the udp_input function, the netif is available there and could easily be passed as a simple parameter to the recv callback function.

Any time I get the urge to modify lwip itself my first thought is, I must be missing something simple, or doing something wrong. I assume there is some foundational piece of information I am missing?
If not, should we add the netif as a parameter to the udp recv callback?

Thanks
- Wayne
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't udp_recv callback contain the received netif?

wayne.uroda@tridentrfid.com
Wow, cool.

Question: how is this thread safe - because the callback happens inside the
TCP thread and so only one packet is processed at a time?

Thanks
- Wayne



--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't udp_recv callback contain the received netif?

Dirk Ziegelmeier-2

On Tue, Jun 25, 2019 at 11:12 AM [hidden email] <[hidden email]> wrote:
Wow, cool.

Question: how is this thread safe - because the callback happens inside the
TCP thread and so only one packet is processed at a time?

Thanks
- Wayne



--
Sent from: http://lwip.100.n7.nabble.com/lwip-users-f3.html

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: Why doesn't udp_recv callback contain the received netif?

goldsimon@gmx.de
In reply to this post by wayne.uroda@tridentrfid.com
Am 25.06.2019 um 05:11 schrieb Wayne Uroda:

> Hi,
>
> Please forgive me if this is a stupid question.
>
> I am writing a DHCP server and using udp_recv functionality to handle
> incoming broadcast messages on a udp pcb.
> I have enabled the BROADCAST flag on the PCB and I can receive the
> incoming packets just fine. The udp pcb is bound to ip_addr_any.
>
> When it comes time to respond to the DHCP discover message, I must use
> udp_sendto_if function. Without specifying the interface, any send fails
> with a routing error because all addresses associated with this first
> message are either 0.0.0.0 or 255.255.255.255 (the only genuine address
> available is the source hardware address, which is useless for
> determining the associated netif).
>
> Here is where I am confused. In order to call udp_sendto_if, I need to
> know the netif. If I look at the udp_input function, the netif is
> available there and could easily be passed as a simple parameter to the
> recv callback function.
>
> Any time I get the urge to modify lwip itself my first thought is, I
> must be missing something simple, or doing something wrong. I assume
> there is some foundational piece of information I am missing?

Obviously, you *are* missing a foundational piece of information: we aim
for backwards compatibility. I think we can be proud to say that old
applications mostly still work with newer versions of lwIP. Having the
netif might be good, but it's not worth bracking backwards compatibility.

Regards,
Simon

_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users