Webif Setting of LAN/WiFi Configuration

[af123]

I will see what the developer says. I suspect it is just regexp that is affected since that backs off to the standard system regexp routine (although it is possible to build Jim with a builtin regexp). In the meantime I'll replace $bytes with [string map {\x00 .} $bytes]

 

[raydon]

Hexdump now working properly with that patch
WPA2-PSK(AES)

Running: wifi
Protocol:802.11b/g
Mode:Managed
Channel:6
Quality:83/100 Signal level:-57 dBm Noise level:-83 dBm
Encryption key:on
Bit Rates:54 Mb/s
0000: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 ssssssssssssssss
0010: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 ssssssssssssssss
0020: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 ssssssssssssssss
0030: 01 00 6d 6d 6d 6d 6d 6d 00 00 00 00 00 00 00 00 ..mmmmmm........
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060: 00 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 ................
0070: 04 00 00 00 01 00 00 00 70 70 70 70 70 70 70 70 ........pppppppp
0080: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 pppppppppppppppp
0090: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 pppppppppppppppp
00A0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 pppppppppppppppp
00B0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 pppppppppppppppp
00C0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 pppppppppppppppp
00D0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 pppppppppppppppp
00E0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 pppppppppppppppp
00F0: 00 00 00 00 00 00 00 00 59 00 00 00 ........Y...

 

[af123]

A quick peruse of jimsh documentation and the only vague reference it makes to null characters is "Note that Jim supports null characters in strings".
A quick peruse of the source code finds lots of references to strlen() and strdup().
Oh dear. No wonder this doesn't work. <sigh>

I think you're jumping to an unreasonable conclusion. Just because the source code makes use of those functions doesn't mean that its support for null characters in strings is broken. I've never had a problem handling data using the built-in jim commands, just this regexp/regsub one where it is calling the regexp routines in the OS/OE libraries. Unfortunately the regexp routines expect a null terminated string. The documentation probably just needs updating - I can't see any way to improve it (and I suspect that big TCL will behave in the same way too).

 

[af123]

We seem to have hijacked this thread somewhat, however...

The latest version of the webif package, 1.2.0-2, has the new network settings panel in it.
At the moment it's hidden by default but you can enable it by running the 'enable_network_settings' diagnostic.

This is working for me for WPA/WPA2 connections - entering the information, saving and then restarting the Humax (without the Ethernet cable attached) results in it automatically joining the network. If for some reason it doesn't join, you can go to the Wifi setup via the on-TV menus and just click on the Apply button to force it to connect or see what the problem is. You might have to select the authentication mode too if it doesn't come up but that should only happen for WEP networks which I doubt many people are using.

If you want to bring up the wireless network with the Ethernet cable attached, then you can run the /sbin/wifi-up utility from the CLI. You should retain your connection and then be able to access the Humax on either network.
(There is a similar utility called /mod/sbin/wifi-up if you have wireless helper installed. That one shuts down the Ethernet interface when bringing the wireless up)

 

[af123]

Screenshot for new functionality:

(available networks are displayed when 'Scan' is clicked)

(Splitting the thread sounds good to me.)

 

[af123]

I will see what the developer says. I suspect it is just regexp that is affected since that backs off to the standard system regexp routine (although it is possible to build Jim with a builtin regexp). In the meantime I'll replace $bytes with [string map {\x00 .} $bytes]

The developer said:

...it's expected...because Jim Tcl uses regcomp/regexec and these APIs take null
terminated strings. (Even when using the built-in regexp, these APIs are
used for compatiblity.)

It would be possible to change the built-in regexp to use lengths instead.

Not a problem now I know - have suggested a documentation update at least.

 

[Ezra Pound]

Wi-Ki notes for Network Setting HERE

 

[af123]

Wi-Ki notes for Network Setting HERE

The diagnostic is just for now so that only people willing to test it can see it. Probably not appropriate to put that in the wiki or at least make it clear that the diagnostic enables a new feature which is still being tested. Once it's proven, the next update will enable it for everyone.

 

[Ezra Pound]

I guessed it was temporary, but I think the note still makes sense. I will remove that line when things settle
EDIT
#77 was initially only displaying the first 6 words for me, I will remove the line completely for the next release. I have also removed the Web-If >> Diagnostic note for enabling this feature

 

[Black Hole]

Bingo! I now have HDR3 connected via WiFi on WPA2-PSK(AES) with a 63-character random string key (copy&pasted from my Windows network credentials).

One slight hitch: although I set the IP settings to manual and copied the IP addresses across from the LAN settings, after reboot (with LAN disconnected) I had to go into the WiFi settings and "apply" before they became active, and when they did they were on DHCP (with an IP address assigned by the router). I manually changed the IP address to what it should be and changed DHCP to manual. Not a biggie, and maybe it takes two stages to get all the parameters from the WebIF settings to bed themselves in.

I realise this was not a huge job given the framework was already in place, but from my point of view it is a major enhancement to the HD/HDR-FOX to be able to use an arbitrary WiFi key - something which stopped me from trying it before.

Running: wifi
Protocol:802.11b/g
Mode:Managed
Channel:1
Quality:99/100  Signal level:-51 dBm  Noise level:-83 dBm
Encryption key:on
Bit Rates:54 Mb/s
0000: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73  ssssssssssssssss
0010: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73  ssssssssssssssss
0020: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73  ssssssssssssssss
0030: 00 00 6d 6d 6d 6d 6d 6d 00 00 00 00 00 00 00 00  ..mmmmmm........
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0060: 00 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00  ................
0070: 04 00 00 00 00 00 00 00 70 70 70 70 70 70 70 70  ........pppppppp
0080: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
0090: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00A0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00B0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00C0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00D0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00E0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00F0: 00 00 00 00 00 00 00 00 00 00 00 00              ............

 

[Black Hole]

This is a bit annoying - every time I reboot, I have to reapply the WiFi settings and it goes back to DHCP. I'll add wireless-helper in to the mix...

Update: that sorted it. Now the WiFi connection comes up straight away after reboot, and with the manual IP setting.

 

[Black Hole]

For information: even with wireless-helper installed, I do not get a Telnet connection in Maintenance Mode.

 

[af123]

This is a bit annoying - every time I reboot, I have to reapply the WiFi settings and it goes back to DHCP. I'll add wireless-helper in to the mix...

Update: that sorted it. Now the WiFi connection comes up straight away after reboot, and with the manual IP setting.

Great - not sure why you are having to do that but I do know that every time you have to apply the wireless settings is causes the IP configuration to go back to DHCP. However, wireless-helper is required for the wireless connection to come up in half-awake mode so almost an essential package for wireless CFW users.

For information: even with wireless-helper installed, I do not get a Telnet connection in Maintenance Mode.

I understand more, although not yet everything, about the wireless configuration so might be able to troubleshoot this further with you. I always get a wireless connection in maintenance mode which doesn't help!

 

[Black Hole]

I could circumvent the DHCP problem by assigning the desired IP address in the router, but I don't need to with wireless-helper solving it at the HDR end (and in any case - it would be a right pain to have to force the connection every boot!). The maintenance mode issue is more of a problem - with the likes of prpr insisting it works and with another pool of users insisting it doesn't. We need to figure out what the common factors are which divide the two experiences.

Could it be that (for whatever reason) in my case the WiFi link does not automatically establish itself without me either applying the network settings or a prompt from wireless-helper? Is this common to other "no maintenance" users, and users who find maintenance mode works on WiFi also have no trouble connecting at boot?

If it is of any relevance, my dongle is marked "Edimax EW-7711UAn" (in lettering so tiny the only way I could read it was by taking a close-up photo!).

 

[af123]

Could it be that (for whatever reason) in my case the WiFi link does not automatically establish itself without me either applying the network settings or a prompt from wireless-helper? Is this common to other "no maintenance" users, and users who find maintenance mode works on WiFi also have no trouble connecting at boot?

Possibly - what does the output of the swifi command look like? (Without the sensitive bits of course).

 

[Black Hole]

HDRFOX3# swifi
ssid=***
key=***
manual=1
auth=8
ip=192.168.1.13
mask=255.255.255.0
gw=192.168.1.254
dns=192.168.1.254
HDRFOX3#

 

[Black Hole]

I have done a little reading up on WiFi security, and it appears that my 63-character random string is over-the-top from a usability point of view (although having set it up like that, I do not intend to change it any time soon).

A 256-bit encryption key is derived from the string (however long it is, 63 characters max) by convolving the string through a secure hashing process which uses the SSID string as a seed. Thus the string could be as short as you like, and the key would still be a 256-bit value unique to the string and the SSID.

However, hackers know the algorithm for deriving the key value, and have look-up tables of the SSIDs and passwords which correspond with particular keys - for common SSIDs and passwords. The SSID is recoverable from eaves-dropped WiFi traffic, so that just leaves the password. Hence your WiFi security depends on (a) not having a common SSID that appears on the lookup tables, and (b) not having a password that is common enough to appear on lookup tables - no matter how long (or short) the password string is. Thus with a personalised SSID and a memorable non-dictionary password string (eg "bLack%holE327") one should be as secure as my impossible-to-type-without-error randomly generated 63-character ASCII string.

All this depends on the WiFi network configuration being set to WPA2 (not WPA or WEP), and any WPS facility available on your router being switched off (which introduces an extra vulnerability through the 8 digit PIN).

Is it worthwhile hiding the SSID? Sometimes a hidden SSID makes inconveniences for the legitimate user, and a hidden SSID is no barrier to a determined hacker, but hiding it does make your network less attractive to a drive-by scrounger. I suggest hiding it unless it is inconvenient to hide it.

 

[raydon]

Couple of more pieces for the jigsaw. Couldn't coax my HDR Fox T2 to connect to my router in any other WEP modes.
Please note. Webif will not allow an empty passphrase with Authentication Type set to "None" I think passphrase entry should be disabled and field set to nulls with this setting.
Can confirm passphrase is set to nulls in the settings database with the "None" setting.
WEP 64-bit Hex passphrase contains a 10 character hex string.

WEP 64-bit Hex
1-0-1

Running: wifi
Protocol:802.11b/g
Mode:Managed
Channel:6
Quality:73/100  Signal level:-61 dBm  Noise level:-83 dBm
Encryption key:on
Bit Rates:54 Mb/s
0000: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73  ssssssssssssssss
0010: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73  ssssssssssssssss
0020: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73  ssssssssssssssss
0030: 00 00 6d 6d 6d 6d 6d 6d 00 00 00 00 00 00 00 00  ..mmmmmm........
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0060: 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
0070: 01 00 00 00 01 00 00 00 70 70 70 70 70 70 70 70  ........pppppppp
0080: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
0090: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00A0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00B0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00C0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00D0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00E0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00F0: 00 00 00 00 00 00 00 00 00 00 00 00  ............

None
0-0-0

Running: wifi
Protocol:802.11b/g
Mode:Managed
Channel:6
Quality:57/100  Signal level:-67 dBm  Noise level:-83 dBm
Encryption key:off
Bit Rates:54 Mb/s
0000: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73  ssssssssssssssss
0010: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73  ssssssssssssssss
0020: 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73 73  ssssssssssssssss
0030: 01 00 6d 6d 6d 6d 6d 6d 00 00 00 00 00 00 00 00  ..mmmmmm........
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0060: 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00  ................
0070: 00 00 00 00 00 00 00 00 70 70 70 70 70 70 70 70  ........pppppppp
0080: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
0090: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00A0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00B0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00C0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00D0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00E0: 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70 70  pppppppppppppppp
00F0: 00 00 00 00 00 00 00 00 44 00 00 00  ........D...

 

[prpr]

Possibly - what does the output of the swifi command look like? (Without the sensitive bits of course).

humax2 ~ # swifi
ssid=***
key=***
manual=0
auth=8
ip=192.0.2.100
mask=255.255.255.0
gw=
dns=

Intriguing that... as ip, gw, dns are obviously set to something else in real operation.

 

[prpr]

I think you're jumping to an unreasonable conclusion.

Possibly, yes. The quick look I took starting at regsub and working down just seemed to have that as some part of string operations. I haven't actually run it through a debugger to see where it really goes and where it goes wrong.

Just because the source code makes use of those functions doesn't mean that its support for null characters in strings is broken.

Agreed. Just being a bit over-zealous.

The documentation probably just needs updating

It does for that.
In general it's too terse about important things, and there aren't (m)any examples. It would be nice if it referred to version 0.75 at least.