I need to generate a random number for the initial transaction ID for DHCP, and also for the initial source port for UDP where the source port wasn't specified.
I might misunderstand you, but should not the DHCP client source port always be udp/68?
Unfortunately, by the time we need our first random number (the DHCP XID) everything is completely deterministic - apart from the initial state of RAM which will have a little bit of randomness after power up - I use a checksum of a few K of main RAM to make a 16 bit seed for the (16 bit) PRNG. The trouble with this is if two machines play the same game and are then reset, it's quite likely they have the same data in this chunk of RAM. In most cases it probably doesn't really matter, but it'll mean the seed is going to be the same if you play the same game twice and reset between each one. (Easily fixed though, I suppose - I could just avoid clearing down the PRNG seed between resets and instead accumulate a value, then at least it remains affected by the power-on seed. It may remain an issue with emulated machines though, if they don't "power on" with RAM in a randomish state).
Rickard: I think you do misunderstand me :-) For DHCP, the randomness is needed for the XID. For the first time we do UDP (probably a DNS query) we need to set the UDP source port to something.
Rickard: I think you do misunderstand me :-) For DHCP, the randomness is needed for the XID. For the first time we do UDP (probably a DNS query) we need to set the UDP source port to something.
Ok, I suspected I did. ;) Regarding the starting udp source port, is there a need for it to be random? I thought a common way was to have the client ports being sequential allocated from some high number, i.e. 1024, 5000 or 60000 or similar.
That's got me thinking.
One thing I lack on a freshly powered up Speccy is a source of randomness. I need to generate a random number for the initial transaction ID for DHCP.
Is the first call a part of your startroutine or do you call it AFTER the startmessage?
BTW my random number generator:
ld hl,(23672) ; use timer as seed
inc hl ; point to next
ld a,h
and #3f ; keep in ROM
ld h,a
ld a,(hl) ; random ROM address
xor l
xor h ; some more randomness
ld (23672),hl ; store random number
ret
Seed is increased by the routine and by intrupts, so a lot of randomness
A holds random number 0 - 255
As some suggested earlier, can not the MAC address of the network adapter be useful, since it is supposed to be globaly unique. Like mixing the MAC address with some other (pseudo)random number, could not that be used to create a DHCP XID?
If I understand it correctly the XID is only used during the phase of getting the address to make sure other clients requesting addresses at the same time can tell if an OFFER was to them or not.
What I mean if the client mac address is used in some way, there could be a small risk that the same XID is used the next day from the same client, but would that be a problem?
As some suggested earlier, can not the MAC address of the network adapter be useful, since it is supposed to be globaly unique. Like mixing the MAC address with some other (pseudo)random number, could not that be used to create a DHCP XID?
This is what I was getting at, to avoid two machines having the same seed at power-on / reset.
Another contender on the theme of "possible sources of randomness that won't be very random in emulators": the decaying bit behaviour when reading from unused AY registers. Only usable on Spectrums that have an AY chip, obviously...
As for deterministic XID, it is not a problem among multiple machines, as they each have different MAC, so the DHCP server doesn't confuse them even if they use same XID. It is only a problem if the same machine would quickly reset again and again and would use the same XID each time. In such case it might get confused by replies which were in fact intended to previous requests. If that is not supposed to happen frequently, using deterministic XID is not an issue.
Oh, and just wondering, after the powerup, is the amount of cycles until the first interrupt always deterministic as well? I was always curious about that, but without a custom ROM, I could never figure it out.
is it hard to add a simple realtime clock to your hw ? it would solve almost everything
Theoretically, no - I could add one to the schematic fairly quickly.... but in practise - yes, it'd be rather difficult. There's no room left to route data/address bus traces to an RTC on the existing board - which would mean an increase in PCB size, which in turn would mean a considerable increase in cost (also most RTCs need quite a lot of footprint too due to the need for a battery of some sort). PCB space is very costly when you're only doing a few tens of PCBs at most. Also, the existing CPLD is full to bursting, so any new hardware would require a CPLD that is twice the price of the one I currently use.
The problem isn't exactly a severe one, and the 'randomish state of memory on startup' has served just fine so far (including on the Euskal Encounter LAN which had rather busy DHCP and DNS servers).
Comments
I might misunderstand you, but should not the DHCP client source port always be udp/68?
Rickard: I think you do misunderstand me :-) For DHCP, the randomness is needed for the XID. For the first time we do UDP (probably a DNS query) we need to set the UDP source port to something.
Ok, I suspected I did. ;) Regarding the starting udp source port, is there a need for it to be random? I thought a common way was to have the client ports being sequential allocated from some high number, i.e. 1024, 5000 or 60000 or similar.
is it hard to add a simple realtime clock to your hw ? it would solve almost everything
Is the first call a part of your startroutine or do you call it AFTER the startmessage?
BTW my random number generator:
Seed is increased by the routine and by intrupts, so a lot of randomness
A holds random number 0 - 255
EDIT : Dispite spaces the code just cam in false
If I understand it correctly the XID is only used during the phase of getting the address to make sure other clients requesting addresses at the same time can tell if an OFFER was to them or not.
What I mean if the client mac address is used in some way, there could be a small risk that the same XID is used the next day from the same client, but would that be a problem?
This is what I was getting at, to avoid two machines having the same seed at power-on / reset.
As for deterministic XID, it is not a problem among multiple machines, as they each have different MAC, so the DHCP server doesn't confuse them even if they use same XID. It is only a problem if the same machine would quickly reset again and again and would use the same XID each time. In such case it might get confused by replies which were in fact intended to previous requests. If that is not supposed to happen frequently, using deterministic XID is not an issue.
Oh, and just wondering, after the powerup, is the amount of cycles until the first interrupt always deterministic as well? I was always curious about that, but without a custom ROM, I could never figure it out.
Theoretically, no - I could add one to the schematic fairly quickly.... but in practise - yes, it'd be rather difficult. There's no room left to route data/address bus traces to an RTC on the existing board - which would mean an increase in PCB size, which in turn would mean a considerable increase in cost (also most RTCs need quite a lot of footprint too due to the need for a battery of some sort). PCB space is very costly when you're only doing a few tens of PCBs at most. Also, the existing CPLD is full to bursting, so any new hardware would require a CPLD that is twice the price of the one I currently use.
The problem isn't exactly a severe one, and the 'randomish state of memory on startup' has served just fine so far (including on the Euskal Encounter LAN which had rather busy DHCP and DNS servers).