News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Obi web interface does NOT like to be accessed remotely

Started by GWCS, February 25, 2012, 03:02:43 AM

Previous topic - Next topic

GWCS

I have set my Obi-110 to have a LAN IP of 192.168.1.110 and web administration port of 8110, however I have left the 5060 port unchanged. I have configured both my modem and router to forward the port accordingly. If I then try to access the Obi from an outside computer using my dynamic DNS address coupled with the port [ mysubdomain.dyndns.org:8110 ] I do get prompted with the User/Password window, and if I enter "admin/mypassword", I seem to log in, but most attempts to access most features give me strange messages like this one:

XML Parsing Error: mismatched tag. Expected: </xsl:when>.
Location: http://mysubdomain.dyndns.org:8110/default.xsl
Line Number 463, Column 13:


Some things I can access remotely, such as the call history, for example.

Why does the Obi web interface only "like" being accessed from a local machine? If that isn't strange enough, I have tried to access it using an Android phone as the remote computer and it simply will not let me get past the username/password stage. It just blanks the two fields, and re-pops the log-in screen, again and again. I am even using Skyfire as my Android browser set for a PC (instead of phone-friendly) view.

Does anyone know what is going on here?

lk96

Is the IP address you assigned to your Obi configured as static on the Obi?

Or you mapped the Obi MAC address to the mentioned IP address within your router/firewall/NAT box ?
So it is your router that assigns that IP address to your obi over DHCP ?

I had similar issues/symptoms as reported in http://www.obitalk.com/forum/index.php?topic=2628.0
My issues were resolved (at least so far) with using static IP address on the Obi.

L.

GWCS

No, I have set the Obi LAN address to be a static 192.168.1.110 (no DHCP assignment) and the administration  port to be 8110 (notice the theme of 110s since the product is called Obi-110?) I thought it would be easier to remember by choosing those numbers. Anyway, my modem (I use Clear, so you have to set ALL anticipated ports, one might use on one's network, on the modem to forward to the router. The Clear modem's gateway is 192.168.15.1 and my router is set to a static address of 192.168.15.10, so ALL ports forward on the modem to 192.168.15.10 (again, the router's IP address). Then within the router's software, one sets which ports should route to which attached devices (computer, Obi, etc.)



Point being, my port forwarding must be set up correctly, because I AM ABLE TO LOG IN from the outside world, but once logged in, I can only access a small fraction of the menu choices without getting those odd messages that the Obi generates.

I viewed  the thread you listed, and it talks about the unit "hanging", which is not something I am experiencing. I am saying that logging into the web interface from outside of my LAN does not behave identically to logging into it from within my LAN. I am very experienced in router configurations and port forwarding, but I have never experienced this type of inconsistency with any device or software. In other words, everything else I have on my network behaves identically whether accessed from within the LAN or from the internet. Further puzzling is my inability to log in from the internet using my Android smartphone. While I *am* getting the Obi's username/password popup window prompt, it simply does not recognize the user/password combination, despite it being correct.

I am new to Obi, and wonder how I might get this thread forwarded to an administrator if you do not have any answers?

QBZappy

GWCS,

Why are you port forwarding twice?

I don't think you need to have the modem port forwarding anything. If the modem is in bridge mode Dynamic DNS clinet should be on the router pointing itself, and then port 8110 forwarded to the OBi.

Maybe that will clear a path to the OBi.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

GWCS

The way that the Clearwire Motorola modem works, one must first port forward within the modem directing all anticipated-to-be-used ports, individually, through the modem to the static IP address of the router. Then, depending on which port you wish to direct to which attached device, within the router's firmware, forward accordingly to the various attached devices. In case you're wondering, you cannot simply forward ports 1-60000 to the router in one step, even though the modem's firmware allows for a port range. I have tried it and it does not work. Anyway, that's slightly off-topic.

So, yes, in the modem, port 8110 (along with every other port that every computer on my network uses) is directed to 192.168.15.10 (the router's static WAN IP).

Then within the router, port 8110 is directed to 192.168.1.110 (the Obi's static LAN IP)

Notice that I color coded the devices with the different LAN IP ranges (third number of the IP address), to point out that the "double-forwarding" of ports is necessary due to the fact the ports pass through two completely different IP ranges.

Please understand that I *AM* able to log in through a computer, remotely through the internet, so I *AM* dealing with a "cleared path", as you put it. Once logged in, however, I am only able to access some of the Obi's features, such as the call history.

Why I cannot log in at all from a smartphone is a total mystery, when I can do so from a computer.

QBZappy

GWCS,

Just for curiosity connect the OBi directly to the modem. See what you get.
Owner of the 1st OBi110/100 units in service in Canada & South America. 1st OBi202 on my street. 1st OBi1032 in Montreal.

tmetro

Quote from: GWCS on February 25, 2012, 03:02:43 AM
If I then try to access the Obi from an outside computer...I seem to log in, but most attempts to access most features give me strange messages like this one:

XML Parsing Error: mismatched tag. Expected: </xsl:when>.
Location: http://mysubdomain.dyndns.org:8110/default.xsl
Line Number 463, Column 13:


My recommendation would be to examine the HTML and JavaScript source code on the pages that are failing. Look for sloppy code that might be referencing an explicit port number.

Perhaps easier, you could run a browser with debugging tools, like Firefox with Firebug, to determine all the network resources being retrieved by the page. If the URLs themselves don't suggest the problem, you could manually retrieve each item using a command line tool like wget or curl and then compare the results to what you see doing the same thing on the LAN.

It could be an unreliable connection, resulting in some requests to the OBi failing.

The error message you quote seems to imply that an XML document retrieved by the browser was corrupted. The message may be misleading, but if accurate it would suggests there is something about this access mode that causes the OBi to send corrupted data. A mere network glitch wouldn't cause this, as TCP would correct any errors. There's a remote chance your provider might be trying to do something clever, like inject advertising or tracking codes into the document and corrupting it, but I'd expect that on a downstream, rather than an upstream, packet.


Quote
The way that the Clearwire Motorola modem works, one must first port forward within the modem directing all anticipated-to-be-used ports, individually, through the modem to the static IP address of the router. Then, depending on which port you wish to direct to which attached device, within the router's firmware, forward accordingly to the various attached devices.

This suggests that both the modem and router are implementing network address translation (NAT) and that the modem is not in bridge mode. It is atypical, but if you are seeing at least partial success in accessing the OBi's web interface, then unlikely related to your problem.

-Tom

ProfTech

I have seen this behavior as well. The first time I saw it I was at my daughters home using Firefox over her Wi-Fi connection to their Obi. Using IE seemed to clear up the issue so I blew it off to a browser issue. But when I got back home I had the same thing happen [again over Wi-Fi] and this time using IE didn't help. Weird part was I have never seen it fail when my computer is connected to my router with an ethernet cable. The most recent release of Obi firmware seems to have improved but not eliminated it completely so I am figuring it really is some sort of mis-configured web page(s) in the Obi. My DSL modem has been in the bridge mode since I installed it  precisely because of the NAT issues. Could never get standard Microsoft VPN to work otherwise.

JohnBowler

I believe the XML emitted by the OBi is malformed and the web interface certainly does not work with some browsers.  Midori (OpenBSD 4.6) doesn't work at all, apparently because it doesn't cache the authentication information and consequently continually asks for user name and password.  So far as I can see there is no way of making the web interface go via https so no way of avoiding this.

Konqueror (Gentoo/Linux ~amd64) works on some pages (even if I don't store the user/password), however, on the Status pages, "system status" "SP service stats" and "PHONE port status" display just the raw, unformatted, text.  Since Konqueror is highly standards compliant (in my experience) I believe the issue is with the formatting of those pages.  The ones that succeed use XHTML, the ones that fail use XML with an embedded XSL stylesheet that uses javascript; my guess is that the javascript is the problem.

Chrome on Windows (actually Windows 8) works fine, but I wouldn't expect Android Chrome to work based on experience with another embedded system (a ZTE MF-60) because the Android Chrome seems to be unable to click on UI objects in some web pages.   I had to install FireFox on my Android system to program the MF-60.

John Bowler <jbowler@acm.org>

JohnBowler

Quote from: JohnBowler on August 06, 2012, 03:19:10 PM
Windows (actually Windows 8) works fine

What that *meant* was "Windows, actually Windows 8, works fine".

Apparently eight) is verboten.