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

2 ASUS RT-N12s (as router & AP) & Xbox 360: UPnP not working

Discussion in 'Networking Issues' started by OndrejB, Dec 10, 2016.

  1. OndrejB

    OndrejB New Member Member

    Good evening (at least in my country),

    I am sorry I didn't mention UPnP in my last question. I was searching it all day, so forgot to mention it.

    I am using 2 ASUS RT-N12s (first revision without letter and D). My network setup looks like this:

    my-network.png

    192.168.1.1, Tomato Firmware 1.28.0000 MIPSR2-138 K26 Max:
    This serves as a router. UPnP and NAT-PMP is enabled. I am not sure about any other change in settings (despite of creating wireless network).

    192.168.1.2, Tomato Firmware 1.28.0000 MIPSR2-138 K26 MiniIPv6:
    This serves as an AP. UPnP and NAT-PMP is disabled.

    Basic -> Network:
    WAN Settings:
    Type: Disabled
    Wireless Client Mode: Disabled
    Bridge WAN port to primary LAN (br0): enabled​
    LAN:
    Bridge: 0
    STP: disabled
    IP: 192.168.1.2
    Mask: 255.255.255.0
    DHCP: disabled
    IP range: -
    Lease time: -​
    Default Gateway: 192.168.1.1​

    Advanced -> Routing:
    Mode: Router​

    In Xbox network settings I left everything as it was, automatic. I have Xbox in static DHCP/ARP/IPT router (192.168.1.1), so it gets same IP every time.

    When Xbox is connected like on picture above, UPnP is not working, ports are not added automatically and Xbox says "NAT Moderate".

    When I tried to connect to router's (192.168.1.1) wi-fi (C33-1), it worked. So it looks like via AP (192.168.1.2) Xbox is not able to open ports through UPnP, possibly double NAT? But I don't know how it's possible, I thought the AP is "transparent" to network and acting like plain switch.

    EDIT 1:
    BUT when I connect my laptop directly to AP (via wi-fi C33-2) and run Skype, UPnP works and I can see it adds some forwarded ports to router.

    EDIT 2:
    Really strange behavior...
    Laptop connected to C33 wifi. I run Skype, check forwarded ports and see something like:
    8938 8938 192.168.1.249 UDP Skype UDP at 192.168.1.249:8938 (3631)
    8938 8938 192.168.1.249 TCP Skype TCP at 192.168.1.249:8938 (3631)

    Laptop connected to AP via ethernet cable (just as Xbox). I run Skype, check forwarded ports and see same like above (with 192.168.1.250), BUT instead of note like "Skype UDP at ..." I see only "NAT-PMP".
    Now it looks like UPnP "request" can't get through, but NAT-PMP can?

    If you have any idea or question, please, let me know.
     
    Last edited: Dec 10, 2016
  2. koitsu

    koitsu Network Guru Member

    Original post which stemmed this thread: http://www.linksysinfo.org/index.php?threads/tomato-shibbys-releases.33858/page-74#post-282370

    I take back what I said in one of my posts there: this is not a double NAT situation.

    What default gateway is 192.168.1.16 handed via DHCP? 192.168.1.1 or 192.168.1.2?

    Also, Skype doesn't support/use NAT-PMP to my knowledge (I would recommend disabling it in the router anyway) -- I use Skype myself -- so whatever you saw in "EDIT 2 Really strange behaviour" is unrelated to Skype.

    Please do not use machines on the wifi network for testing/analysis of this situation, if you can avoid it. It makes matters extremely complicated. Please stick with Ethernet only. It makes things a LOT easier to comprehend/understand when saying "Laptop hooked to RT-N12D router on LAN port 2".

    I think I may see the problem, but it's very complicated to try and explain how to debug this on a forum. It would be a lot easier if I was there physically.

    Are you using any custom VLANs?

    Are you using any custom bridges (i.e. more than just br0)?

    In this situation, for analysis, it's very likely you're going to need to install Entware-ng (I think Shibby has his own version, Optware/Optware-ng? I forget -- he keeps changing it around) on a USB flash drive and install tcpdump for packet captures. Explaining how to do this (ESPECIALLY when multiple interfaces are involved!) is tedious and very time-consuming, made even more complicated by the fact that SSDP uses a broadcasting mechanism (packets going to 239.255.255.250 (multicast)). It's very possible that the RT-N12 the XBox is hooked up to isn't passing multicast packets upstream (to 192.168.1.1). My gut feeling is that that's the case.
     
  3. OndrejB

    OndrejB New Member Member

    I just checked, it is 192.168.1.1. I tried to manually specify both, it made no difference.

    I tried it two times, port numbers were same, only the description was different. But this is not important anyways, it was just test.

    No. My setup is really simple.

    I tried to run miniupnpd -d for debugging purposes and I saw some network activity from devices in the house, but not the Xbox. It could be related.
     
  4. koitsu

    koitsu Network Guru Member

    Great (re: no custom VLANs or bridges).

    Your network configuration is really quite simple indeed: 192.168.1.2 forwards packets to 192.168.1.1 which it doesn't know what to do with. It's classic IP routing, very easy (and clean -- well done!).

    Please don't run miniupnpd with -d flag. I have no way of knowing if you ran the command correctly (there are other flags Tomato uses), and Tomato's init will try to restart the daemon on its own if it ends anyway, so you end up with a "fighting situation" (init vs. manual running).

    Can you please try using Skype from DESKTOP-2 and see if you end up seeing relevant UPnP forwards?

    I'm taking this troubleshooting process one step at a time. I have several ideas/steps still in mind (SSDP broadcast has my focus right now), but I do not wish to disclose them until I see the results of each test every time. So, we progress forward slowly, but will figure it out.
     
  5. OndrejB

    OndrejB New Member Member

    Okay, DESKTOP-2 connected via ethernet cable to 192.168.1.2. Everything set to automatic, gateway 192.168.1.1, DHCP 192.168.1.1.

    UPnP enabled:
    nothing :/

    UPnP & NAT-PMP enabled:
    External Internal Internal Address Protocol Description
    31490 31490 192.168.1.10 UDP NAT-PMP 31490 udp
    31490 31490 192.168.1.10 TCP NAT-PMP 31490 tcp

    EDIT:
    One more thing to mention, on 192.168.1.1 DHCP range is set to 192.168.1.3 - 192.168.1.254.
     
    Last edited: Dec 10, 2016
  6. koitsu

    koitsu Network Guru Member

    Is DESKTOP-2's IP 192.168.1.10?

    If so: on DESKTOP-2, in Skype, if you go into Tools -> Options -> Advanced -> Connection, what is the port number shown in grey/italics in the field "Use port [XXXXX] for incoming connections"?

    I would bet money that it's not Skype, but instead Bonjour or some other Apple-related software installed on DESKTOP-2. Not very many things use NAT-PMP. Some BitTorrent clients do. And again, to my knowledge, Skype cannot do NAT-PMP, only UPnP.

    If not: then those NAT-PMP forwards are unrelated to DESKTOP-2, thus unrelated to Skype.

    My money right now is on that SSDP multicast/broadcast isn't being passed upstream to the 192.168.1.1 router (i.e. 192.168.1.2 sees it, but it never makes it to 192.168.1.1). Packet captures (on routers) will be necessary.
     
  7. OndrejB

    OndrejB New Member Member

    Well, it may be strange, but it says "Use port 31490 for incoming connections."
     
  8. koitsu

    koitsu Network Guru Member

    How uncomfortable; there's no mention anywhere that Skype has ever had NAT-PMP support. My attempts to trigger it (disabling UPnP + enabling NAT-PMP in the router, then re-launching Skype and attempting some P2P I/O) have all failed.

    Is DESKTOP-2 a Windows-based PC? If so, are you using Skype 7.30.85.105? If so, huh, then they must have added NAT-PMP at some point without disclosing it. Microsoft... sigh *shakes head* :)

    I've been doing some reading and yes, I believe the reason UPnP isn't working is because of SSDP's reliance on multicast broadcast, which doesn't behave as you hope given your network topology. I strongly believe this can be made to work, with minimal effort. I'm about 90% sure at this point.

    Rather than teach you how to do packet captures and all the nuances involved there, I'd rather just recreate the network topology (and again: blessings to you for keeping it simple and optimal :) ). I'll need to pick up another router on which I can put Tomato and then reproduce the problem. I can do the analysis from there, and reproduce things without much issue.

    If you'd like to try some ideas/thoughts I have, I'd be willing to provide them, but I make no guarantees what will happen nor do I guarantee what the security implications could be.

    In the meantime, could you please get me output from the following commands on both routers? Please put them in code blocks (for retaining formatting) here on the forum, and please put them in the order of the RT-N12D first followed by the RT-N12:

    Code:
    brctl show
    netstat -r -n
    
    You can XXX out some of the octets of your real Internet WAN IP on the RT-N12D, and XXX out parts of the MACs from brctl show (please only X out the last 3-4 digits), but please don't change anything else.
     
  9. OndrejB

    OndrejB New Member Member

    Yes, DESKTOP-2 is Windows 8 PC with fresh downloaded Skype, my version is 7.30.80.105. LAPTOP-1 is Windows 10 with a little bit older version of Skype. Both were doing the same in the port forwarding of router.

    You are very helpful, thank you very much.

    I have some understanding how to do packet capturing, I remember I ran tcpdump (actually, it was rpcapd probably) and viewed it remotely with WireShark, but it's some time.

    I understand you don't want to explain, so I will wait if you come up with something. :)
     
  10. OndrejB

    OndrejB New Member Member

    I tried at least "something"...

    Run rpcapd on 192.168.1.2, Xbox is connected by cable to 192.168.1.2, filter in Wireshark set to "sspd". Nothing, not a single letter. Then I pulled of the cable (so the Xbox connected to wifi automatically) and suddenly there popped few SSPD rows.

    Now I tested it with wifi network C33-2 (which is virtual wlan provided by 192.168.1.2) and SSPD rows are there...

    Why it does not work via ethernet and does via wifi? :O
     
  11. koitsu

    koitsu Network Guru Member

    Please don't use rpcapd for this. You attempting captures within explicit instructions doesn't help the situation, it just throws more "random stuff" into the mix. I tried to cover this already when I said earlier, quote, "and install tcpdump for packet captures. Explaining how to do this (ESPECIALLY when multiple interfaces are involved!) is tedious and very time-consuming, made even more complicated by the fact that SSDP uses a broadcasting mechanism (packets going to 239.255.255.250 (multicast))".

    So before I bother to try to reproduce this (and I'm betting I can, my understanding of networking is fairly good, heh :)) -- and I'll add I've already looked at some of the Tomato code that pertains to where my line of thinking is going, and there is a reason I am asking this specific question -- can I ask you something?

    Why did you hook the RT-N12D to the RT-N12's WAN port?
     
  12. OndrejB

    OndrejB New Member Member

    Sorry, I was just curious if I can observe something.

    No particular reason, I've read somewhere that I can since there is option to bridge WAN to br0.
     
  13. koitsu

    koitsu Network Guru Member

    The WAN port on Tomato routers is treated very, very uniquely.

    Inside the RT-N16 (like many other models), there is actually a 5-port Ethernet switch. Yes, I said 5. The segregation of ports (i.e. splitting up 4 ports for LAN, and 1 for WAN) is done using VLAN support (which requires direct support for the Ethernet switching chip in the router). This is how all the interfaces break down:

    eth0 = 5-port Ethernet switch (as a whole)
    eth1 = 2.4GHz WiFi
    vlan1 = 4 ports on eth0 (back of router's "LAN" ports 1-4)
    vlan2 = 1 port on eth0 (back of router's "WAN" port)
    br0 = Software bridge consisting of eth1 and vlan2 -- this is what Tomato calls your "LAN"

    Based on my review of some of the Tomato code, I think if you move the connection from the WAN port to a LAN port, you'll very likely see UPnP begin to work.

    If it works, I can explain why in detail.
     
  14. OndrejB

    OndrejB New Member Member

    Hello again, koitsu!

    Sorry I'm late, I'm a daysleeper :X (5:49 pm here). YOU... ARE... GENIUS! (And I'm dumb I didn't try it earlier.) After connecting the cable into LAN port it works like a charm! :)

    Thank you very much for your incredible help!
     
  15. koitsu

    koitsu Network Guru Member

    No problem. Let me know if you want a write-up explaining why that works (my gut feeling was right, it has to do with multicast traffic).

    And again, for a third time: thank you for keeping your network simple (and for the excellent diagram!). It makes me happy to see someone using standard/classic IP routing cleanly, vs. tossing together a bunch of weird bridges or VLANs.
     
  16. OndrejB

    OndrejB New Member Member

    Well, I am curious. If you don't mind, please, explain. :)

    I noticed 2 VLANs in default Tomato settings, one has LAN ports assigned, second has only WAN port. So it is possible to reassign the WAN port?

    Haha, you don't have to thank me for simple network, I just needed to extend my network and also wireless range. I am living in a 100m^2 apartment, but there is like 20+ wireless networks around me, so I had to use 2nd AP to get good coverage in every room, insane. I am planning to get Mikrotik or Unifi in the future to get good coverage with only one AP.
     
  17. koitsu

    koitsu Network Guru Member

    There are many potential reasons, actually, and packet captures would be able to prove which of them were actively true/in place.

    The short of it is that multicast traffic (which SSDP is -- it's traffic destined to 239.255.255.250, which is part of the 224.0.0.0/4 multicast network per IANA) is not forwarded out the WAN port (vlan2) in Tomato.

    This is one potential reasons why the 192.168.1.1 router (which runs miniupnpd) never saw the SSDP traffic from systems which were attached (via Ethernet or wifi) to the 192.168.1.2 router. Essentially, the SSDP traffic was "segregated" to the 192.168.1.2 router.

    There IS a way to turn on "multicast forwarding" (in a manner of speaking) -- I had to look at the code in Tomato -- but it's, shall I say... somewhat complicated. It involves use of the igmpproxy daemon (which is something I don't have experience with). As I began to read more about it, I began to question the rules/configuration used in that daemon and stopped. There are other multicast-related features/tweaks in Tomato as well, which I also investigated (some of which begin injecting iptables rules for multicast ranges), but again, I stopped myself. I instead took a step back and thought "no, wait, don't bring that up. This has to be simpler than that." My brain kept thinking "he's treating 192.168.1.2 not really like a router -- it doesn't normally forward packets because all devices connected to 192.168.1.2 are using a gateway of 192.168.1.1 -- but just 'another device on the LAN'. Almost like a dumb switch with wifi support. Ten bucks this has to do with interfaces, and with the uniqueness of multicast traffic vs. unicast."

    Your first response to the above explanation will probably be: "okay, I kind of understand, except that I had the 'Bridge WAN port to primary LAN (br0)' setting enabled. Should that not have made it work?" -- it's a good question. I did not taken the time to actually investigate what that feature really does (meaning: I don't know if it associates vlan2 with br0 or not). That is why I asked for brctl show and netstat -r -n output from both routers.

    My theory is that no, it's probably done differently, but I could be wrong. Again: this is something I could determine very quickly with a duplicate network setup or if I was physically present, but explaining how to do all of this remotely is time consuming. (Most network technicians charge for this degree of time/support)

    Packet captures done on all devices' respective interfaces (this means something like 4 or 5 different copies of tcpdump all running at the same time! Yes really!) to see what the behaviour is would determine this definitively, but as I described previously, explaining how to do that would also have taken more time.

    But there is an added level of complexity, going back to the first couple paragraphs of my explanation: there are normally on Tomato not routing rules present for 224.0.0.0/4. Given what the behaviour was that was being seen, my impression is that traffic to multicast addresses were not subject to being forwarded to the default gateway (i.e. a client connected to 192.168.1.2 sending a packet to 239.255.255.250 would not have had its packet forwarded to 192.168.1.1). The Linux kernel actually has knowledge/support for multicast forwarding (these are different than unicast packets!), and I have a feeling that's disabled by default.

    At one point I even started Googling for information (all of the above was being done purely in my head -- again, years of networking experience), and I came across this post on an AVS forum that really resonated with me (it basically confirmed some of my suspicions): http://www.avsforum.com/forum/27-re...ding-upnp-ssdp-broadcasts-across-subnets.html

    This is even further complicated by the fact that miniupnpd only cares about traffic from specific interfaces.

    I apologise for the long-winded and somewhat circular explanation, but it really boils down (to me) to the fact that 192.168.1.2 wasn't "part of the actual LAN that 192.168.1.1 consisted of". Operationally it was fine (and your routing was fine!), but for multicast packets the situation is a little different.

    I definitely think it'd be possible to get it to work using your original network topology (WAN port of 192.168.1.2 connected to LAN port of 192.168.1.1), but "what to tweak" to get SSPD to work is something I'd have to sit down and analyse myself. But as I said: when I started going down that road, I said "STOP! His network is very simple, let's think about this a little longer, I bet the answer is more obvious".

    Yeah, I explained what all the interfaces consist of in an earlier post.

    I assume you're asking this because you want to use the physical Ethernet port labelled WAN for LAN purposes. Yes, I suppose that would work, but I would not advise it. There's a lot of code internally that relies on the existence of a WAN port (even if its set to Disabled), so by removing vlan2 and re-associating the port to be part of vlan1, Tomato may break very badly.

    This is a separate subject/test/thing that I would have to test with an additional router and so on. There's a reason networking labs exist at Fortune 500 companies -- physically separate rooms with physically separate routers/devices/equipment, used to simulate a different environment, solely so engineers can work out what the anomaly is and figure it out. I don't like "playing" with my actual Internet-connected Tomato router because it interrupts my workflow and potentially could cause problems. I have to have a working Internet connection, and I only have one router. To do this -- or to reproduce/test/fully analyse the stuff I described above -- I'd really need a small lab to reproduce the network topology and work it all out.
     
    c4flash likes this.
  18. c4flash

    c4flash New Member Member

    I have a similar problem to OndrejB. In my case, rokus connect to lan, but not to internet.
    setup: ISP > EdgerouterX > RT-N16 > LAN/wifi

    Everything works when only using RT-N16, including rokus.
    With Edgerouter interposed, everything EXCEPT rokus work. All other eth/wifi devices work.
    Because rokus wander around the lan after power failures etc, I have set them up on RT-N16 using dhcp/arp to retain ip/mac binding in a small block: 192.168.1.11-13
    the RT-N16 connects from a lan port [port 3] to the EdgerouterX's lan port eth1 [wan is eth0]

    I set the RT-N16 for a static address and the EdgerouterX for NO dhcp for downstream LAN. (all my devices on the RT-N16 have static addresses). Edgerouter is set as gateway, RT-N16 is set as router. dhcp is enabled for the roku block of addresses.

    Any ideas? Should I use a specific port on the rt? I only had time to try port 3 today; roomies complained of no access because I disconnected the switch to their subnets, to keep thing simple, lol
     
  19. c4flash

    c4flash New Member Member

    So, it just dawned on me that since I am using the Edgerouter as gateway, I might have to re-enable dhcp on it for the roku block only and see if I can find ip/mac binding in the somewhat opaque menu options of the Edgerouter.

    Then. disable dhcp on the RT-N16; erase the dhcp/arp binding in tomato; reboot both routers, and see what happens.

    what do you think?

    I'll try this tomorrow or next day.
     
  20. c4flash

    c4flash New Member Member

    This worked; rokus bound to ip/mac; all wifi/eth devices connected; 3 10.x.x.x subnets from my roomies connected and set for adequate bandwidth with burst for first 100Mb (QoS); speedtest from dslreports (https): 242.2Mbps.

    Just a few minor adjustments; save configs for both EdgerouterX and RT-N16 and I'll call it a day.
     

Share This Page