0

This is a real bugger:)

My modem is a ZTE ZXHN H108L, connected to a linux firewall/router/gateway. The gateway is a Slackware 14.0 system on which DNS, DHCP, VPN and transparent PROXY run. The gateway has 2 hardware NICs. eth1 is connected to the modem (192.168.231.117), and eth0 is connected to the intranet (192.168.112.0/24).

I use the dns to give names to several intranet and vpnnet hosts. The modem has the convenient name "modem.skails.office" (or just "modem" if I sit in a pc on this intranet). From /var/named/skails.office.hosts :

modem                   A       192.168.231.117

nslookup resolves the modem address correctly from all pc's of the intranet.

root@stargaze:~# nslookup modem
Server:     127.0.0.1
Address:    127.0.0.1#53

Name:   modem.skails.office
Address: 192.168.231.117

root@stargaze:~# nslookup modem.skails.office
Server:     127.0.0.1
Address:    127.0.0.1#53

Name:   modem.skails.office
Address: 192.168.231.117

So when I try to access the modem from the gateway's browser (firefox), I type http://192.168.231.117/. I provide the credentials and I log on fine.

If I try to do the same by issuing the address http://modem/ or http://modem.skails.office/, I will still be presented with the logon window, but it will NOT accept my credentials. I really do not know what could be the problem here.

I used tcpdump -i eth1 host modem and port 80 to log a successful and and unsuccessful attempt to log on and grab the status page.

  1. successful tcpdump wget --user admin --password 1234 "http://192.168.231.117/status/status_deviceinfo.htm" -O -

Connecting to 192.168.231.117:80... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Reusing existing connection to 192.168.231.117:80.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
...

  1. unsucessful tcpdump wget --user admin --password 1234 "http://modem/status/status_deviceinfo.htm" -O -

Resolving modem (modem)... 192.168.231.117
Connecting to modem (modem)|192.168.231.117|:80... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Reusing existing connection to modem:80.
HTTP request sent, awaiting response... 401 Unauthorized
Authorization failed.

Can you make anything out of it? Do you need any other data that I have perhaps not thought to include? How can I investigate this matter further?

Andrew Schulman
  • 8,561
  • 21
  • 31
  • 47
nass
  • 548
  • 4
  • 10
  • 24
  • Can you provide the nslookup results from the gateway to see what it is returning on the modem lookup? Also what it sees for the full modem.skails.office lookup? Just wondering if it may be an A or CNAME record issue. – BeepBeep Feb 27 '15 at 16:09
  • @BeepBeep Hi there, I have included simple `nslookup` invocation in the question. If you need some more advanced invocation, please let me know. – nass Feb 27 '15 at 16:58
  • It's not clear, at least to me, what your specific question is. I have all kinds of answers I could give you, but I have no idea which one is the one you're looking for. (If it's "what should I do next", the obvious next step is to confirm that it's the `Host` header that's the relevant difference.) – David Schwartz Feb 27 '15 at 17:11
  • @DavidSchwartz yes, this is the sort of answer I seek. A guide as to how to investigate this matter further. It is not obvious to me and It is not obvious how to to use this info you provided. when you say `host` do you refer to the linux gateway? Should I use `curl` for this job? – nass Feb 27 '15 at 17:59

1 Answers1

1

The modem's web server isn't designed to handle something other than its IP in the Host HTTP header, thus you obtain undefined behavior and in this case it means the authentication fails when you send something other than its IP in that Host header.

Normally unless you're using virtual hosts (which allows hosting multiple sites under multiple domains pointing to the same IP, and using that Host header to tell which site was requested) you're just supposed to ignore that header altogether, which the developers of that firmware obviously didn't do. I wouldn't be surprised if they were actually using a virtual host (unnecessarily) and that's why only a specific Host header set to the router's IP allows you to authenticate, because everything else doesn't match that virtual host.

The name doesn't have anything to do with it, it's just that curl/wget automatically set the correct Host header based on that DNS name. If you can remove or override that header and set it back to the modem's IP then it'll work just fine (use wget --header="Host:" ... to remove the header).

  • could you tell me how can I intercept the `host` http header in order to learn something out of this? Also, this is not a problem in all modems... – nass Feb 27 '15 at 18:32
  • @nass You can use `curl -v` rather than wget, the "-v" argument means verbose and will display everything that goes over the wire, including the header. –  Feb 27 '15 at 18:44
  • hmm thank you, I did see it. It's weird If you asked me I'd swear I've seen it working! still I can't argue on it. I mean I've been using it for years at this point, and it strikes me as odd that I had not come across this earlier...! – nass Feb 27 '15 at 18:53
  • @nass maybe it used to work on an older version of wget which handled Host headers differently and somehow wasn't adding it for some unknown reason. –  Feb 27 '15 at 18:54
  • huge thanks BTW. This is one of those things that one could go on being oblivious about for a lifetime :D – nass Feb 27 '15 at 18:54
  • I wonder if I could point a `dns` entry on modem's settings, to my linux gateway dns server, could the modem itself resolve the host "modem" to itself? – nass Feb 27 '15 at 18:56
  • @nass the modem doesn't do any resolving and the problem isn't DNS related, it's just that the modem's web server exhibits undefined behavior when the `Host` header is set to something else than its IP. –  Feb 27 '15 at 18:59
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/21506/discussion-between-nass-and-andre-daniel). – nass Feb 27 '15 at 19:13