hascall@cs.iastate.edu (John Hascall) (05/31/90)
I am working on a bootp client which I hope to use as follows (in
/etc/rc.local):
ifconfig `bootp-client`
The aim of the program is to produce a string like the following:
se0 129.186.1.62 netmask 255.255.255.0 broadcast 129.186.1.255
The client program creates a datagram socket, but when it attempts
to bind (to addr=INADDR_ANY, port=BOOTP) it fails unless I preceed
the bind with a SIOCSIFADDR (set address) ioctl call%. Herein lies the
problem: the whole reason for this program is to discover the address!
If I just stick in a bogus address (say 129.186.0.0) I get the bootp
request sent fine, but I don't receive the reply. I have tried all
sorts of things but none have worked...
...does any one have any ideas on how to make this work?
Thanks again,
John Hascall hascall@atanasoff.cs.iastate.edu
% according to man side effect of SIOCSIFADDR is to initialize the interfacemogul@wrl.dec.com (Jeffrey Mogul) (06/01/90)
In article <1758@dino.cs.iastate.edu> hascall@cs.iastate.edu (John Hascall) writes: > I am working on a bootp client ... > >The client program creates a datagram socket, but when it attempts >to bind (to addr=INADDR_ANY, port=BOOTP) it fails unless I preceed >the bind with a SIOCSIFADDR (set address) ioctl call%. Herein lies the >problem: the whole reason for this program is to discover the address! > >If I just stick in a bogus address (say 129.186.0.0) I get the bootp >request sent fine, but I don't receive the reply. I have tried all >sorts of things but none have worked... > > ...does any one have any ideas on how to make this work? The reason why it doesn't work is that the ipintr() routine in the kernel checks the destination address against the list of interface addresses for the host, and if it doesn't match (and it isn't an IP broadcast) then the packet is not accepted. (Actually, if you are running a router, then the packet is forwarded; otherwise, it is unceremoniously dropped). Once you get a hold of Ultrix 4.0 I think you could probably get around this using the "packet filter" facility. You would still have to set some random address using SIOCSIFADDR, because until the interface is initialized the packet filter cannot use it. After that, your program could use either the packet filter or the normal means to send the BOOTP request packet, but it would have to use the packet filter to receive the BOOTP reply packet and it would have to decode the complete stack of packet headers (Ether, IP, and UDP) itself. Also, in order to be able to receive IP packets whose Ethernet destination address is the same as the host's Ethernet address (such as the BOOTP reply) you must set a global variable in the kernel called "pfcopyall" to a value greater than 0. (I would recommend setting this back to 0 when the program is done using the packet filter). In order to set this value, you'll have to write a little code to extract the symbol from the /vmunix symbol table, and then poke at it in /dev/kmem ... and this could be risky, since if you have booted from a kernel file other than /vmunix, you'll probably end up trashing some other variable instead. At the very least, I recommend not mucking with this variable if its value isn't zero. That this is so hard to do is partly my fault, and I've suggested that it be cleaned up in a later release. Meanwhile, you might find it a lot easier to implement a RARP client (and server) using the packet filter, since RARP doesn't need to use IP. You could then write a program that uses RARP to set the IP address, then uses BOOTP to set the other parameters. -Jeff
thinman@cup.portal.com (Lance C Norskog) (06/02/90)
You have a logical conundrum here. You are trying to figure out how to "turn on" IP, but you are trying to use IP to figure this out. You have to send and receive your own raw Ethernet packets. Ultrix may have some technique for doing this. System V has it's own scheme where the Ethernet devices have their own /dev entries (jeeez wotta concept) which you open and "bind" to a protocol number. good luck.