Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[siofjofj]

As other users on the forum have had unresolved issues with using the VMG8x24-B10A as a combined modem and router with Sky VDSL (FTTC) (see https://forum.kitz.co.uk/index.php/topic,18011.0.html and https://forum.kitz.co.uk/index.php/topic,22821.0.html), and that I too may face these issues if I get VDSL, I thought I would do some investigation.

As is now well known, Sky/NowTV VDSL connections do not use PPPoE, they use IPoE. The IP address is provided by DHCP, however this only works if the 'Option 61' parameter in the DHCP discover packets sent by the CPE contains an appropriate string. Originally this string had to be sniffed from the ISP supplied CPE, but it is now possible to use a generic string such as 'abcdef123456@skydsl|abcd1234'. The required format seems to be [12 digit hex]@skydsl|[8 digit alpha-numeric] or [12 digit hex]@nowtv|[8 digit alpha-numeric].

Inserting the generic string 'abcdef123456@skydsl|abcd1234' into a router known to work with Sky VDSL and sniffing the DHCP discover packets with Wireshark results in the option 61 parameter:

Code: [Select]

Hex: 3d 1c 61 62 63 64 65 66 31 32 33 34 35 36 40 73 6b 79 64 73 6c 7c 61 62 63 64 31 32 33 34
ASCII: =[FS]abcdef123456@skydsl|abcd1234
1st byte (Code): 0x3d = 61, as expected for Option 61
2nd byte (Len) : 0x1c = 28, as expected for a 28 character string
3rd byte (i1)  : 0x61 = 'a' the first character of the input string
This is in an RFC2132-like format:

Code: [Select]

Code  Len Client-Identifier
+----+----+----+----+----+---
| 61 | n  | i1 | i2 | i3 | ..
+----+----+----+----+----+---


The Zyxel VMG8x24-B10A however, in its GUI, accepts:
DHCP option 61 IAID : ( 8 digit Hex )
DHCP option 61 DUID : ( digit Hex )

The first attempt was to convert the generic string to hex, then divide this into the first 8 digits and then the rest. The GUI form was thus filled with

Code: [Select]

IAID: 61626364
DUID: 656631323334353640736b7964736c7c6162636431323334
and the result captured using Wireshark. It was

Code: [Select]

Hex: 3d 1f ff 61 62 63 64 00 02 65 66 31 32 33 34 35 36 40 73 6b 79 64 73 6c 7c 61 62 63 64 31 32 33 34
ASCII: =[US]ÿabcd[NUL][STX]ef123456@skydsl|abcd1234
1st byte (Code): 0x3d = 61, as expected for Option 61
2nd byte (Len) : 0x1f = 31, 3 higher than expected for a 28 character string
3rd byte (Type): 0xff = 255, not a valid ASCII character. I have represented it as 'ÿ' from Windows-1252 encoding since this is what Wireshark does.
This is in a RFC4361-like format:

Code: [Select]

Code  Len  Type IAID                 Type      DUID
+----+----+-----+----+----+----+----+----+----+----+----+---
| 61 | n  | 255 | i1 | i2 | i3 | i4 | 00 | 02 | d1 | d2 | ..
+----+----+-----+----+----+----+----+----+----+----+----+---
This format has introduced the three additional bytes ÿ (0xff = 255), [NUL] (0x00 = 0) and [STX] (0x02 = 2), leading to a string which is too long. The length could be fixed by eliminating '456' before '@skydsl' in the input string. However, this is unlikely to work since @skydsl will no longer be preceeded by 12 hex digits.

I then decided to look at the source code of the udhcp client used in the VMG8924-B10A, specifically /userspace/gpl/apps/udhcp/options.c, and came up with the attached patch. This patch modifies the code used to contruct the option 61 string such that it no longer inserts the three type bytes or the IAID. Compiling and flashing a firmware with this patch applied, then filling in the GUI with:

Code: [Select]

IAID: 00000000 (the GUI insists on 8 digits of hex here)
DUID: 61626364656631323334353640736b7964736c7c6162636431323334 (abcdef123456@skydsl|abcd1234 as hex)
gives the following result (from Wireshark)

Code: [Select]

Hex: 3d 1c 61 62 63 64 65 66 31 32 33 34 35 36 40 73 6b 79 64 73 6c 7c 61 62 63 64 31 32 33 34
ASCII: =[FS]abcdef123456@skydsl|abcd1234
1st byte: 0x3d = 61, as expected for Option 61
2nd byte: 0x1c = 28, as expected for a 28 character string
3rd byte: 0x61 = 'a' the first character of the input string
Since this is identical to the output of a router that works on Sky VDSL out of the box, I strongly suspect this will work. I have created the patch in such a way that it can be used with johnson's custom build system https://github.com/johnson442/custom-zyxel-firmware, and have made two builds with it. Both are based on the Zyxel v28 firmware and have johnson's modifications for jumbo frames, multiple telnet sessions, stats server and boot commands. One uses the default 'v' DSL firmware (https://www.dropbox.com/s/3g39b9stnhp4acx/8x24-B10A-28-jumbo-opt61-tel-stats-cmd.bin?dl=0) and the other uses the newer 'x6' DSL firmware for those with vectoring (https://www.dropbox.com/s/51dxs5zgnb9qw54/8x24-B10A-28-jumbo-opt61-tel-x6-stats-cmd.bin?dl=0). I have tested both to boot and for the correct operation of the patch.

Hopefully this will be useful for someone.

[burakkucat]

Very interesting. Thank you for sharing the information.

Two questions: In your opinion, is there a defect in the vanilla ZyXEL firmware image for DHCP Option 61? If yes, would you consider reporting it to ZyXEL?

[siofjofj]

Two questions: In your opinion, is there a defect in the vanilla ZyXEL firmware image for DHCP Option 61? If yes, would you consider reporting it to ZyXEL?

I would not say that this is a defect, as the IAID and DUID format of Option 61 entry is valid as per RFC4361, and in this case the first 'Type' field should be hard coded to 255 since this indicates the IAID and DUID format. I would describe the situation as an unimplemented feature, that feature being the entry of an RFC2132 Option 61 parameter. I am however slightly puzzled by the second two-byte type field (hard coded to 0x00 0x02) as I cannot find any references as to why it should take this value (indeed RFC4361 does not even mention this type field, but Wireshark does identify it as such). This is pretty much my first time trying to apply the contents of RFCs, so I'm not sure I'd want to tell Zyxel they've done it wrong if I'm not sure what exactly the correct operation should be myself!

From looking at the 5.50 revision of the manual for the VMG3925-B10B (which applies to a device which has Zyxel's revised GUI), it looks like their newer GUI might have a choice between entering an RFC4361 style identifier as two hex strings, or an RFC2132 style one as a single ASCII string. I don't have this device so can't check. The revised GUI on the VMG1312-B10D may be similar if anyone is able to check.

[burakkucat]

Understood.

[siofjofj]

I guess what I'm trying to say is that my alteration is more of a bodgey-hack rather than an actual bug-fix! Glad you found it interesting!

[siofjofj]

Just an update to this. Now that I have a NowTV VDSL connection, I can confirm that this patch actually works in practise as I am now using it. Also, since my new connection has vectoring and it was established in this thread that the A2pv6F039v2 DSL firmware may be a better choice in this situation I have made a new firmware variant with the option 61 patch and the A2pv6F039v2 DSL firmware (together with all of johnson's other patches) which is available here.