Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make multicast_address optional #21

Open
mon opened this issue Apr 23, 2024 · 2 comments
Open

Make multicast_address optional #21

mon opened this issue Apr 23, 2024 · 2 comments

Comments

@mon
Copy link
Contributor

mon commented Apr 23, 2024

I'd like to use this library to program a device that uses BOOTP. BOOTP benefits greatly from the "which interface did this packet come from" aspect of the library, but uses broadcast packets instead of multicast. Specifically, you'd listen on all ports for a BOOTP request, then reply to the port it came from to start upload.

Before I start work, I'd like to check on the best way to implement

  • MulticastSocket::all_interfaces/with_options - Change the argument to an Option<>, or move it into the options struct with a default of "no group"? I don't think it's possible to avoid an API break, unless you'd prefer new all_interfaces_without_group or something
  • Binding to a port - make it so this is the required argument instead?
  • MulticastSocket::send - split into send with an address and send_to_group, or keep send as-is and add send_to?

p.s. I hope you're not too bothered by all my activity! Basically, I have an unpublished crate similar to multicast-socket, but then I found yours which uses far fewer resources, doesn't need threads, works properly on Linux etc... So I'm slowly bringing across features so I can drop my terrible impl.

@bltavares
Copy link
Owner

Specifically, you'd listen on all ports for a BOOTP request, then reply to the port it came from to start upload.

I'm not as familiar with the protocol, so take that in consideration for the next comments.

It would help me if you could share an example/bootp.rs file of the desired API for me to understand it better.

p.s. I hope you're not too bothered by all my activity!

Not at all :) Feel free to keep posting issues, I just can't promise you any fast response tho.

  • MulticastSocket::all_interfaces/with_options
  1. Could using SocketAddrV4::new([172, 31, 255, 255].into(), 0) possibly work already?
  • Binding to a port - make it so this is the required argument instead?
  1. There is already support for specifying a port to listen, so I'm unsure on this part.
  • MulticastSocket::send - split into send with an address and send_to_group, or keep send as-is and add send_to?

I think a send_to might be the best option from my current understanding.

@mon
Copy link
Contributor Author

mon commented Apr 29, 2024

I guess I should explain BOOTP a little better, as it may help. The existing way to specify a port won't work, because it forces me to pick a multicast group (which BOOTP doesn't have).

BOOTP is pretty much just DHCP (DHCP is actually an extension of the BOOTP protocol). A good chunk of embedded devices' bootloaders will

  • Send a broadcast (i.e. 255.255.255.255) packet on the BOOTP port- saying "I am here, I am this board, please reply"
  • Wait for a broadcast response saying "I am the server, this is my IP, connect to this TFTP server and download your firmware"

The pseudocode would be something like:

let mut socket = MulticastSocket::new_on_port_only(67); // broadcast only, no multicast ADD_MEMBERSHIP
while let message = socket.recv() {
    if !valid_bootp_packet(message.data) {
        continue;
    }
    let mut reply = create_bootp_response(message.data);
    reply.to = message.origin_address;
    reply.server_addr = message.interface.ip;
    socket.send_to(&message.interface, &reply.to_vec(), INADDR_BROADCAST);
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants