@nexus

Quote:

Do you also don't use a network time protocol server to synchronize the system clock?

hum, well spotted. I'm using rnetmon and It's rnetmon who cause the problem.

Removing and roadshow reboot fine. too bad for me, said that came around AOS4.1U1 and AOS4.1U2 (I was wrong)


This is great because with the olsen's explanation, we know now that some tools, who run allways on the backgroud and access to internet, can block roadshow to reset is aked by the user.

Last edited by Mrodfr on 07-Sep-2010 at 06:12 PM.
Last edited by Mrodfr on 07-Sep-2010 at 06:09 PM.

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

@olsen

Quote:

So you better played the data exchange behind the BOOTP as straight as possible and did not make it unduly hard for the simplistic BOOTP UDP code to get its job done.

Well, DHCP is a bit more complex than BOOTP. But not much.

I did a quick test with Microsoft's DHCP server, and it will send DHCPOFFER and DHCPACK messages that are larger than the MTU, and they are of course fragmented at the server and reassembled at the client. As you said, though, it might not be an issue if you're limiting the number of options requested.

For my test, I did something you would hopefully never see in the wild, which was fill option 15 (domain name) with 3,000 bytes of garbage. It caused problems for the client, of course, but it's only purpose was to show that the DHCP server can and will send datagrams larger than the MTU, and a BOOTP relay agent (Cisco's in this case) will happily forward them. As you've seen, even an MTU of 576 bytes may not be enough. (EDIT: Furthermore, the MTU between the client and the relay may different than the path MTU between the relay and the server.)

Regarding the DF flag, I don't think it matters. You're broadcasting to the local subnet, so there's no path involved that might require fragmentation. The BOOTP relay agent shouldn't even be aware of the flag by the time it sees your DHCPDISCOVER, DHCPREQUEST, or DHCPINFORM messages.

Regarding DHCPINFORM, a client with a static address may still want to use DHCP to find gateways, DNS servers, etc.

EDIT2: A user with a SOHO router may not have a relay involved, but a user connected directly to an ISP almost certainly will. Regarding DHCP servers, I would test with common "Internet sharing" solutions as well, such as those supported by Windows and Mac OS.

Last edited by Trev on 07-Sep-2010 at 07:37 PM.
Last edited by Trev on 07-Sep-2010 at 07:35 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@abalaban

Quote:

abalaban wrote: @olsen Quote: olsen wrote: There may be no sound solution for this issue. The overall idea is that you can shut down the network if there are no clients pending. Some clients may hang onto their bsdsocket.library handles even after they have ceased using their network connection. The "NetShutdown" command will signal all these clients to cease operations and release the bsdsocket.library handles. But not all clients are able and willing to listen to this notification, or to act upon it. On a Unix system you could shut down uncooperative clients quite easily, but on AmigaOS you have to rely upon them to cooperate. If they don't play ball, you're stuck and cannot shut down the network operations. It's as ugly as that. It's interesting, can you point me on a documentation where how to code a cooperative client, or at least explain me how to do that ?

Opening bsdsocket.library will bind the Ctrl+C signal to the TCP/IP stack context. This means that if your client code calls a function which will have to wait for it to complete (e.g. calling recv() to read data from the network), sending the Ctrl+C signal to your client program will interrupt the function currently in progress. Technically, the Ctrl+C signal is actually bound to the Unix SIGINT handling logic within the TCP/IP stack code. The bsdsocket.library API permits you to rebind that signal, or you can disable its delivery completely (through the SocketBaseTags() function).

And it's not just the function in progress which is affected by the Ctrl+C signal, your client program will receive that signal, too. This is where it gets interesting. Because of how the signal is delivered, the client is expected to immediately process it. It should clean up after itself, close bsdsocket.library and quit if it can.

The "NetShutdown" command has the effect of sending all the bsdsocket.library clients the interrupt signal. It then waits for a message to indicate that all clients have released their instances of bsdsocket.library, or that a timeout occurs first.

In any case, the signals will be delivered, regardless of whether the forced shutdown procedure is successful or not. If "NetShutdown" does not succeed, some clients may have quit. But if it succeeds, then you have managed to cleanly shut down the network and all its clients.

Last edited by olsen on 07-Sep-2010 at 07:54 PM.

@Mrodfr

Quote:

Mrodfr wrote: @nexus Quote: Do you also don't use a network time protocol server to synchronize the system clock? hum, well spotted. I'm using rnetmon and It's rnetmon who cause the problem. Removing and roadshow reboot fine. too bad for me, said that came around AOS4.1U1 and AOS4.1U2 (I was wrong) This is great because with the olsen's explanation, we know now that some tools, who run allways on the backgroud and access to internet, can block roadshow to reset is aked by the user.

Now that sounds like an interesting idea to enhance Roadshow. I could integrate an NTP client into the library. The DHCP client code is able to pick up the NTP server(s) available in the local network, and that information could be put to good use.

@olsen

Quote:

olsen wrote: Now that sounds like an interesting idea to enhance Roadshow. I could integrate an NTP client into the library. The DHCP client code is able to pick up the NTP server(s) available in the local network, and that information could be put to good use.

Yes, please! It would be good for those that don't have a functional RTC in their classic Amigas (for example due to battery leakage or an A500 without memory extension).

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@Trev

Quote:

Trev wrote: @olsen Quote: So you better played the data exchange behind the BOOTP as straight as possible and did not make it unduly hard for the simplistic BOOTP UDP code to get its job done. Well, DHCP is a bit more complex than BOOTP. But not much.

With DHCP you can assume to some degree that the client will be capable of UDP within the context of a "real" TCP/IP stack. A genuine BOOTP client is probably just about able to send and receive individual UDP datagrams.

Quote:

I did a quick test with Microsoft's DHCP server, and it will send DHCPOFFER and DHCPACK messages that are larger than the MTU, and they are of course fragmented at the server and reassembled at the client. As you said, though, it might not be an issue if you're limiting the number of options requested.

Some DHCP servers will actually limit their responses to include only the amount of information that will fit into the space indicated by the client. That's better than crashing it, due to buffer overflows

Quote:

For my test, I did something you would hopefully never see in the wild, which was fill option 15 (domain name) with 3,000 bytes of garbage. It caused problems for the client, of course, but it's only purpose was to show that the DHCP server can and will send datagrams larger than the MTU, and a BOOTP relay agent (Cisco's in this case) will happily forward them. As you've seen, even an MTU of 576 bytes may not be enough. (EDIT: Furthermore, the MTU between the client and the relay may different than the path MTU between the relay and the server.)

Relay agents should use TCP to transport the DHCP data from one network to another, so there isn't much of a size or fragmentation issue. But I doubt that many DHCP clients are able to receive properly assembled UDP fragments. If I remember correctly, the UDP fragments carry sequence numbers (well, the IP headers do, but not the UDP headers), but unlike TCP fragments there is no well-defined time scale within which the fragments ought to be assembled, and in the right order, for the client to safely pick them up.

Quote:

Regarding the DF flag, I don't think it matters. You're broadcasting to the local subnet, so there's no path involved that might require fragmentation. The BOOTP relay agent shouldn't even be aware of the flag by the time it sees your DHCPDISCOVER, DHCPREQUEST, or DHCPINFORM messages. Regarding DHCPINFORM, a client with a static address may still want to use DHCP to find gateways, DNS servers, etc. EDIT2: A user with a SOHO router may not have a relay involved, but a user connected directly to an ISP almost certainly will. Regarding DHCP servers, I would test with common "Internet sharing" solutions as well, such as those supported by Windows and Mac OS.

I haven't tested this specific scenario yet, but yesterday's DHCP client code update now finally seems to work just fine with VxWorks based DHCP server solutions

@olsen

Quote:

Some DHCP servers will actually limit their responses to include only the amount of information that will fit into the space indicated by the client. That's better than crashing it, due to buffer overflows

Microsoft's client doesn't use the max length option, but it's not difficult to test.

Quote:

If I remember correctly, the UDP fragments carry sequence numbers (well, the IP headers do, but not the UDP headers), but unlike TCP fragments there is no well-defined time scale within which the fragments ought to be assembled, and in the right order, for the client to safely pick them up.

IP should handle packet reconstruction, but UDP can't guarantee delivery of all data. The loss of one or more fragments should result in the DHCP client not receiving the DHCPOFFER or DHCPACK, in which case it would retransmit DHCPDISCOVER, DHCPREQUEST, or DHCPINFORM accordingly. You know all this already, though.

Quote:

I haven't tested this specific scenario yet, but yesterday's DHCP client code update now finally seems to work just fine with VxWorks based DHCP server solutions

I imagine that will cover most of the SOHO routers out there.

I don't have a phone that supports tethering (not officially, anyway) over WiFi, but it would be good to have the code tested with mobile operating systems that support it. Linux-based phones probably won't be an issue.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@olsen

This is interesting. Microsoft's DHCP server ignores the message size option and will send all option data as long as an option's data doesn't cause the DHCP message, not including IP and UDP headers, to exceed 4095 bytes. This is loosely described in in http://support.microsoft.com/kb/321592, but it's off by one byte.

The following options are always returned:

DHCP Message Type (53)
Subnet Mask (1)
Renewal (T1) Time Value (58)
Rebinding (T2) Time Value (59)
IP Address Lease Time (51)
Server Identifier (56)

The buffer size is checked per option in the order the options appear in the parameter request list, so while a particular large option may be excluded, subsequent smaller options may not be.

The TFTP server name (66) and Bootfile name (67) options are truncated to fill the sname and file fields, respectively. I observed at least one case where bootfile was returned in file as well as options, and I'm not sure which rules the server uses to determine where to return the option.

EDIT2: I'm testing with Windows Server 2003 R2 Service Pack 2. Behavior may be different in newer version of Windows.

EDIT3: Here's a sample. You can see that I've requested Domain Name (15), but it's not returned because the value I've defined on the DHCP server is too long (3791 bytes):

FRAME: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = UDP - User Datagram; Packet ID = 52537; Total IP Length = 288; Options = No Options
UDP: Src Port: Unknown (3739); Dst Port: Bootstrap Protocol Server (67); Length = 268 (0x10C)
DHCP: Discover (xid=1859DF52)
DHCP: Op Code (op) = 1 (0x1)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 408543058 (0x1859DF52)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: Client IP Address (ciaddr) = n.n.n.n
DHCP: Your IP Address (yiaddr) = 0.0.0.0
DHCP: Server IP Address (siaddr) = 0.0.0.0
DHCP: Relay IP Address (giaddr) = 0.0.0.0
DHCP: Client Ethernet Address (chaddr) = xxxxxxxxxxxx
DHCP: Server Host Name (sname) =
DHCP: Boot File Name (file) =
DHCP: Magic Cookie = 99.130.83.99
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP Discover
DHCP: Client-identifier = (Type: 1) xx xx xx xx xx xx
DHCP: Maximum DHCP Message Size = (Length: 2) 02 40
DHCP: Parameter Request List = (Length: 2) 0f 03

FRAME: Base frame properties
ETHERNET: EType = Internet IP (IPv4)
IP: Protocol = UDP - User Datagram; Packet ID = 62712; Total IP Length = 328; Options = No Options
UDP: Src Port: Bootstrap Protocol Server (67); Dst Port: Bootstrap Protocol Client (68); Length = 308 (0x134)
DHCP: Offer (xid=1859DF52)
DHCP: Op Code (op) = 2 (0x2)
DHCP: Hardware Type (htype) = 1 (0x1) 10Mb Ethernet
DHCP: Hardware Address Length (hlen) = 6 (0x6)
DHCP: Hops (hops) = 0 (0x0)
DHCP: Transaction ID (xid) = 408543058 (0x1859DF52)
DHCP: Seconds (secs) = 0 (0x0)
DHCP: Flags (flags) = 0 (0x0)
DHCP: Client IP Address (ciaddr) = 0.0.0.0
DHCP: Your IP Address (yiaddr) = n.n.n.n
DHCP: Server IP Address (siaddr) = n.n.n.n
DHCP: Relay IP Address (giaddr) = n.n.n.n
DHCP: Client Ethernet Address (chaddr) = xxxxxxxxxxxx
DHCP: Server Host Name (sname) =
DHCP: Boot File Name (file) =
DHCP: Magic Cookie = 99.130.83.99
DHCP: Option Field (options)
DHCP: DHCP Message Type = DHCP Offer
DHCP: Subnet Mask = n.n.n.n
DHCP: Renewal Time Value (T1) = n Days, 0:00:00
DHCP: Rebinding Time Value (T2) = n Days, 0:00:00
DHCP: IP Address Lease Time = n Days, 0:00:00
DHCP: Server Identifier = n.n.n.n
DHCP: Router = n.n.n.n
DHCP: End of this option field

EDIT4: It's not really relevant, but the DHCP server also sends all data to 68/udp. I was sending dummy DHCPREQUEST messages from a toy socket, so it doesn't really matter. I was also behind a relay. I wasn't looking at frames on the server side, so it's also possible the relay stripped the message size option, though not likely (I hope).

EDITx: Trying to find a code/source tag.

Last edited by Trev on 09-Sep-2010 at 01:20 AM.
Last edited by Trev on 08-Sep-2010 at 09:20 PM.
Last edited by Trev on 08-Sep-2010 at 09:19 PM.
Last edited by Trev on 08-Sep-2010 at 09:18 PM.
Last edited by Trev on 08-Sep-2010 at 09:18 PM.
Last edited by Trev on 08-Sep-2010 at 09:09 PM.
Last edited by Trev on 08-Sep-2010 at 09:07 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: @olsen This is interesting. Microsoft's DHCP server ignores the message size option and will send all option data as long as an option's data doesn't cause the DHCP message, not including IP and UDP headers, to exceed 4095 bytes.

This is bad I suppose the Microsoft DHCP client code caught this issue by truncating the data received, so the server issue was not identified as a problem.

Off I go to add another layer of sanity checks to the DHCP client code in Roadshow...

@olsen

I have allready posted this (page 3) but I really would like to know what happened and if this problem could be resolved:


The explanation:

My internet connection is an old ADSL1. The modem need maybe 20 seconds to be synchronized and maybe 20 seconds for connected with the DNS.

As the Amiga boot too speedy for the modem, the addnetinterface check before the modem fully connected (between synchronized and DNS resolving by DHCP).

the result for me is on some internet pages, a too long waiting time about some parts of the internet page (with Ibrowse the blue square rest forever in blue).

The problem is just the DNS is checked verry often by the browser (blue square on Ibrowse). If I wait untill the modem is synchronized and DNS resolved by the modem and switch on the SAM, the DNS is only resolved the first access to internet by the brower.

For resolving that, I switch on the modem and wait the modem is completely connected before switching on the SAM.

Like that, the internet connection work fine and just only one time with Ibrowse the DNS resolving at start and all internet page after work fine.

Now most of the users maybe let their internet connection allways online or use ADSL2+ (verry short connection and synchronized time) but there are users like me with this kind of problem.

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

@Mrodfr

Quote:

Mrodfr wrote: @olsen I have allready posted this (page 3) but I really would like to know what happened and if this problem could be resolved: The explanation: My internet connection is an old ADSL1. The modem need maybe 20 seconds to be synchronized and maybe 20 seconds for connected with the DNS. As the Amiga boot too speedy for the modem, the addnetinterface check before the modem fully connected (between synchronized and DNS resolving by DHCP). the result for me is on some internet pages, a too long waiting time about some parts of the internet page (with Ibrowse the blue square rest forever in blue). The problem is just the DNS is checked verry often by the browser (blue square on Ibrowse). If I wait untill the modem is synchronized and DNS resolved by the modem and switch on the SAM, the DNS is only resolved the first access to internet by the brower. For resolving that, I switch on the modem and wait the modem is completely connected before switching on the SAM. Like that, the internet connection work fine and just only one time with Ibrowse the DNS resolving at start and all internet page after work fine. Now most of the users maybe let their internet connection allways online or use ADSL2+ (verry short connection and synchronized time) but there are users like me with this kind of problem.

I cannot tell what happens inside the web browser, but may there's an answer in how the DNS lookups work from within the TCP/IP stack.

When a web browser processes the contents of the page, it will eventually try to access data beyond the page. That could be scripts, images, etc. Each access requires a DNS lookup.

The lookup begins by contacting the first DNS server you configured (normally, you ought to have at least two alternative servers configured). For this the TCP/IP stack will send a packet towards the server and wait for it to respond.

Time is a factor here: if there is no response within five seconds, another packet will be sent. The packet will be resent after another ten seconds, and if there is still no reply, the whole procedure will be repeated for the second configured DNS server.

If this second lookup fails, too, you'll have spent at least 20-30 seconds during which the page did not continue to load. Since there are likely multiple references on the page to resources within the same domain, the web browser will end up queueing multiple DNS lookups.

If your modem has not yet connected to the ADSL network by the time the DNS lookups time out, you'll be stuck. It's not as if your modem or gateway router keeps the DNS lookup requests on ice until it is ready to forward them. There's no way to pull this off, because the TCP/IP stack making these requests is governed by its own timeouts.

So, long story short, don't try this at home. Wait for your modem and gateway router to become ready before you fire up your web browser.

@olsen

Does the Roadshow resolver cache have a negative TTL? (EDIT: Does Roadshow have a resolver cache? If yes, can it be flushed?)

Last edited by Trev on 09-Sep-2010 at 08:16 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@olsen

I've validated that the relay does not remove the option, and that 4095 bytes appears to be a hard limit. A message size option with a value larger than 4095+headers is also ignored. I even tried sending the value in host byte order just in case there was a bug in the DHCP server implementation. No luck.

Quote:

This is bad I suppose the Microsoft DHCP client code caught this issue by truncating the data received, so the server issue was not identified as a problem.

It was probably a combination of the two. It sounds like both the client and the server were limited to 576 bytes at some point and expanded to support the additional options the Microsoft DHCP client sends and requests (it's a long list) by default. EDIT: The list may be shorter if the client system isn't a member of an Active Directory domain, but that's not really relevant.

Last edited by Trev on 09-Sep-2010 at 08:20 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: @olsen Does the Roadshow resolver cache have a negative TTL?

No, the cache is tucked into a part of the stub resolver API which is completely unaware of the DNS record information. It would not know how to pay attention to the negative TTL.

Quote:

(EDIT: Does Roadshow have a resolver cache? If yes, can it be flushed?)

Yes, it has (I was tempted to write 'of course it has' for a second). This is not a sophisticated cache, it's merely intended to take the heat off multiple sequential A record lookups, as are done so frequently by web browsers.

The code only caches successful A record lookups, and only for a very short time (about 5 minutes), so as not to interfere with the governing rules of DNS record TTLs.

The cache is shared by all bsdsocket.library clients. As of this writing, the A record cache cannot be flushed under user control.

Last edited by olsen on 10-Sep-2010 at 09:11 AM.
Last edited by olsen on 10-Sep-2010 at 09:09 AM.

@olsen

So we don't have a true local cache and instead depend on the speed of an upstream forwarder. A local cache (or a caching-only local forwarder) would be a nice addition on systems with memory to spare.

What do you do if the response has TTL < 5? (Not likely, but some folks are overly aggressive with round-robin TTLs.)

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: @olsen So we don't have a true local cache and instead depend on the speed of an upstream forwarder. A local cache (or a caching-only local forwarder) would be a nice addition on systems with memory to spare.

Possibly, but it's difficult to make a DNS cache work in a local environment with little RAM and no secondary storage behind it.

I know from experience that it is quite impossible to predict how much memory a caching DNS server will eat up. With a disk cache you can at least assume that the cache will be driven by locality, but you don't really have that in DNS server queries.

With a real cache, there is a danger that its resource usage will become unmanageable quickly. And on AmigaOS that usually means running dangerously short of free memory, impacting overall system stability. Last time I looked we did not have the tools to implement a generic dynamic, in-memory caching system in the operating system.

That small local A record cache in Roadshow was never intended for anything but reducing the number of queries sent to the "real" DNS server. If what you are doing would benefit from a local DNS cache, you would be much better off with a real caching name server, running on a system that has secondary storage and enough memory to spare to make the most prominent queries fast.

Quote:

What do you do if the response has TTL < 5? (Not likely, but some folks are overly aggressive with round-robin TTLs.)

The entry will stick around until its local retain time expires (five minutes). Maybe the timeout ought to be configurable. So far there have been no complaints about the cache, but then again not many people may have known that it existed in the first place

@olsen

Quote:

Thank you, that confirms what I discovered just today by looking at a tcpdump capture kindly provided to me.

Ahh good.

Quote:

I don't know if you took packet samples,

I'll ask the guy who did the test.

Quote:

The pieces of the puzzle aren't all in yet, but I suspect that fixing the issue in Roadshow might just mean introducing a bug into Roadshow's code.

Yesh I thought that kind of thing might happen.

@olsen

It shouldn't be too much trouble to limit the size of the cache to an arbitrary number of entries, but I get your point. A disk-backed cache might also have higher latency than a remote server, particularly on older systems. I typically work with systems with gigabytes to spare, so it's rarely an issue.

(I should have said TTL < 300, but you got my meaning.)

Last edited by Trev on 10-Sep-2010 at 04:19 PM.
Last edited by Trev on 10-Sep-2010 at 04:18 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@olsen

Quote:

There are varying grades of difficulties even in writing a handler

Yes there would be. Unless you want to keep it simple.

Quote:

Or a particularly fancy replacement for the NIL: device

Nice idea. I'll submit it for official review if you like.

Quote:

A tool for that purpose has been around for quite a while. I don't remember exactly what it was called, but it was published ages ago on a Fred Fish disk.

Damn it! I was told practically the opposite long ago when I asked on the internet once. Oh, here it is:

http://groups.google.com.au/group/comp.sys.amiga.programmer/browse_thread/thread/1004012d623a47c4/dfe0b83539c280d3?hl=en&lnk=gst&q=dos++handler#dfe0b83539c280d3

I must have come off as arrogant at the end. I'd spent some work on it but just wnated to test the outsdide world to see if I had wasted my time. It looked like I had not. But it could only do simple handlers, it couldn't work with a mountlist. Something I planned wo work on. Still on the backburner...

Last edited by Hypex on 10-Sep-2010 at 05:00 PM.

@Hypex

Quote:

Hypex wrote: Quote: The pieces of the puzzle aren't all in yet, but I suspect that fixing the issue in Roadshow might just mean introducing a bug into Roadshow's code. Yesh I thought that kind of thing might happen.

Except that this wasn't really necessary after all The current Roadshow version (in beta testing) now seems to work just fine with the kind of router/DHCP server that wouldn't even want to listen to the DHCP client's request packets.

The final puzzle pieces were what goes into the discovery/request packets (always add client identifier records), and how large each packet sent has to be (at least 300 bytes). If you can provide both, most DHCP servers seem to be happy to listen to what your client sends. And you won't even have to bother about unicast/broadcast packet delivery.

Now if only some of this had been in the specification...

Last edited by olsen on 10-Sep-2010 at 04:42 PM.