TomatoUSB

Hello folks,

I'm using Shibby's latest build on a WNR3500Lv2 (firmware link : tomato.groov.pl\download\K26RT-N\build5x-101-EN\Netgear%20WNR3500Lv2\tomato-Netgear-3500Lv2-K26USB-1.28.RT-N5x—101-VPN.chk).
The router is in Gateway mode. Its config is pretty basic, no access restrictions or similar stuff that could get in the way (not that I'm aware of, at any rate).

When I enable UPnP listening on the LAN bridge, my UPnP client (miniupnpc 1.5 on Debian testing) doesn't detect any available IGD when it should. I tried disabling Secure Mode, enabling Show in My Network Places, to no avail.

$ upnpc -l
upnpc : miniupnpc library test client. (c) 2006-2010 Thomas Bernard
No IGD UPnP Device found on the network !

I believe neither this client nor my computer's network configuration (firewall etc) are to blame, because when I bypass the router (plugging the WAN ethernet wire directly to the computer) I can access the DSL modem's IGD without problem, the very same command upnpc -l then gives me a list of the UPnP port translations on the modem along with the auto-detected modem's IGD URL.
Being rather new to Tomato I probably have missed something along the way in some other configuration page, but unfortunately STFW'ing didn't help.

Any hints as to where I should look?
Thanks for your time.

Anything in the tomato log? The router miniupnpd can fail to start if it can't detect a WAN IP - not sure why you would want upnp running on the modem - are you deliberately running in "double nat", would need "double nat + dmz" to have a chance of router upnp being any use!

Thanks for your reply.

While I was answering your questions I decided to tcpdump the discovery process (I should have done that earlier, sorry), and added iptables logging.
As it happens, Tomato does reply but the iptables firewall on my computer somehow doesn't recognize those packets as RELATED/ESTABLISHED so it drops them.
The weird thing is that with the exact same firewall configuration there is no problem with the packets that come back from my modem during a similar discovery process. I have yet to find out why one works but not the other.

I'll keep you updated so that it can be useful to someone else (or maybe even improve Tomato on that respect if that's possible).
My apologies for not doing all of my homework before posting here.

And incidentally, yes, I'm running a "double NAT" setup because my modem doesn't give me any choice about that (if I put it in bridge mode I lose the phone and TV services, yay for French ISPs), and I want the full-blown Tomato gateway services which are much better than my modem's. But that's not an issue for me: I'm perfectly fine with opening UPnP ports "manually" (in scripts, that is) using the miniupnpc client. Since the client accepts an IGD URL I can access my modem's UPnP services that way.
Typical (planned) usage:

$ cat start-listening-service
#!/bin/sh
upnpc -u <modem_ip/igd_url> -a <router_wan_ip> <wan_port> <wan_port> tcp    # adds a port redirection from the modem to the router
upnpc -a <computer_lan_ip> <lan_port> <wan_port> tcp                        # adds a port redirection from the router to the computer
listening-service                                                           # blocks until shut down
upnpc -d <wan_port> tcp                                                     # removes the port redirection from the router
upnpc -u <modem_ip/igd_url> -d <wan_port> tcp                               # removes the port redirection from the modem

After some more tinkering, I still can't see why the modem's reply passes the firewall while the router's reply does not. Both tcpdump outputs (firewall down to be sure to catch everything) are identical. The router sends two packets when the modem only sends one, but that's not the problem: both packets from the router are dropped & logged anyway when the firewall is up.

Oh well I'll just poke a hole in my firewall (incoming UDP 1900 from the router, if anyone happens to have the same problem in the future) and be done with it.