The Amiga Future 147 will be released on the 5th November.
Amiga Future Aktion: Probeheft für 1 Cent
Im Augenblick gibt es im Shop unter https://www.amigashop.org die Möglichkeit ein Probeheft der Amiga Future für 1 Cent (+ Versandkosten, inkl. MwSt.) zu bestellen.
Amiga Future Promotion: Sample issue for 1 cent
We have a special offer for all of you who’ve gotten a taste of it: Right now you can order an Amiga Future issue for 1 cent (plus shipping costs and included VAT) at https://www.amigashop.org.
8 posts • Page 1 of 1
Roadshow (68k and OS 4.1 FE) "only" supports DHCP offers via broadcast, not via unicast. Any plans on changing that?
Some info here: https://learningnetwork.cisco.com/thread/32255
"At Layer 2, the client's messages are always broadcast, and those of the server's can be unicast or broadcast depending on how vendor implemented it."
"DHCP servers and BOOTP relay agents may not be able to deliver DHCP messages to clients that cannot accept hardware unicast datagrams before the TCP/IP software is configured."
The reason I'm asking is because some DHCP servers have the broadcast offer disabled on purpose or it is broken. Most clients handle that well but not an Amiga running Roadshow which means you have to configure the IP address manually.
This sounds like it may be straightforward to implement. The network interface configuration file would need to support a new DHCP client option, though, to let you signal the server that you would like to receive unicast "offer" messages.
I can't promise it, but this looks like the perfect project for those days after Christmas when, finally, there's some time to catch up with all the work which you never got around to do
Sounds great! A question though, just to make things clear: This extra option for the interface configuration file isn't enough. Roadshow actually has to understand the unicast datagrams too, right? Before it actually has gotten an IP assigned.
Roadshow already handles this through the interface to the layer 2 (SANA-II) device.
When Roadshow receives inbound network traffic, which is eventually fed into the TCP/IP stack for processing, it always briefly checks if there is a DHCP client request pending.
If so, it looks into the packet, checks if it carries an IPv4 UDP payload, and that payload is intended for the BOOTP protocol (which DHCP is built on top of). If so, it decodes the BOOTP datagram and looks closely at the contents. If there is a DHCP server response inside (DHCPOFFER, DHCPACK), and that response's transaction number matches the transaction number of a pending DHCP client request, then a copy of the datagram is forwarded to the built-in Roadshow DHCP client.
This procedure works well both for broadcast and unicast traffic. In fact, I already tested this with the unicast modifications which I detailed in my previous forum message, and it appears to work.
Guess what, I even found a bug in my original DHCP client code: it forgets to set the broadcast flag in the DHCPREQUEST message (it only set it for DHCPDISCOVER messages). Hence, the server is free to send its DHCPACK response as unicast. So my code was probably accidentally more robust than it was required to be
Quick update: I just tested the DHCP unicast option with the ISC DHCP server reference implementation, and it worked
Looks like an update for Roadshow will be available shortly. I am still working on the documentation and the update/distribution archives...
It's getting really close now, isn't it?
Yes, it definitely is getting really close
I am currently working on getting Roadshow 1.12 into shape. The updated distribution archive (which is what you receive when you buy Roadshow from the online store) is almost ready for release, same goes for the demo version and the SDK. The update archive, which patches an already installed Roadshow 1.11 to version 1.12, still needs more work, though.
I am quite confident that everything will be ready by the end of this week.