1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

local loopback removal

Discussion in 'HyperWRT Firmware' started by ShadowDragon, Jan 25, 2005.

  1. ShadowDragon

    ShadowDragon Network Guru Member

    I recently bought a WRT54G and found one problem that no firmware has fixed. :(

    I run a small IRC server on my LAN for myself and a few friends to connect to.

    With my previous routers (A linksys BEF something or other and an SMC Barricade 7004VWBR) if I connected to the server using it's private address, I would show up with my private address. Since this does not allow DCC transfers I started connecting to the server using my dynamic DNS. This would make me show up as my public IP address and all was fine.

    With the WRT54G I now show up as the Router's IP address, this of course does not allow DCC.

    Has anyone figured out how to get the WRT54G to give the public IP like the other routers I've had?

    Failing that: Avenger, can a toggle to turn this "feature" on and off be added to the next version of HyperWRT?
     
  2. ShadowDragon

    ShadowDragon Network Guru Member

    I guess no-one has any tips huh?

    Linksys has written back for a fourth time, even including the log files I showed them of me connecting to the server with the same canned response about enabling/disabling "filter nat redirection" which just either connects me with the local IP or doesn't let me connect period. :roll:
     
  3. sillygoose

    sillygoose Network Guru Member

    I'm a little confused about what you're trying to do and what does or doesn't work. Tell if I have this right. You have a server on your LAN that you run an IRC daemon on, say 192,168.1.50. You have another computer you use to connect to that IRC server, say 192.168.1.100. You have a public ip that you register with DynDNS that belongs to the WAN interface of you WRT54G, say 69.1.1.1. For DCC to work you need your connection to the IRC server to appear to come from yourName.dyndns.org (69.1.1.1). You can't tell the IRC client to connect to 192.168.1.50 because then you appear to come from 192.168.1.100. On other routers you were able to tell the IRC client to connect to yourName.dyndns.org and then your client also appeared to be connected from yourName.dyndns.org? With the WRT54G when you try this you appear connected from 192.168.1.1? Could the problem be with the order of the iptables targets? Maybe packets coming from the LAN to the WAN IP get passed back to the LAN before being NATed?
     
  4. ShadowDragon

    ShadowDragon Network Guru Member

    Sorry if I wasn't specific enough to begin with. The deeper I delve into the problem the more "correct" my terminology dealing with the router becomes. :)

    Example WRT54G:

    192.168.1.1 = router LAN
    192.168.1.50 = server
    192.168.1.100 = client
    69.1.1.1 = router WAN
    foo.bar.org = DynDNS
    48.2.1.1 = friend

    /server 192.168.1.50 ShadowDragon
    /whois ShadowDragon
    192.168.1.100

    /server foo.bar.org ShadowDragon
    /whois ShadowDragon
    192.168.1.1

    48.2.1.1 DCC -> 192.168.1.1 [Failure]
    192.168.1.100 (Masq=192.168.1.1) DCC -> 48.2.1.1 [Failure]

    Example BEFSR41/7004VWBR:

    /server 192.168.1.50 ShadowDragon
    /whois ShadowDragon
    192.168.1.100

    /server foo.bar.org ShadowDragon
    /whois ShadowDragon
    69.1.1.1

    48.2.1.1 DCC -> 69.1.1.1 [Success]
    192.168.1.100 (Masq=69.1.1.1) DCC -> 48.2.1.1 [Success]

    ---

    After giving up talking to Linksys in any format (spent an hour on the phone only to be told that there was no way it was possible without two WAN ports/IPs.) I poured through the source, it is configured to Masq to "Lanface" on lan connections. On wan connections it is configured to Masq to "Wanface".

    If I ssh into the router and poke around I find the dnsmasq.conf file which contains interface=br0. If I do an ifconfig on the router, I find that br0 holds the private IP, vlan1 is what holds my Public IP. If I change the dnsmasq.conf file and stop/restart the dnsmasq service (the only way to get it to read dnsmas.conf for security reasons) It re-writes the file putting br0 back in there. :(

    So I tried editing firewall.c to change the first instance of "lanface" to "wanface"

    if (nvram_match("block_loopback", "0")) {
    /* Allow "LAN to LAN" loopback connection.
    * DMZ and port-forwarding could match it. */
    save2file("-A POSTROUTING -o %s -s %s%s -d %s%s -j MASQUERADE\n",
    lanface, lan_cclass, "0/24", lan_cclass, "0/24" );
    }
    else {
    save2file("-A POSTROUTING -o %s -s %s%s -d %s%s -j DROP\n",
    lanface, lan_cclass, "0/24", lan_cclass, "0/24" );
    }

    Well I can get it to make dep but it fails on the final make. I tried just the stock firmware and it does the same thing, so apparently my linux box doesn't like the code anyway. We won't go with what my BSD box does when I try to make dep, even with gnumake :lol:

    I'm hoping either someone else has a way of doing it from the router shell without changing the firmware or someone that can get the code to compile can either change that line or (just in case someone really wants the router masqing lan connections, I personally fail to see the point but I'm sure someone would need it eventually) add another option to the "Filter nat"/"loopback" that allows you to toggle between LAN and WAN.

    an iptables -L doesn't show me anything about giving out LAN or WAN ip.
     
  5. sillygoose

    sillygoose Network Guru Member

    It sounds like you figured out the problem. What error do you get when trying to do the make? Did you set up the mips compiler properly? I can compile a firmware for you if you'd like, what version do you want
     
  6. ShadowDragon

    ShadowDragon Network Guru Member

    Probably not. This is definately the first time I've ever done anything with MIPS.

    mipsel-uclibc-ld -r -o .pppoecd magic.o fsm.o lcp.o ipcp.o upap.o pppoehash.o pppoe_client.o libpppoe.o main.o auth.o options.o demand.o utils.o sys-linux.o pppoe.o md5.o chap.o md4.o chap_ms.o /usr/lib/libcrypt.a
    /opt/brcm/hndtools-mipsel-linux/bin/mipsel-linux-ld: /usr/lib/libcrypt.a(crypt_util.o): linking PIC files with non-PIC files
    Bad value: failed to merge target specific data of file /usr/lib/libcrypt.a(crypt_util.o)
    /opt/brcm/hndtools-mipsel-linux/bin/mipsel-linux-ld: /usr/lib/libcrypt.a(crypt.o): linking PIC files with non-PIC files
    Bad value: failed to merge target specific data of file /usr/lib/libcrypt.a(crypt.o)
    /usr/sbin/mipsel-uclibc-ld: line 3: 1454 Segmentation fault /opt/brcm/hndtools-mipsel-linux/bin/mipsel-linux-ld $@ -L/opt/brcm/hndtools-mipsel-uclibc-0.9.19/usr/lib -L/opt/brcm/hndtools-mipsel-uclibc-0.9.19/lib -L/opt/brcm/org/tools-src/uClibc
    gmake[2]: *** [pppoecd] Error 139
    gmake[2]: Leaving directory `/home/bsmith/WRT54G_3_01_3_0922/release/src/router/ppp/pppoecd'
    gmake[1]: *** [ppp] Error 2
    gmake[1]: Leaving directory `/home/bsmith/WRT54G_3_01_3_0922/release/src/router'
    gmake: *** [all] Error 2


    I did, after paying for it, manage to get ahold of a developer altered version of Alchemy which allowed me to change the dnsmasq line above, stop the service and restart it with my new conf file, that didn't help. :(

    Linksys 3.01.3 with HyperWRT 2.0 is fine by me if you want to compile it and send to shdwdrgn at shadoweb dot net at least I'll be able to see if that change does what I hope it does.
     
  7. Crusader

    Crusader Network Guru Member

    ive got something like the same problem that i cant resume dcc tranfers :(
     
  8. sillygoose

    sillygoose Network Guru Member

    I was getting ready to make the change to firewall.c and realized that what you want changed isn't going to fix your problem. That is an iptables rule that is specified in that code. The iptables rule doesn't appear when doing an iptables -L. There doesn't seem to be a POSTROUTING chain at all. The rule you are asking appears in my /tmp/.ipt file with br0 specified. The issue seems to be that iptables wasn't compiled with POSTROUTING support.
     
  9. ShadowDragon

    ShadowDragon Network Guru Member

    I was afraid that wasn't going to work. So in other words I have to live without it or return the router and find another brand that still works the way the linksys routers used to. :(
     
  10. ShadowDragon

    ShadowDragon Network Guru Member

    Actually I just did an iptables -t nat -L and this was at the bottom...

    Chain POSTROUTING (policy ACCEPT)
    target prot opt source destination
    <Rules made via the web interface for forwarding>
    MASQUERADE all -- anywhere anywhere



    I added this to the postrouting chain but it didn't change anything
    SNAT all -- 192.168.2.0/24 anywhere to:<public IP>
     
  11. sillygoose

    sillygoose Network Guru Member

    Look in your /tmp/.ipt file. What interface is shown in the postrouting chain there?
     
  12. ShadowDragon

    ShadowDragon Network Guru Member

    -A POSTROUTING -o vlan1 -j MASQUERADE
     
  13. sillygoose

    sillygoose Network Guru Member

    Interesting, I think when I looked this morning mine had a "-A POSTROUTING -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADE". That makes me think you don't need a recompiled firmware we just need to figure out which setting causes that.
     
  14. ShadowDragon

    ShadowDragon Network Guru Member

    Yeah, I rebooted the router just to make sure it wasn't the rule I added, and it's still vlan1

    /tmp # more .ipt |grep POSTROUTING
    :pOSTROUTING ACCEPT [0:0]
    <port forwarding rules removed>
    -A POSTROUTING -o vlan1 -j MASQUERADE

    I've only got 9 days left before I'm out of the return window of the router. I love this router and the fact it's running linux but this little problem is certainly annoying! :D
     
  15. sillygoose

    sillygoose Network Guru Member

    try running this command "/usr/sbin/iptables -t nat -A POSTROUTING -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADE" I still haven't been able to figure out what setting causes it to be added but I think it will fix your problem and at the least you can add to the startup script.
     
  16. ShadowDragon

    ShadowDragon Network Guru Member

    No go. :(

    And yes, I changed my private ipblock to the one I actually use.
     
  17. sillygoose

    sillygoose Network Guru Member

    I think we were on the wrong path I don't think rule does what you thought it did. Try something like this "/usr/sbin/iptables -t nat -A PREROUTING -d 69.1.1.1 -p tcp --dport 6667 -j DNAT --to 192.168.1.50" and this "/usr/sbin/iptables -t nat -A POSTROUTING -d 192.168.1.50 -s 192.168.1.0/24 -p tcp --dport 6667 -j SNAT --to 69.1.1.1"
     
  18. ShadowDragon

    ShadowDragon Network Guru Member

    Already in there


    it added this

    SNAT tcp -- 192.168.1.0/24 192.168.1.50 tcp dpt:ircd to:69.1.1.1

    No change (yes, I used the real info for the rule. ;) )
     

Share This Page