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

Problems with build 44 (vpn3.6)

Discussion in 'Tomato Firmware' started by bozo, Feb 18, 2010.

  1. bozo

    bozo Addicted to LI Member

    Hi,

    I upgraded from build 42 to 44 and I seem to have a couple of problems:

    1. Samba does not appear to work (worked fine with 42 and Windows 7 before)
    2. FTP server works on WAN only on port 21. When I connect through a different port it does not list any directories.

    Any ideas?

    Thanks,
    B.
     
  2. teddy_bear

    teddy_bear Network Guru Member

    Not enough info to say anything. Works for me with XP and Vista with no issues.
    iptables -L -n, to start with, and make sure you're testing it from the real WAN, not just using external IP from LAN...

    BTW, when did you download the vpn build? The one I originally uploaded had a bug in vpn implementation, and I published an updated one last night. Should not cause any of your issues though.
     
  3. Disman_ca

    Disman_ca Super Moderator Staff Member Member

    Moved to seperate thread
     
  4. bozo

    bozo Addicted to LI Member

    Ok, there is no issue with Samba. It turned out to be a Win7 issue but works now.

    I still have the problem with the ftp server though when I acess it from the WAN and use a port other than 21 (here 4321). It lets me log in via ftp but "hangs" when I want to list a directory. Here is the output of iptables -L -n:

    Chain INPUT (policy DROP)
    target prot opt source destination
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
    ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
    DROP all -- 0.0.0.0/0 66.185.5.117
    DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
    ACCEPT tcp -- 0.0.0.0/0 192.168.10.1 tcp dpt:80
    ACCEPT tcp -- 0.0.0.0/0 192.168.10.1 tcp dpt:22
    ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:4321

    Chain FORWARD (policy DROP)
    target prot opt source destination
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
    DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID
    TCPMSS tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 tcpmss match 1461:65535 TCPMSS set 1460
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    wanin all -- 0.0.0.0/0 0.0.0.0/0
    wanout all -- 0.0.0.0/0 0.0.0.0/0
    ACCEPT all -- 0.0.0.0/0 0.0.0.0/0

    Chain OUTPUT (policy ACCEPT)
    target prot opt source destination

    Chain wanin (1 references)
    target prot opt source destination

    Chain wanout (1 references)
    target prot opt source destination

    Thanks!
     
  5. teddy_bear

    teddy_bear Network Guru Member

    You didn't confirm that you're testing FTP from the actual WAN side, and not from one of your LAN computers just using the external WAN IP. Are you?

    If you are, is there any chance that your router is behind another firewall? Maybe an office or campus network, or your ISP blocking certain ports?
     
  6. bozo

    bozo Addicted to LI Member

    I am ftp-ing to my router (at home) from work. There is probably a firewall at work here but I don't think that that is the problem. I was able to ftp from work with build 42 to any port I wanted and with build 44 only port 21 works properly. The reason why I think it has something to do with the router software is because ftp will let me log in as a user but it "hangs" when it is trying to list the directories.:confused:

    Thanks!
     
  7. teddy_bear

    teddy_bear Network Guru Member

    I do not see any changes in between v42 and v44 that could possibly cause this... I'll test it with the VPN build later and will let you know.
     
  8. teddy_bear

    teddy_bear Network Guru Member

    UPDATE: Flashed my 520gu with v44 VPN build, and tested FTP access from WAN on both ports - 4321 and 21. Worked perfectly on both ports with no issues - I was able to connect, get directory listings, and upload/download files. (However, I have not tried it with VPN server or client running... There's a small chance that there's a conflict there but I doubt so - in any case you can easily test it yourself).

    So whatever the problem is, it must be somewhere on your end. Try to do thorough nvram erase and reconfigure manually, as this might help when everything else fails.
     
  9. bozo

    bozo Addicted to LI Member

    Ok, I'll do some more debugging. Thank you so much for your help!
     

Share This Page