Beta [iplhack] BBC iPlayer resurrection

[Black Hole]

I'll bypass the homeplugs (temporarily) and see if that helps.

 

[Black Hole]

Having run a cable to the router: I confirm iplhack works* on HD-FOX, and that it relies on Menu >> Settings >> System >> Internet Setting >> Configure LAN >> Configure IP = DHCP.

* By "works", I mean TV Portal >> iPlayer can browse for BBC catch-up content and play the content, whereas without iplhack (or without DHCP) the content can be browsed but will not play (iPlayer responds with a "Something has gone wrong" message).

 

[/df]

TBH I've only used it on HDs because the room with the HDR is otherwise engaged.

My spies tell me that the BBC treats HD and HDR as the same iPlayer device type.

 

[/df]

...* By "works", I mean TV Portal >> iPlayer can browse for BBC catch-up content and play the content, whereas without iplhack (or without DHCP) the content can be browsed but will not play (iPlayer responds with a "Something has gone wrong" message).

If anyone sees an iPlayer message like this, it may be useful to record the number that's also shown (say 20001) in a tiny font, as someone with too much free time may be able to find this code in the iPlayer JS and hence determine what was failing. Certainly use the number in a complaint about vanilla iPlayer to the BBC.

 

[prpr]

The key thing is that it's using dnsmasq in the second and third cases as shown by "Server: 127.0.0.1".

So, dnsmasq not get used at all when the IP is statically configured, which means iplhack will never work. This is a bit crap, is it not? But oh so Humax.
It looks like /etc/resolv.conf can be edited after it's been blitzed at startup by humaxtv, but will it then use it? It does using nslookup anyway.

 

[Black Hole]

If resolv.conf can be written to post-boot, isn't that easier than invoking another instance of dnsmasq?

 

[/df]

So, dnsmasq not get used at all when the IP is statically configured, which means iplhack will never work. ...

With my wifi startup script, 127.0.0.1 and the other servers added by the DHCP script are present even though the on-screen LAN info says "Manual". I thought, wrongly (see below), that in BH's example is the first I saw where DHCP had never been used: my initial hypothesis was that once DHCP had set up these servers they would stay until something cleared them (such as the RW flash being re-formatted in a factory, or uncommanded, reset), but more testing neededno.

Clearly it would be possible to add 127.0.0.1 to resolv.conf at xinit time.

It looks like /etc/resolv.conf can be edited after it's been blitzed at startup by humaxtv, but will it then use it? It does using nslookup anyway.

See below and update here.

If resolv.conf can be written to post-boot, isn't that easier than invoking another instance of dnsmasq?

What's needed for iplhack is to change configuration that's in /etc/dnsmasq.conf, which is a read-only file, whereas /etc/resolv.conf is a symlink to a /var/lib/humaxtv/resolv.conf file in RW flash. Stopping the default instance of dnsmasq and replacing it with custom instance seems like the easiest solution, especially as it appeared necessary to restart the reconfigured dnsmasq regularly in case the IP address resolved for open.live.bbc.co.uk should be rotated out of service.

The recommended configuration for dnsmasq is here:

...A machine which already has a DNS configuration (ie one or more external nameservers in /etc/resolv.conf and any local hosts in /etc/hosts) can be turned into a nameserver simply by running dnsmasq, with no options or configuration at all. ...

In the simple configuration described above, processes local to the machine will not use dnsmasq, since they get their information about which nameservers to use from /etc/resolv.conf, which is set to the upstream nameservers. To fix this, simply replace the nameserver in /etc/resolv.conf with the local address 127.0.0.1 and give the address(es) of the upstream nameserver(s) to dnsmasq directly. You can do this using either the server option, or by putting them into another file, and telling dnsmasq about its location with the resolv-file option.

Whereas the Humax setup fails to do the first part (sentence 2) of para #2 if DHCP is not used and always fails to do the second part (sentence 3).

 

[Black Hole]

BH's example is the first I saw where DHCP had never been used

That's not the case - I populate using DHCP, then switch to manual and configure just the IP address. Each time a manual configuration is applied, 127.0.0.1 disappears.

 

[/df]

That's not the case - I populate using DHCP, then switch to manual and configure just the IP address. Each time a manual configuration is applied, 127.0.0.1 disappears.

So scratch that hypothesis! There must be some other difference that's causing Manual to appear in my LAN info displays even though the setup data seems to say DHCP and the behaviour otherwise indicates DHCP (eg, there is a udhcpc process for wlan0).

I have a development version of iplhack that transforms a vanilla installation into the recommended configuration as quoted from Simon Kelley's site, including setting 127.0.0.1 as the DNS server. The side-effect is that the LAN info display shows 0.0.0.0 as the DNS server, regardless of the original setting, as below:

...
The DNS Address value shown on the "Configure LAN" page is (apparently) the address from the first nameserver entry in /etc/resolv.conf that is not 127.0.0.1.
...

Although this development version would obviously work better than one with no 127.0.0.1 DNS address, it doesn't otherwise seem to be any more reliable than the released version. I'm wondering if the apparently random iPlayer app behaviour depends on which CDN is selected to deliver the content (Akamai vs AWS IIRC).

 

[/df]

With apologies to testers who may wish to uninstall this package in favour of the one true fix, there is a typo in the script that runs before removing the package.

In post #1 there's an updated version that should uninstall fully, which should appear in the Beta repository in due course.

Otherwise, iIf you haven't tried to uninstall iplhack yet, please edit the file /mod/var/opkg/info/iplhack.prerm and remove the errant i in the one significant command, which should now read:

/mod/etc/init.d/[SZ]99iplhack stop 2>&1 >/dev/null
#instead of
#/mod/etc/init.d/i[SZ]99iplhack stop 2>&1 >/dev/null

The uninstall process will now work as intended.

If that file doesn't exist, the package has probably already been uninstalled. Instead, use this command at a command prompt to clean up the detritus:

if crontab -l | grep -q /iplhack; then crontab -l | grep -v /iplhack | crontab -; fi

After either of these, a restart may also be a good idea.

 

[prpr]

With apologies to testers who may wish to uninstall this package in favour of the one true fix, there is a typo in the script that runs before removing the package.

You probably ought to push out an update to fix this. Then anyone who has auto-update installed will be able to uninstall it cleanly subsequently without any bother.

 

[/df]

You probably ought to push out an update to fix this. Then anyone who has auto-update installed will be able to uninstall it cleanly subsequently without any bother.

See updates above, if any Beta users have auto-update as well (?).

 

[Black Hole]

TBH I've only used it on HDs because the room with the HDR is otherwise engaged.

Cool. A loo with entertainment!

 

[Black Hole]

if crontab -l | grep -q /iplhack; then crontab -l | grep -v /iplhack | crontab -; fi

What are the consequences if a user doesn't do this? What are the consequences if a user does this without needing to? Is there an easy test to tell if it needs doing? Would installing and then uninstalling the updated version of iplhack have the desired effect?

 

[prpr]

What are the consequences if a user doesn't do this?

Cron tries to run something that doesn't exist every 10 minutes.

What are the consequences if a user does this without needing to?

None.

Is there an easy test to tell if it needs doing?

You could look at the /mod/var/spool/cron/crontabs/root file, to see if there is a line containing "iplhack", but it's easier just to run the command.

Would installing and then uninstalling the updated version of iplhack have the desired effect?

Yes.

 

[Black Hole]

Okay...

v0.9.1:

>>> opkg remove iplhack
/mod/var/opkg/info/iplhack.prerm: line 3: /mod/etc/init.d/i[SZ]99iplhack: not found
Removing package iplhack from root...

Done.

It seems to me the errant "i" is still there!

 

[prpr]

You need 0.9.2 attached to post 1. I guess there's some reason /df can't upload it to the repository.

 

[Black Hole]

Doh!

 

[Black Hole]

You could look at the /mod/var/spool/cron/crontabs/root file, to see if there is a line containing "iplhack", but it's easier just to run the command.

grep iplhack /mod/var/spool/cron/crontabs/root

Using that, I was quickly able to confirm I only ever had iplhack installed on one machine.

if crontab -l | grep -q /iplhack; then crontab -l | grep -v /iplhack | crontab -; fi

and then

grep iplhack /mod/var/spool/cron/crontabs/root

confirmed it gone.

 

[/df]

grep iplhack /mod/var/spool/cron/crontabs/root

Using that, I was quickly able to confirm I only ever had iplhack installed on one machine.
...

Thus confirming the previous suggestion that it would have been easier to run the command that I posted...

You need 0.9.2 attached to post 1. I guess there's some reason /df can't upload it to the repository.

He had no idea that he might be able to. Like the manager's Hello World program

From: A Manager
To: A Programmer
Subject: Hello World program

Hi Al

Would you be able to write me a Hello World program?

I need it by COB tomorrow.

Thanks
Art

--
Arthur Manager
Program Manager
Cyber Corp