6 replies to this topic

[bingo]

i config tftpd32, set ip pool starting address to 169.100.100.10 (sample). after a short time the internal ethernet adapter (server interface) gets these new ip 169.100.100.10. this problem currently in 3.35 and 3.50.

[bingo]

the log:
Rcvd DHCP Discover Msg for IP 0.0.0.0, Mac 00:03:0D:A0:9C:E3 [13/10 18:53:41.857]
Client requested address 0.0.0.105 [13/10 18:53:41.857]
DHCP: proposed address 169.254.210.100 [13/10 18:53:41.857]
2864 Request 2 not processed [13/10 18:53:41.935]
Rcvd DHCP Rqst Msg for IP 0.0.0.0, Mac 00:03:0D:A0:9C:E3 [13/10 18:53:41.998]
Previously allocated address 169.254.210.100 acked [13/10 18:53:41.998]
2864 Request 2 not processed [13/10 18:53:42.060]
Rcvd DHCP inform Msg for IP 169.254.210.100, Mac 00:03:0D:A0:9C:E3 [13/10 18:53:49.299]
Rcvd DHCP inform Msg for IP 169.254.210.100, Mac 00:03:0D:A0:9C:E3 [13/10 18:53:53.308]

but Mac 00:03:0D:A0:9C:E3 is server interface! after short time the ip jumps from 169.254.210.61 to 169.254.210.100.

[Colin]

This may cause by a bug in bootpd.c char *DHCPSearchOptionsField .
I am trying to fix it.

But in my opinion server interface should set static address.

[bingo]

temporary workaround:
it works with static ip to mac (internal adapter) in tftpd32.ini.

Static DHCP entries
The key is the MAC address (separator , the value is the IP address

[Colin]

I patch the function DHCPSearchOptionsField in bootpd.c.
1. check the DHO_END. Well formed DHCP packet should have DHO_END at last position.
2. check if the Option equal what we want.

[codebox]unsigned char *DHCPSearchOptionsField (unsigned char *pOpt, int nField, int *pLength) { int Ark; unsigned char *p; if (* (DWORD *) pOpt != * (DWORD *) DHCP_OPTIONS_COOKIE ) return NULL; for ( Ark = 0, p = pOpt + (sizeof DHCP_OPTIONS_COOKIE - 1) ; Ark<DHCP_OPTION_LEN-3 && p[Ark]!=nField && p[Ark]!=DHO_END; Ark += (p[Ark]==DHO_PAD ? 1 : 2+p[Ark+1]) ); if(p[Ark]==nField && Ark<DHCP_OPTION_LEN-2 && Ark+p[Ark+1] < DHCP_OPTION_LEN) { if (pLength!=NULL) *pLength = p[Ark+1]; return &p[Ark+2]; } return NULL; } // DHCPSearchField [/codebox] But I think I have not fix the bug. Although the buffer is fill with zero before receiving, but what filled in the buffer beyond the packet length is unknown. No touch is a good idea.
It is better to get packet length from recvfrom func and store it in structure.
Then call DHCPSearchOptionsField with the structure.
By then the function can know if it have go over the hole packet.

[Ben321]

temporary workaround:
it works with static ip to mac (internal adapter) in tftpd32.ini.

Static DHCP entries
The key is the MAC address (separator , the value is the IP address

OMG How did you get it to assign a static IP? I've been trying to do this for a while now. The FAQ says to do it in the registry. It also says it's possible to switch to using an ini file instead of registry. But it provides NO INSTRUCTIONS on how to do static IPs in the ini file. Please explain what you did! I hate it when people find a workaround, but DON'T EXPLAIN IT, so others who might NEED it, are then NOT HELPED, due to the LACK OF EXPLAINING OF A FIX THAT OTHERS FOUND!!!!!!

[Sha0]

OMG How did you get it to assign a static IP? I've been trying to do this for a while now. The FAQ says to do it in the registry. It also says it's possible to switch to using an ini file instead of registry. But it provides NO INSTRUCTIONS on how to do static IPs in the ini file. Please explain what you did! I hate it when people find a workaround, but DON'T EXPLAIN IT, so others who might NEED it, are then NOT HELPED, due to the LACK OF EXPLAINING OF A FIX THAT OTHERS FOUND!!!!!!

Is there really a need for someone to explain it?  It's in the help, once again.

1. Open tftpd32
2. Click the Help button
3. In the Tips and Tricks column, click the Tips link
4. Read the page