Hey,

So I'm new to the land of linux, and am the happy owner of a debian box, that now servers as my fileserver,webserver,ftpserver and firewall.

I'd like the windows machines in my home network to be able to use MSN file transfers. I downloaded the ip_masq_mms from here <oops cannot show a url, since I'm a new user, it's where google leads you when you look for msn and ipmasq> and (to my own surprise ;-), managed to compile it.

So now I have a ip_masq_mms.o

I tried using modprobe to install this module:

modprobe ip_masq_mms says it cannot find ip_masq_mms, nor can
modprobe ip_masq_mms.o

Do I need to put this file in a special directory?

I managed to modprobe ip_masq_ftp just fine the other day.

Confused in so many ways ;-)

Lucas

Addition: kernel 2.2.22, debian

In /boot, you will find a link pointing to the module library in /lib for the specific kernel which you are running. If you compiled from the the same source, it should go there. If you remembered to do all of the "make" commands in order--it should have put it there. Did you remember to make clean? make Mrproper? I always look it up. I never trust my memory.

But if you were able to do the whole process the other day, something else may be wrong.

Hey Eqwatz. Thanks for helping me along.

Ok, so I found all ip_masq_XXX.o 's to reside in /lib/modules/2.2.22/ipv4
I now copied my .o file into this folder, and do:

modprobe ip_masq_mms

it still says it cannot locate the module. Whereas

modprobe -l

lists about 9 modules, one of which is my ip_masq_mms.o file.

So I'm guessing I did something wrong compiling this thing. The tarball contained a .c file, and a Makefile. (I've pasted the makefile below). The source to my linux source is correct. When compiling (by typing make in the folder containing the makefile & .c file) it does give me a warning:

{standard input}: Assembler messages:
{standard input}:9: Warning: ignoring changed section attributes for .modinfo

Should I compile differently? I don't see the makefile checking for parameters, so I wouldn't really know what to tell it.

Thanks, Lucas


.SUFFIXES : .o .c
CFLAGS = -O2 -Wall -fomit-frame-pointer -fno-strength-reduce -pipe -m386 -includ
e /usr/src/linux/include/linux/modversions.h
DEFINES = -D__KERNEL__ -DMODULE -DMODVERSIONS -DCPU=386 -DEXPORT_SYMTAB
INCLUDES = -I/usr/src/linux/include
CC = gcc

all: ip_masq_mms.o

ip_masq_mms.o : ip_masq_mms.c
$(CC) $(CFLAGS) $(INCLUDES) $(DEFINES) -c $<

clean:
rm -f ip_masq_mms.o

Somewhere you missed a step when you compiled the package. When you get to the last step: make install; it should have put the module in the correct place for you. And it should have done other things as well. Either you missed a step or the make-file for the module is botched up.

There is also something going on in the background of the compilation of a module; a "linker" puts in the symlinks, and entries in the modules.conf file, so everything can work together. Doing these things manually can be done, but it is painstaking and exacting work. If it isn't done just right, BAD THINGS can happen.

Check other makefiles on the system for other modules, the warning indicates that they are not defined the same way.

Manually check the path for the "CFLAGS =" and " INCLUDES =" section. If you are running RH 8 or 9, that is not a good path. Go ahead and point it to the exact path to the linux source to the kernal you are using right now.
[That is the best thing to do, I found that the /usr/src/linux (which is itself a link) for some reason does not always point to the right place after using up2date. Possibly, because it leaves you with the option of booting to the old kernel. It is always best not to have a link pointing to another link. The miniaturized computer science guys in there running the compiler can get upset.]

You want to match the flags in CFLAGS = on all of your modules if you can, as well as the DEFINES = stuff. They may "work" if they don't match, but can still cause problems. An example is the -m (March)386 flag, if everything else on the system is compiled for your exact cpu or a different one--say -m586 or -m686 sometimes things get weird on you. So compare the make files if you can find them. Some packages have a script which checks the environment for the cpu-type and return a value to a variable in the make file as a pre-process.

Instead of having really learned what is going on, I admit I just compare things and look them up if they fail.

It's been awhile since I spent time reading makefiles: I still look everything up, and compare problem builds with make files for similar things which were successful. (With an emphasis on those in the kernal source. Yeah, it takes time.) I never trust my memory.

The best of all worlds is that there are no error or warning messages at all.
Usually the documentation for the specific package will tell you if there are any warnings it is safe to ignore. Otherwise, be paranoid.