@Trev

Quote:

Trev wrote: @olsen From RFC 2131: Quote: In the case of a client using DHCP for initial configuration (before the client's TCP/IP software has been completely configured), DHCP requires creative use of the client's TCP/IP software and liberal interpretation of RFC 1122. The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured; 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. To work around some clients that cannot accept IP unicast datagrams before the TCP/IP software is configured as discussed in the previous paragraph, DHCP uses the 'flags' field. The leftmost bit is defined as the BROADCAST (B) flag. The semantics of this flag are discussed in section 4.1 of this document. The remaining bits of the flags field are reserved for future use. They MUST be set to zero by clients and ignored by servers and relay agents. So, either the client should accept the packet, or the server must honor the broadcast flag....

I put this to the test, and the issue is definitely not with the DHCP server failing to send its "DHCP offer" message to the DHCP client. That message definitely arrives correctly, regardless of whether it is sent as unicast or multicast traffic (my original code picked up either form just fine).

The issue is with the DHCP server not responding to the DHCP client code's "DHCP request" message. This is why the client keeps resending it in the hope that the server will respond. I'm still looking into the matter, which is getting stranger by the minute...

@olsen

This could be open to interpretation by DHCP server implementations:

Quote:

To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message MUST use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as the original DHCPDISCOVER message.

While this should only be of interest to relay agents and only apply to initial address allocation, some server implementations may use secs along with either chaddr or the client identifier to uniquely identify leases, despite a subsequent RFC directive to do otherwise. The server should respond with DHCPNACK if it can't allocate the address, regardless. (I'm only familiar with uIP's DHCP client code, which is very simplistic; secs is always zero, which is acceptable according to the RFC.)

The SOHO router could also be using a relay agent internally. If so, the DHCPREQUEST may be discarded if secs has passed an implementation specific threshold or if hops is greater than 16, similar to IP forwarding TTLs.

http://www.isc.org/software/dhcp should be a good reference for *nix-based routers. I don't know the basis for VxWorks' dhcpd.

EDIT: The device's dhcpd may also discard DCHPREQUEST packets sent between the last DHCPREQUEST and some arbitrary wait period, e.g. five seconds.

EDIT2: I just did a test from my OS4 box, and I see that you're setting option 57 (maximum DHCP message size) to 548 bytes. The minimum legal value is 576 bytes, which corresponds to minimum host requirements. The option documentation isn't specific, but since the minimum value is 576, it must include protocol headers. I suspect your DHCP server, like mine, is discarding the packets because of this. (You could also remove the option altogether.)

Last edited by Trev on 06-Sep-2010 at 07:41 PM.
Last edited by Trev on 06-Sep-2010 at 07:38 PM.
Last edited by Trev on 06-Sep-2010 at 07:15 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: EDIT2: I just did a test from my OS4 box, and I see that you're setting option 57 (maximum DHCP message size) to 548 bytes. The minimum legal value is 576 bytes, which corresponds to minimum host requirements. The option documentation isn't specific, but since the minimum value is 576, it must include protocol headers. I suspect your DHCP server, like mine, is discarding the packets because of this.

I'm way ahead of you (well, a little bit) The maximum message size is short by 28 bytes, which is the size of the IP and UDP headers that get tacked onto the BOOTP payload when it is committed to the wire. The documentation I referred to back in 2003 didn't state whether or not the message size included the IP/UDP header size. It has to be included.

I found a few more gotchas today. Such as: some DHCP servers will throw more than the maximum message size at you, with tons of options that will overrun your BOOTP receive buffer if you don't verify that the buffer is large enough. There was a test missing in my code, which explains why some users had their system crash if they used DHCP with Roadshow. Also, 576 bytes are far from enough for today's use; I've seen more than 590 bytes tossed at my code when it clearly stated that it could handle only 548 bytes. My updated code now supports the full MTU packet size.

The DHCP packets my client sent were almost always too large. Good thing that they were padded with zeroes, but that still isn't good enough.

Some DHCP servers prefer it if option 61 (client identifier) is passed around with the discovery/request packets. My client code didn't do that until now.

There's an update in the making, and I hope to get enough feedback soon to find out whether these changes finally made a difference

@olsen

MTU size will necessarily vary according to the medium, path, and other bits in use, e.g. PPPoE, NAT, etc. Your IP layer should take care of fragment reassembly, so the DHCP client should be prepared to accept a datagram of 65535 bytes. That's going to be a fun problem on small memory 680x0 systems. But, you're ahead of me on the max message size issue, and I don't know how a server responds when its offer contains option data that exceeds that size.

_________________
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:

olsen wrote: 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.

SnoopDOS can also log packets.

BTW, why not adapt AROS's network prefs program to provide a GUI for 68k RoadShow?

@Trev

Quote:

Trev wrote: @olsen MTU size will necessarily vary according to the medium, path, and other bits in use, e.g. PPPoE, NAT, etc. Your IP layer should take care of fragment reassembly, so the DHCP client should be prepared to accept a datagram of 65535 bytes.

The DHCP server's reach should cover the local area network which the client tries to obtain an IP address for, or at least there should be a relay server attending to it. The MTU issue concerns how large the packet size can be which the client will accept. It can't pick 1500 bytes, it has to follow the MTU settings of the interface. Since the BOOTP packets are usually transmitted with the "do not fragment bit" set, they cannot be larger than the MTU allows for. If the client asked for a larger size, it would guarantee that the packets would be dropped somewhere along the way.

Quote:

That's going to be a fun problem on small memory 680x0 systems. But, you're ahead of me on the max message size issue, and I don't know how a server responds when its offer contains option data that exceeds that size.

I tested only a few configurations so far. Some servers wll limit what they will send in the DHCP offer message, some will not care at all. The ones that do not care could crash the DHCP client, due to missing buffer overflow checking in my code.

Oh well... I guess I learned to watch out for a few more things in the past couple of years.

@ncafferkey

Quote:

ncafferkey wrote: @olsen [quote] olsen wrote: 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.

Quote:

SnoopDOS can also log packets.

The tool I had in mind did not log packets, it allowed you to create packets, with a GUI, and send them to file systems and handlers. While you could always roll your own code to do that, such a tool can be really neat

Quote:

BTW, why not adapt AROS's network prefs program to provide a GUI for 68k RoadShow?

I'd rather not get into the business of making or adapting GUIs for Roadshow any more. Besides, the network configuration management is but one part of the GUI that would have to be created.There's still the PPP and PPPoE connection management to be taken care of, and it's quite something

@olsen

The MTU for roadshow on AOS4, (with no MTU file on env/roadshow drawer) is 1518 (per default). Ranger show that. It's an error ???

_________________
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 The MTU for roadshow on AOS4, (with no MTU file on env/roadshow drawer) is 1518 (per default). Ranger show that. It's an error ???

This is likely the maximum number of bytes that are committed to the wire by the hardware, and not the MTU. The MTU for Ethernet would be 1500 bytes, which is the maximum payload size before any hardware protocol overhead is added. The 18 bytes probably come together as 6 (source address) + 6 (destination address) + 2 (protocol type) + 4 (crc) bytes.

@Trev

Quote:

Trev wrote: http://www.isc.org/software/dhcp should be a good reference for *nix-based routers. I don't know the basis for VxWorks' dhcpd.

VxWorks may be the magic word after all: I just learned that routers based upon the VxWorks firmware are likely to discard BOOTP/DHCP packets shorter than 300 bytes. The Roadshow DHCP client code could produce packets shorter than this threshold, which would explain why some DHCP servers would accept this input, and some would not. The 300 bytes come, with a lot of handwringing, out of RFC951. The ISC DHCP reference implementation has no issues receiving packets that short, but it always pads the packets it sends to this minimum length.

I have just updated the client code again. What now hits the wire is almost identical to what other DHCP client implementations produce. Roadshow just asks for fewer options

If it was the length of the packets causing all this trouble, it would neatly explain why some DHCP servers never paid any attention to Roadshow asking for address renewal. The renewal packets are by their nature much shorter than anything else the client sends to the server.

@olsen

Another thing related to roadshow and AOS4.1U2:

Roadshow refuse to reboot:

http://www.amigans.net/modules/newbb/viewtopic.php?viewmode=flat&type=&topic_id=4241&forum=22

_________________
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 Another thing related to roadshow and AOS4.1U2: Roadshow refuse to reboot: http://www.amigans.net/modules/newbb/viewtopic.php?viewmode=flat&type=&topic_id=4241&forum=22

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.

@olsen

I fully realize the thrust of Roadshow was never serial dialup, but I'm curious.
Does Roadshow employ persistent ftp/http?

#6

Last edited by number6 on 07-Sep-2010 at 04:43 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@olsen

Quote:

Since the BOOTP packets are usually transmitted with the "do not fragment bit" set, they cannot be larger than the MTU allows for. If the client asked for a larger size, it would guarantee that the packets would be dropped somewhere along the way.

Are they? I haven't seen that in practice. If the DHCPOFFER or DHCPACK message is larger than the MTU, it will be fragmented. I'm not on a large network at the moment, but I'll verify that later today using Microsoft's DHCP server.

There's at least one reference to multiple DHCPACK messages in response to DHCPINFORM, but I don't see anything that clarifies the use of "multiple." Is that one response from each of multiple servers or multiple responses from a single server? Probably the former.

_________________
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

@number6

Quote:

number6 wrote: @olsen I fully realize the thrust of Roadshow was never serial dialup, but I'm curious.

It does come with its own PPP driver for asynchronous serial links, and a PPPoE driver built upon the same core PPP code (which naturally uses a different frame encoding). And if you're bold enough, slip.device/cslip.device are supported along with all other SANA-II drivers.

Quote:

Does Roadshow employ persistant ftp/http?

What do you mean by that? I do not know what you are referring to.

@number6

Quote:

Does Roadshow employ persistant ftp/http?

You're probably referring to "active FTP," and it's up to the FTP client and server to support it, not the IP stack. The difference between active and passive FTP is in who initiates data connections (the FTP client or the FTP server) and on which ports the transfers occur. It's easier for firewalls to manage active FTP sessions, but any decent firewall can manage both.

While HTTP uses a connection-oriented protocol (TCP), HTTP itself is stateless.

EDIT: Changed "initiates data transfers" to "initiates data connections." The Wikipedia article on FTP does a nice job of explaining how it works.

Last edited by Trev on 07-Sep-2010 at 04:55 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 Quote: Since the BOOTP packets are usually transmitted with the "do not fragment bit" set, they cannot be larger than the MTU allows for. If the client asked for a larger size, it would guarantee that the packets would be dropped somewhere along the way. Are they? I haven't seen that in practice. If the DHCPOFFER or DHCPACK message is larger than the MTU, it will be fragmented. I'm not on a large network at the moment, but I'll verify that later today using Microsoft's DHCP server.

From how I understand BOOTP was intended to work, you could not expect a lot of sophistication from the client's side.

In many cases the UDP send/receive code was likely cobbled together from code that wrote/read to/from the Ethernet device's transmit buffers without the aid of any TCP/IP stack to take care of UDP fragmentation and reassembly. Once the code obtained its IP address, it could proceed to download the real operating system image through tftp (another protocol easily built using primitive UDP packet exchange) and boot something nicer than the ROM boot code

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.

Quote:

There's at least one reference to multiple DHCPACK messages in response to DHCPINFORM, but I don't see anything that clarifies the use of "multiple." Is that one response from each of multiple servers or multiple responses from a single server? Probably the former.

My code does not use the DHCP inform message, as it walks through the entire sequence of discover/offer/request/ack. From what I gather, the DHCP inform message may have been intended to help PPP clients to get their bearings once the connection was operational. Back in the early days of PPP standardization, all the neat options that now tell you which DNS servers are available, etc. were not yet implemented. The DHCP inform message would have been a good workaround to solve the problem at hand without having to wait for the standardization to get around.

The reason why there might be multiple DHCP ack messages in response to a DHCP inform message would be the same why there might be multiple DHCP offer messages in response to a DHCP discovery message: multiple DHCP servers on the same network. With the regular DHCP packet exchange, the client makes a selection when multiple responses come after the DHCP discovery message has gone out. The same is likely necessary after the DHCP inform message has produced responses.

@olsen

Quote:

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.

EDIT1: Part removed because resolved

EDIT2: roadshow DSI explanation removed.

Thanks for your availability on this interesting thread who now transformed to roadshow itself.

Last edited by Mrodfr on 07-Sep-2010 at 06:16 PM.
Last edited by Mrodfr on 07-Sep-2010 at 06:10 PM.
Last edited by Mrodfr on 07-Sep-2010 at 06:01 PM.
Last edited by Mrodfr on 07-Sep-2010 at 05:59 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:

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 ?

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@Mrodfr

Do you also don't use a network time protocol server to synchronize the system clock?
Small tools like 'Wet' would be another source of error with this respect

I'm just asking because I recognized the same as you but one of the above caused the problem, I think


regards,
nexus

_________________
dye 'em black!