> A UPnP daemon with netfilter hooks (and whatever else it needs to hook
> into) is the proper way to do this and go on with it. In the spirit of
> hating Microsoft, some people may abandon this idea. But it is becoming
> widely accepted. And lets face it, I administer some 60 windows
> machines and they are all connecting at multiple locations through
> Linux. I'm sure many people are in the same boat.
You are absolutely correct. "Real" standard or not, UPnP support is rapidly
expanding, and there is no good reason that we should not be properly
supporting it. I have about 300 windows machines in various locations that
I support, and each location is connected to the Internet via a Linux NAT
box. It's been killing me that I can't support UPnP (Messenger
specifically) across the NAT, but you can go down to Best Buy and for $100
pick up a Linksys "Internet Gateway" that supports UPnP.
Anyway -- enough ranting.
> I say we go for it. Is the guy who done the one for 2.2 responding to
> emails? Let's take a look at his code, and see what we can do.
I have not contacted the guy who wrote the daemon for 2.2. But, I have
spent the last hour or so going over his code to see how he was hooking into
IPChains in order to see how difficult it will be to convert. From what I
can tell so far, this is how it works:
1) The dameon makes use of the functions in the Intel SDK in order to listen
and communicate with other UPnP machines. It tells the local subnet that
the Linux box is a UPnP gateway, and then listens for UPnP requests and
keeps track of any ports that it is forwarding to machines on the inside.
2) When the daemon recieves a request to open ports for a specific
computer/application, it:
a) Does a lot of error checking to make sure that the ports are actually
available and not in use and then,
b) Makes a straight-up system call to ipchains or portfw to reconfigure
the firewall. He literally just calls IPChains from the commandline like
this:
sprintf(command,"/sbin/ipchains -D upnp -j ACCEPT -p %s -s %s -d %s %d",
prt, SrcIP, DestIP, DestPort);
doCommand(command);
I suspect that there is a much cleaner way to hook into netfilter, but in
the very short term (immediately) I think I can modify the current daemon to
run with iptables (using the same system) in a matter of an hour or so. I
actually intend to do this right now.
In the longer term, I think we should look at two things:
1) I'm not terribly familiar with the netfilter architecture. Maybe one of
the netfilter developers can chime in and tell me what the proper way to
hook into netfilter would be? We need to do several things:
a) Make sure a port is not already in use through another application or
forwarded via the rc.firewall script.
b) open ports in the input chain
c) forward ports to an inside machine
d) remove the forwarding / close ports
There are probably some more things we'll need to do, but those are the only
ones I've seen in the "pseudoicsd" code so far. Should I technically be
#including "some_netfilter_file.h" and calling netfilter functions in C to
perform these tasks, or is it equally "proper" to do it through a
"system("iptables -A UPNP -sblah -dblah")" method?
2) I am going to hack up this daemon right now, but think we need to contact
the author and coordinate the abstraction of the calls that open, forward,
and close ports. Hopefully we can keep a single source tree that supports
both IPChains and Netfilter.
I'll report back in a bit when I get this thing working with netfilter.
