Edubuntu does not work with DHCP Konfiguration on port 1067

[mailing-joergd at gmx.net]

Hi Gavin,

thank you for your help - it works!

> 
> I understand.  It's actually desirable for the client to be able to choose
> their DHCP server.  Unusual, but I can see where you're going :-)

Yes, the idea behind it is to run edubuntu besides an existing system
(which already uses a network provided operating system).
I mean there are lots of imaginable scenarios:
-providing linux clients temporarily 
-convince the school's admin to use edubuntu
-test the whole system
-etc
As soon as you shouldn't touch an existing configuration you come
to the idea of a edubuntu server with a seperated DHCP server!

The edubuntu traffic and processor load is seperated on a single machine
then, which is a nice side-effect. I think it's more easy to monitor the
system performance on a dedicated machine. Managing this through a boot
loader would also be possible. But this requires administration on a
running system and on site.

Finally, I have a simple adsl router at home (where I set up the Edubuntu
server) which distributes the IP addresses. When a edubuntu client sends
a dhcp request on standard port 67/68, it mostly gets a response from the
adsl-modem-router-dhcpserver-all-in-one box. Changing the behaviour of that
box is futile.
Ok, such cheap hardware routers might not come up in large-scale computer labs...

Of course, it would be sensible to merge edubuntu and the other system in 
the long run. Then the floppy-disk (which is currently necessary) could
be left out. But step by step...

> > > If it came to it, you could rebuild the dhcp3-client package and
> > > install it into your edubuntu chroot with the default port number
> > > changed in the source.  (ick!)  It looks like you need to look at
> > > client/dhclient.c line 298.
> > 
> > Hmmm I'm pessimistic after trying to build my own kernel already
> failed...
> 
> It _should_ be straightforward to rebuild the dhcp3-client package.  An
> example is here:
> 
> http://www.debian-administration.org/articles/20

Useful information for a newbie like me anyway :-)

> 
> However, as you've pointed out, it's the initrd dhcp client that you need
> to modify.
> 
> I created an nfs mounting initramfs here (I don't have edubuntu here but
> debian should be close) and looked around within it.  The file
> /scripts/nfs
> seems to be where the network interface is brought up. 
> 
> 	# For DHCP
> 	modprobe -q af_packet
> 	ipconfig ${DEVICE}
> 
> This script is apparently copied from a master copy at
> /usr/share/initramfs-tools/scripts/nfs when you create the initrd using
> mkinitramfs.  The master copy of the script is part of the initramfs-tools
> package.
> 
> You can modify this script to read as follows:
> 
> 	# For DHCP
> 	modprobe -q af_packet
> 	ipconfig -p 1068 ${DEVICE}
> 
> and then run mkinitramfs to rebuild your initrd image (this is in the ltsp
> chroot obviously).  I've tested here and that ipconfig does recognise the
> -p option.

YES! That's it. Solves my problem really perfectly. Thank you,
after spending days with the problem this was the decisive hint.

> Obviously you'd need to redo this every time initramfs-tools got upgraded.

Are the initramfs-tools upgraded via the Update Manager?
 
> You may come up with a better answer than this, but I think the above
> should work to get you going.
> 
> > These option settings are used to bypass specified options (like DPORT)
> > to the client kernel. As described, the kernel delivered with
> > ltsp_initrd_kit recognizes the DPORT setting. For other people using the
> > ltsp package it seems to work with the option settings, too (take a look
> > at the ltsp mailing list).
> 
> I guess I understand, it's just that (as I understand) the kernel doesn't
> do the dhcp do it must then pass this info on to whatever does.

Yes, the option is actually caught by the script called 'linuxrc' and then
passed to the dhcp client. Easy to comprehend with the ltsp_initrd_kit...

> > How are the edubuntu images in /var/lib/tftpboot/ltsp created? Is there
> > any chance to adapt them without having to make a new kernel? What are
> > the differences between the edubuntu images and the ltsp images?
> 
> mkinitramfs, I presume.

Ah, ok. The ltsp documentation describes customizing the client's kernel 
by compiling a new kernel. 
 
> > Thanks a lot for your help,
> > hopefully we can fix this issue somehow.
> 
> Try the above.  I think it should work.

It does work. I'll invite you to some beer if you sojourn somewhere in bavaria/germany :-)
 
> Incidentally, if you want to look inside an initrd image you can do:
> 
> gunzip -c /var/lib/tftpboot/ltsp/initrd-xxxx.img >/tmp/initrd.tmp
> mkdir tmproot/
> cd tmproot/
> cpio -i --make-directories < ../initrd.tmp
> 
> and you should be able to explore the archive, see listing 2 here:
> 
> 	http://www-128.ibm.com/developerworks/linux/library/l-initrd.html

Yes, also works fine.

> 
> If you manage to make a modified initrd, I think this should get you
> going.
> Of course, I've never done this, but everything I've tried here suggests
> it
> should work.
> 
> Gavin
> 
> PS If you get your thin client up and running on the nfs root, dhclient
> probably takes over the ongoing dhcp responbilities so you may need to
> convince it to use the other port too.

Seems to be not a problem during boot process. Maybe it becomes one when
the client's lease expires (Maybe the client will ask for a new one using
the dhclient?)

Best regards and thanks again,
Jörg Deutschmann
-- 


Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer