Comments (9)
I know this is ancient, and that you've likely found a fix or moved on by now,
but if you are still able to reproduce this, can you attach a PCAP
(tcpdump/Wireshark) trace of what both systems see?
My guess is that the ports involved aren't what staticDHCPd expects to deal
with and that the packets are actually being sent, but aren't being received.
An alternative is that an option that RHEL was looking for isn't present, and
there may be a hint in its request that can be used to adapt behaviour
appropriately.
Original comment by red.hamsterx
on 29 Mar 2012 at 5:39
from staticdhcpd.
Guessing this is done since it's been a year.
Original comment by red.hamsterx
on 27 Mar 2013 at 5:24
- Changed state: Done
from staticdhcpd.
The pxebooting (bootp) involves two rounds of 'handshakes' between dhcp server
and client. See: http://www.tcpipguide.com/free/t_BOOTPDetailedOperation.htm
The booting does not work for EL4 U7/U8 probably because when dhcp server
answers the client request for the second handshake, it still does a
'broadcast' as it does for the first round. I changed the flag to 'unicast',
then the server was able to boot. Why EL5 and later hosts were able to work, I
have no idea.
Original comment by [email protected]
on 28 Mar 2013 at 8:35
from staticdhcpd.
Curious...
In all cases, the code will check the sender's address and determine whether
the client's IP is unicast or not
(http://code.google.com/p/staticdhcpd/source/browse/branches/logging-web/staticD
HCPd/staticdhcpdlib/dhcp.py?r=477#800) before deciding where to send the
response. PXE should be no different.
I know it's been a long time, and thanks for following up, Andrew, but if you
can give me a pcap for this situation (both working and not), I'd like to study
it to see if I can spot the abnormality or otherwise see if I can compensate
for the unusual behaviour.
There's no hard requirement in the PXE specs, from what I recall, that says the
server providing PXE must be the same as the server providing DHCP, so it's
unreasonable for the client to expect that the second server knows its lease
status. That said, since, in this case, the server does know the lease-status
of the client, sending two packets, one unicast and one broadcast, in the case
of PXE, shouldn't cause any problems and that can be made an option pretty
easily.
Original comment by red.hamsterx
on 28 Mar 2013 at 8:47
- Changed state: Accepted
from staticdhcpd.
Actually, I'll just go ahead and build those in as options in 2.0.0:
* An option to make all PXE requests go to client_ip, regardless of whether it was a broadcast request or not
* An option to make all PXE requests, if they look like a broadcast request, go to both addresses
2.0.0 should have an RC package tomorrow, unless I get hit with something big
before then.
Original comment by red.hamsterx
on 28 Mar 2013 at 8:59
from staticdhcpd.
Actually, no, that's a mistake on my side. I missed the clause that said if
ciaddr is non-zero, use ciaddr instead. I'll make the change and release 1.5.8
and 1.6.3 with a corresponding patch when I release 2.0.0.
Original comment by red.hamsterx
on 28 Mar 2013 at 9:17
from staticdhcpd.
Ok, I might have misled you with the 'broacast/unicast' statement earlier. This
has been quite some time for me too. I looked again at my code and your recent
code
(http://code.google.com/p/staticdhcpd/source/browse/branches/logging-web/staticD
HCPd/staticdhcpdlib/dhcp.py?r=477#800).
For the line below in 'def _handleDHCPDiscover':
self._sendDHCPPacket(
wrapper.packet, wrapper.source_address, wrapper.pxe,
wrapper.mac, definition.ip
)
For my 'fix', I did a check to see if the discover request is from the first or
second round communication. If it is from second round, I just set the
wrapper.source_address to the ip that I know that should be assigned to the
client. Instead of relying on whatever that is sent back from the client. My
earlier confusion of 'broadcast/unicast' probably stemed from my observation
that the cases where the boot failed, the wrapper.source_address was all
255.255.255.255, instead of the client's actual IP address. So this might be a
bug of Redhat Enterprise linux 4 that failed to set the src ip in the packet
properly and was fixed in Redhat 5? Unfortunately I don't have the testing
environment to do a pcap.
Original comment by [email protected]
on 28 Mar 2013 at 9:32
from staticdhcpd.
No, I don't think you misled me at all, Andrew.
ciaddr and the sender's actual address are two entirely different things: the
first one is part of the packet, saying "this is my address" and the second one
is the address of the socket that actually sent the packet.
My code has only been looking at the socket's address, oblivious to the
possibility that the client might be using broadcast to find the PXE server
(which makes sense here, because the DHCP server has no obligation to set the
next server's IP in the response packet if it doesn't know that the client
requires PXE), while still including a bit of information saying "I'd like to
be contacted here, please".
This is a logical error on my side and it was likely addressed by RedHat
accepting broadcast responses as equivalent to unicast in later versions of the
software they included.
Original comment by red.hamsterx
on 28 Mar 2013 at 9:38
from staticdhcpd.
1.6.8 and 1.5.7 have been published, with the change also integrated into 2.0.0.
Since you've already found a fix for this issue, I'll close it as Fixed. I
don't expect you to test it on my behalf, because RHEL 4 is old and your
environment is probably stable now, but thank you very much for reporting it
and for helping to find the problem.
Original comment by red.hamsterx
on 28 Mar 2013 at 10:16
- Changed state: Fixed
from staticdhcpd.
Related Issues (20)
- Redis extention or nosql db layer
- PXE? HOT 6
- Support for relay agents requiring Option 82 HOT 2
- Publishing project to PIP? HOT 3
- support for Database INSERT for unknownMAC HOT 3
- IPv6 support? HOT 2
- How can I handleUnknownMAC? I want my server should allocate IP to the client even if mac address of client is not in INI or database. HOT 5
- Doesn't support python 3 (and doesn't document that) HOT 1
- Can staticdhcpd make a lease table from watching DHCP traffic? HOT 2
- adding extentions HOT 2
- AttributeError: 'NoneType' object has no attribute 'split' HOT 7
- TypeError: setsockopt() argument 3 must be string or read-only buffer, not None HOT 20
- staticDHCPd version 2.0.0-rc1 doesn't start HOT 3
- Cannot load mysql.sql on MariaDB 10.3.17 HOT 3
- Error in the rfc3925_125_decode function HOT 1
- dev null dup2 Bad file descriptor HOT 1
- Need to Port to Python3 HOT 22
- Documentation HOT 2
- DHCPRENEW support HOT 1
- Oracle database support is untested
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from staticdhcpd.