Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: johnson on March 23, 2018, 05:01:51 PM
-
The often suggested ZyXEL modems on this forum have great performance, but to my knowledge none support RFC 4638 with MTUs over 1492 for PPPoE connections in bridge mode. As far as I understand, all BT based FTTC connections should support it, but working examples to google are thin on the ground.
Other modems I am aware of with BCM63168 chipset:
Billion 8800nl
Netgear D6400
BT HH5B?
Does anyone have experience with one that can support over 1492 MTU when used as a modem in bridge mode?
[Moderator edited as per thread creator's request.]
-
I'm on the lookout as well :)
I can't get it working on my Zyxel 8324. I'm currently playing around with a TG589vac v2. But for some reason I can't even get the PPP client on the EdgeRouter to establish a session :mad:
Will report back when I know more.
-
TG589vac v2 is a no go. Managed to get it working as a bridged modem, but it doesn't support RFC4638 (firmware 17.2).
-
Well I finally got around to playing with MTU settings with the VMG1312 and I feel like I must be missing something but it seems to be working.
After setting a 1508 mtu on the wan interface of a router running openwrt (x86 box with seperate lan cards for wan & lan) it negotiated a ppp session with 1500 byte payload:
daemon.notice pppd[1630]: pppd 2.4.7 started by root, uid 0
daemon.debug pppd[1630]: Send PPPOE Discovery V1T1 PADI session 0x0 length 10
daemon.debug pppd[1630]: dst ff:ff:ff:ff:ff:ff src 00:00:00:00:00:00
daemon.debug pppd[1630]: [service-name] [PPP-max-payload 05 dc]
daemon.debug pppd[1630]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 48
daemon.debug pppd[1630]: dst 00:00:00:00:00:00 src 00:00:00:00:00:00
daemon.debug pppd[1630]: [AC-name some.thing-here] [PPP-max-payload 05 dc] [service-name] [AC-cookie 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
daemon.debug pppd[1630]: Send PPPOE Discovery V1T1 PADR session 0x0 length 30
daemon.debug pppd[1630]: dst 00:00:00:00:00:00 src 00:00:00:00:00:00
daemon.debug pppd[1630]: [service-name] [PPP-max-payload 05 dc] [AC-cookie 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
daemon.debug pppd[1630]: Recv PPPOE Discovery V1T1 PADS session 0x3e9 length 48
daemon.debug pppd[1630]: dst 00:00:00:00:00:00 src 00:00:00:00:00:00
daemon.debug pppd[1630]: [service-name] [PPP-max-payload 05 dc] [AC-name some.thing-here] [AC-cookie 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
daemon.debug pppd[1630]: PADS: Service-Name: ''
daemon.info pppd[1630]: PPP session is 1001
daemon.warn pppd[1630]: Connected to 00:00:00:00:00:00 via interface eth2
0x05dc = 1500 for the "PPP-max-payload"
ifconfig on the router then shows a 1500 mtu for the pppoe-WAN interface where it showed 1492 before
Pings get fragmented if over 1464 still, but if you telnet into the VMG1312 and change first the ptm0 and them ptm0.1 interface to 1508 using:
ifconfig ptm0 mtu 1508
ifconfig ptm0.1 mtu 1508
Then pings with payload of 1472 magically start working:
ping -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=18.6 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=19.0 ms
1480 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=19.5 ms
1480 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=18.2 ms
1480 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=18.8 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 18.222/18.863/19.567/0.470 ms
Seeing as nothing breaks after setting the WAN port of the openwrt router to 1508, having to run 2 cmds on the modem after a reboot to get it working doesnt seem an issue.
Why I'm sceptical as to whether this result is accurate is that using the tester at http://www.letmecheck.it/ I still get a discovered MTU of 1492. Any idea why I can send unfragmented ICMP packets at 1500 but this test fails? I'l add that when I tried the tester there before with a definite 1492 pppoe connection from the router to modem it comes back with 1500 discovered... *scratches head*
Also tried the exact same steps on a billion 8800nl, same result.
Am I missing something? Is the test for fragmentation I'm using wrong? Have also tried:
ping -f -l 1472 8.8.8.8
From a windows 7 VM and got no DF set fragmentation message.
-
Asus RT-AC68U running AsusWRT-Merlin with a Zyxel VMG1312-B10A in bridge mode.
Following the advice above....
Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 8.8.8.8: bytes=1472 time=19ms TTL=58
Letmecheckit isn't working from my laptop though, i get the error...
This IP is being shared among many domains.
To view the domain you are looking for, simply enter the domain name in the location bar of your web browser.
-
Thanks for trying it out j0hn.
Weird error you are getting from the site, working for me albeit still giving 1492 from the MTU check.
-
Pings get fragmented if over 1464 still, but if you telnet into the VMG1312 and change first the ptm0 and them ptm0.1 interface to 1508 using:
ifconfig ptm0 mtu 1508
ifconfig ptm0.1 mtu 1508
Then pings with payload of 1472 magically start working:
ping -M do -s 1472 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=59 time=18.6 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=59 time=19.0 ms
1480 bytes from 8.8.8.8: icmp_seq=3 ttl=59 time=19.5 ms
1480 bytes from 8.8.8.8: icmp_seq=4 ttl=59 time=18.2 ms
1480 bytes from 8.8.8.8: icmp_seq=5 ttl=59 time=18.8 ms
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 18.222/18.863/19.567/0.470 ms
Seeing as nothing breaks after setting the WAN port of the openwrt router to 1508, having to run 2 cmds on the modem after a reboot to get it working doesnt seem an issue.
Nice find! Didn't think of doing that on my 8324. Will give that a go.
I did try altering the WAN IP connection (downloaded config, changed and uploaded the altered config back to the device) but it didn't do anything.
<WANIPConnection instance="1">
<Enable>TRUE</Enable>
<ConnectionType>IP_Bridged</ConnectionType>
<Name>VDSL</Name>
<ExternalIPAddress>(null)</ExternalIPAddress>
<SubnetMask>(null)</SubnetMask>
<DefaultGateway>(null)</DefaultGateway>
<MaxMTUSize>1508</MaxMTUSize>
<MACAddress>90:EF:68:A0:FF:A0</MACAddress>
<X_5067F0_IfName>ptm0.1</X_5067F0_IfName>
<X_5067F0_ConnectionId>1</X_5067F0_ConnectionId>
<X_5067F0_VlanMux8021p>2</X_5067F0_VlanMux8021p>
<X_5067F0_VlanMuxID>101</X_5067F0_VlanMuxID>
<PortMappingNumberOfEntries>0</PortMappingNumberOfEntries>
<X_5067F0_Op43Enabled>TRUE</X_5067F0_Op43Enabled>
<X_5067F0_IPv6Enabled>TRUE</X_5067F0_IPv6Enabled>
<X_5067F0_IPv6WanMode>1</X_5067F0_IPv6WanMode>
</WANIPConnection>
Why I'm sceptical as to whether this result is accurate is that using the tester at http://www.letmecheck.it/ I still get a discovered MTU of 1492. Any idea why I can send unfragmented ICMP packets at 1500 but this test fails? I'l add that when I tried the tester there before with a definite 1492 pppoe connection from the router to modem it comes back with 1500 discovered... *scratches head*
That's odd. Do you have MSS clamping configured on the router? What does this tester show?
https://www.speedguide.net/analyzer.php
-
Speedguide results:
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2018.04.08 08:40
IP address: xx.xx.xx.xxx
Client OS/browser: Linux (Firefox 59.0)
TCP options string: 020405b40402080ae5636c2f0000000001030307
MSS: 1460
MTU: 1500
TCP Window: 29312 (not multiple of MSS)
RWIN Scaling: 7 bits (2^7=128)
Unscaled RWIN : 229
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 1172kbps (147KBytes/s)
BDP limit (500ms): 469kbps (59KBytes/s)
MTU Discovery: ON
TTL: 52
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)
Also:
MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1448, which is less than MSS because of Timestamps, or other TCP/IP options used.
for clarity.
The MSS of 1460 seems right, but is 1448 of usable data?
Do you have MSS clamping configured on the router?
I have whatever the default is on openwrt which seems from https://wiki.openwrt.org/doc/uci/firewall#defaults (https://wiki.openwrt.org/doc/uci/firewall#defaults) to be off with "mtu_fix" 0.
-
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2018.04.08 09:06
IP address: xx.xx.xx.xx
Client OS/browser: Windows 10 (Chrome 65.0.3325.181)
TCP options string: 020405b40103030801010402
MSS: 1460
MTU: 1500
TCP Window: 65536 (not multiple of MSS)
RWIN Scaling: 8 bits (2^8=256)
Unscaled RWIN : 256
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 2621kbps (328KBytes/s)
BDP limit (500ms): 1049kbps (131KBytes/s)
MTU Discovery: ON
TTL: 110
Timestamps: OFF
SACKs: ON
IP ToS: 01001000 (72)
Precedence: 010 (immediate)
Delay: 0 (normal delay)
Throughput: 1 (high throughput)
Reliability: 0 (normal reliability)
Cost: 0 (normal cost)
Check bit: 0 (correct)
DSCP (DiffServ): AF21 010010 (18) - Assured Forwarding class 2, low drop precedence (RFC 2597).
-
Changing the MTU to 1508 on the two ptm interfaces works for me too :thumbs:
The MSS of 1460 seems right, but is 1448 of usable data?
I don't get that though.
MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.
Full results:
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2018.04.08 09:11
IP address: xx.xx.xx.xx
Client OS/browser: Windows 10 (Chrome 65.0.3325.181)
TCP options string: 020405b40103030801010402
MSS: 1460
MTU: 1500
TCP Window: 65536 (not multiple of MSS)
RWIN Scaling: 8 bits (2^8=256)
Unscaled RWIN : 256
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 2621kbps (328KBytes/s)
BDP limit (500ms): 1049kbps (131KBytes/s)
MTU Discovery: ON
TTL: 116
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)
-
Thanks for trying it out j0hn.
Weird error you are getting from the site, working for me albeit still giving 1492 from the MTU check.
I was seeing the same error on the letmecheck.it site and found that this is seen when connecting via IPv6. When using IPv4 the page / site displays correctly.
Speedguide results:
MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1448, which is less than MSS because of Timestamps, or other TCP/IP options used.
for clarity.
The MSS of 1460 seems right, but is 1448 of usable data?
The 1448 byte Maximum Segment Size (MSS) you're using is due to the TCP Timestamp option that is enabled on your host. As per section 1.3 of RFC 7323 (https://tools.ietf.org/html/rfc7323) TCP Extensions for High Performance:
The Timestamps option may appear in any data or <ACK> segment, adding 10 bytes (up to 12 bytes including padding) to the 20-byte TCP header.
-
Changing the MTU to 1508 on the two ptm interfaces works for me too :thumbs:
Great stuff!
The 1448 byte Maximum Segment Size (MSS) you're using is due to the TCP Timestamp option that is enabled on your host. As per section 1.3 of RFC 7323 (https://tools.ietf.org/html/rfc7323) TCP Extensions for High Performance:
Thanks smf22, disabled it with "echo 0 > /proc/sys/net/ipv4/tcp_timestamps" and get:
MTU = 1500
MTU is fully optimized for broadband.
MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.
Are there any downsides to removing the timestamp?
-
Getting some slightly odd results.
I can ping 8.8.8.8 and bbc.co.uk using a packet size of 1472.
pi@raspi3a:~ $ ping -M do -s 1472 -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=57 time=13.2 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=57 time=13.2 ms
1480 bytes from 8.8.8.8: icmp_seq=3 ttl=57 time=13.1 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 13.159/13.231/13.294/0.109 ms
pi@raspi3a:~ $ ping -M do -s 1472 -c 3 bbc.co.uk
PING bbc.co.uk (151.101.0.81) 1472(1500) bytes of data.
1480 bytes from 151.101.0.81: icmp_seq=1 ttl=60 time=13.0 ms
1480 bytes from 151.101.0.81: icmp_seq=2 ttl=60 time=13.4 ms
1480 bytes from 151.101.0.81: icmp_seq=3 ttl=60 time=13.0 ms
--- bbc.co.uk ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 13.057/13.183/13.419/0.191 ms
But not these:
pi@raspi3a:~ $ ping -M do -s 1472 -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2093ms
pi@raspi3a:~ $ ping -M do -s 1472 -c 3 cloudflare.com
PING cloudflare.com (198.41.214.162) 1472(1500) bytes of data.
--- cloudflare.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2077ms
I can ping them fine from a VPS.
$ ping -M do -s 1472 -c 3 cloudflare.com
PING cloudflare.com (198.41.214.162) 1472(1500) bytes of data.
1480 bytes from 198.41.214.162: icmp_seq=1 ttl=52 time=4.26 ms
1480 bytes from 198.41.214.162: icmp_seq=2 ttl=52 time=4.22 ms
1480 bytes from 198.41.214.162: icmp_seq=3 ttl=52 time=4.33 ms
--- cloudflare.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 4.225/4.277/4.338/0.070 ms
$ ping -M do -s 1472 -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1480 bytes from 1.1.1.1: icmp_seq=1 ttl=52 time=3.99 ms
1480 bytes from 1.1.1.1: icmp_seq=2 ttl=52 time=3.91 ms
1480 bytes from 1.1.1.1: icmp_seq=3 ttl=52 time=3.98 ms
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 3.915/3.963/3.992/0.034 ms
:wall:
-
Yeah this fails for me too:
ping -M do -s 1472 cloudflare.com
Bummer.
Edit: What ISP are you with highpriest? I'm on TTB.
-
Yeah this fails for me too:
ping -M do -s 1472 cloudflare.com
Bummer.
Why though? Doesn't make sense.
Edit: What ISP are you with highpriest? I'm on TTB.
I'm with Zen.
-
j0hn could you try a 1472 byte ping to cloudflare?
-
^Cpi@raspberrypi:~ $ ping -4 -M do -s 1464 -c 4 cloudflare.com
PING cloudflare.com (198.41.214.162) 1464(1492) bytes of data.
1472 bytes from 198.41.214.162: icmp_seq=1 ttl=57 time=96.7 ms
1472 bytes from 198.41.214.162: icmp_seq=2 ttl=57 time=22.1 ms
1472 bytes from 198.41.214.162: icmp_seq=3 ttl=57 time=22.4 ms
1472 bytes from 198.41.214.162: icmp_seq=4 ttl=57 time=22.3 ms
--- cloudflare.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 22.133/40.926/96.772/32.243 ms
pi@raspberrypi:~ $ ping -4 -M do -s 1472 -c 4 cloudflare.com
PING cloudflare.com (198.41.214.162) 1472(1500) bytes of data.
--- cloudflare.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3133ms
Looks like they don't support 1472 MTU?
I can't see why else some hosts would work and others not.
-
Looks like they don't support 1472 MTU?
I can't see why else some hosts would work and others not.
They definitely support it.
$ ping -M do -s 1472 -c 3 cloudflare.com
PING cloudflare.com (198.41.214.162) 1472(1500) bytes of data.
1480 bytes from 198.41.214.162: icmp_seq=1 ttl=61 time=0.978 ms
1480 bytes from 198.41.214.162: icmp_seq=2 ttl=61 time=1.20 ms
1480 bytes from 198.41.214.162: icmp_seq=3 ttl=61 time=1.13 ms
--- cloudflare.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 0.978/1.103/1.200/0.096 ms
This is from a Linode VPS.
-
A ZyXEL VMG1312-B10A is used at The Cattery and the MTU is configured as 1500 from the GUI. Testing shows --
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2018.04.08 14:03
IP address: xxx.xxx.xxx.xxx
Client OS/browser: Linux (Firefox 52.0)
TCP options string: 020405b40402080a015972080000000001030307
MSS: 1460
MTU: 1500
TCP Window: 29312 (not multiple of MSS)
RWIN Scaling: 7 bits (2^7=128)
Unscaled RWIN : 229
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 1172kbps (147KBytes/s)
BDP limit (500ms): 469kbps (59KBytes/s)
MTU Discovery: ON
TTL: 49
Timestamps: ON
SACKs: ON
IP ToS: 00000000 (0)
Pinging various targets --
[Duo2 ~]$ ping -M do -s 1472 -c 3 bbc.co.uk
PING bbc.co.uk (151.101.64.81) 1472(1500) bytes of data.
1480 bytes from 151.101.64.81: icmp_seq=1 ttl=57 time=52.4 ms
1480 bytes from 151.101.64.81: icmp_seq=2 ttl=57 time=52.1 ms
1480 bytes from 151.101.64.81: icmp_seq=3 ttl=57 time=53.2 ms
--- bbc.co.uk ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2056ms
rtt min/avg/max/mdev = 52.170/52.626/53.270/0.468 ms
[Duo2 ~]$
[Duo2 ~]$ ping -M do -s 1472 -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 1472(1500) bytes of data.
1480 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=53.5 ms
1480 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=56.1 ms
1480 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=58.4 ms
--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2062ms
rtt min/avg/max/mdev = 53.599/56.069/58.493/2.007 ms
[Duo2 ~]$
[Duo2 ~]$ ping -M do -s 1472 -c 3 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1480 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=51.6 ms
1480 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=51.3 ms
1480 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=53.0 ms
--- 1.1.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2056ms
rtt min/avg/max/mdev = 51.318/52.012/53.049/0.769 ms
[Duo2 ~]$
[Duo2 ~]$ ping -M do -s 1472 -c 3 cloudflare.com
PING cloudflare.com (198.41.214.162) 1472(1500) bytes of data.
1480 bytes from 198.41.214.162: icmp_seq=1 ttl=57 time=51.4 ms
1480 bytes from 198.41.214.162: icmp_seq=2 ttl=57 time=51.0 ms
1480 bytes from 198.41.214.162: icmp_seq=3 ttl=57 time=49.5 ms
--- cloudflare.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2052ms
rtt min/avg/max/mdev = 49.503/50.675/51.441/0.861 ms
[Duo2 ~]$
-
The problem seems to only exist with bridging PPPoe
https://support.aa.net.uk/VMG1312-B10A:_Bugs
Bridging 1508 bytes ethernet
Issue Description
Bridging does work, but we'd very much like the router to support baby jumbo frames bridging to VDSL and ADSL, to support *at least* 1508 bytes to allow RFC4638 PPPoE to a connected device.
Date Reported
2015-02-19
2016-10-24 Sadly (even though the hardware can support it) ZyXEL have told us that they will not be adding support for baby jumbo frames.
Resolution
Not going to be supported. (sorry)
This is where being with an ISP like AAISP pays off. They have the technical ability to help diagnose these issues.
They have sold/issued large amounts of these modems so they may be interested in helping.
-
My understanding (as confirmed by the AAISP bug above), was under bridging it doesn't work.
The only modem I know that works with bridged PPPoE is the Huawei HG612!
-
A ZyXEL VMG1312-B10A is used at The Cattery and the MTU is configured as 1500 from the GUI. Testing shows --
Are you on ADSL, burakkucat? Looks like it is working perfectly for you. I still can't explain why I can ping some with a 1472 byte payload and not others.
tcpdump shows echo replies from 8.8.8.8...
ubnt@ubnt:~$ sudo tcpdump host 192.168.1.9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on switch0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:35:01.078275 IP 192.168.1.9 > google-public-dns-a.google.com: ICMP echo request, id 2887, seq 1, length 1480
14:35:01.090980 IP google-public-dns-a.google.com > 192.168.1.9: ICMP echo reply, id 2887, seq 1, length 1480
14:35:02.079648 IP 192.168.1.9 > google-public-dns-a.google.com: ICMP echo request, id 2887, seq 2, length 1480
14:35:02.092094 IP google-public-dns-a.google.com > 192.168.1.9: ICMP echo reply, id 2887, seq 2, length 1480
14:35:03.080804 IP 192.168.1.9 > google-public-dns-a.google.com: ICMP echo request, id 2887, seq 3, length 1480
14:35:03.093998 IP google-public-dns-a.google.com > 192.168.1.9: ICMP echo reply, id 2887, seq 3, length 1480
But nothing from cloudflare.com.
14:35:15.137375 IP 192.168.1.9 > 198.41.215.162: ICMP echo request, id 2888, seq 1, length 1480
14:35:16.157058 IP 192.168.1.9 > 198.41.215.162: ICMP echo request, id 2888, seq 2, length 1480
14:35:17.180946 IP 192.168.1.9 > 198.41.215.162: ICMP echo request, id 2888, seq 3, length 1480
-
I still can't explain why I can ping some with a 1472 byte payload and not others.
This is what makes it so infuriating. PPPoE -> modem -> VDSL cab and beyond are clearly passing 1500 byte packets, why does the server you communicate with matter?
Think I'l break out the HG612 this evening to see if its the same.
-
This is what makes it so infuriating. PPPoE -> modem -> VDSL cab and beyond are clearly passing 1500 byte packets, why does the server you communicate with matter?
Think I'l break out the HG612 this evening to see if its the same.
Heh, exactly! I was thinking of resurrecting the HG612 as well. I've got one here somewhere.
-
Are you on ADSL, burakkucat? Looks like it is working perfectly for you.
Yes, that is correct. The circuit is set to use only G.992.3 and not G.992.5 nor G.992.1
-
Its sad cause in a video recorded at one of the broadband uk events, the BT guy said he wanted to ditch pppoe due to how crap it is, yet BT kept it in the end on g.fast so its here for a while yet. :(
Bad MTU sizes is the one obvious problem alongside the high cpu resources required on pppoe, horrible protocol.
Its one of the major reasons I am still on sky, I have wanted to move to aaisp for a while but MER has kept me on sky.
-
Heh, exactly! I was thinking of resurrecting the HG612 as well. I've got one here somewhere.
Dusted off the HG612, installed the unlocked firmware (B030SP08 with GUI) and it handles baby jumbos perfectly. Everything works flawlessly.
I find it annoying that I have to switch to a nearly 10 year old device to get this working >:(
I've acquired a cheap BT Business Smart Hub off of eBay and will be testing that when it arrives (it supports bridge mode).
-
Yes, that is correct. The circuit is set to use only G.992.3 and not G.992.5 nor G.992.1
Off-topic, but why disable ADSL2+?
-
Off-topic, but why disable ADSL2+?
Due to the overall length of the circuit, the sub-carriers from 256 to 512 are never used. :no:
When a 2Wire 2700HG-B was used, it would always attempt to synchronise using G.992.5 but after reporting an inconsistent signal would drop back to G.992.3 . . . The diagnostic pages of the 2Wire devices were very useful in displaying the circuit's status, including bit-loading. Subsequent to those historic events, I have checked with more capable devices (e.g. ZyXEL VMGxxxx-B10x) and have shown that G.993.2 is optimum.
-
This is interesting. Looks like AAISP is actively working with ZyXEL to add RFC4638 support on the two devices supplied by AA (the VMG3925-B10B and the VMG1312-B10D).
https://support.aa.net.uk/Category:ZyXEL_VMG3925_B10B
MTU 1500 when in bridge mode not possible yet, but we are working with ZyXEL on this. (2018-03)
https://support.aa.net.uk/Category:ZyXEL_VMG1312_B10D
MTU 1500 when in bridge mode not possible yet, but we are working with ZyXEL on this. (2017-11)
Here's hoping they add this to all their devices in the near future.
-
AAISP have actively worked with ZyXEL to get it added to every ZyXEL device they have shipped.
They haven't succeeded once.
https://support.aa.net.uk/VMG1312-B10A:_Bugs
Bridging 1508 bytes ethernet
Issue Description
Bridging does work, but we'd very much like the router to support baby jumbo frames bridging to VDSL and ADSL, to support *at least* 1508 bytes to allow RFC4638 PPPoE to a connected device.
Date Reported
2015-02-19
Updates
2015-02-19 ZyXEL development team aware, and are looking in to whether they can support this feature.
2015-03-28 Still ZyXEL HQ are still evaluating the effort to make this change.
2015-04-14 ZyXEL are working on supporting larger Ethernet frame sizes as part of the 'BT Lab modem conformity tests' (SIN 498). No ETA though.
2015-06-02 This has been chased with ZyXEL, we expect some form of update in the next couple of days
2015-06-03 Software Patch 6 is nearing release but we don't have details of which open issues are solved in this.
2015-06-09 We are chasing for further updates
2015-06-10 ZyXEL R&D resource is tied up and focus is on getting BT testing completed/passed, this feature is required to pass BT testing anyway, so we need to wait for the testing to complete and pass and then we should expect new software
2015-06-25 ZyXEL UK have been reminded again, and in turn they will be chasing up ZyXEL HQ. We're still waiting for the router to pass BT conformance testing
2016-10-24 Sadly (even though the hardware can support it) ZyXEL have told us that they will not be adding support for baby jumbo frames.
Resolution
Not going to be supported. (sorry)
The VMG1312-B10D has an extremely poorly performing chipset. I've not looked up the other device mentioned. Unless it has a BCM63168 or BCM63138 I wouldn't go near it.
-
AAISP have actively worked with ZyXEL to get it added to every ZyXEL device they have shipped.
They haven't succeeded once.
Given that they are still hounding ZyXEL (as of March 2018), they haven't quite given up :)
The VMG1312-B10D has an extremely poorly performing chipset. I've not looked up the other device mentioned. Unless it has a BCM63168 or BCM63138 I wouldn't go near it.
The 3925 is BCM63168 equipped. It is well liked by Kitz users, as far as I can tell.
-
It's a shame it shares the same horrible shape/style as many of the other Zyxels.
I love how the vmg1313-b10a wall mounts like the HG612, with the ports underneath.
AAISP spent over 18 months trying to get Zyxel to add support for Baby Jumbo Frames, only for them to discontinue the device and replace it with the vmg1312-b10D. Which also doesn't support Baby Jumbo Frames.
Doesn't seem like a high priority for Zyxel.
-
Spotted this: https://github.com/Olipro/VMG1312-B10A
Anyone brave enough to try it? :)
This is the commit:
https://github.com/Olipro/VMG1312-B10A/commit/101a09d1c515fce95e987255e5d0cf66a828a1f5
-
Oh snap!
Guess I'm going to brick my 1312 this weekend.
-
Guess I'm going to brick my 1312 this weekend.
But not if you feel confident enough to recover it via the console serial port . . . the header pins are already present on the PCB. :D
-
But not if you feel confident enough to recover it via the console serial port . . . the header pins are already present on the PCB. :D
Indeed! Have a usb serial converter lying around somewhere.
-
Spotted this: https://github.com/Olipro/VMG1312-B10A
Anyone brave enough to try it? :)
This is the commit:
https://github.com/Olipro/VMG1312-B10A/commit/101a09d1c515fce95e987255e5d0cf66a828a1f5
Can anyone make sense of the two changes this chap has made? They seem sane but I'm far from a kernel hacker.
The first change in "bcmxtmrt_atm_ioctl" seems to be something you could set later i.e with "ifconfig ptm0 mtu 1508"?
I guess the second in "DoCreateDeviceReq" seems more fundamental as its set as the ppp session is brought up.
???
-
Can anyone make sense of the two changes this chap has made? They seem sane but I'm far from a kernel hacker.
I neither get a sensation that someone has "tweaked my tail" >:( nor a "warm and fuzzy" feeling :hug: when viewing those few lines out of context. Overall, the changes look perfectly reasonable. But somebody needs to try the experiment. I wonder who that might be . . . :-\
-
It boots!
Guess that CFLAG is magic because all the interfaces now have an MTU of 2048.
Not attached it to my line yet, will report back.
-
It boots!
:clap: :dance:
Guess that CFLAG is magic . . .
It is just defining a global parameter to be used when "make" is invoked.
. . . all the interfaces now have an MTU of 2048.
I'm not sure from whence it obtained that value!
But, certainly, progress has been made. :)
-
It is just defining a global parameter to be used when "make" is invoked.
Indeed, but one that means the driver now supports an MTU over 1500 - "DCONFIG_BCM_ETH_JUMBO_FRAME", no idea where 2048 comes from, jumbo frames are up to 9000 right?
Anyway:
ifconfig eth1 mtu 1508
ifconfig: SIOCSIFMTU: Invalid argument
becomes pleasant silence now.
-
. . . jumbo frames are up to 9000 right?
Yes, that is my understanding.
-
What has baffled me is how the HG612 handles it. All the interfaces show an MTU of 1500 yet it works fine.
-
Well the electrical storm this evening had other ideas about me trying out the modem.
What has baffled me is how the HG612 handles it. All the interfaces show an MTU of 1500 yet it works fine.
Yeah it doesnt make sense, still haven't gotten around to trying an old HG612 but I was assuming its interfaces MTUs would change in accordance. :shrug2:
-
Be interesting to see if you get this online.
-
Yeah it doesnt make sense, still haven't gotten around to trying an old HG612 but I was assuming its interfaces MTUs would change in accordance. :shrug2:
Do you mean dynamically? If I run ifconfig, all the interfaces, as Alex mentioned, display an MTU of 1500.
br0 Link encap:Ethernet HWaddr F4:55:9C:8F:D8:6B
inet addr:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2072138 errors:0 dropped:0 overruns:0 frame:0
TX packets:72522 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:637045771 (607.5 MiB) TX bytes:60792028 (57.9 MiB)
br1 Link encap:Ethernet HWaddr F4:55:9C:8F:D8:6B
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:30 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1380 (1.3 KiB) TX bytes:0 (0.0 B)
eth0 Link encap:Ethernet HWaddr F4:55:9C:8F:D8:6B
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:28526102 errors:0 dropped:0 overruns:0 frame:0
TX packets:52453668 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3116806923 (2.9 GiB) TX bytes:3743298805 (3.4 GiB)
Interrupt:40 Base address:0x6a00
eth0.4 Link encap:Ethernet HWaddr F4:55:9C:8F:D8:6B
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2076172 errors:0 dropped:0 overruns:0 frame:0
TX packets:72519 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:675003403 (643.7 MiB) TX bytes:61105674 (58.2 MiB)
eth0.5 Link encap:Ethernet HWaddr F4:55:9C:8F:D8:6B
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26449930 errors:0 dropped:0 overruns:0 frame:0
TX packets:52381149 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2441803520 (2.2 GiB) TX bytes:3682193131 (3.4 GiB)
ptm1 Link encap:Ethernet HWaddr F4:55:9C:8F:D8:6C
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:53234922 errors:0 dropped:0 overruns:0 frame:0
TX packets:26428824 errors:0 dropped:1 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4294967295 (3.9 GiB) TX bytes:1240813055 (1.1 GiB)
ptm1.101 Link encap:Ethernet HWaddr F4:55:9C:8F:D8:6C
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:52381149 errors:0 dropped:0 overruns:0 frame:0
TX packets:26449929 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2948460507 (2.7 GiB) TX bytes:2441803456 (2.2 GiB)
And yet, RFC4638 works perfectly.
$ ping -c 4 -M do -s 1472 cloudflare.com
PING cloudflare.com (198.41.214.162) 1472(1500) bytes of data.
1480 bytes from 198.41.214.162: icmp_seq=1 ttl=59 time=13.0 ms
1480 bytes from 198.41.214.162: icmp_seq=2 ttl=59 time=13.1 ms
1480 bytes from 198.41.214.162: icmp_seq=3 ttl=59 time=13.0 ms
1480 bytes from 198.41.214.162: icmp_seq=4 ttl=59 time=13.0 ms
--- cloudflare.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 13.002/13.093/13.196/0.133 ms
-
Any ideas if that will work on a VMG8324?
-
Any ideas if that will work on a VMG8324?
Don’t think so.
-
ping -M do -s 1472 cloudflare.com
PING cloudflare.com (198.41.214.162) 1472(1500) bytes of data.
1480 bytes from 198.41.214.162 (198.41.214.162): icmp_seq=1 ttl=58 time=21.1 ms
1480 bytes from 198.41.214.162 (198.41.214.162): icmp_seq=2 ttl=58 time=20.7 ms
1480 bytes from 198.41.214.162 (198.41.214.162): icmp_seq=3 ttl=58 time=21.0 ms
1480 bytes from 198.41.214.162 (198.41.214.162): icmp_seq=4 ttl=58 time=21.2 ms
It works!
Don’t think so.
Well I think the 8324 still uses a broadcom switch, so the same changes should work for it. Just need to get the source from https://www.zyxel.com/form/gpl_oss_software_notice.shtml. Maybe even have the necessary stuff already from that github account, just changing PROFILE to VMG8324... I really should set up the build environment and try.
-
It works!
Excellent :thumbs:
Well I think the 8324 still uses a broadcom switch, so the same changes should work for it. Just need to get the source from https://www.zyxel.com/form/gpl_oss_software_notice.shtml. Maybe even have the necessary stuff already from that github account, just changing PROFILE to VMG8324...
Indeed. But that particular firmware will not install on a 8324, hence my comment. The 8324 has a 4 x 1 GbE switch (plus the 1 GbE WAN port), so the hardware is different.
I really should set up the build environment and try.
It's not easy based on the notes on the repo. Apparently it only builds on 32-bit variants of a legacy version of Ubuntu?
-
It's not easy based on the notes on the repo. Apparently it only builds on 32-bit variants of a legacy version of Ubuntu?
Yeah a bit of a faff, but the isos are readily available and the guy details the change to get repos to work on it, its just whether what he got from zyxel has the goodies for compiling for the 8324.
-
True. I've sent a request off to Zyxel, let's see what they come back with.
What's irritating is how simple this is to implement; the hardware clearly supports it but Zyxel is completely unwilling to add support for this officially >:(
-
Can you explain what you changed and does it survive a reboot?
-
Can you explain what you changed and does it survive a reboot?
You mean me j0hn?
I flashed the firmware linked in the previous page, it works from boot.
YMMV though and its just some random guys binary if you dont set up the build env.
-
Yes I meant you ::)
The changes listed on github are way over my head.
-
Just flash the precompiled firmware from the releases section:
https://github.com/Olipro/VMG1312-B10A/releases
Set your routers wan MTU to 1508 and it just works.
Like I said it worked for me but flash at your own risk.
-
I've just tried applying the modified firmware image to my bridged VMG1312-B10A. I was already running V1.00(AAJZ.14)C0 which this modified firmware is based off so figured it would be a relatively safe upgrade. And indeed it was, modem rebooted and came back with the existing config intact. Updated the settings on my firewall to request a 1500 byte MTU on the PPPoE connection and bingo, it's working!
The modem's ptm0 interface reports that it is at 1508 bytes;
ptm0 Link encap:Ethernet HWaddr B8:EC:A3:75:AA:30
inet6 addr: fe80::baec:a3ff:fe75:aa30/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1508 Metric:1
RX packets:84797 errors:0 dropped:0 overruns:0 frame:0
TX packets:62019 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:73633078 (70.2 MiB) TX bytes:9125407 (8.7 MiB)
Pings work up to a payload of 1472 bytes, confirming that a 1500 MTU is working (1472 byte payload + 8 byte ICMP header + 20 byte IP header = 1500 bytes);
>ping kingj.net -f -l 1472
Pinging kingj.net [195.154.46.25] with 1472 bytes of data:
Reply from 195.154.46.25: bytes=1472 time=21ms TTL=53
Reply from 195.154.46.25: bytes=1472 time=21ms TTL=53
Above 1473 bytes payload, fragmentation is required as expected. Confirming at least that there's no secret fragmentation going on on the modem side!
ping kingj.net -f -l 1473
Pinging kingj.net [195.154.46.25] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Very pleased that this works! The BCM63168 and the VMG1312-B10A's filtering works great on my line letting me sync at a full 80/20, but it was always a shame to have no baby jumbo frame support. So very glad that's no longer a problem.
-
True. I've sent a request off to Zyxel, let's see what they come back with.
What's irritating is how simple this is to implement; the hardware clearly supports it but Zyxel is completely unwilling to add support for this officially >:(
Did Zyxel respond to this?
-
Did Zyxel respond to this?
Sorry, forgot to update this thread. Yes, they did. They have sent me the source code for the VMG8324-B10A (version V1.00(AAKL.21)C0). I just haven't had the time to setup the build environment and test the same modifications as the one done on the 1312 by the other chap.
Had a look through the other project in a bit more detail - I'm pretty sure that code will only build for the 1312.
-
I would love to try this fw out, the MTU thing was putting me off using the 1312-B10A. Also, I would need to get two more B10As from somewhere as I have three lines but only one modem currently (which the ISP AA sold me).
Mind you, there is still the PPP session drop bug - https://support.aa.net.uk/VMG1312-B10A:_Bugs - which affects AA users but if I understand correctly not some other ISPs because that article says it is determined by whether or not the ISP uses a static WAN IP address, which AA always does.
-
The PPP session drop bug only affects the device when used as a modem router.
Used in bridge mode with your Firebrick you would have no such issue.
Have you compared the Zyxels sync rate with your current modem?
-
The 8924 firmware image from Zyxel for anyone who wants it. It's the V1.00(AAKL.21)C0 firmware.
I see no reason this won't work with the 8924 the same as it does for the 1312.
I'll have a go at building the firmware image tomorrow.
https://www.dropbox.com/sh/3kefsh7qo5yuixm/AABT4xceivGrYBTsz4pNDz5ya?dl=0
The link expires on May 13th 2018
-
So should I go for it, try my B10A out, if I can find it? With the custom firmware. It will be in straight-modem only mode in my case. As I said earlier, I've been very keen on getting PPP MTU 1508 support and RFC 4638.
And just to sanity check, PPP bug if used as a router but not if modem-only?
Burakkucat, you mentioned that you have one I think. I can't remember if yours is being used as just a modem or a router. It's rather a lot to ask, but let me know if you are up for testing the fw? Would you have time or inclination to build it even?
Does someone have cross-compiler tools then?
Could I also get some help reflashing it? (drugs)
Also so help with configuring it afterwards. (more drugs) For example I need to get it into modem-only + G.992.3-only + PPPoEoA VC-MUX no-FCS-preserved mode and get the wireless turned off.
-
So should I go for it, try my B10A out, if I can find it? With the custom firmware. It will be in straight-modem only mode in my case. As I said earlier, I've been very keen on getting PPP MTU 1508 support and RFC 4638.
If you can (or if you can get some local help), I would say "yes".
And just to sanity check, PPP bug if used as a router but not if modem-only?
A bridging modem does nothing PPP-wise, so yes, that bug only affects the VMG1312-B10A when used in modem/router mode under certain conditions. I would trust the words of j0hn!
Burakkucat, you mentioned that you have one I think. I can't remember if yours is being used as just a modem or a router. It's rather a lot to ask, but let me know if you are up for testing the fw? Would you have time or inclination to build it even?
I use my VMG1312-B10A in modem/router mode and it allows me to set the MTU to 1500. Hence I have no need of the customised firmware.
The custom firmware image is available --
Just flash the precompiled firmware from the releases section:
https://github.com/Olipro/VMG1312-B10A/releases
Set your routers wan MTU to 1508 and it just works.
Like I said it worked for me but flash at your own risk.
Could I also get some help reflashing it? (drugs)
Also so help with configuring it afterwards. (more drugs) For example I need to get it into modem-only + G.992.3-only + PPPoEoA VC-MUX no-FCS-preserved mode and get the wireless turned off.
You really need some help from someone in the same country, Alba.
-
The thing about the bug is that I believe certain usage patterns happened to trigger it despite the fact that as you rightly say, it knows nothing about the details of PPP but this is a PPPoE thing, I was wrong.
“PPPoE Session-ID caching bug (In Bridge mode)” is the entry in AA’s bugs list. So it would affect me under the right usage conditions, to do with constant value of (say UDP) source port and long-term usage if I am understanding correctly. It's an evil hardware higher-level protocol snooping thing, where it should not know anything about such protocols but in fact it sneakily does. Huawei has the same bug.
I don't suppose someone out there could fix that bug, suggested fix strategies are mentioned by AA. I wonder if AA could be given enough source code for them to fix it themselves.
-
PPPoE Session-ID caching bug (In Bridge mode)
Issue Description
Last year we had an problem with Huawei FTTC modems, the standard ones that Openreach supply The bug appears to be that the modem manages to "blacklist" some UDP packets after a PPP restart. Typically this affects VPN tunnels. The short term fix is to unplugged and plugged back in!
We now have what looks to be the same fault on the ZyXELs - both on ADSL and VDSL.
When a PPPoE session finishes and a new one starts, ethernet frames containing IP packets with the same source and destination IP and port combination that were used in the previous session are received with the PPPoE Session-ID from the earlier session.
This affects long running sessions using protocols which use the same source port for all communications. This includes IPsec and (in some circumstances) SIP.
Our understanding of this, having talked to Huawei last year to get a very similar bug fixed is that the problem is with the packet accelerator feature in the Broadcom chipset. It is caching frame headers including the PPPoE Session-ID, but not checking if the Session-ID is the same when searching for the entry in the cache for subsequent packets. Unplugging the ethernet cable from the VMG1312 momentarily resolves the problem - that action must trigger a cache flush in the Broadcom chipset.
Possible fixes would be to either not store the Session-ID in the packet accelerator cache at all, or to check the Session-ID in addition to the IP and ports when searching the cache. A workaround would be to disable the packet accelerator.
(Side note for other ISPs looking at this: This does not affect lines that have dynamic WAN addresses, which none of our service do.)
This is so obscure it's ridiculous. It's not ZyXEL that need to fix it, it's Broadcom.
It appears to be present in most Broadcom modems.
I use an IPsec VPN a dozen times a day and have never come across this on either the ZyXEL or the Huawei HG612, which I've used for over 5 years between them.
It's the IPV6 bugs that cause lots of issues with the VMG1312-B10A. They only affect it in router mode.
-
So should I go for it, try my B10A out, if I can find it?
It worked on mine, and was up for several days before I went back to an older firmware for unrelated issues. So no problems using it and then going back to something different, all just flashing through the web interface.
Of course for peace of mind getting the originals from zyxel and setting up the build environment would be better.
On a related note, does anyone recall people changing out the dsl driver on similar firmwares? I have vague memories of people changing out the broadcom 39'x' dsl driver portion of the firmware in order to get newer versions on HG612s and maybe others. I think I have found issues with newer versions of the BCM code and frankensteining together the 1508 patches with an older driver would be great.
-
On a related note, does anyone recall people changing out the dsl driver on similar firmwares? I have vague memories of people changing out the broadcom 39'x' dsl driver portion of the firmware in order to get newer versions on HG612s and maybe others. I think I have found issues with newer versions of the BCM code and frankensteining together the 1508 patches with an older driver would be great.
It was back in November 2012 that asbokid documented a series of experiments in which he tested the result of dynamically swapping-out the hardware driver's blob, i.e. the driver's firmware, and not the driver itself. I think I have a copy of his report stashed away, somewhere.
-
When they supply a binary blob, they presumably don't trust their customer with the source code in case they rip it off or fiddle around with it, quite understandable.
Do they have a vector table of entries into it at a documented offset, or use a kind of standard dynamic library format ?
-
When they supply a binary blob, they presumably don't trust their customer with the source code in case they rip it off or fiddle around with it, quite understandable.
Yes, I suspect that is the case.
Do they have a vector table of entries into it at a documented offset, or use a kind of standard dynamic library format ?
Sorry, I do not have any knowledge of the (xDSL driver's) blob format. There is one person who might have studied such entities or who might have an opinion and that is ejs.
-
Replaced AAJZ.11 with this custom AAJZ.14, didn't reconfigure, sent "ifconfig ppp2.1 mtu 1500" in telnet and didn't notice a problem for the past 2 days (modem-router mode).
But, it only lasts for the PPP session, and next session reverts back to 1492.
I don't know what can be done as I'm clueless about these things.
-
Sorry, I'm not following spring, what happens when you just boot that firmware straight up without doing anything at all to configure things?
-
Pinging 1472 [+28 = 1500] without fragmentation doesn't work, why else would I say it reverts back.
-
So this mod only works temporarily?
-
Yeah, just for as long as the WAN connection held.
-
Damn that is such a total disappointment, sounds like the author has got some more work to do?
Could any kitizen fix it properly?
-
The fix is for using a VMG1312-B10A in bridging modem mode.
No "fix" is required for a VMG1312-B10A in modem/router mode.
-
Well if someone else could confirm my experience, it'd be something to work on for "the next" release.
-
Damn that is such a total disappointment, sounds like the author has got some more work to do?
Could any kitizen fix it properly?
No, it appears this thread has confused spring.
The changed firmware is to make 1508 mtu work while the device is being used as a modem (as per thread title) in bridge mode. From his previous posts (setting ppp session parameters over telnet on the VMG1312) he is using it as a modem/router, in which case he only needed to set the MTU to 1500 in the web interface. His method of changing the ppp session is of course not persistent, just as changing it on your router by direct commands would not survive a reboot.
Maybe I should edit the OP to make it even clearer we are talking about bridge mode?
-
Maybe I should edit the OP to make it even clearer we are talking about bridge mode?
Yes, please, that would be helpful.
-
Yes, please, that would be helpful.
I dont seem to be able to edit the first post, might I suggest this: If you dont mind doing the honours burakkucat.
The often suggested ZyXEL modems on this forum have great performance, but to my knowledge none support RFC 4638 with MTUs over 1492 for PPPoE connections in bridge mode. As far as I understand, all BT based FTTC connections should support it, but working examples to google are thin on the ground.
Other modems I am aware of with BCM63168 chipset:
Billion 8800nl
Netgear D6400
BT HH5B?
Does anyone have experience with one that can support over 1492 MTU when used as a modem in bridge mode?
And maybe add bridge mode to the title as well?
-
I dont seem to be able to edit the first post, <snip>
And maybe add bridge mode to the title as well?
Ah, yes, the post has "aged" out of the time-frame, available to you, for its editing. Hopefully my modifications are appropriate! ;)
-
That's perfect, thank you!
-
That's perfect, thank you!
s/perfect/purrfect/
You are welcome. :)
-
No, it appears this thread has confused spring.
The changed firmware is to make 1508 mtu work while the device is being used as a modem (as per thread title) in bridge mode. From his previous posts (setting ppp session parameters over telnet on the VMG1312) he is using it as a modem/router, in which case he only needed to set the MTU to 1500 in the web interface. His method of changing the ppp session is of course not persistent, just as changing it on your router by direct commands would not survive a reboot.
Maybe I should edit the OP to make it even clearer we are talking about bridge mode?
Can this be changed? Don't think so.
Maybe I could upload a configuration file with 1492 edited to 1500, but I won't try that for now.
Next time take the time to test something before you pretend to know it for sure.
-
I have now flashed that custom firmware in my VMG1312-B10A, modem-only mode. Tested with DF pings and MTU 1500 + 8 = 1508 joy! Very pleased with that.
-
Can this be changed? Don't think so.
Maybe I could upload a configuration file with 1492 edited to 1500, but I won't try that for now.
Next time take the time to test something before you pretend to know it for sure.
My apologies! I admit I have not used the VMG1312 as a modem/router to test, but was going on other forum users use of it with 1500 MTU.
So when you issued:
ifconfig ppp2.1 mtu 1500
on a router with unmodified firmware it failed?
Seems unlikely as the changes were only to the switch driver to allow > 1500 byte MTU ethernet frames from another router, and to change the ptm session parameters to default to 1508.
Could you share the output of "ifconfig" from your modem/router currently?
-
bcmsw Link encap:Ethernet HWaddr
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Base address:0xda00
br0 Link encap:Ethernet HWaddr
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: Scope:Link
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:2048 Metric:1
RX packets:259691 errors:0 dropped:0 overruns:0 frame:0
TX packets:431812 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:23021480 (21.9 MiB) TX bytes:557977520 (532.1 MiB)
eth0 Link encap:Ethernet HWaddr
inet6 addr: Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:34415 errors:0 dropped:0 overruns:0 frame:0
TX packets:51871 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3206690 (3.0 MiB) TX bytes:54580614 (52.0 MiB)
eth0.0 Link encap:Ethernet HWaddr
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:34001 errors:0 dropped:0 overruns:0 frame:0
TX packets:51249 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2562311 (2.4 MiB) TX bytes:53360556 (50.8 MiB)
eth1 Link encap:Ethernet HWaddr
UP BROADCAST MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth1.0 Link encap:Ethernet HWaddr
inet6 addr: Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:3489 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:1162228 (1.1 MiB)
eth2 Link encap:Ethernet HWaddr
UP BROADCAST MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth2.0 Link encap:Ethernet HWaddr
inet6 addr: Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:3457 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:1159216 (1.1 MiB)
eth3 Link encap:Ethernet HWaddr
inet6 addr: Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:226139 errors:0 dropped:0 overruns:0 frame:0
TX packets:384815 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:24552437 (23.4 MiB) TX bytes:510288675 (486.6 MiB)
eth3.0 Link encap:Ethernet HWaddr
inet6 addr: Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:225695 errors:0 dropped:0 overruns:0 frame:0
TX packets:383986 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:20459649 (19.5 MiB) TX bytes:505773672 (482.3 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:66 errors:0 dropped:0 overruns:0 frame:0
TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4294 (4.1 KiB) TX bytes:4294 (4.1 KiB)
ppp2.1 Link encap:Point-to-Point Protocol
inet addr: P-t-P: Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP ALLMULTI MULTICAST MTU:1500 Metric:1
RX packets:431109 errors:0 dropped:0 overruns:0 frame:0
TX packets:254197 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:552112647 (526.5 MiB) TX bytes:21057615 (20.0 MiB)
ptm0 Link encap:Ethernet HWaddr
inet6 addr: Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1508 Metric:1
RX packets:427737 errors:0 dropped:0 overruns:0 frame:0
TX packets:252047 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:556776733 (530.9 MiB) TX bytes:25572463 (24.3 MiB)
ptm0.1 Link encap:Ethernet HWaddr
UP BROADCAST RUNNING MULTICAST MTU:1508 Metric:1
RX packets:431119 errors:0 dropped:0 overruns:0 frame:0
TX packets:254209 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:555562051 (529.8 MiB) TX bytes:26650346 (25.4 MiB)
-
So as you say the best course of action is to change the mtu value in an uploaded configuration. The ptm interfaces have their MTU set at 1508 as per the changes to the firmware, but this maybe unnecessary.
Would be good to see if you set the wan mtu to 1500 with cfg file and then change the ptm interfaces back to 1500 if packets get fragmented. That way we'd know if its just the nag from the web interface that needs to be circumvented and no need for the other changes when running as a modem/router.
-
Can this be changed? Don't think so.
Maybe I could upload a configuration file with 1492 edited to 1500, but I won't try that for now.
Next time take the time to test something before you pretend to know it for sure.
I think johnson's confusion comes from the fact that when used in modem/router mode there is no need for the special jumbo frames firmware.
The "ifconfig ptm0 mtu 1508" + "ifconfig ptm0.1 mtu 1508" commands just work. Yes it's not permanent, but it works without having to install any special firmware.
So I recommend you install the standard AAJZ.14 from Zyxel.
In bridge mode sending the "ifconfig ptm0 mtu 1508" command doesn't work right, even when using a router that supports 1508 MTU (Baby Jumbo Frames).
The firmware is a complete fix when used with a router that supports 1508 MTU.
-
I still have hope in editing the configuration file so I'll keep using this firmware, but I don't know which entry there would be the wan mtu?
And a side question, does AAJZ.14 sync the best for you guys? Or you've had a better experience with an older firmware?
-
The only "configuration.conf" I have from a VMG1312 was already in bridge mode, and a quick search of it has no hits for "MTU" "1492" or "1500". But this maybe due to no section for a normal PPPoE based connection. Have a look through one from your current setup.
As for the best syncing firmware, the latest is probably best but... I had a go with a really old one recently to see if it fixed an unrelated problem and it synced the highest I have seen, with the caveat that it had much higher errors and disconnected several times in the few days I used it. This may be no problem if you have a more stable line than mine (its garbage). Was the AAJZ.7 from ftp://ftp2.zyxel.com/VMG1312-B10A/firmware/.
Pinch of salt and all that, but it gave me a few Mbits more download sync.
-
Perhaps the following image will convince you that the default maximum MTU size, settable via the GUI, for modem/router mode of a ZyXEL VMG1312-B10A (purchased in the U.K. and with no ISP/CP customisation) is 1500.
(https://elrepo.org/people/ajb/MTU_1500_Default.png)
I have two units. Both are identical. :)
Edited to add the lines grep'd from the saved configuration files --
[Duo2 ZyXEL_VMG1312-B10A]$ grep MaxMTUSize config*txt
configuration-backupsettings_20180408-2200.txt: <X_404A03_MaxMTUSize>1500</X_404A03_MaxMTUSize>
configuration-backupsettings_20180414-2114.txt: <X_404A03_MaxMTUSize>1500</X_404A03_MaxMTUSize>
[Duo2 ZyXEL_VMG1312-B10A]$
-
Under Maintenance > Configuration
backup your current config
find the line...
<X_404A03_MaxMTUSize>1492</X_404A03_MaxMTUSize>
try change it to
<X_404A03_MaxMTUSize>1500</X_404A03_MaxMTUSize>
Restore the edited .conf
report back here?
-
I'm thinking maybe the difference is your ADSL connection burakkucat?
-
He's Talktalk
They use IPoe
PPPoe is 1492 max
-
I'm thinking maybe the difference is your ADSL connection burakkucat?
He's Talktalk
They use IPoe
PPPoe is 1492 max
Sorry but neither suggestions have any relevance to the fact that two separate VMG1312-B10A have been configured from the GUI and the upper limit of the MTU offered -- and accepted -- is 1500.
-
Sorry but neither suggestions have any relevance to the fact that two separate VMG1312-B10A have been configured from the GUI and the upper limit of the MTU offered -- and accepted -- is 1500.
The limit is 1492 for me (PPPoE). Anyway I'll try the configuration file and edit this post.
Edit: I can't find MTU or 1492, maybe if I reset the configuration to how AAJZ.14 makes it [previously used .11]. Maybe I need to edit it from the default 1492 to a different value for it to show up?
Edit2: Okay I edited it to 1491 in the web interface and it showed up. I'll try changing it to 1500.
Edit3: Boots up the interface at 1492 despite the configuration file at 1500. And web interface shows 1492. Guess I'll switch to the official firmware soon.
As for the best syncing firmware, the latest is probably best but... I had a go with a really old one recently to see if it fixed an unrelated problem and it synced the highest I have seen, with the caveat that it had much higher errors and disconnected several times in the few days I used it. This may be no problem if you have a more stable line than mine (its garbage). Was the AAJZ.7 from ftp://ftp2.zyxel.com/VMG1312-B10A/firmware/.
Pinch of salt and all that, but it gave me a few Mbits more download sync.
Would it have any effect if I have a fixed rate line?
-
What if you choose PPPoE as the connection type and then try an MTU over 1492?
-
Would it have any effect if I have a fixed rate line?
Fixed as in banded? Or you are already at the max sync of your package? Either way I doubt it.
-
Fixed as in banded? Or you are already at the max sync of your package? Either way I doubt it.
Constant sync rate, and yes I'm at the max sync.
Would be good to see if you set the wan mtu to 1500 with cfg file and then change the ptm interfaces back to 1500 if packets get fragmented. That way we'd know if its just the nag from the web interface that needs to be circumvented and no need for the other changes when running as a modem/router.
Tried that earlier today, WAN connection was up but internet didn't work at 1500 nor set back to 1508, so I restarted the router. Seems this custom firmware is "locked" at 1508. So I conclude it probably must be 1508 for baby jumbo frames to work.
-
Just installed the pre-compiled Olipro firmware for fun on a spare VMG1312-B10A. In bridge mode jumbo frames are working well:
$ ping -M do -c 4 -s 1472 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1472(1500) bytes of data.
1480 bytes from 1.1.1.1: icmp_seq=1 ttl=57 time=10.9 ms
1480 bytes from 1.1.1.1: icmp_seq=2 ttl=57 time=10.5 ms
1480 bytes from 1.1.1.1: icmp_seq=3 ttl=57 time=10.5 ms
1480 bytes from 1.1.1.1: icmp_seq=4 ttl=57 time=10.3 ms
Bump the packet length up to 1473 and as expected:
$ ping -M do -c 4 -s 1473 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
The Zxyel VMG1312-B10A is also working fine with BT multicast TV, IPTV (again, in bridge/modem mode and then fed into a pfsense box).
-
I've made a firmware for the VMG8924-B10A if anyone wants it. Based on the latest 1.00(AAKL.21)C0
http://bit.ly/8x24Jumbo
-
Replaced AAJZ.11 with this custom AAJZ.14, didn't reconfigure, sent "ifconfig ppp2.1 mtu 1500" in telnet and didn't notice a problem for the past 2 days (modem-router mode).
But, it only lasts for the PPP session, and next session reverts back to 1492.
I don't know what can be done as I'm clueless about these things.
Spring are you sure you were getting 1500 byte packets through to every site? I'm just looking through the source to find what needs to be changed to allow saved 1508 mtu in modem/router mode and there are several hard coded limits to 1492 when using PPPoE in pppd itself.
From earlier in this thread you can see that before modification setting 1508 mtu appeared to work, but somehow the fragmentation was being masked.
Can you try a fragmentation test to cloudflare.com with your current setup?
-
Is this what you wanted? o.o
ping cloudflare.com -l 1472 -f
Pinging cloudflare.com [198.41.214.162] with 1472 bytes of data:
Reply from 198.41.214.162: bytes=1472 time=15ms TTL=58
Reply from 198.41.214.162: bytes=1472 time=15ms TTL=58
Reply from 198.41.214.162: bytes=1472 time=14ms TTL=58
Reply from 198.41.214.162: bytes=1472 time=14ms TTL=58
Ping statistics for 198.41.214.162:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 14ms, Maximum = 15ms, Average = 14ms
ping cloudflare.com -l 1473 -f
Pinging cloudflare.com [198.41.214.162] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 198.41.214.162:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
-
Thank you!
So setting the ppp session to 1508 after the fact works fine, good to know.
I have tried making changes to the firmware to allow setting 1508 in the web interface and also remove the limits set in the pppd daemon so it should accept 1508 initially. This should allow you to set it in the web interface and have to come up correctly on boot.
I want to try it on my line first, but are you up for testing it?
-
Thank you!
So setting the ppp session to 1508 after the fact works fine, good to know.
I have tried making changes to the firmware to allow setting 1508 in the web interface and also remove the limits set in the pppd daemon so it should accept 1508 initially. This should allow you to set it in the web interface and have to come up correctly on boot.
I want to try it on my line first, but are you up for testing it?
I have PPPoE which is normally 1500-8, so with baby jumbo it's 1508-8, so I have the ppp interface at 1500 (1508 wasn't able to ping 1473 bytes, and it makes sense because the jumbo limit is +8 not +16 :v ).
Thanks so much though :baby:
I can't afford to brick my device though I mean if it's just a line test sure 0.0
-
I'm not sure what you mean spring, I wasnt suggesting you have anything set wrong.
-
I'm not sure what you mean spring, I wasnt suggesting you have anything set wrong.
If you want you can PM me and I'll try I know some people here might be jealous about the fact I might not be able to trigger any DLM on my line even if I tried lol so if you tested it's all safe but haven't let it sync on your line then sure.
However I'm very afraid, if I brick my device I'm as good as dead
-
However I'm very afraid, if I brick my device I'm as good as dead
Well I wouldnt want that on my conscience! ;D
I have flashed it and it boots just fine, but I will test it on my line first and maybe find someone else that uses the 1312 as a modem/router to test.
Btw, even after a bad flash the 1312 can be recovered without a serial connection but holding the reset button in while booting for ~20 seconds. The light flashes red then goes solid red, you wait ~1 minute and then you can upload a working firmware as the boot loader has a build in web server.
-
Well I wouldnt want that on my conscience! ;D
I have flashed it and it boots just fine, but I will test it on my line first and maybe find someone else that uses the 1312 as a modem/router to test.
Btw, even after a bad flash the 1312 can be recovered without a serial connection but holding the reset button in while booting for ~20 seconds. The light flashes red then goes solid red, you wait ~1 minute and then you can upload a working firmware as the boot loader has a build in web server.
How bad of a flash? The worst possible one as well? Sure I'll test.... the loader is uploaded at 192.168.1.1 ?
Almost everyone here triggers DLM if they start testing so it costs me nothing from that aspect even if you asked me 10 times just today I would
-
I have to say I have not bricked it to test, but the flashing procedure doesnt seem to touch the boot loader so I can only assume it would still be functional even if you wrote all zeros to the area where the kernel and filesystem should be.
-
I have to say I have not bricked it to test, but the flashing procedure doesnt seem to touch the boot loader so I can only assume it would still be functional even if you wrote all zeros to the area where the kernel and filesystem should be.
Why do people say "I think I'll brick my B10A today" then? xD
-
Almost everyone here triggers DLM if they start testing so it costs me nothing from that aspect even if you asked me 10 times just today I would
How come your line is not affected?
-
How come your line is not affected?
DLM doesn't have to work and if it does that's fine anyway if I re-sync up to at least 5 times a day nothing happens and I have 5 to go today [if not 100 :lol:]
In the past when I had ADSL, if I resynced 20 times the same day the DLM didn't notice a thing :lol:
It must be that it takes measures only when actually needed :v
My line conditions were never "changing", and the kind of faults I had on ADSL were complete loss of sync for hours at just one raindrop at a time sometimes 16 hours per day or even further in the past 23 hours per day, or that I had to pick up the phone forever or else there was no sync. There were some magic years with "no issues", but since I've had VDSL it's all well as I'm finally not 3000m but 100m away and my line isn't old, since our in-building phone wire got cut half a year ago or more don't remember, I have a brand new line that's never been used because the guy that cut our wire (among every other of the 30 phone wires in the box) chose our line, but we didn't go back to the line that was stolen from us, we were hooked up with a new one that happend to be free to use at the time. So we got the new neighbours line instead >:D
-
Wish I could accidentally cut my line and have new copper installed! ;D
No dice with the firmware, tried it on my line but it still brings up the ppp1.1 interface with an MTU of 1492. I'l poke around in the source more and try and find what I'm missing that keeps it at 1492.
-
I've made a firmware for the VMG8924-B10A if anyone wants it. Based on the latest 1.00(AAKL.21)C0
http://bit.ly/8x24Jumbo
I think I read somewhere that 8924 and 8324 share the same firmware, so my question is: would this modified firmware work on a VMG8324-B10A as well ?
-
It will.
I have built the firmware and flashed it on an 8324, using the same PROFILE=VMG8924-B10A command used for both.
Edit: and if you are interested in being a guinea pig I have a version compiled with the latest broadcom xDSL driver A2pv6F039x1
-
It will.
I have built the firmware and flashed it on an 8324, using the same PROFILE=VMG8924-B10A command used for both.
Edit: and if you are interested in being a guinea pig I have a version compiled with the latest broadcom xDSL driver A2pv6F039x1
Great... let's see if j0hn is willing to re-share the link... ::)
-
Here are firmwares compiled from zyxel sources, the ...jumboframes.bin ones have only the patches from Olipro's repo and the 3925 ones have the updated A2pv6F039x1 xDSL driver vs A2pv6F039v version in the latest ones from zyxel.
I have tested all to boot with a serial console attached and none make any new warning messages. I have only used the 8324 with new xDSL driver on my line and it worked fine several hours before I pulled it to test more.
https://www.dropbox.com/sh/jw4pdc3yem4zzaa/AACVBARaPKaEemeeJ8hP87J_a?dl=0
Edit: To clarify these are all based on the latest version of each, the VMG8324-B10A_1.00(AAKL.21)C0 & VMG1312-B10A_1.00(AAJZ.14)C0
-
Thought I'd add if anyone is apprehensive, the recovery procedure from a bad flash is easy (though I have not needed it):
The 1312/8324 can be recovered without a serial connection by holding the reset button in while booting for ~20 seconds. The light flashes red then goes solid red, you wait ~1 minute and then you can upload a working firmware as the boot loader has a build in web server. Set your PC to 192.168.1.100 and access 192.168.1.1 after waiting the required time.
This process is the same as having a serial connection and interrupting the boot, so gets you to the same boot loader based web server. I admit I have not had a bad flash to test it, but given its totally in the boot loader I cant see how a flash from the web GUI or other could interfere with it.
-
Here are firmwares compiled from zyxel sources, the ...jumboframes.bin ones have only the patches from Olipro's repo and the 3925 ones have the updated A2pv6F039x1 xDSL driver vs A2pv6F039v version in the latest ones from zyxel.
I have tested all to boot with a serial console attached and none make any new warning messages. I have only used the 8324 with new xDSL driver on my line and it worked fine several hours before I pulled it to test more.
https://www.dropbox.com/sh/jw4pdc3yem4zzaa/AACVBARaPKaEemeeJ8hP87J_a?dl=0
Much appreciated ! :drink:
-
Many thanks indeed. Most grateful!
-
Have also been trying to make changes to the VMG1312 initially to make 1500 mtu work from boot using it as a modem router. Have got as far as changing out the ppp version from 2.4.4 to one from this later commit that enables baby jumbo frames:
http://git.ozlabs.org/?p=ppp.git;a=commit;h=fd1dcdf758418f040da3ed801ab001b5e46854e7
But I tried it on my line yesterday and the ppp1.1 interface still came up with an mtu of 1492 :wall:
I'm honestly at a loss as to how springs setup works - changing the ppp interface mtu after it is live, as a decent amount of work was done to the ppp program to get RFC4638 to work.
-
Maybe you can make it set itself to 1500 after it is live, or change PPPoE default to 1500. Any way for it to work xd
-
Great ROM! Just loaded '1312-B10A-from-zyxel-jumboframes-3925adsl_phy.bin' - the one with the latest Broadcom driver.
Jumbo frames are working correctly and DSLstats is showing Modem/router firmware: AnnexA version - A2pv6F039x1.d26a as expected.
Thanks for the effort you have put into this johnson, well done! :clap:
-
I'm curious to know if there's any improvement in attainable/sync rate and/or error rates with this new DSL driver?
-
I didn't want to say, cos reboot time of day and local conditions are always changeable and play their part... but my re-sync was up by 700K.
It will take longer testing to be sure of any ongoing improvement...
-
Is there a .bin file editor I can use just 'for curiosity' ?
-
Earlier in this thread (Reply #97 (https://forum.kitz.co.uk/index.php/topic,21273.msg372303.html#msg372303)) I responded with a terse --
Sorry but neither suggestions have any relevance to the fact that two separate VMG1312-B10A have been configured from the GUI and the upper limit of the MTU offered -- and accepted -- is 1500.
I feel that I should expand on the above.
When both of the VMG1312-B10A devices were configured they were not connected to the xDSL circuit. The only connections were to the PSU (duh!) and via an Ethernet patch cable to a computer. The "wizard" process, offered on the first GUI visit, was ignored (& turned off), the pre-existing WAN interfaces ("Network Setting ---> Broadband") were deleted and one WAN interface was created for my usage.
I wonder if that accounts for why I was allowed to create the WAN interface with an MTU of 1500 using the ZyXEL released firmware image?
(https://elrepo.org/people/ajb/MTU_1500_Default.png)
-
Tested johnson's new build for the VMG 1312-B10A all fine no problems.
No speed improvement with G.992.3 and my very long line, in fact downstream sync is 25kbps slower and upstream is 3kbps slower. I did a second resync, speeds were unchanged. A 1% downstream change like this hardly means much of course.
-
Here are firmwares compiled from zyxel sources, the ...jumboframes.bin ones have only the patches from Olipro's repo and the 3925 ones have the updated A2pv6F039x1 xDSL driver vs A2pv6F039v version in the latest ones from zyxel.
I have tested all to boot with a serial console attached and none make any new warning messages. I have only used the 8324 with new xDSL driver on my line and it worked fine several hours before I pulled it to test more.
https://www.dropbox.com/sh/jw4pdc3yem4zzaa/AACVBARaPKaEemeeJ8hP87J_a?dl=0
Edit: To clarify these are all based on the latest version of each, the VMG8324-B10A_1.00(AAKL.21)C0 & VMG1312-B10A_1.00(AAJZ.14)C0
Thanks for all your work. I've just ordered an 8324 yet to arrive so the device is new to me and this may be dumb. But your post says you used the latest 8324 firmware but the dropbox link I'm only seeing links for 1312 and 8924. Is it fine to use the 8924 on the 8324? :-\
-
Many thanks Johnson for compiling those firmwares have saved them in my hardware archive for the VMG-1312-B10A.
-
Is it fine to use the 8924 on the 8324? :-\
Yes, the VMG8924 and VMG8324 share the same firmware.
And while I think of it: "Welcome to the Kitz forum." :)
-
Yes, the VMG8924 and VMG8324 share the same firmware.
And while I think of it: "Welcome to the Kitz forum." :)
Thanks for the clarification and the warm welcome.
-
I have dug up a set of release notes for the low-level broadcom driver in the web somewhere. In the bug fixes I saw, I don’t remember noticing anything relating to lowly G.992.3. Is that correct? I didn't know how far back to look as I was not sure what the baseline low-level driver version was.
-
I have dug up a set of release notes for the low-level broadcom driver in the web somewhere. In the bug fixes I saw, I don’t remember noticing anything relating to lowly G.992.3. Is that correct? I didn't know how far back to look as I was not sure what the baseline low-level driver version was.
I found this from cisco detailing the changes from 39v to 39x1:
https://www.cisco.com/web/software/282821780/140978/ReleaseNote_A2pv6F039x3.pdf
Only these lines mention G992.x
Improve kl0 estimate in G.992.[35]
Fix long training time in G.992.1 against AD72 DSLAM
I'm not sure what these even mean so ???
If you see no improvement with the 39x1 driver its probably best to stick with the one zyxel chose to use. I was interested it trying the later driver as I have experienced some weird behaviour with my line and recent firmwares and have G.vector (G.993.5) and there are several mentions to improvement with it. There may be unforeseen consequences to just swapping out the adsl_phy.bin without changing the kernel driver as again from the cisco document:
Improve power saving in DSL PHY by powering down unused line. This feature requires
new xDSL driver A2x026n
With 26n I believe referring to a later kernel driver to the 26a one these zyxel firmware have. So be warned its experimental and probably not advised, but hey, if people dont see and stability issues and see some kind of improvement then why not.
-
Is there a .bin file editor I can use just 'for curiosity' ?
You can use binwalk on linux to unpack the filesystem to poke around, its what I used to get the xDSL bin out the 3925 firmware:
https://github.com/ReFirmLabs/binwalk
If setting up VMs isnt a hassle you can create these firmwares yourself with no trust in a 3rd party other than xyxel. They have a GPL request page where you put in your model and serial number and they supply a package with all the tools and easy to use scripts to create the firmware, there are only 2 changes you need to make to get jumbo frames working and they are detailed in Olipro's repo mentioned earlier in the thread. The instructions in the package are clear and easy to follow. As it says in them and Olipro's github you have to build on an old 32bit version of ubuntu, but the only thing that makes it any harder to use than a normal system is changing the apt sources to point at ubuntu's old archives.
-
Could that be read two ways? - 1 needing a later higher level driver if one wishes to make use of eg a new power management feature, as opposed to 2. interface compatibility / incompatibility between lower and upper level drivers
-
Should we transfer to the other thread concerned with software ‘maintenance’? What do you think?
-
I read it as the former, the fact it mentions you needed the newer kernel driver for only that feature suggests you can use old ones and simply not have it. But who knows, I thought I'd still say something as 26a vs 26n sounds like a lot of iterations missed in the zyxel supplied one.
-
Ah I see.
-
Any gains so far over the older dsl driver?
-
No. Just very slightly worse downstream sync rate.
-
Mine was up slightly with the new firmware, same error rates for me as the latest standard Zyxel firmware.
ES/hour: 1.49 (down) 0.09 (up)
-
Yes I didn't note error rates.
-
May I ask someone who is using the MTU=1508 whether you can really get better performance or what's the benefit(s) ?
Tia.
-
It is purely theoretical in my view, no possibility of any problems with the reduced IP MTU 1492 packet size with applications that send IP 1500 byte packets. There is a very slight performance increase though due to the extra 8 bytes of payload being carried in an IP packet or TCP+IP packet, 1500/1492
-
May I ask someone who is using the MTU=1508 whether you can really get better performance or what's the benefit(s) ?
Tia.
Packet sizes can be 0.005% bigger.
Not something you're going to notice in real time.
-
If you can get IP MTU 1500 + 8 = 1508 then you might as well have it, no danger of any incompatibility with remote apps (just theoretical as I said) and there is less than zero cost provided the overheads you have do not push you above 32 cells ie 1536 bytes in total, which is the limit of 32 ATM cell payloads * 48 bytes capacity per cell = 1536. Do if you have say 36 bytes overhead and 1500 bytes of IP then you are fine. More than 36 bytes of overhead and you need to reduce IP MTU to say 1492 to get the total eg 1492 + overhead below 1536.
In my case the overhead for PPPoEoA including PPP and the AAL5 CPCS is 32, so 32 + 1500 is not above 1536 so that is fine. The figure PPP + PPPoE + ethernet mac with no FCS + RFC 2684 (para. ‘bridged’, VC-MUX ) + AAL5 CPCS = 2 + 6 + 14 + 2 + 8 = 32. See wikipedia article on PPPoE, section on PPPoEoA overheads, for (what I hope is) a proper explanation.
-
So I have been running an 8324 with the jumbo frames + x1 dsl code for about a week now and am happy to report that it has solved the issue (I'm 99% sure is) related to vectoring. Thinking about making a post detailing that issue, but otherwise, have those that tried it had at least stable lines?
Would be great to find other users with vectoring enabled to confirm, but it seems like very few have it.
-
Would be handy if anyone could work out how to allow multiple telnet instances. Could be another handy feature to add to customized firmware builds.
Earlier versions of Zyxel firmwares allowed this, then Zyxel randomly limited it to 1 session. It means if something like DslStats hangs then the modem effectively locks you out of telnet until the session eventually times out.
I'm looking at you Johnson :P
-
£30 per feature I reckon :wry:
-
So I have been running an 8324 with the jumbo frames + x1 dsl code for about a week now and am happy to report that it has solved the issue (I'm 99% sure is) related to vectoring. Thinking about making a post detailing that issue, but otherwise, have those that tried it had at least stable lines?
Would be great to find other users with vectoring enabled to confirm, but it seems like very few have it.
Well I've flashed it today and it's better by 0.1 SNR etc and don't ask why but I ended up resynching 8 times and as always there's no sign of DLM.
Also definitely not more errors. We'll see.
-
@spring do you find that you get changes of sync speed between resynchs when you haven’t changed anything? This used to happen for me, but nowadays such changes are really small.
-
Would be handy if anyone could work out how to allow multiple telnet instances. Could be another handy feature to add to customized firmware builds.
Earlier versions of Zyxel firmwares allowed this, then Zyxel randomly limited it to 1 session. It means if something like DslStats hangs then the modem effectively locks you out of telnet until the session eventually times out.
I'm looking at you Johnson :P
So I had a play with what could be changed to allow more than one telnet/ssh session. Unfortunately messing with these firmwares is not much fun as all the important features and settings are hidden inside binaries with no source supplied in the GPL package.
Seems the change to telnet sessions was hardcoded in the telnetd binary as the "A telnet session already exist, cannot creat new telnet session" message is contained within it.
As far as I can tell this seems to be the only change to it since the version which allowed multiple sessions (all the way back with AAJZ.3 from 2014) so I just swapped in that version and it seems to work fine. This is probably both bad and wrong, but given we are using telnet anyway and it seems they have not upgraded it since release, I guess we are not that concerned about its possible security holes.
No joy trying the same approach with ssh sessions, as far as I can tell ssh doesnt even work for me with the AAJZ.03 release. ???
So here are 4 more firmwares with the old telnetd binary to allow multiple sessions:
https://www.dropbox.com/sh/q4y2y2kbhb7mb1i/AAA6C520hnZVD0RtStqvRz_da?dl=0
As per the last link the -oldtelnet.bin just have the jumbo frames patches and old binary, with -3925.bin the updated adsl_phy.bin.
Hope someone finds them useful, but a warning that I have only tried the 1312-B10A version out, so maybe wait until I have tried the 8324, might do it in a minute actually.
-
Many thanks johnson, that is very good of you.
I think £30 per feature is a bit cheap, ought to be more. ;D
-
Nah, its just fun messing with things to make them better.
Flashed the 8324 image to my running box btw, all good and now no more holes in my DSLstats graphs when I forget to close a telnet session!
Its probably a dumb idea as there are several other great stats monitoring methods, but I was looking into how to add slightly better monitoring to the web GUI. Its the same state of affairs as telnet & ssh though, everything hard coded into the httpd binary. No server side scripts to mess with. So would probably need add another small web server, something like libmicrohttpd, but could then serve more detailed things like snr or bitloading. Instantaneous things I guess as logging anything over time is tricky with the tiny amount of memory available.
Does that sound stupid? I feel like it would be quite nice to be able to have a quick look at the bit loading or SNR graph straight from the modem. Its probably harder than it seems and not worth it, but I'l look anyway.
-
Also Weaver, did you get another browser running that works properly with the GUI? Saw theres a nasty minified javascript file in the source that does something to do with "smoothscrolling" that could be the culprit of your safari woes.
-
I tried Chrome but that was just the same, as I expected. Another Kitizen claimed that my opinion was out of date - I had read that all iOS web browsers are based on Webkit code or bits of core code used by Safari or whatever - and claimed that this was no longer the case. But I just don’t know the truth of it. It actually is perhaps not so simple. Regardless of the browser’s code, it could be that there is either capability detection or browser sniffing code in the javascript and maybe it detects one or the other browser but classes them all as one and the same ‘mobile’ nonsense thing and then this triggers broken behaviour.
The issue is one where eg the DSL statistics page is unreadable because part of it goes off the bottom of the screen. Unfortunately I can’t fix by turning Javascript off, not even turning it off selectively + temporarily, as the page in question is then not drawn at all.
-
Sweet!
Zyxel limiting all their devices to 1 telnet session was a real pain.
I'm sure there's a few users still on the 6b1 firmware of the 8923-b10a as that's the last 1 that offered multiple telnet sessions.
This gives them the option to upgrade without losing that functionality.
Cheers Johnson!
-
I'm sure there's a few users still on the 6b1 firmware of the 8923-b10a as that's the last 1 that offered multiple telnet sessions.
I went back through them, but the latest available from the zyxel ftp folder without the silly telnet restriction was AAJZ.5C0, AAJZ.6C1 had it.
But like I say, if you compare the binaries (clumsily with 'strings') the only real change seems to be adding the "feature" of 1 session allowed. So dont think we're missing out on anything with the older version.
-
I tried Chrome but that was just the same, as I expected. Another Kitizen claimed that my opinion was out of date - I had read that all iOS web browsers are based on Webkit code or bits of core code used by Safari or whatever - and claimed that this was no longer the case. But I just don’t know the truth of it. It actually is perhaps not so simple. Regardless of the browser’s code, it could be that there is either capability detection or browser sniffing code in the javascript and maybe it detects one or the other browser but classes them all as one and the same ‘mobile’ nonsense thing and then this triggers broken behaviour.
The issue is one where eg the DSL statistics page is unreadable because part of it goes off the bottom of the screen. Unfortunately I can’t fix by turning Javascript off, not even turning it off selectively + temporarily, as the page in question is then not drawn at all.
Yeah without js it will not even be able to fetch the data for the stats page.
I had a go using the chrome debugger deleting all references to "overflow" which is I believe the style option that adds scroll bars, in the vain hope it would just move the buttons to the bottom of a long page, but all I ended up with was a broken mess.
Wish I could have proper go at fixing it but as I cant replicated it on any of my android devices it would just be stabbing in the dark.
-
The page cannot be dragged to make it scroll. It moves upwards so far and then twangs back down again, as I may have said before. Sometimes you can see a tiny bit more content that is visible further down the window (ie in the -y direction) below the bar containing icons when you manage to pull the whole lot upwards for a second or so.
-
@spring do you find that you get changes of sync speed between resynchs when you haven’t changed anything? This used to happen for me, but nowadays such changes are really small.
Never had any change in sync speeds, and for DLM to kick in from resyncs it might be 15-20 times or more. Or maybe it only cares about the conditions while running and not syncs/desyncs [maybe failure of syncing though], so could it do unlimited resyncs per day? good chance for that, but seems for others here that can resync 1-5 times per day making it 10 would be sufficient improvement.
I tried Chrome but that was just the same, as I expected. Another Kitizen claimed that my opinion was out of date - I had read that all iOS web browsers are based on Webkit code or bits of core code used by Safari or whatever - and claimed that this was no longer the case. But I just don’t know the truth of it. It actually is perhaps not so simple. Regardless of the browser’s code, it could be that there is either capability detection or browser sniffing code in the javascript and maybe it detects one or the other browser but classes them all as one and the same ‘mobile’ nonsense thing and then this triggers broken behaviour.
The issue is one where eg the DSL statistics page is unreadable because part of it goes off the bottom of the screen. Unfortunately I can’t fix by turning Javascript off, not even turning it off selectively + temporarily, as the page in question is then not drawn at all.
sounds like mobile things, you can try firefox in the store https://itunes.apple.com/app/apple-store/id989804926 and if not then you know you need a laptop. Or theres a way to work around it with browser addons or settings, for customization Firefox is better than Chrome.
-
See other thread. Sorry for OT! ;D
-
firmware with newer dsl driver seems fine so except the possible kernel incompatibility that I haven't yet encountered, it should be more stable/faster for "everyone" (" ")
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 35190 Kbps, Downstream rate = 109337 Kbps
Bearer: 0, Upstream rate = 3455 Kbps, Downstream rate = 44880 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 25.1 19.6
Attn(dB): 10.7 0.0
Pwr(dBm): -14.9 -15.1
VDSL2 framing
Bearer 0
MSGc: -6 432
B: 235 17
M: 1 1
T: 0 1
R: 14 16
S: 0.0000 0.1569
L: 11951 1734
D: 1 55
I: 250 34
N: 250 34
Q: 8 0
V: 1 0
RxQueue: 34 0
TxQueue: 17 0
G.INP Framing: 18 0
G.INP lookback: 17 0
RRC bits: 0 24
Bearer 1
MSGc: 90 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 10.6667 0.0000
L: 24 0
D: 1 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 164638
OHFErr: 0 0
RS: 1357205088 2248649
RSCorr: 410 1639
RSUnCorr: 0 0
Bearer 1
OHF: 59702287 0
OHFErr: 0 0
RS: 358213354 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 713203 0
rtx_c: 143 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 44859 0
errFreeBits: 656161700 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1161853343 0
Data Cells: 515193186 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
AS: 959130
Bearer 0
INP: 44.00 2.00
INPRein: 0.00 0.00
delay: 0 2
PER: 0.00 17.24
OR: 0.01 203.20
AgR: 44951.38 3657.71
Bearer 1
INP: 2.50 0.00
INPRein: 2.50 0.00
delay: 0 0
PER: 16.06 0.01
OR: 47.81 0.01
AgR: 47.81 0.01
Bitswap: 126/126 0/0
Total time = 11 days 2 hours 25 min 56 sec
FEC: 410 1639
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 10 min 56 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 2 hours 25 min 56 sec
FEC: 14 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 30 29
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 11 days 2 hours 25 min 29 sec
FEC: 410 1639
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
>
adsl info --pbParams
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 35190 Kbps, Downstream rate = 109337 Kbps
Bearer: 0, Upstream rate = 3455 Kbps, Downstream rate = 44880 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Discovery Phase (Initial) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (33,857) (1218,1959) (2795,4083)
Medley Phase (Final) Band Plan
US: (6,31) (882,1193) (1984,2770)
DS: (41,857) (1218,1959) (2795,4083)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 35190 kbps 109337 kbps
Actual Aggregate Tx Power: - 15.1 dBm - 14.9 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.1 10.1 15.1 N/A N/A 6.3 12.7 20.6
Signal Attenuation(dB): 0.1 10.0 14.9 N/A N/A 6.3 12.6 20.6
SNR Margin(dB): 24.4 20.1 19.3 N/A N/A 25.1 25.1 25.1
TX Power(dBm): -17.7 -19.1 -27.8 N/A N/A 12.3 8.1 6.8
>
Stats recorded 14 Jun 2018 17:24:28
DSLAM type / SW version: IFTN:0xb206 (178.6) / v0xb206
Modem/router firmware: AnnexA version - A2pv6F039x1.d26a
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 11 days 2 hours 25 min 30 sec
Resyncs: 0 (since 14 Jun 2018 17:19:22)
Downstream Upstream
Line attenuation (dB): 10.7 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 44880 3455
SNR margin (dB): 25.1 19.6
Power (dBm): -14.9 -15.1
Interleave depth: 1 55
INP: 44.00 2.00
G.INP: Enabled Not enabled
Vectoring status: 5 (VECT_UNCONFIGURED)
RSCorr/RS (%): 0.0000 0.0729
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 0 0
-
firmware with newer dsl driver seems fine so except the possible kernel incompatibility that I haven't yet encountered, it should be more stable/faster for "everyone" (" ")
Slightly lower downstream sync on my line.
I'm sure Weaver had the same results.
I've reverted back to the adsl_phy.bin that came with the 1312-b10a firmware.
I'm happy enough with 1508 MTU and multiple telnet sessions.
I'm not touching the modem at the moment as I have a new crosstalker that knocked nearly 5Mb off my downstream attainable and 0.5Mb off the upstream.
I'll try keep the line synced as long as possible.
Running at 1dB SNR on the downstream, the target is 3dB.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 7613 Kbps, Downstream rate = 46022 Kbps
Bearer: 0, Upstream rate = 8070 Kbps, Downstream rate = 51405 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 1.0 4.0
Attn(dB): 24.5 0.0
Pwr(dBm): 13.3 3.1
>
-
I missed something - why did you go back to the earlier version of the low-level driver?
-
Slightly lower downstream sync on my line.
I'm sure Weaver had the same results.
I agree, slightly lower downstream for me too, but since it fixes my crazy vectoring related half speed after a none reboot resync, I'm sticking with it for now.
It may just be the slightly lower sync, but I have experienced a good deal less errors with it than the much older adsl_phy I was using previously.
I'l maintain that if you dont experience any obvious benefit its probably best to stick with the one normally included.
-
Ah - maybe that explains where some of my speed went then? That would clear up a big mystery - see t’other thread. Any idea how big the effect might be?
-
Its possible Weaver, but from earlier in the thread you noted only a 25kbps drop:
No speed improvement with G.992.3 and my very long line, in fact downstream sync is 25kbps slower and upstream is 3kbps slower. I did a second resync, speeds were unchanged. A 1% downstream change like this hardly means much of course.
-
Apologies, I didn't notice the word ‘upstream’. I was lamenting over my loss of downstream speed after switching to the ZyXELs, so disregard my earlier comment.
As for upstream, I have not noted any further loss of upstream speed during my time with the ZyXELs, but the upstream speed of the ZyXEL modems is worse than that of my earlier DLinks.
-
I missed something - why did you go back to the earlier version of the low-level driver?
It performed better.
It's the adsl_phy.bin that matches the accompanying kernel driver.
It's a fairly common thing that users will swap the dsl driver on Broadcom modems.
Unless you see a noticeable benefit or it fixes a specific issue (like Johnson's Vectoring issue) then I wouldn't recommend changing the dsl driver.
-
j0hn, was it faster? Noticeably so? Is that downstream or both ? Sorry to be so full of questions but that might explain one or two mysteries.
-
Doesnt help much but I can easily make firmwares with any of the available adsl_phys. I believe there are 4-5 around that should work with these modems.
Was even thinking about a nice way to change between them in one firmware, using a slightly modified adsldd.ko module and storing the adsl_phys in ram after boot... but I guess it would be something very few people would use.
-
What differences might I see if I go back to the earlier release, with only the jumbo 1508 mod ?
-
What differences might I see if I go back to the earlier release, with only the jumbo 1508 mod ?
I know you want an answer from j0hn, but if I may - very little. I think comparing performance on your ADSL line to VDSL is pretty apples to oranges, its easy to get half to whole mbit differences between syncs with nothing changed on our noisy VDSL lines, so while I have experienced maybe 500kbps lower with the x1 adsl_phy I'm not sure what that would translate to on your line.
If you want to go fishing with the various different BLOBs (heh, thats fun to type) then by all means, the most I have ever had my VMG1312 sync at was with the version 7 firmware from 2015, it was really unstable on my line and caused DLM intervention after going on a resync spree 3 nights in a row. Maybe that wouldnt happen on your ADSL line, I'm happy to make a firmware with it in if you'd like to try.
But if you are up for tweaking then dropping your SNRM by 1db would probably provide much more pleasing results. I mean look at j0hn's connection, 3db target but down to 1db and going strong. With the ability you have to control this being on ADSL it would be the first place I went if I was trying to eek out more speed... ;D
-
I would like to try those firmwares johnson. Some poeple don't benefit the tendency for less errors like j0hn & get lower speed & already are at their lowest target db [1db in this case], but to me it seems like most people do benefit less errors & half didn't get a significant speed drop.
Because of the kernel incompatibility that j0hn emphasied, it's definitely worth trying to make a firmware with the last DSL driver compatible with d26a.
What differences might I see if I go back to the earlier release, with only the jumbo 1508 mod ?
You've been on it...
-
Can one tweak SNRM with these devices? If so, what are the magic incantations? And is there any way of making it persistent?
-
> xdslctl --help
Usage: xdslctl start [--up] <configure command options>
xdslctl stop
xdslctl connection [--up] [--down] [--loopback] [--reverb]
[--medley] [--noretrain] [--L3] [--diagmode] [--L0]
[--tones <r1-r2,r3-r4,...>] [--normal] [--freezeReverb] [--freezeMedley]
xdslctl configure/configure1 [--mod <a|d|l|t|2|p|e|m|M3|M5|v>] [--lpair <(i)nner|(o)uter>]
[--trellis <on|off>] [--snr <snrQ4>] [--bitswap <on|off>] [--sesdrop <on|off>]
[--sra <on|off>] [--CoMinMgn <on|off>] [--i24k <on|off>] [--phyReXmt <0xBitMap-UsDs>]
[--Ginp <0xBitMap-UsDs>] [--TpsTc <0xBitMap-AvPvAaPa>] [--monitorTone <on|off>]
[--profile <0x00 - 0xFF>|<"8a |8b |8c |8d |12a |12b |17a |30a">] [--us0 <on|off>]
[--dynamicD <on|off>] [--dynamicF <on|off>] [--SOS <on|off>] [--maxDataRate <maxDsDataRateKbps maxUsDataRateKbps maxAggrDataRateKbps>]
[--forceJ43 <on|off>] [--toggleJ43B43 <on|off>]
xdslctl bert [--start <#seconds>] [--stop] [--show]
xdslctl afelb [--time <sec>] [--tones] [--signal <1/2/8>]
xdslctl qlnmntr [--time <sec>] [--freq <msec>]
xdslctl inm [--start <INMIATO> <INMIATS><INMCC><INM_INPEQ_MODE><INM_INPEQ_FORMAT>] [--show]
xdslctl snrclamp [--shape <shapeId>] [--bpshape [bpIndex-bpLevel,]]
xdslctl nlnm [--show ] [--setThld <Thld_Num_Tones>]
xdslctl diag [--logstart <nBytes>] [--logpause] [--logstop] [--loguntilbufferfull <nBytes>] [--loguntilretrain <nBytes>] [--dumpBuf <sizeKb>]
xdslctl ntr [--start [output freq(default is 8000)]] [--stop]
xdslctl info [--state] [--show] [--stats] [--SNR] [--QLN] [--Hlog] [--Hlin] [--HlinS] [--Bits]
[--pbParams] [--linediag] [--linediag1] [--reset] [--vendor] [--cfg] [--webstats]
xdslctl profile [--show] [--save] [--restore]
xdslctl --version
xdslctl --help
>
I would suggest something like --
xdslctl configure --snr <value>
-
I've heard Broadcom chips can't tweak target margin on VDSL. So you can't do it from the modem, rather on the ISP end.
-
I believe you can, its something on long the lines of xdslctl configure --snr X, but let me get back to you after a bit of a read.
https://wiki.kitz.co.uk/index.php/Broadcom_CLI#adsl_command
I think this still holds true on these devices, but some experimentation is probably required.
The adventurous might try:
xdslctl configure --snr 80
for an approx 1db reduction. But as I say some further reading is in order if you are up for trying it out.
Edit: persistence is another matter, but if it works for you maybe there is a way of making it stick with some scripts baked into the firmware
-
https://forum.kitz.co.uk/index.php/topic,21632.msg373790.html#msg373790
I also read it on Google after that. If someone still wants to try it then it's his decision.
-
Weavers line is ADSL spring, it should work.
-
Oh, well, right, my bad, I mentioned it's VDSL though.
Also, I think it's because of how frustrated I was about this fact, as I have a Broadcom, and ECI cannot set a target margin either, so stuck on 6dB.
-
DslStats has a page with SNR tweaks for ADSL.
You can adjust the SNR offset up or down in 0.1dB increments.
Never used them myself but DslStats is built for Broadcom devices so should work for Weaver.
-
Some users would definitely find that excellent ‘baked-in script’ (baked in :-) ? ) or built-in or whatever to be a very very useful feature? That is such a good idea.
I am already on 3dB downstream target so I am probably asking for instability based on experience with the DLink modems, which used to droop to 1.5dB or even 0.6-0.8dB long-term. I do have, we think, the Broadcom equivalent of ADSL2 G.INP although they call it "PhyR" (ie PhyRTx) iirc. So that could mean I might be able to push it harder without huge trouble. But a loss in performance due to many PhyR retransmissions might cancel out the modest speed gains obtained from higher sync rate.
What would you recommend. Should I roll back to your first firmware release? The one with just the jumbo 1508 MTU mod in it?
(I need a system of version numbers to talk about your excellent custom releases. Internally I have named the image files with something like an xxx-CSW-v01 suffix so I can keep them organised and refer to them somehow.)
-
Oh, well, right, my bad, I mentioned it's VDSL though.
Also, I think it's because of how frustrated I was about this fact, as I have a Broadcom, and ECI cannot set a target margin either, so stuck on 6dB.
Just to clarify, in case some people here aren't aware, although it's not a modem with a Broadcom chipset... the Lantiq/Infineon chipset offers the ability to change the downstream SNRM offset in 0.1 dB increments on VDSL2 and ADSL connections as well (where Broadcom chipset doesn't seem to do the same for VDSL2 connections). That is also assuming the connection isn't capped/banded and running at the maximum allowed speed.
Depending on what modem you're using which has a Lantiq/Infineon chipset, perhaps the ECI /r, something like the following should work:
dsl_cpe_pipe.sh locs 0 50
dsl_cpe_pipe.sh acs 2
This would effectively bump the downstream target SNRM up by +5 dB and cause the connection to re-sync with that change. The '50' value can be changed to another value between -50 to 50, in increments of 1 (effectively 0.1 dB). A setting of -30 for example would be -3 dB, so if you normally sync with a target SNRM of 9 dB then this would decrease it to around 6 dB for the downstream.
DrayTek routers usually offer this option as well, since they have a Lantiq/Infineon chipset, however it's done differently... such as:
vdsl snr -30
This setting should also be retained between reboots which is nice, if it's not then just do 'vdsl savecfg' to be absolutely sure.
-
Should I go back to the earlier VMG 1312-B10A custom firmware (with unchanged low-level driver) ?
-
New firmware for VMG1312-B10A, 1.00(AAJZ.16)C0
-
Again not sure if I'm responding when you'd prefer input from others with more experience, but, if its not that much trouble, why not try it out of one of your 3 modems and gauge the difference? With your saved xml configs even if the flash takes out your settings (which it doesn't for me) you can try one modem with the original adsl_phy with minimal effort and see what difference it makes.
To complicate matters I just made a firmware with the much older A2pv6F039o1 adsl_phy.bin from the AAJZ.7 firmware I was talking about previously. It has only the jumbo frames patches, no reverted telnetd bin for multiple sessions as I thought that might complicate things.
I've tested it to boot, but nothing further.
https://www.dropbox.com/sh/lijl9krbghcpc2c/AAAlzU2b8mtbZ0k2shjVJpINa?dl=0
Sorry for probably needlessly confusing things, just thought I'd offer the older one like I said I would.
-
New firmware for VMG1312-B10A, 1.00(AAJZ.16)C0
Good spot!
As far as I can tell from the patch notes these are the only two changes:
1.
There are compatibility problems in IE 8 when web encryption, so remove two enhance
.
(1).
Revert “Hide Authentication password when editing SIP Account in GUI.”
(2).
Revert “Implement web POST encryption”
......
1.
Security patch
Device security fix on debugging web pages access without authentication.
So IE8 compatibility and something to do with unauthenticated webpage access.
-
Ah so probably not worth it to update...
-
@Weaver further info about AAJZ.7: https://forum.kitz.co.uk/index.php/topic,21273.msg372297.html#msg372297
-
Good spot Hushcoden, but I am currently at 1.4db ds and 79999 sync so probably not worth the reboot as I will lose about 5mbits. Still have downloaded the 16 firmware ready to install.
-
I got a very slight speed reduction with the .7 release - d/s sync 2858 -> 2847 but I did not leave it switched off for 30 mins which I should perhaps have done and this could just be DLM randomness.
-
Thanks for that Spring, I got lost there!
-
I'll try the jumbo frame firmware with original modem code again and see if it does better than the modified with latest version x1, that I've been on for 3 weeks [there's x3, but it's a fix for Intel CO's with FW version 12.3.8 in G993.2]. I have to do this instead of comparing with previous stats as it was fine for the first week then it got worse, could just be my line.
Edit: So far the error rates in 4 hours with original aka v, are as much as 7 days with x1. Going to go back. There is higher SNR, but too many errors. Also dropped my WAN connection after 4 hours (?).
Edit2: Seems to have sorted itself & is perfectly fine now. I'll leave it for a few days to be conclusive.
-
I'll try the jumbo frame firmware with original modem code again and see if it does better than the modified with latest version x1, that I've been on for 3 weeks [there's x3, but it's a fix for Intel CO's with FW version 12.3.8 in G993.2]. I have to do this instead of comparing with previous stats as it was fine for the first week then it got worse, could just be my line.
Edit: So far the error rates in 4 hours with original aka v, are as much as 7 days with x1. Going to go back. There is higher SNR, but too many errors. Also dropped my WAN connection after 4 hours (?).
Edit2: Seems to have sorted itself & is perfectly fine now. I'll leave it for a few days to be conclusive.
Thats valuable information spring, thanks for trying it out.
So are you saying after trying the v version you went back to the x1, or did the v version sort itself out?
-
Yeah the ZyXEL AAJZ.14 with just jumbo frames, by you [original adsl_phy.bin] is doing alright for this hour.
Before I changed firmware I did "adsl connection --down" & after uploading let it restart into a sync. Maybe due to not waiting [the line fit the mold of x1 after 3 weeks, and took a few hours for v to stabilize. plausible].
Edit: First time this happend, the modem rebooted itself; but the jumbo-frame FW I've used before was of Olipro. I'm going to flash to Olipro's. That is, assuming it's not my configuration file made for jumbo+3925 that I also use on the jumbo-only. I rule out electricity because it didn't come on and off, rather a lengthy reboot. To clarify, I used re-opened DSLStats a lot today so it might be this modem, too, has reboot issues. But I'm doing this to verify. Other than that v is running just fine, need more time & another switch back to x1 to know if it's better or worse. Right now things are better but time is needed to draw relations.
Edit2: Towards the end of the tones v has a better looking SNR graph than x1, but up until mid tones x1 is better. Also, notice the drop with v in multiple spots at tone 800. So, I rather not evaluate which is better. I plan switching to x1 again to confirm.
Edit3: I think I'll leave it on v, for some reason there are fewer errors & unless there is an increase I'll remain on it. Before that v didn't do as good as now [as good as x1 did], and x1 also did better than v in the first week after switching to it, before gradually getting worse. Absolutely no idea why it's like this. But when x1 worked well, like in its first week or two, it did better than the prime of v. I'll use v for another couple of days, and decide if to try x1 again.
-------------- x1 --------------
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 35190 kbps 109686 kbps
Actual Aggregate Tx Power: - 15.1 dBm - 14.9 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.1 10.1 15.1 N/A N/A 6.3 12.7 20.6
Signal Attenuation(dB): 0.1 10.0 14.9 N/A N/A 6.3 12.6 20.6
SNR Margin(dB): 24.4 20.2 19.2 N/A N/A 25.2 25.3 25.3
TX Power(dBm): -17.7 -19.1 -27.8 N/A N/A 12.3 8.1 6.8
-------------- v --------------
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 34969 kbps 110052 kbps
Actual Aggregate Tx Power: - 15.2 dBm - 15.0 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.1 10.1 15.2 N/A N/A 6.1 12.8 20.6
Signal Attenuation(dB): 0.1 10.0 15.0 N/A N/A 6.0 12.6 20.6
SNR Margin(dB): 24.2 20.1 18.8 N/A N/A 25.4 25.4 25.4
TX Power(dBm): -17.8 -19.3 -28.3 N/A N/A 12.3 8.0 6.7
-
Thank you for the detailed info spring.
Those graphs make me sad though, does the ISP in your area have a monopoly? Its criminal that you are capped like that given the attainable.
-
Yes ;)
Either DSL or cable which is worse & has the same upload [200/6]
------------- V ------------
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 35126 kbps 109951 kbps
Actual Aggregate Tx Power: - 15.2 dBm - 15.0 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.1 10.1 15.2 N/A N/A 6.1 12.8 20.6
Signal Attenuation(dB): 0.1 10.0 15.0 N/A N/A 6.0 12.6 20.6
SNR Margin(dB): 24.3 20.2 19.1 N/A N/A 25.4 25.4 25.4
TX Power(dBm): -17.8 -19.3 -28.3 N/A N/A 12.3 8.0 6.7
Seems v has been fixing itself. :D
Note up until now, I have just a generic dsl cable & generic microfilters, no ferrites, so not the ideal setup but I don't think it matters.
I think I've learned enough to say that because switching modem code can lead to endless adjustments to the line, the more time it's tested, the more is known about it. first day I experienced one disconnection & higher than normal errors in the first 4 hours - then up until second day many SNR graph changes & normal errors, third day started to look exactly how it did in my previous use of it. so i'd say 3 days [of course, if it's performing badly as soon as a sync & on the 2nd day as well, it's not going to improve. if someone has DLM, the first day or 12 hours should be the deadline as according to my experience only the first 4 hours were the "transition period"]. it may require one manual resync if it performed better for the first week then had a decline, for confirmation [should be at least as stable as the previous modem code].
Also note this is on VDSL and not ADSL [can be vastly different].
Edit: Olipro's loads pages much faster, I don't know if it's related to using it, but it does.
Edit2: Drops at tone 800 with v came back, but this likely means x1's big and only problems at the last few tones weren't a coincidence either.
Edit3: I think v had enough time and is indeed doing better than x1 but I'm flashing back to x1 to confirm.
Edit4: Alright so first off, it wasn't Olipro's being faster; Johnson's is just as fast. Second, x1 exhibits its classic graph: https://i.imgur.com/msesn2P.png . I will manually open DSLStats to snapshot every 12 hours to follow up.
Edit5: https://i.imgur.com/liJdWwY.png
Edit6: https://i.imgur.com/hmcIQHG.png
Edit7: https://i.imgur.com/4KLoxlS.png
Edit8: https://i.imgur.com/2qGKNYj.png
Edit9: https://i.imgur.com/9eyR3Z8.png
Edit10: https://imgur.com/a/cGqcvhh
I'll continue testing it as it seems to have "calmed" a bit.
Latest 1 day time = 8 hours 35 min 43 sec
FEC: 8 44
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 35 329
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
Dear Sir
The below link is V.100(AAJZ.16)C0 open source code for VMG1312-B10A.
Please get the open source code from following link:
https://www.dropbox.com/sh/h0lbhuua35zn2na/AABXME58sEFhJRKkprd_0iF-a?dl=0
Note: This open source code link would be expired on July 2 2018.
Thanks a lot.
-
Could you also attach Hlog and QLN?
-
HLog/QLN are calculated at sync, and the previous sync was of V not x1
I don't recommend x1 at all (for someone with DLM, if not then sure have fun with probably the same results I'm getting) I'm just doing this for testing xd
Upstream bitloading is the same, missing much, and you can compare it with V, however I'm sure the next time I sync it would be fixed; at least, first time I've noticed x1 to sync with missing bits.
https://imgur.com/a/xsJ6DEu
Uptime: 4 days 14 hours 28 min 36 sec
Latest 1 day time = 14 hours 27 min 2 sec
FEC: 26 36
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 33 141
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Counters
Bearer 0
OHF: 0 689296
OHFErr: 0 0
RS: 877665088 1319125
RSCorr: 180 816
RSUnCorr: 0 0
Bearer 1
OHF: 24756357 0
OHFErr: 0 0
RS: 148537775 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 758878 0
rtx_c: 65 0
rtx_uc: 0 0
G.INP Counters
LEFTRS: 0 0
minEFTR: 44859 0
errFreeBits: 272086287 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 4255361864 0
Data Cells: 208225146 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 35509 kbps 109648 kbps
Actual Aggregate Tx Power: - 15.0 dBm - 14.8 dBm
====================================================================================
VDSL Band Status U0 U1 U2 U3 U4 D1 D2 D3
Line Attenuation(dB): 0.1 10.1 15.2 N/A N/A 6.4 12.8 20.7
Signal Attenuation(dB): 0.1 10.0 15.0 N/A N/A 6.3 12.7 20.7
SNR Margin(dB): 23.5 19.4 19.0 N/A N/A 25.3 25.3 25.3
TX Power(dBm): -17.7 -18.9 -27.3 N/A N/A 12.3 8.0 6.8
Edit: I think the thing is now, if it can run a month stable [v ran stable "forever"], if it can't I'll flag it as not worth anyone's time xD
It's capable of performing better than V [at least on par] but the problem was the small gain on the good days wasn't worth the devastating days. 50 FEC on DS/US per day is V. x1's best is 30.
-
Thanks for the reminder j0hn, link was in my spam folder.
So here are 2 builds from the latest AAJZ.16 version for the VMG1312-B10A, the differences to last version are minor so no real need to upgrade if you dont feel like it. Just a version with the jumbo frames patches and another with the old telnetd binary if you enjoy having more than one telnet session open at a time, no updated dsl_phy as it seemed it only benefited me and caused more confusion than good.
Both tested to boot, but not on a line yet.
https://www.dropbox.com/sh/c5no9h8ckyp2i4i/AADwAR6oVbzwFjtE-bLdy81Za?dl=0
-
Great job! Any chance of the VMG8924-B10A versions too please ;D
Thanks :)
-
I have not put in a request yet for the 8924/8324 version, but the 1312 one took a while after the release so it will probably be similar.
Edit: request submitted, will get back as soon as I have the new source
-
Firmwares for 8924/8324 based off the new AAKL.24:
https://www.dropbox.com/sh/4xfif7ssq8pdq6u/AAChWy_N8UIVmpqQizmI2CUra?dl=0
Again 2, one just jumbo patches and another for multiple telnet sessions.
Both tested to boot but not on a line.
I should add this to every post, but please flash at your own risk. Have seen from other posts that unlike the 1312 a serial console is essential to recover from a bad flash on the 8924/8324. If your device is mission critical and you have no spare modems, flash with extreme caution.
Have a nice sunny saturday!
-
Many thanks! :)
-
My DGA4132 is playing up. I find it a bit of a chore to administer, so was thinking of getting a VMG1312-B10A to run in bridging modem mode hopefully with MTU 1508.
I am on VDSL 450M from Huwaei cabinet my line is syncing at 67 DS and 8 US…..
Anyway after wading through this forum I am somewhat confused.
1. Is the Core VGM1312-B10A firmware for MTU1508 firmware: https://github.com/Olipro/VMG1312-B10A/releases and is this is based on the first ZyXel firmware 1 with the oldest Broadcom driver? Am I able to telnet it via Putty/WinSCP?
2. @Spring Where is the link to the V firmware that you speaks of and recommends please?? And which Broadcom driver is in this firmware in relation to the official Zyxel driver?
@Johnson I recall you mentioned Zxyel firmware 7 having the highest sync rate, have you built a custom mashup of this firmware as yet form MTU1508? If so I wouldn’t mind giving it a try.
Again huge thanks to all of you who contribute to this forum (those who ask and those that answer) and to the wider Kitz community.
-
A VMG1312-B10A will probably serve you well, but I wouldn't expect any large increase in sync over the DGA4132.
1. The first firmware in the wild that supported 1508 MTU on the 1312 was from Olipro, he figured out the magic words that needed to be added to a Makefile and 1 other source file in the Zyxel supplied firmware build package. Would be really cool if he showed up here in fact, sure lots of people would have kind words. This version you linked is based on the last but one release of the stock firmware and it by all means perfectly suitable for flashing and use. All I have done is apply the same patches he has to newer versions of the firmware from Zyxel, some messing with binaries related to the dsl driver and changing the telnet version to allow multiple sessions. Olipros version has fully functional telnet and ssh, the changes I have made since are just to allow multiple concurrent telnet sessions.
2. The "V" version of the adsl_phy.bin has been the default in all builds of the 1312 (and 8324/8924) firmware for many release versions now, the latest versions I have posted and will link again here use it.
3. I did make a firmware with the "O" version of the adsl_phy.bin for someone to experiment with, but for them at least it offered no benefit, you are free to try it yourself and I will link it too.
My advice since people have tried the newer "X1" adsl_phy as well as the older "O" version is to stick to the normal "V" one that Zyxel ship with the firmware and is the only that I have used with the latest releases of the firmwares, unless you have a BDUK area connection with vectoring, then some improvement may be realised from the later adsl_phy.
So:
The latest 1312 images based on V16:
https://www.dropbox.com/sh/c5no9h8ckyp2i4i/AADwAR6oVbzwFjtE-bLdy81Za?dl=0
The weird older adsl_phy one if you wish to experiment:
https://www.dropbox.com/sh/lijl9krbghcpc2c/AAAlzU2b8mtbZ0k2shjVJpINa?dl=0
The later x1 adsl_phy - best used only if you have vectoring:
https://www.dropbox.com/s/84uvih8rex1wyed/1312-B10A-from-zyxel-jumboframes-3925adsl_phy.bin?dl=0
Hope this helps, please ask for clarification if I have been confusing.
Edit: typos
-
A VMG1312-B10A will probably serve you well, but I wouldn't expect any large increase in sync over the DGA4132.
1. The first firmware in the wild that supported 1508 MTU on the 1312 was from Olipro, he figured out the magic words that needed to be added to a Makefile and 1 other source file in the Zyxel supplied firmware build package. Would be really cool if he showed up here in fact, sure lots of people would have kind words. This version you linked is based on the last but one release of the stock firmware and it by all means perfectly suitable for flashing and use. All I have done is apply the same patches he has to newer versions of the firmware from Zyxel, some messing with binaries related to the dsl driver and changing the telnet version to allow multiple sessions. Olipros version has fully functional telnet and ssh, the changes I have made since are just to allow multiple concurrent telnet sessions.
2. The "V" version of the adsl_phy.bin has been the default in all builds of the 1312 (and 8324/8924) firmware for many release versions now, the latest versions I have posted and will link again here use it.
3. I did make a firmware with the "O" version of the adsl_phy.bin for someone to experiment with, but for them at least it offered no benefit, you are free to try it yourself and I will link it too.
My advice since people have tried the newer "X1" adsl_phy as well as the older "O" version is to stick to the normal "V" one that Zyxel ship with the firmware and is the only that I have used with the latest releases of the firmwares, unless you have a BDUK area connection with vectoring, then some improvement may be realised from the later adsl_phy.
So:
The latest 1312 images based on V16:
https://www.dropbox.com/sh/c5no9h8ckyp2i4i/AADwAR6oVbzwFjtE-bLdy81Za?dl=0
The weird older adsl_phy one if you wish to experiment:
https://www.dropbox.com/sh/lijl9krbghcpc2c/AAAlzU2b8mtbZ0k2shjVJpINa?dl=0
The later x1 adsl_phy - best used only if you have vectoring:
https://www.dropbox.com/s/84uvih8rex1wyed/1312-B10A-from-zyxel-jumboframes-3925adsl_phy.bin?dl=0
Hope this helps, please ask for clarification if I have been confusing.
Edit: typos
Thanks Johnson!
First things first I cannot seem to be able to find G.INP value on my modem GUI stats page (in the DGA4312) however it does say PATH: Fast.... would this indicate G.INP is indeed enabled??
-
Given a Huawei cab and broadcom chipset with a sync that isn't maxing out the 80/20 cap its improbable that you don't have G.INP enabled.
Are you running the DGA4132 with the stock firmware? I admit my ignorance, but isnt the long thread about the DGA4130 in this section of forum home to a nice custom firmware that shows lots of stats? I havent been keeping up with it.
Can you not telnet or ssh into the router and issue commands like "xdslctl info --stats"?
-
I had to telnet in to my DGA4130 to see full stats. I assume the 4132 will be similar.
Either that or setup DslStats (which automates the stats collecting for you).
-
Ok I got DslStats running and G.INP is enabled down stream...
How can I tell if I'm in a BDUK area? For ISP, I am with an ENTAnet through a reseller...
-
Theres a map if you scroll down a little here:
https://www.gov.uk/guidance/broadband-delivery-uk
-
My DGA4132 is playing up. I find it a bit of a chore to administer, so was thinking of getting a VMG1312-B10A to run in bridging modem mode hopefully with MTU 1508.
I am on VDSL 450M from Huwaei cabinet my line is syncing at 67 DS and 8 US…..
Anyway after wading through this forum I am somewhat confused.
What issues are you having, mines been rock solid and I find it very easy to use the GUI, also supports 1508 frames?
I tried a Zyxel 1310-B10A, which syc'd at a slightly lower rate, the 4132 also gave me a few less errors and a higher 14.5 U/L Snr, rather than ~10 on the Zyxel.
First things first I cannot seem to be able to find G.INP value on my modem GUI stats page (in the DGA4312) however it does say PATH: Fast.... would this indicate G.INP is indeed enabled??
I'm running the latest Ansuel GUI 8.6.4 and G.INP info is under Diagnostics\xDSL but you have to click '+ show advanced' at the top right to see the extra stats info, then you can scroll further down to see those extra stats.
I'm also now running the latest 1.1.2.004 firmware with no issues.
-
Thank you very much to everyone for the posts above which are really helpful and interesting.
I'm running on a FireBrick 2900 with two HG612 modems and bonded AAISP Soho::1 lines. Baby jumbo frames. Huawei FTTC cabinet. Everything works fine. :)
However, I'd like to swap out the modems. I understand the Broadcom BCM63138 chipset is best (being based on a much faster ARM core rather than MIPS) but the modems which I can see which use it (Netgear D7000, Technicolor DGA4130, Asus DSL-AC87VG, Billion 8900AX R2) don't seem to support bridge mode + baby jumbo. So I should fall back on the BCM63168 (Zyxel 3925, 8324 and 8924) or the BCM63381 (which I understand is just the BCM63168 but without VoIP - Zyxel 1312-B10A).
The posts in this thread have talked about firmware for the 8324/8925 and the 1312-B10A.
I can obviously get one of those routers but I was just wondering whether there's any obvious reason why the Olipro baby jumbo patches wouldn't work for the 3925 or the 1312-B10D (being the two modems which are currently sold by AAISP) ? I realise that I'd have to ask Zyxel for the source and then compile my own firmware using a toolchain etc setup in a VM.
(One final thing: the PPP bug in the 1312-B10A has been mentioned. This is the one referred to here:
https://support.aa.net.uk/VMG1312-B10A:_Bugs
"VPNs may not reconnect if PPP drops - until you unplug and replug the LAN-side ethernet cable! We saw this same thing last year with Huawei HG612, which use the same chipset. (ZyXEL HQ are investigating having seen this demonstrated in our offices)"
"PPPoE Session-ID caching bug (In Bridge mode) [...]"
Just to add that unless I've misunderstood there's a FireBrick workaround for this:
https://www.revk.uk/2018/07/very-frustrating-modem-bug.html )
-
Welcome to the Kitz forum. :)
Another happy A&A user, with the latest FB2900 FireBrick!
I can obviously get one of those routers but I was just wondering whether there's any obvious reason why the Olipro baby jumbo patches wouldn't work for the 3925 or the 1312-B10D (being the two modems which are currently sold by AAISP) ?
I can't think of any reason why you could not apply similar patches so, yes, go for it. And let us know how you get on. ;)
-
So I should fall back on the BCM63168 (Zyxel 3925, 8324 and 8924) or the BCM63381 (which I understand is just the BCM63168 but without VoIP - Zyxel 1312-B10A).
The BCM63381 is a budget chipset, which syncs quite a bit lower than the BCM63168 (on VDSL2 anyway).
I've owned a Technicolor DGA4130 with a BCM63138 chipset and it didn't perform as good as the BCM63168 in my Zyxel does.
The Zyxel VMG1312-B10A and VMG8x24-B10A both have additional noise filters that aren't found in other modems and this makes them the 2 favourite devices by many on these forums.
There's no reason why you couldn't use other Zyxel models with the Olipro github patch but I would avoid devices with the BCM63381.
-
Many thanks, burakkucat and j0hn for the replies.
I have a spare VMG3925-B10B lying around and have requested the firmware source from Zyxel. I'll give it a go and will report back if I succeed!
Another happy A&A user, with the latest FB2900 FireBrick!
I've been a happy A&A user since December 2001 when I first took out ADSL from them ("Office 500" - 512kbps; 20:1 contention; £100+VAT per month!).
The Zyxel VMG1312-B10A and VMG8x24-B10A both have additional noise filters that aren't found in other modems and this makes them the 2 favourite devices by many on these forums.
There's no reason why you couldn't use other Zyxel models with the Olipro github patch but I would avoid devices with the BCM63381.
Thanks for the heads up! I hadn't realised that the chipset in the VMG1312-B10A and the VMG1312-B10D are different. As I understand it now:
BCM63168 + extra common mode noise filter:
VMG1312-B10A
VMG3925-B10B
VMG8x24-B10A
BCM63381:
VMG1312-B10D
Looking at:
https://www.zyxel.com/uk/en/products_services/service_provider-dsl_cpe.shtml
all of the above are described as a "VDSL modem/residential gateway" except the VMG8x24-B10A which is described as a "VDSL residential VoIP integrated access device".
-
The VMG8x24-B10A (8324/8924) is only described differently because it has VOIP ports.
Ignoring that addition they are functionally the same devices as the others.
The VMG3925-B10B should be a good choice and previous threads show it performs as good as the 8x24's which were the favorite devices of many members of this forum for some time.
My preference of the VMG1312-B10A is mainly down to its design/shape. It has a very similar design as the OpenReach provided Huawei HG612 which wall mounts great next to the master socket.
The "PPPoE Session-ID caching bug (In Bridge mode)" mentioned on the AAISP pages for the 1312-B10A doesn't only affect that device, but affects many Broadcom devices with the same chipsets (and not just Zyxels).
It's not a bug I've ever come across myself.
Being a Firebrick user you won't have to worry about that anyway :)
-
I have a spare VMG3925-B10B lying around and have requested the firmware source from Zyxel. I'll give it a go and will report back if I succeed!
I cant see any reason why the Olipro patches wont work on the 3925.
Setting up the build environment isnt hard, just follow the instructions that come in the source package. Any questions just ask. If the layout is exactly the same then I can provide a patch file that I use on 1312/8324s, but its probably easier to just go and edit the files yourself using Olipros github as a guide.
-
I setup the Ubuntu VM and compiled the tool chain (rather than using the binary provided by Olipro) and the firmware (for the VMG1312-B10A). it seems to be work but I have no VMG1312-B10A to test with.
I will wait for Zyxel to come back to me with the VMG3925-B10B source.
I've set out my notes below in case it's helpful for anyone else.
==
== Files required
==
Ubuntu 10.04.4 server i386 ISO:
http://old-releases.ubuntu.com/releases/10.04.0/ubuntu-10.04-server-i386.iso
==
Zyxel VMG1312-B10A source with Olipro baby jumbo patches:
https://github.com/Olipro/VMG1312-B10A
==
MIPS tool chain source:
https://www.downloads.netgear.com/files/GPL/DGN2200v3_V1.1.00.25_WW_20150526.zip
The MIPs cross compiler source file - uclibc-crosstools-gcc-4.4.2-1-full.tar.bz2 - is inside DGN2200v3_V1.1.00.25_WW_20150526.zip.
==
The six source files required for building the tool chain (which I have taken from - hopefully - "safe" locations):
https://uclibc.org/downloads/old-releases/uClibc-0.9.29.tar.bz2
https://ftp.openbsd.org/pub/OpenBSD/distfiles/binutils/binutils-2.20.tar.bz2
http://www.nic.funet.fi/index/SlackWare/slackware-12.2/source/d/gdb/gdb-6.8.tar.bz2
https://mirrors.edge.kernel.org/pub/linux/kernel/v2.6/linux-2.6.30.tar.bz2
https://www.mpfr.org/mpfr-2.4.1/mpfr-2.4.1.tar.bz2
https://www.mpfr.org/mpfr-2.4.1/patches
(once downloaded, this needs to be renamed to mpfr-2.4.1.patch)
==
== Building
==
Install Ubuntu-10.04.4-server-i386.iso
I allocated 10G of hard disk space for the VM
After building tool chain and firmware, 62.9% of 9.15GB was used
Edit /etc/apt/sources.list
Replace all "gb.archive" with "old-releases"
Replace all "security.ubuntu" with "old-releases"
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install <list of packages kept back> (force install of packages with new dependencies)
sudo apt-get autoremove
sudo apt-get install gcc
sudo apt-get install libncurses-dev
sudo apt-get install bison
sudo apt-get install texinfo
sudo apt-get install flex
sudo apt-get install g++
sudo apt-get install gawk
sudo apt-get install autoconf
sudo apt-get install zlib1g-dev
sudo apt-get install libcurses-ocaml-dev
sudo apt-get install gettext
sudo apt-get install unzip
Transfer the following files to the Ubuntu VM:
uclibc-crosstools-gcc-4.4.2-1-full.tar.bz2
the six files required for building tool chain
the Olipro git repository files
== ( build tool chain )
sudo bash
mkdir /opt/toolchains
Unpack uclibc-crosstools-gcc_source-4.4.2-1.tar.bz2 in /usr/src
cd /usr/src/buildroot-4.4.2-1
make distclean
make menuconfig
Follow step 6 in
https://community.netgear.com/t5/DSL-Modems-Routers/Compiling-the-toolchain-for-the-DGND3700v2/m-p/1073898
(except that "Tool chain and header file location" should be
"/opt/toolchains/uclibc-crosstools-gcc-4.4.2-1"
and not
"/opt/toolchains/uclibc-crosstools-gcc-4.4.2-1-with-ftw")
mkdir –p output/dl
cd output/dl
Copy in the six files required for building tool chain
cd ../..
make
exit sudo
== ( build Zyxel firmware )
"sudo dpkg-reconfigure dash and say NO (switches /bin/sh to /bin/bash)"
sudo ln -s /opt/toolchains/uclibc-crosstools-gcc-4.4.2-1-with-ftw /opt/toolchains/uclibc-crosstools-gcc-4.4.2-1
(this is not required if the change to step 6 above is followed)
Unpack the Olipro git repository files into a temp directory
cd to the temp directory
make PROFILE=VMG1312-B10A
"You can flash images/ras.bin straight to your device from the device’s Web UI."
-
zyxel give you everything you need to build the firmware.
Then for the broken sources simply edit /etc/apt/sources.list and change archive.ubuntu.com and security.ubuntu.com to old-releases.ubuntu.com.
no need to look for a single package anywhere.
edit: to add, that's on a completely fresh install of Ubuntu 10.04
There are clear instructions earlier in the thread. I think anyone attempting to follow your guide is making a lot of work for themselves.
-
zyxel give you everything you need to build the firmware.
I'm not sure because I don't have what Zyxel provide (but I hopefully will in a day or so!) but as I seem to make out, I think Olipro added the tool chain binaries (the MIPS cross compiler). That's why he wrote in the README file:
Toolchain binaries are not provided for distribution, they are purely here "unintentionally". You can get the source for it off ZyXeL anyway if you want it or I'll go bug them for sources - for a fee.
So it's a case of either (i) using the tool chain binaries as provided by Olipro or (ii) compiling from source (my instructions above). Maybe I'm just a bit paranoid :) but I prefer to compile from source code if I can.
-
Indeed, though its admirable you have put one together yourself, the source package comes with everything you need. I would also be hesitant to flash what comes out of your self rolled chain if I didn't have a usb to serial converter at hand to debrick, just in case.
What Olipro means is he is redistributing what zyxel gave him.
Edit: For fun if you throw the VMG1312 firmware you have compiled up on dropbox or similar I will flash it, have one on the desk right now.
-
@jhm welcome jhm - I am another Firebrick FB2700 and FB2500, four-way IP-bonded AA user. I use ZyXEL VMG 1312-B10A modems with user johnson’s MTU 1508 modified firmware.
By some good fortune I have not bumped into the packet accelerator caching bug. It must be due to my particular usage pattern.
-
Ah, if I'd not misunderstood and realised that Zyxel provide the tool chain binaries, I would not have spent a good part of today working on this! :D
Edit: For fun if you throw the VMG1312 firmware you have compiled up on dropbox or similar I will flash it, have one on the desk right now.
Thank you! Here you go:
https://www.dropbox.com/s/i0zgs2yp5gd06l9/ras.bin
but as you say, I hope you have a USB to serial converter handy just in case...
-
Flashed and it boots just fine :clap:
Obviously have not tried it on a line, but it has all the MTUs set as expected.
-
Excellent - that's a relief! ;D
I will wait for the VMG3925-B10B firmware from Zyxel so that I can try the same on my box then.
-
They are usually pretty prompt about responding, should have it by tomorrow evening.
I dont know how much you have messed with your VMG3925, but last time I spoke to someone with one they had to gain the supervisor password in order to get DSLStats working with it, the top thread over in the Modem Unlocking section has a fairly comprehensive guide, does involve cracking a hash which isnt much fun without a GPU.
-
@jhm welcome jhm - I am another Firebrick FB2700 and FB2500, four-way IP-bonded AA user. I use ZyXEL VMG 1312-B10A modems with user johnson’s MTU 1508 modified firmware.
By some good fortune I have not bumped into the packet accelerator caching bug. It must be due to my particular usage pattern.
Thank you, weaver. Do you mean that you bond the four lines using two FireBricks at your end ? Or one at your end and the other at A&A (although I thought this configuration is only required if you're bonding lines from more than one ISP) ?
From what I read, I think the packet accelerator caching bug affects mainly (or only ?) those running VPNs.
-
I dont know how much you have messed with your VMG3925, but last time I spoke to someone with one they had to gain the supervisor password in order to get DSLStats working with it, the top thread over in the Modem Unlocking section has a fairly comprehensive guide, does involve cracking a hash which isnt much fun without a GPU.
I haven't touched my VMG3925 since receiving it from A&A as a freebie when I signed up for a 12-month contract with them on my second line. I have A&A on my main line and was with BT on the second line - both using a HG612.
If the VMG3925 with new firmware works in bridge mode with baby jumbo frames, I'll get another one and replace the two HG612s.
In relation to the supervisor password and without looking into it yet, I wonder if it's possible to just fix this in the firmware rather than cracking the hash ? I see this in the VMG1312 firmware:
VMG1312-B10A/targets/fs.src/etc/profile: echo
"supervisor:3Gnc.CJE1790M:0:0:Administrator:/:/bin/sh" > /var/passwd
This is what presumably gives you the fixed supervisor password on the VMG1312 so I wonder if it's possible to make a change to the firmware of the VMG3925 to do something like this.
-
Thats a good shout, but the reason special measures are required to obtain the supervisor password on the 3925 is a firmware change to obfuscate it. On the 1312s and 8324/8924s its given up in plain text by issuing a "dumpmdm" command.
Not to say there isnt a similarly simple target area in the 3925, just maybe it resides somewhere else in this modems source.
-
Newer Zyxels don't have the dumpmdm command and the Supervisor pass isn't available without cracking the hash.
It's not a method that's used for the fun of it :P
-
In relation to the supervisor password and without looking into it yet, I wonder if it's possible to just fix this in the firmware rather than cracking the hash ? I see this in the VMG1312 firmware:
VMG1312-B10A/targets/fs.src/etc/profile: echo
"supervisor:3Gnc.CJE1790M:0:0:Administrator:/:/bin/sh" > /var/passwd
This is what presumably gives you the fixed supervisor password on the VMG1312 so I wonder if it's possible to make a change to the firmware of the VMG3925 to do something like this.
Look a little closer and you will see that is only an initial set-up of the "passwd" file with a descrypt() encrypted string. Further manipulation then takes place.
Now, if what you imply is true, someone who knows their descrypt() from many years ago would recognise "3G" as the salt and "nc.CJE1790M" as the perturbation resulting from an operation with a string of length no more than eight characters. ;)
-
Look a little closer and you will see that is only an initial set-up of the "passwd" file with a descrypt() encrypted string. Further manipulation then takes place.
Ah, but couldn't I add something in the bootup script(s) run as root to zap the passwd file each time ? :)
Now, if what you imply is true, someone who knows their descrypt() from many years ago would recognise "3G" as the salt and "nc.CJE1790M" as the perturbation resulting from an operation with a string of length no more than eight characters. ;)
That reminds me of the days when 56-bit DES was US export restricted. :D
-
Yes, I remember it well. ;)
For amusement, here is a quick and dirty piece of C source code --
#define _XOPEN_SOURCE
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
/* Link with -lcrypt. */
int main()
{
char *key = "zyad1234";
char *salt = "3G";
printf("crypt(%s, %s) returns %s\n", key, salt, crypt(key, salt));
printf("supervisor:3Gnc.CJE1790M:0:0:Administrator:/:/bin/sh\n");
exit(EXIT_SUCCESS);
}
Compiled and executed it returns --
crypt(zyad1234, 3G) returns 3Gnc.CJE1790M
supervisor:3Gnc.CJE1790M:0:0:Administrator:/:/bin/sh
Confirming what, I believe, you already know. :D
-
Confirming what, I believe, you already know. :D
Very good. ;D
I will take a look at the 3925 source when I get it from Zyxel. :)
-
All ZyXEL CPEs (initially) have a supervisor password of "zyad1234". Subsequent manipulation transforms it into a 8-character string (taken from the set of lower-case hexadecimal digits).
I believe that if one quotes the device serial number (or is it the MAC?) to ZyXEL, they are able to provide the supervisor password. I'm quite sure it is not a case of a look-up in a very big list -- just a software transformation. So that is a nice project for someone . . . :-X
-
@jhm - sorry, my post was rather misleading. I have an FB2500 which acts as a standby / backup against lightning damage. (The FB2500 was indeed called in from retirement to report for duty a while ago when a port on my FB2700 got zapped. Then AA simply gave me a free, newFB2700 as a replacement, so I didn’t even need to claim on insurance. Even restarted the clock on the warranty I think, iirc. Incredible.)
I have four modems going into a small ZyXEL switch acting as a VLAN MUX/de-MUX, the MUX being needed because there are not enough free ports on the Firebrick. Distinct VLAN tag numbers are associated with each line, which The Brick understands.
-
@weaver - a free FB2700 as a replacement is great service! With my FB2900, I only got a free cuddly dragon (https://www.amazon.co.uk/FireBrick-Ignis-Cuddly-dragon-30cm/dp/B07GL15J5X/). :D I have a similar setup as yours but with only two lines - HG612s (to be replaced with VMG3925-B10Bs) to a Zyxel switch and then a FB2900 and some MikroTik WAPs around the house.
Back OT: it took two days but I now have the firmware source from Zyxel for the VMG3925-B10B. Time to have a look what's inside...
-
Back OT: it took two days but I now have the firmware source from Zyxel for the VMG3925-B10B. Time to have a look what's inside...
OK - thanks to my brother, the VMG3925-B10B is working now with baby jumbo frames in bridge mode with the latest firmware V5.13(AAVF.11)C0 (which has Broadcom firmware version A2pv6F039x1).
The build process and the jumbo patch required for the VMG3925-B10B firmware is different from the VMG1312-B10D build process and the Olipro jumbo patch.
Zyxel supplied firmware source (request here (https://www.zyxel.com/form/gpl_oss_software_notice.shtml)) with baby jumbo frames enabled:
https://github.com/trejan/VMG3925-B10B
Changes to the two files (README.md and bcmsdk-416L05-AAVF-config-3.4):
https://github.com/trejan/VMG3925-B10B/commit/1b41dc24b9e382dd8e12d5367dec229ab0d82e22
Compiled firmware image with baby jumbo frames in bridge mode:
https://github.com/trejan/VMG3925-B10B/releases
The Zyxel supplied firmware image (w/o baby jumbo frames in bridge mode) in case you want to restore:
ftp://ftp.zyxel.com//VMG3925-B10B/firmware/VMG3925-B10B_5.13(AAVF.11)C0.zip
It works fine here but obviously use at your own risk etc.
-
I got 3 Mbps (so far at least) more out of my line by switching from the HG612 to the VMG3925-B10B. :)
I have another VMG3925-B10B on the way to replace the HG612 remaining on the other line of the bonded pair. That other modem will be used for some digging around to see if the supervisor password can be recovered/set without cracking the hash...
-
That other modem will be used for some digging around to see if the supervisor password can be recovered/set without cracking the hash...
A new version of the VMG3925-B10B firmware is now up on:
https://github.com/trejan/VMG3925-B10B
This contains (i) the jumbo frames patch; and (ii) a mechanism to sync the admin user password to supervisor + root.
The supervisor and root passwords are reset every startup by a big closed source Zyxel shared library (/lib/private/libzcfg_be.so) that handles all of the initialisation and configuration tasks in this router. The library calculates a new root + supervisor password based on the serial number or MAC address with an unknown algorithm. There is now a cronjob that will sync the admin user password to the root + supervisor accounts every minute. Don't try to directly change the root or supervisor account passwords as they will get overwritten.
-
Awesome work jhm (and brother)!
Is there any reason you are running the password copy script in a cron job that often? Does the zyxel management stuff generate the supervisor password other times than at boot?
-
Is there any reason you are running the password copy script in a cron job that often? Does the zyxel management stuff generate the supervisor password other times than at boot?
I think it's only generated at boot by the Zyxel binary. The only reason for having the cron job run every minute is in case the admin password is changed by the user so that it can be synced across to supervisor and root within a minute (rather than requiring a reboot of the modem).
-
Ah, good point!
-
BCM63168 + extra common mode noise filter:
VMG1312-B10A
VMG3925-B10B
VMG8x24-B10A
BCM63381:
VMG1312-B10D
https://forum.kitz.co.uk/index.php/topic,18246.msg383403.html#msg383403
I'm not convinced the VMG3925-B10B has the filter as you mentioned. I assume you got that info from the AA page?
-
I'm not convinced the VMG3925-B10B has the filter as you mentioned. I assume you got that info from the AA page?
Yes, and noted the questions you've raised on this in the other thread on here and on TBB. Thank you - I will be keen to hear!
-
I flashed the VMG1312 firmware from GitHub on my modem and 1500 MTU isn't working :(
-
Need more details.
Is it being used as a bridge modem or full modem router?
If being used as a bridge modem please login to the Zyxel via telnet and run
ifconfig
and post the results here
-
Thanks for the quick response. It's in bridge mode.
bcmsw Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Base address:0xda00
br0 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::6bf:6dff:feaf:5d00/64 Scope:Link
UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1508 Metric:1
RX packets:2605 errors:0 dropped:0 overruns:0 frame:0
TX packets:2773 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:255798 (249.8 KiB) TX bytes:1959116 (1.8 MiB)
eth0 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
inet6 addr: fe80::6bf:6dff:feaf:5d00/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:43518 errors:0 dropped:0 overruns:0 frame:0
TX packets:84514 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8066813 (7.6 MiB) TX bytes:101613799 (96.9 MiB)
eth0.0 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
inet6 addr: fe80::6bf:6dff:feaf:5d00/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:43178 errors:0 dropped:0 overruns:0 frame:0
TX packets:83776 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8973718 (8.5 MiB) TX bytes:100310619 (95.6 MiB)
eth1 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
UP BROADCAST MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth1.0 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
inet6 addr: fe80::6bf:6dff:feaf:5d00/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:121 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:28422 (27.7 KiB)
eth2 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
UP BROADCAST MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth2.0 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
inet6 addr: fe80::6bf:6dff:feaf:5d00/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:28174 (27.5 KiB)
eth3 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
UP BROADCAST MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth3.0 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
inet6 addr: fe80::6bf:6dff:feaf:5d00/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:2048 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:114 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:27790 (27.1 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:134 errors:0 dropped:0 overruns:0 frame:0
TX packets:134 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:8208 (8.0 KiB) TX bytes:8208 (8.0 KiB)
ptm0 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
inet6 addr: fe80::6bf:6dff:feaf:5d00/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1508 Metric:1
RX packets:87958 errors:0 dropped:0 overruns:0 frame:0
TX packets:39340 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:95165230 (90.7 MiB) TX bytes:8447363 (8.0 MiB)
ptm0.1 Link encap:Ethernet HWaddr 04:BF:6D:AF:5D:00
UP BROADCAST RUNNING MULTICAST MTU:1508 Metric:1
RX packets:68683 errors:0 dropped:0 overruns:0 frame:0
TX packets:35488 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:82295699 (78.4 MiB) TX bytes:7730846 (7.3 MiB)
-
It worked.
Just the router to look at.
What model is the router? Does it definitely support RFC4638 ?
Does it allow you to set 1500 MTU or only 1492?
What's the ISP?
-
It's a TP-LINK Archer C7 running OpenWrt. I've set the MTU to 1508 in the web interface.
The ISP is BT.
-
Test it here:
http://www.letmecheck.it/mtu-test.php
-
Not Found
The requested URL /mtu-test.php was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
-
Not Found
The requested URL /mtu-test.php was not found on this server.
Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
That's very odd. ???
http://www.letmecheck.it/my-ip.php works for me.
-
I'm on BT, it must be a BT issue with accessing that site.
Regardless.
ping -D -s 1472 www.bbc.co.uk
PING gtmlivelive-eu-c-1nlbwwwcouk-17e0f31403454351.elb.eu-central-1.amazonaws.com (3.120.156.170): 1472 data bytes
556 bytes from 192.168.1.1: frag needed and DF set (MTU 1492)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 dc05 dd69 0 0000 40 01 f586 192.168.1.102 3.120.156.170
Request timeout for icmp_seq 0
556 bytes from 192.168.1.1: frag needed and DF set (MTU 1492)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 dc05 6093 0 0000 40 01 725d 192.168.1.102 3.120.156.170
Request timeout for icmp_seq 1
556 bytes from 192.168.1.1: frag needed and DF set (MTU 1492)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 dc05 8dd9 0 0000 40 01 4517 192.168.1.102 3.120.156.170
-
You need to disable ipv6 temporarily to use
http://www.letmecheck.it/my-ip.php
Technically the MTU is 1500, that's what I set in my router.
It's 1492 without this patch.
Perhaps Open-WRT want it set as 1508 I've no experience with that.
edit: should have asked earlier, can you run "ifconfig" on the router also and post the results.
-
I flashed the VMG1312 firmware from GitHub on my modem and 1500 MTU isn't working :(
It's a TP-LINK Archer C7 running OpenWrt. I've set the MTU to 1508 in the web interface.
If your router uses a switch with vlans for the wan and lan interfaces you need to set the root interface to 1508 then set it back to 1500 for the lan interface that inherits from it. See:
https://forum.archive.openwrt.org/viewtopic.php?id=51326
I have a BTHH5A and an x86 machine running openWRT which only required 1508 set in the web interface and a tp-link wdr3600 that needed the main switch set to 1508 then the subsequent 'lan' interface set back to 1500.
Have a look at your /etc/config/network file and if the interfaces for wan and lan have the form eth0.1 eth0.2 or similar then this should do the trick.
-
A new version of the VMG3925-B10B firmware is now up on:
https://github.com/trejan/VMG3925-B10B
This contains (i) the jumbo frames patch; and (ii) a mechanism to sync the admin user password to supervisor + root.
The above now updated to the latest firmware - V5.13(AAVF.12)C0 - with the following:
Bootbase version : V1.63 | 05/25/2018 17:40:14
Firmware version : V5.13(AAVF.12)C0
Kernel version: 3.4.11
DSL mode code version: A2pv6F039x6
DSL driver version: d26s
WLAN code version: 7.14.164.20.cpe4.16L05.0-kdb
3G WWAN package version: 1.18
-
Inspired by some PMs with snadge about getting full 1500 MTU on these devices when used as a router I have found a few things out after putting an 8324 on my line as a full router with stock firmware.
The commands required with unmodified firmware are as follows:
ifconfig ptm0 mtu 1508
ifconfig ptm0.1 mtu 1508
This will cause the ppp session to break, timeout and reconnect. The process takes 2.5 – 3 minutes and you will lose internet connectivity but not sync.
After the new ppp session is created it must be changed:
ifconfig ppp2.1 mtu 1500
At least with my testing (many times) this always resulted in successful 1500 byte pings. One caveat is that when quickly changing between them it is sometimes required to disable and re-enable your networking adapter to get accurate results with the ping test (on linux at least).
This leads me to the conclusion that even if using the devices as routers the modified firmware is desirable as no drop and wait for reconnect of the ppp session is required. Of the two modifications one is to bring up all the ptm interfaces with 1508 MTU by default, so only the instant “ifconfig ppp2.1 mtu 1500” is required, which is what I believe spring was talking about all along.
Given this single command that causes no loss of session or sync is all thats required with the baby jumbo frames patches applied I thought I would make a firmware with the most basic of scripts to check the current MTU and change if required:
#!/bin/bash
waitTime=60
interface="/sys/devices/virtual/net/ppp2.1/mtu"
sleep 50
while [ 1 ]
do
if [ -f $interface ]
then
currentMtu=`cat $interface`
if [ $currentMtu -eq 1492 ]
then
echo 1500 > $interface
fi
fi
sleep $waitTime
done
Just tests the if the interface exists and if so checks for 1492 and changes to 1500. Couldnt be simpler.
I would have liked to change the ppp negotiation so it comes up at 1500 be default but after a decent amount of trying could not. I tried changing the GUI so 1500 was accepted and changing all references to the 1492 limit in the pppd program to no avail. I suspect (as always) that one of the closed source binarys supplied that takes the value from the web interface and supplies it to the pppd program/commits it to config has its own checks that default to 1492.
So, for anyone running an 8924/8324 as a full router (can make one for 1312s but doubt people are using them in this way) this firmware has the jumbo frames patches and the script above running from boot:
https://www.dropbox.com/s/b7b5gwzwteysk9t/8924-B10A-AAKL24-router1500.bin?dl=0
Have flashed to my 8324, connected to a line and it works as intended, but as always you are flashing at your own risk.
Any questions please ask! :)
-
Very clever. Great work!
;)
-
Having tried this FW for Johnson I got some strange results.
I found that my connection worked on SOME websites, Kitz being one that doesn't work, this was with a windows MTU of 1500, I did ping 1742 tests and they worked also, TELNET access to the router is no longer possible? even though it was accessible shortly after the fw swap.
WINDOWS MTU VALUE:
1492 = working websites / Speedtest = 73Mbit / ping test 1472 = FAIL
1500 = partially working websites / Speedtest = 21Mbit / ping test 1472 = PASS
Iam at a loss as to why telnet access no longer works? or why the above settings give me the results they do
current windows MTU is 1492 as it only works properly with that and this is speedguides test results:
MTU = 1492
MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput.
MSS = 1452
MSS is optimized for PPPoE DSL broadband. If not, consider raising your MTU value.
Default TCP Receive Window (RWIN) = 262656
RWIN Scaling (RFC1323) = 8 bits (scale factor: 2^8=256)
Unscaled TCP Receive Window = 1026
In Windows 10, unless "TCP/IP Auto-Tuning" is disabled, only the Current TCP Window is displayed. Use the latest TCP Optimizer for tweaking.
You seem to be using Google Chrome. Note that Chrome can modify the TCP Window for sockets it creates under some OSes, and therefore servers may not get your OS-assigned RWIN value. FAQ
RWIN is not multiple of MSS. If your OS supports setting RWIN directly, consider changing it to a multiple of MSS for optimum performance.
Other RWIN values that might work well with your current MTU/MSS:
63888 (up to 2 Mbit lines, depending on latency. MSS * 44)
127776 (1-5 Mbit lines, depending on latency. MSS * 44 * 2)
255552 (2-15 Mbit lines, depending on latency. MSS * 44 * 2^2)
511104 (10-30 Mbit lines, depending on latency. MSS * 44 * 2^3)
1022208 (30-100 Mbit lines depending on latency. MSS * 44 * 2^4)
bandwidth * delay product (Note this is not a speed test):
Your current TCP Window limits you to: 10506 kbps (1313 KBytes/s) @ 200ms latency
Your current TCP Window limits you to: 4202 kbps (525 KBytes/s) @ 500ms latency
MTU Discovery (RFC1191) = ON
Time to live left = 48 hops
TTL value is ok.
Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 00000010 (2)
Precedence (priority) = 000 (routine)
Delay = 0 (normal delay)
Throughput = 0 (normal throughput)
Reliability = 0 (normal reliability)
Cost = 1 (low cost)
Check bit = 0 (correct, 8th checking bit must be zero)
DSCP (DiffServ) = CS0 000000 (0) - class 0, default traffic (RFC 2474).
-
Any reason you're tweaking the MTU value in Windows?
-
I guess I can only suggest you revert to a previous firmware.
I am running the posted one currently on an 8324 and have full telnet access and 1472 pings working from linux and windows PCs.
The only change from stock are the jumbo frames patches which numerous people have used and the inclusion of that script.
The script does nothing to interfere with telnet. You have mentioned in PMs questions about setting your NIC to jumbo frames "2,3,4,5,6,7,8 or 9 KB MTU..?" Also you are changing windows MTU value manually? Modern OSs do not require intervention for such values, you are more likely to set something wrong than improve things changing them.
-
@ johnson
Am I right in thinking that the most up-to-date dsl driver is included in that firmware you've provided for the BJFs? And is it the general opinion of other knowledgeable people that it is the most stable driver available, more so than the d24j version, for example?
The reason I ask is that having started (once-upon-a-time) with a Huawei HG612 and then cycled through a ZyXEL VMG1312-B10A, a Billion BiPAC 8800NL (v1) and a ZyXEL VMG3925-B10B, I've gone back to the HG612 as the other modem/routers haven't appeared to play well with my line and the HG612 appears to be quite settled with regard to downstream ES and hasn't yet thrown a fit.
See, I've been wondering if someone with The Knowledge would be able to take Asbokid's firmware for the HG612 and swap out the dsl driver within that firmware for the latest dsl driver contained within Johnson's BJF firmware for the ZyXELs. If you all get my drift of course. Has that been thought of before or would no one be that bothered since the consenus appears to be that the HG612 is inferior to the ZyXEls?
(Of course, it could be that the latest dsl driver in the ZyXELs is the source of my problems and the d24j is much better suited to my line. ;))
-
The driver version makes absolutely zero difference.
The only noticeable change anyone noted trying it was Johnson fixing a vectoring issue on his own line.
The HG612 dsl driver is for a different chipset so won't work on these devices.
-
Ah, right, a non-starter then... :)
-
Ah, right, a non-starter then... :)
Indeed, as j0hn says the newer adsl_phy (half the modem code) had not been shown to produce any improvement except in my weird edge case, and the HG612s driver is very much incompatible with these chipsets.
If you have tried a 3925 that has the very latest adsl_phy and accompanying kernel module I have seen in the wild for a BCM63168 device.
If the HG612 is producing the most stable line for you there is no reason to stop using it. :)
-
i got telnet working, sodding firewall decided to block that port >:(
I still get the same results so have reverted firmware
Johnso, what was your windows MTU setting?
-
I would hazard a guess from his comment that he hasn't changed anything and he's using the default settings.
As am i and it works perfectly.
If you can revert any changes you have made or reset the settings to default if possible.
-
I would hazard a guess from his comment that he hasn't changed anything and he's using the default settings.
As am i and it works perfectly.
If you can revert any changes you have made or reset the settings to default if possible.
Initially I didn't make any changes.. my windows MTU was 1492 (to match the setting in the router) so when I changed FW I changed the windows MTU back to 1500 and those are the results I got... doesn't work for me? unless MTU in windows is set at 1492 and when I do that the 1472 tests fail which tell me its not functioning as it should
this FW is specific to 8x24, Im guessing the FW you will be using is the one for bridged setups
-
Initially I didn't make any changes..
so when I changed FW I changed the windows MTU back to 1500
Very confused :-\
If you didn't make any changes what did you change back?
You don't ever need to touch any MTU settings in Windows.
Setting it on the router is enough.
I'm really not familiar with tweaking MTU settings on Windows so I'm not entirely sure what has been changed and what needs restored.
I would start off by going to Settings > Network & Internet > Network Reset.
this FW is specific to 8x24, Im guessing the FW you will be using is the one for bridged setups
You still shouldn't be touching the Windows MTU settings, bridged or not.
I've just downloaded the firmware above and will load it on to my 8924 in a couple hours and try it on my line in modem/router mode.
-
ok I will try and explain better,
so when i first got the 8924 a few months ago and found its forcing an MTU of 1492 I changed the windows MTU setting to match that... it worked with 1500 or 1492 in windows, I left it at 1492 as it matches the router MTU and therefore packet fragmentation (more overhead) would not occur. When using Johnsons 8x24 1500MTU firmware, it works fine with a windows MTU of 1492 but not with 1500 on my setup.
I have read that (dependant on NIC and router specs and configs) the MTU value for the transport of data (between PC and Router) is determined by the lowest value of the two, this sounds to me, if for e.g. the NIC is set at 1492 and the router at 1500 then the router and windows should decide on using 1492, the problem is some NIC's and routers don't follow standards fully, so it is possible to end up with strange results dependent on hardware and configuration...thats what I read anyway.
will you be running your test from window 10..? I use W10x64Pro and an Atheros Ar8151 NIC (driver 2.1.0.27 - 18/9/17)
Im going to be making the move to Linux soon (dual-boot)..
-
So I tried again this morning with a full from cold reboot of the 8324 still running the router-1500 firmware.
Once you wait the correct amount of time (worst case 60s) from the ppp session coming up 1472 pings work perfectly from windows PCs a linux system and even my android phone.
One new piece of information I found is that if you abruptly close a putty session from a windows machine no efforts are made to log out, the session remains and so no further connections via telnet can be made until that one times out - 5 minutes or so.
Indeed I have not changed the MTU on any of these computers, having a fixed MTU is not desirable. Path MTU discovery works so that your modem/router having a lower that ideal one will be discovered and accounted for, also in the opposite direction, large LAN to LAN transfers between PCs with supporting NICs will go up to the full 9000 byte jumbo frame MTU. There really is no reason to mess with it and I cant help but feel your changes to it may be the cause of your issues.
Do have any other systems to test from?
An android device with a terminal emulator can perform:
ping -M do -s 1472 cloudflare.com
For instance.
-
yeah I will try again in a few days (DLM)... all I changed was the MTU to match the router, I have always practiced this, as soon as I got the 8924 I set windows MTU to 1492, I will try my mobile (Android) in a few days.
my NIC supports something called JUMBO FRAMES and its currently disabled, the options are 'DISABLED' or 'xKB MTU' (where 'x' = a value of 2-9) - is it worth using this feature? if so, which MTU KB value?
also you mention 'MTU Path Discovery' - is this a feature that my NIC & router can use to set the LAN MTU? or is it a feature the router & dslam uses to set the WAN MTU..?
thanks
-
I have always practiced this
Time to stop :-[ ;)
-
... all I changed was the MTU to match the router, I have always practiced this, as soon as I got the 8924 I set windows MTU to 1492, . . .
Isn't there an "auto" setting for the MTU within BGW?
If you were using a Unix or Linux kernel based system, there would be no need to change the MTU of the system's interface from "auto".
-
I gave this firmware a test and larger pings do work but something is amiss with certain websites. Cloud based websites using Amazon for hosting don't appear to work as an example and certain other sites are very slow to load. Verified on both Mac and iPhone and totally rebooted both devices just in case.
I noted that the Speedguide.net TCP analyser correctly identified that 1500 MTU was possible. However http://www.letmecheck.it/mtu-test.php still showed a max MTU of 1492.
-
Thanks for trying it out bkehoe.
I guess there is some other factor I cant test for that is causing issues.
my NIC supports something called JUMBO FRAMES and its currently disabled, the options are 'DISABLED' or 'xKB MTU' (where 'x' = a value of 2-9) - is it worth using this feature? if so, which MTU KB value?
also you mention 'MTU Path Discovery' - is this a feature that my NIC & router can use to set the LAN MTU? or is it a feature the router & dslam uses to set the WAN MTU..?
Do you have some ethernet card "helper" program or something installed supplied by the manufacturer? Excuse me ignorance, but I have never dealt with such programs, as far as I know and have experienced modern OSs manage all settings themselves to be optimum. If it was me I would select 9k jumbo frames as it should manage smaller MTUs automatically, or just uninstall the extra "settings" program.
As far as I understand pMTU works from endpoint to endpoint, so its your PCs OS negotiating the best MTU possible through to the service you are connecting to.
-
You also have to have an isp that supports MTU 1508, and their wholesale carrier if applicable and the phone line link and DSLAM or FTTC must all support it. There are web-based testing tools that will test the link all the way to / from a test server to discover MTU.
-
The commands required with unmodified firmware are as follows:
ifconfig ptm0 mtu 1508
ifconfig ptm0.1 mtu 1508
Sorry to jump back to this particular post. So in theory I can enter these 2 commands on stock firmware to enable baby jumbo frames without having to install any custom firmware? Of course they'll be the requirement to re-enter these commands on modem reboot / re-sync. My Zyxel is in bridge mode so I'll configure the PPPoE MTU settings over on my main router.
-
Unfortunately not. In bridge mode the switch ports on the Zyxel must support > 1500 byte MTU ethernet frames in order to pass PPPoE packets with full 1500 byte payloads. Hence the modification to the drivers Makefile:
EXTRA_CFLAGS += -DCONFIG_BCM_ETH_JUMBO_FRAME
As this change is needed when compiling, a modified firmware is a must when in bridge mode.
If you are comfortable with VMs and basic linux usage the process is fairly painless to build your own image. Request the source package from Zyxel (the have a handy form for it) and you can build a firmware with only trust in them.
-
I forgot to say, in my previous post, that when my isp was using BT 20CN as their wholesale carrier, BT did not support MTU 1500+8=1508, so I got a good modem, got everything set up for IP MTU 1500 and then couldn’t understand why it didn’t work, and was disappointed. And my ISP had failed to point this gotcha out when they were advertising MTU 1500 capabilities.
-
Test it here:
http://www.letmecheck.it/mtu-test.php
That site states I have an MTU of 1494..
Using the VMG1312-B10A .16 firmware with the newer xdsl driver and a fix for 1500 MTU here: https://richard.burtons.org/2017/03/12/mtu-1500-for-bt-adsl-with-openwrt/
-
That site states I have an MTU of 1494..
Using the VMG1312-B10A .16 firmware with the newer xdsl driver and a fix for 1500 MTU here: https://richard.burtons.org/2017/03/12/mtu-1500-for-bt-adsl-with-openwrt/
What router are you using, a WNDR3700 with openwrt on as in the link?
-
What router are you using, a WNDR3700 with openwrt on as in the link?
TP-Link WDR4300 running openwrt 18.06.2
-
TP-Link WDR4300 running openwrt 18.06.2
Do 1472 pings work to cloudflare etc?
If not you can try setting the base ethernet adapter on the router (usually eth0) to 1508 as per:
https://forum.kitz.co.uk/index.php/topic,21273.msg390527.html#msg390527
And test again.
In my experience letmecheck.it is accurate.
-
Isn't there an "auto" setting for the MTU within BGW?
If you were using a Unix or Linux kernel based system, there would be no need to change the MTU of the system's interface from "auto".
Are you sure about that? Both my Fedora boxes show MTU 1500 for all interfaces (with no MTU specified in the network configuration) and if I try to ping a larger size between them I get "ping: local error: Message too long, mtu=1500".
I would be quite interested if I can get path MTU working as it would reduce the CPU load when transferring files between them.
-
Well that's Fedora for you. ;) Six months is a very long time in Fedora-land. :D
-
Well that's Fedora for you. ;) Six months is a very long time in Fedora-land. :D
Fedora is supposed to be the "bleeding edge" of distros so if they don't have it then surely 99% of distros do not?
-
@bkhoe well if letmecheck.it tester says you don’t have a big enough IP PDU MTU (only 1492) then some upstream device is limiting your path and you will just have to stick with that smaller MTU unless you can swap out the system that is the bottleneck.
When I was using BT 20CN ADSL and G.992.1 (https://en.wikipedia.org/wiki/G.992.1) with PPPoEoA I could not get IP MTU 1500 (PPP PDU MTU 1500+8=1508) to work at all. This was even though I had the right modem and had all of the other required bits here. It was because the BT service just refused to handle 1508 byte long PPP frames. So I was just stuck with IP PDU MTU = 1492 like you.
The checklist is router plus modem plus internet link upstream, especially including any internet access carrier service, not forgetting any possible wholesale carrier services such as BT or TalkTalk Wholesale or others, not just your ISP themselves. In fact it will be the wholesale carrier service that matters, if any, not the ISP. Whatever is nearest to you in the chain. See Kitz’s articles on internet access in this site.
-
A new version of the VMG3925-B10B firmware is now up on:
https://github.com/trejan/VMG3925-B10B
This contains (i) the jumbo frames patch; and (ii) a mechanism to sync the admin user password to supervisor + root.
Do you have a pre-compiled binary for this?
-
You also have to have an isp that supports MTU 1508, and their wholesale carrier if applicable and the phone line link and DSLAM or FTTC must all support it. There are web-based testing tools that will test the link all the way to / from a test server to discover MTU.
My ISP (Zen) told me once that RFC4638 is supported on all FTTC connections that use BT's network. Not sure how true that is.
-
Do you have a pre-compiled binary for this?
https://github.com/trejan/VMG3925-B10B/releases
-
https://github.com/trejan/VMG3925-B10B/releases
Thanks, I always seem to gloss over the "releases" link on github.
-
I think it is true. It’s only 20CN THAT has a problem as far as I know, but I couldn’t say for all random LLU systems. I think FTTC is always fine.
-
I think it is true. It’s only 20CN THAT has a problem as far as I know, but I couldn’t say for all random LLU systems. I think FTTC is always fine.
It may have changed but the last time I was on Origin Broadband they didn't support it.
-
The OpenReach NGA network (FTTC/P, G.Fast) supports RFC4638 and I believe it has since launch.
AFAIK digital region did not support RFC4638. So if you were with Origin with Digital Region then that may have been the issue.
-
The OpenReach NGA network (FTTC/P, G.Fast) supports RFC4638 and I believe it has since launch.
AFAIK digital region did not support RFC4638. So if you were with Origin with Digital Region then that may have been the issue.
No this was Origin once they were on BT and had changed networks a few times. I always assumed it was due to their legacy of coming from Digital Region so their kit was never configured for it.
-
A new version of the VMG3925-B10B firmware is now up on:
https://github.com/trejan/VMG3925-B10B
This contains (i) the jumbo frames patch; and (ii) a mechanism to sync the admin user password to supervisor + root.
Wait, so should I be able to login as supervisor with my admin password on the pre-compiled binary image or am I misunderstanding something?
-
Wait, so should I be able to login as supervisor with my admin password on the pre-compiled binary image ...
Yes, exactly!
The supervisor and root passwords are reset every startup by a big closed source Zyxel shared library (/lib/private/libzcfg_be.so) that handles all of the initialisation and configuration tasks in this router. The library calculates a new root + supervisor password based on the serial number or MAC address with an unknown algorithm. There is now a cronjob that will sync the admin user password to the root + supervisor accounts every minute. Don't try to directly change the root or supervisor account passwords as they will get overwritten.
-
Yes, exactly!
Strange, its not working here from telnet, SSH or UI.
Is this applied to both firmware images? I used the latest one with the new UI as I don't intend to use the UI enough for a few bugs to be a problem.
-
Strange, its not working here from telnet, SSH or UI.
I just tried it here on both of mine and they both work - logging in as supervisor (using the admin password) on both the UI and SSH, e.g.
$ ssh supervisor@192.168.1.2
supervisor@192.168.1.2's password:
BusyBox v1.20.1 (2019-01-29 02:40:42 GMT) built-in shell (ash)
Enter 'help' for a list of built-in commands.
$ exit
Connection to 192.168.1.2 closed.
Is this applied to both firmware images? I used the latest one with the new UI as I don't intend to use the UI enough for a few bugs to be a problem.
By both firmware images, do you mean those on the Github releases page - V5.13AAVF.12C0-jumbo.bin and V5.13AAVF.11C0-jumbo.bin? From memory, it's applied to both but definitely it's applied to the most recent one.
-
V5.13AAVF.12C0-jumbo.bin
# ssh supervisor@192.168.10.1
The authenticity of host '192.168.10.1 (192.168.10.1)' can't be established.
RSA key fingerprint is SHA256:DVk0QzNvcY2eXnZVCmtx2oZ0h1tmc0qdeChMmmvH+oI.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.10.1' (RSA) to the list of known hosts.
supervisor@192.168.10.1's password:
Permission denied, please try again.
supervisor@192.168.10.1's password:
Permission denied, please try again.
supervisor@192.168.10.1's password:
supervisor@192.168.10.1: Permission denied (publickey,password).
[root@God ~]# ssh admin@192.168.10.1
admin@192.168.10.1's password:
No entry for terminal type "xterm-256color";
using dumb terminal settings.
ZySH>
-
I don't know what's wrong but:
1 (sorry if this is obvious - just checking) does the new firmware otherwise work, i.e. baby jumbo frames are supported now ?
2 if yes to the above, maybe you can change your admin password, wait two minutes (the cronjob runs every minute) and then try logging in again as admin and supervisor using that password?
-
I don't know what's wrong but:
1 (sorry if this is obvious - just checking) does the new firmware otherwise work, i.e. baby jumbo frames are supported now ?
2 if yes to the above, maybe you can change your admin password, wait two minutes (the cronjob runs every minute) and then try logging in again as admin and supervisor using that password?
1. Yes, baby jumbo works perfectly.
2. You make a good point. I wonder if its glitching because I set the password BEFORE updating the firmware? Will try now.
-
Nope, tried changing it back to the same password then after an hour that didn't work so changed it to something else, still doesn't work. :no:
-
Nope, tried changing it back to the same password then after an hour that didn't work so changed it to something else, still doesn't work. :no:
Hmmm, I'm confused now. I looked at the changes to the stock Zyxel distribution on Github and I can't see (anymore?) the change which syncs the passwords. I will ask my brother (who put it up on Github).
-
Hmmm, I'm confused now. I looked at the changes to the stock Zyxel distribution on Github and I can't see (anymore?) the change which syncs the passwords. I will ask my brother (who put it up on Github).
Any news on this?
-
Can anyone help with the newest jumbo frame firmware for the VMG1312-B10A? Thanks.
-
@gigabitethernet - I can get a copy to you. Direct from our Johnson, the author, would be from the horse’s mouth. Or I could dig backwards through this thread and find the link.
-
This post at an earlier point in the thread (https://forum.kitz.co.uk/index.php/topic,21685.msg384925.html#msg384925) contains the download link. That is the version I am using on all my (many) modems. Rock solid, ignore the reports in posts immediately following as I just made stupid mistakes and failed to install it. It is just superb.
That version has - the MTU 1500+8=1508 feature,
- allows multiple telnet sessions iirc - please check
- has the ‘easy stats’ SNRM graphing feature using a web server in the modem,
- the ‘easy stats’ stats querying protocol where you can read pages of stats over http without login
A new version is under development.
I use all of the features of it all the time as I don’t currently have a suitable machine that can display stats via a telnet-based protocol because of limitations in the tools I use. I am iPad-only these days and I have not learned Python yet, which is probably the way to go for easy casual app development on iPad.
Another opportunity to thank our kitizen and friend Johnson for his outstanding (and continuing) work on this.
-
Can anyone help with the newest jumbo frame firmware for the VMG1312-B10A? Thanks.
If you mean based on the v17 sources then zyxel have not released them yet. Me and j0hn got responses stating June as time it will be released ???.
From trying the v17 and poking around with it the changes are so minimal as to be completely unimportant, particularly if using as a modem not a router (from memory the only significant change was something to do with UPnP).
If you are after the v16 version with just the jumboframes patches I'l point you to this post:
https://forum.kitz.co.uk/index.php/topic,21545.msg381478.html#msg381478
Specifically from the dropbox folder: 1312-B10A-AAJZ16-jumboframes.bin
Hope this helps!
@Weaver
Thanks for the kind words! As you know I should be able to offer a much nicer version than just the SNRM graphing in the linked firmware soon, so I wouldn't recommend anyone using that one unless they are specifically after HTTP based stats retrieval.
I have the orientation and point tapping working btw, I'l PM about testing.
-
If you mean based on the v17 sources then zyxel have not released them yet. Me and j0hn got responses stating June as time it will be released ???.
From trying the v17 and poking around with it the changes are so minimal as to be completely unimportant, particularly if using as a modem not a router (from memory the only significant change was something to do with UPnP).
If you are after the v16 version with just the jumboframes patches I'l point you to this post:
https://forum.kitz.co.uk/index.php/topic,21545.msg381478.html#msg381478
Specifically from the dropbox folder: 1312-B10A-AAJZ16-jumboframes.bin
Hope this helps!
@Weaver
Thanks for the kind words! As you know I should be able to offer a much nicer version than just the SNRM graphing in the linked firmware soon, so I wouldn't recommend anyone using that one unless they are specifically after HTTP based stats retrieval.
I have the orientation and point tapping working btw, I'l PM about testing.
Thanks, I am in a BDUK area with vectoring - can you recommend the best firmware for me?
-
Thanks, I am in a BDUK area with vectoring - can you recommend the best firmware for me?
Funny you should ask that, as I have recently been testing the latest adsl_phy.bin from the VMG3925, version A2pv6F039x6 vs A2pv6F039v.
For me the difference has been night and day. I have vectoring (BDUK) and the second Huawei cab connected to my PCP (serves over 600) went live around a month ago. This coupled with the seasonal change has resulted in hundreds of downstream CRCs a day and several full drops of connection a week.
Since trying the x6 modem code I have had 1 drop in 8 days and 10s of CRCs total. Also I have had upstream G.INP enabled, but I'm sure this is just coincidence as have had it briefly before.
Have not made a public VMG1312-B10A firmware with the x6 code, is there anything specific you would like if you want to try it? Or just the base jumbo frames patches and the new modem binary?
-
Heres a v16 firmware with only the jumbo frames patches and newer A2pv6F039x6 adsl_phy. These are the only changes.
Direct link:
https://www.dropbox.com/s/631264ulfa7pm8h/1312-B10A-AAJZ16-jumboframes-x6.bin?dl=0
Is also available in the main dropbox folder from the previously linked post.
Have flashed to my testing VMG1312, but not put on a line. Your own risk etc etc. ;D
-
@gigabitethernet - referring to the earlier post
https://forum.kitz.co.uk/index.php/topic,21545.msg381478.html#msg381478
see the reference to bin files named ‑x1 which have the later improved low-level DSL driver code in them. The files with that ‑x1 in them are the ones for you.
* Specifically, go for : https://www.dropbox.com/sh/c5no9h8ckyp2i4i/AAD26V-J9eU498dDq8a4U0Kia/1312-B10A-AAJZ16-jumboframes-oldtelnet-customcmds-x1.bin
(which is kept in this folder (https://www.dropbox.com/sh/c5no9h8ckyp2i4i/AADwAR6oVbzwFjtE-bLdy81Za?dl=0&lst=).)
—
[ I’m assuming that that one does not have the lovely internal SNRM graphing web server and ‘easy stats’ over http features too, is that correct? If you would also like this superb but non-essential feature, which I use, then you would need to ask very nicely for a ‑x1 build of it, with all the trimmings.
I use the later version mentioned at
https://forum.kitz.co.uk/index.php/topic,21685.msg384925.html#msg384925
which has the SNRM-graphing internal web server feature, which is superb, but there is no file there containing the build ‑x1 variant, which would be the right one for you. ]
-
Funny you should ask that, as I have recently been testing the latest adsl_phy.bin from the VMG3925, version A2pv6F039x6 vs A2pv6F039v.
For me the difference has been night and day. I have vectoring (BDUK) and the second Huawei cab connected to my PCP (serves over 600) went live around a month ago. This coupled with the seasonal change has resulted in hundreds of downstream CRCs a day and several full drops of connection a week.
Since trying the x6 modem code I have had 1 drop in 8 days and 10s of CRCs total. Also I have had upstream G.INP enabled, but I'm sure this is just coincidence as have had it briefly before.
Have not made a public VMG1312-B10A firmware with the x6 code, is there anything specific you would like if you want to try it? Or just the base jumbo frames patches and the new modem binary?
You're extremely kind doing all of this so first of all many thanks and thanks to Weaver as well.
I don't wish to make life too difficult for you so I would be perfectly content with the jumbo frames and newer modem binary.
The SNRM graphing stuff sounds interesting as well but I will completely understand not including this - I don't wish to give you any more work than is needed, you have already been so helpful.
I feel like something of a specialty, I don't know many who have vectoring on this forum. I remember when it appeared out of nowhere several years ago now. I did not have it initially (I was the first line to go live on my cabinet back in 2015 I think it was - I think I got vectoring sometime in 2016 although I might be wrong).
-
@gigabitethernet - Sorry about that posts crossed over somehow. What a twit. ??? :-[
@johnson - sorry for being a bit slow. Is it true that the only advantages of the newer x6 low level dsl driver code are for VDSL2 users who also have g.vector?
-
I feel like something of a specialty, I don't know many who have vectoring on this forum. I remember when it appeared out of nowhere several years ago now. I did not have it initially (I was the first line to go live on my cabinet back in 2015 I think it was - I think I got vectoring sometime in 2016 although I might be wrong).
Indeed, from my recollection there has only been a handful of people with vectoring talk here. Maybe its testament to its efficacy that people with it have less problems and so seek help less on forums like this.
Would be neat if you could test the x6 firmware linked and report back, from experience vectoring produces unpredictable results. Last person I spoke to here with it ended up using a firmware from years ago just to get a normal sync speed. ???
-
@johnson - sorry for being a bit slow. Is it true that the only advantages of the newer x6 low level dsl driver code are for VDSL2 users who also have g.vector?
As far as I know yes. The last document (from cisco I believe) I found that detailed the changes between versions had very little to say about ADSL, but it may have been tunnel vision on my part.
-
Any idea how hard it would be to patch in the SNRM graphing into the VMG3925-B10B firmware?
I really didn't want to have to compile it myself, but I'd also like to re-enable the administrator passwork sync functionality so it may come to that if the original person who compiled it is too busy.
-
Bit of a weird one this - haven't tried johnson's new firmware yet - but after switching from a Huawei HG612 to the Zyxel VMG1312-B10A, the Internet feels less responsive, like websites take a bit longer to load and sometimes websites freeze a bit (e.g. YouTube).
I am using a TP-LINK Archer C7 running OpenWrt and I haven't changed its setup at all. It worked fine with the HG612.
Does anyone have any ideas?
-
@GigabitEthernet the VMG 1312-B10A modems have performed well for me compared to my previous (DLink) modems, 5-10% improved downstream sometimes but at higher SNRM and greatly improved reliability. Upstream is slightly worse than the DLink modems, which is a nuisance. This is all over ADSL2 though so be warned, your mileage may vary.
-
@GigabitEthernet the VMG 1312-B10A modems have performed well for me compared to my previous (DLink) modems, 5-10% improved downstream sometimes but at higher SNRM and greatly improved reliability. Upstream is slightly worse than the DLink modems, which is a nuisance. This is all over ADSL2 though so be warned, your mileage may vary.
I think you've misunderstood my post.
-
I think I have too. My apologies! ??? :-[
-
No problem, Weaver.
I will flash johnson's newer firmware right away.
The firmware I am currently running - "1312-B10A-from-zyxel-jumboframes-3925adsl_phy" - is very unstable and my modem has dropped twice in 24 hours. The Internet feels less responsive with this firmware and less reliable, than with my Huawei HG612 which would stay up for weeks!
-
Any idea how hard it would be to patch in the SNRM graphing into the VMG3925-B10B firmware?
I really didn't want to have to compile it myself, but I'd also like to re-enable the administrator passwork sync functionality so it may come to that if the original person who compiled it is too busy.
I hope not hard at all, I now have a 3925 to test and will want the graphing working before doing so.
About the copying of admin to supervisor password that was present in that github repo then removed. Copying it over every 60 seconds is certainly an option, but when the tools to crack and change the supervisor password permanently without firmware changes are available, isnt this the best option?
-
The firmware I am currently running - "1312-B10A-from-zyxel-jumboframes-3925adsl_phy" - is very unstable and my modem has dropped twice in 24 hours. The Internet feels less responsive with this firmware and less reliable, than with my Huawei HG612 which would stay up for weeks!
That firmware uses the x1 adsl_phy, so I would be surprised if the x6 one offered improvement, but excited if it did.
Another thing to try would be a much older firmware with different adsl_phy and kernel module. Will look up what the other user I mentioned found to work.
As for the perception of "slower" internet with the zyxel, I can not suggest any reason this would exist. Its possible, but I have no idea what would cause it. Did you ever sort out how to set the ports on your archer correctly under OpenWRT to get 1500 byte MTU?
-
I hope not hard at all, I now have a 3925 to test and will want the graphing working before doing so.
About the copying of admin to supervisor password that was present in that github repo then removed. Copying it over every 60 seconds is certainly an option, but when the tools to crack and change the supervisor password permanently without firmware changes are available, isnt this the best option?
Compared to having it work automatically in the firmware? Not really. Every time I think of sorting it out, I forget exactly where the most recent instructions are on the forum, thus I haven't done it yet. ;)
It only really needs copying over once, at boot, or included in the password changing script so it happens when you change it via the UI. I'd look into it, but I'm really wary of flashing any firmware that someone else hasn't already checked works as I don't have a spare for testing.
-
Firmwares for 8924/8324 based off the new AAKL.24:
https://www.dropbox.com/sh/4xfif7ssq8pdq6u/AAChWy_N8UIVmpqQizmI2CUra?dl=0
Is anyone able to confirm this is the latest/correct location of trusted firmware for Zyxel 8924 B10A with 1500 MTU support when running in bridge mode and multiple telnet sessions? Thanks
-
Is anyone able to confirm this is the latest/correct location of trusted firmware for Zyxel 8924 B10A with 1500 MTU support when running in bridge mode and multiple telnet sessions? Thanks
I built one using AAKL.28 a while ago but never got round to sharing it. It has the jumbo frames patch and nothing else. Not sure what the multiple telnet session fix is, but I didn't bother since I have no use for it.
-
"using AAKL.28 " really? Good news if so, I thought we were still waiting for the sources to be released (6 months was quoted).
Care to share it mate?
-
"using AAKL.28 " really? Good news if so, I thought we were still waiting for the sources to be released (6 months was quoted).
Care to share it mate?
Here you go: https://www.dropbox.com/s/hvy0m087809zphe/VMG8324-B10A_1.00%28AAKL.28%29C0_RFC4638.bin?dl=0
I'm running it right now, so it works but use at your own risk and all that :) This firmware has only been tested/used in bridged mode. In routed mode, YMMV.
This only has the jumbo frames patch, nothing else has been touched.
-
Perfect! Thanks ;D
-
For reference this is the best URL for the AAKL24 version of these firmwares for VMG1312-B10A and VMG8924/8324-B10A it explains what firmware does what.
https://forum.kitz.co.uk/index.php/topic,21545.msg381478.html#msg381478
Does anyone know if there is any real problem these being for AAKL24 instead of the more recent AAKL28?
The ability of multiple telnet sessions, jumbo frames and custom commands is one of the reasons I want to try this firmware.
Thanks
-
Does anyone know if there is any real problem these being for AAKL24 instead of the more recent AAKL28?
Have a look at the change history (listed in the PDF in the firmware archive file) and decide for yourself.
-
hmmm
# ifconfig ptm0 mtu 1508
ifconfig: SIOCSIFMTU: Invalid argument
-
I have so far been unable to load and test this firmware (AAKL28), as I am still in the first week of line training after I moved ISP and DLM was reset...
-
I've made a firmware for the VMG8924-B10A if anyone wants it. Based on the latest 1.00(AAKL.21)C0
http://bit.ly/8x24Jumbo
can you please do one for VMG3925-B10B? thanks.
Ideally based on V5.13(AAVF.7)C0
-
Here are firmwares compiled from zyxel sources, the ...jumboframes.bin ones have only the patches from Olipro's repo and the 3925 ones have the updated A2pv6F039x1 xDSL driver vs A2pv6F039v version in the latest ones from zyxel.
I have tested all to boot with a serial console attached and none make any new warning messages. I have only used the 8324 with new xDSL driver on my line and it worked fine several hours before I pulled it to test more.
https://www.dropbox.com/sh/jw4pdc3yem4zzaa/AACVBARaPKaEemeeJ8hP87J_a?dl=0
I own an 8324 but these are for the 8924 not 8324.
Ideally I want to use the 3925-B10a tho as its smaller, looks nicer and syncs with less errors than the 8324.
Edit: To clarify these are all based on the latest version of each, the VMG8324-B10A_1.00(AAKL.21)C0 & VMG1312-B10A_1.00(AAJZ.14)C0
-
Johnson may already have the source from Zyxel for this but I'll request it from them anyway.
They usually respond quickly but have held back brand new firmware for a few months recently.
-
A new version of the VMG3925-B10B firmware is now up on:
https://github.com/trejan/VMG3925-B10B
This contains (i) the jumbo frames patch; and (ii) a mechanism to sync the admin user password to supervisor + root.
many thanks, hopefully this newer firmware has same sync performance as my current one.
Johnson may already have the source from Zyxel for this but I'll request it from them anyway.
They usually respond quickly but have held back brand new firmware for a few months recently.
jhm has done it, as soon as DLM puts me on fast path I am flashing (DLM reset after aaisp migration).
Thank you, but please go ahead, just in case it doesnt work properly :)
-
I have AAJZ17 for the 1312, AAKL28 for the 8x24 & AAVF13 for the 3925. Been meaning to get around to building the various telnetd/x6/stats versions for each device and flashing all to test.
Also have dockfiles and helper scripts to build on all platforms with just a working docker install and a few commands, need to clean them up and put them on github.
In the meantime any specific version anyone would like? I think underzone mentioned an 8324 with jumbo frames and x6 adsl_phy, others?
-
Anything of note between AAVF.12 and AAVF.13 on 3925?
-
Anything of note between AAVF.12 and AAVF.13 on 3925?
ftp://ftp.zyxel.com/VMG3925-B10B/firmware/VMG3925-B10B_5.13(AAVF.13)C0_2.pdf
There are quite a few changes but nothing really jumps out if you are using them in bridge mode.
Edit: Scratch that, didnt notice the DSL driver is updated from d26s to d26u, that would be of note but I'm not sure of its impact.
-
Thanks johnson,
is the x6 adsl_phy still the latest?
-
ftp://ftp.zyxel.com/VMG3925-B10B/firmware/VMG3925-B10B_5.13(AAVF.13)C0_2.pdf
There are quite a few changes but nothing really jumps out if you are using them in bridge mode.
Edit: Scratch that, didnt notice the DSL driver is updated from d26s to d26u, that would be of note but I'm not sure of its impact.
In that case I'm interested as I can always try it on one line only, see how it fairs.
I wonder what " [eITS# 180800775] Detail information when CPE sync up DSL." is about?
I also see WLAN memory/resource leak, which could explain why when I tried testing WiFi I would get random lockups.
-
In the meantime any specific version anyone would like? I think underzone mentioned an 8324 with jumbo frames and x6 adsl_phy, others?
I am waiting for my line to stabilise due to interleaving being applied but when it is sorted I plan on upgrading to bridge mode on my 8324 and a new separate router.
I'm hoping to use the jumbo frames and multiple telnet features so an update would be great.
I was however planning using the firmware with custom commands also just in case I need it in the future.
Not sure if this would save time but why have so many versions why not just have the fully featured version with jumbo, telnet and custom commands and then that in std, x1 & x6?
Thanks for creating these firmwares I for one are certainly thankful.
-
the newest jhm firmware seems good from initial impressions, no issues flashing through GUI, and it also defaults to 1508 so you dont even need to run the commands or edit anything on the modem. I have confirmed from tests (after adjusting aaisp control panel settings and pfsense) that I do now have a live 1500 byte mtu on pppoe. Thanks to everyone involved in the work on this.
--edit--
Some notes on the new firmware. These issues are not related to the patch I think.
On this firmware zyxel overhauled the UI, its not good. But the more concerning bits is what else I noticed.
The modem was powered down to send a dying gasp to dslam, dsl cable unplugged, and then I powered back up and flashed, I then waited 3 15 min cycles, and powered it down, then plugged dsl cable back in and powered it up.
On dslstats it logged 3200 ES which is very close to the dsl downtime. I dont see these ES anywhere in the telnet data so it is odd, but I have never seen that behaviour before when doing this process on older firmware versions. I do wonder if the modem now saves its stats on shut down to its storage so it can remember it, but as I Said I dont see it anywhere in the telnet data.
Also just to check if I am not going senile I looked at dslstats to see the modem uptime, but thats now "not available" so some things have moved around as well that affects the monitoring.
We will find out probably within a day if this becomes a DLM issue as 3200 exceeds the daily threshold, my feeling is only the stats "since link time" are passed on.
Yeah I see this which is modem uptime, and they also not there and confirm I did power down when I said, so no idea where dslstats got this 3200ES from.
"Total time = 13 hours 45 min 28 sec
FEC: 0 131
CRC: 131 13
ES: 97 13
SES: 0 0
UAS: 24 24
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
-
VMG8924/8324-B10A
https://forum.kitz.co.uk/index.php/topic,21545.msg381478.html#msg381478
Should this firmware automatically give me jumbo frames when in bridged mode or do I need to configure it somewhere or add commands in the customcmds script? Thanks
-
The version I use has baby jumbo capability by default, and I would assume your software is the same. I am using Johnson’s build fro the VMG 1312-B10A - with MTU 1508, multiple telnet sessions, Johnson’s own ‘easy stats’ http api and his http SNRM history recording graphing server and maybe other features which I forget.
-
Should this firmware automatically give me jumbo frames when in bridged mode or do I need to configure it somewhere or add commands in the customcmds script? Thanks
Automatic. Although depending on the router you are using with the zyxel in bridge mode you have have to set the PPP MTU to 1508 there. No need to touch custom commands, its only for setting SNRM target or line cap.
-
https://github.com/johnson442/custom-zyxel-firmware
Finally got the docker build cleaned up and put on github.
A reasonable amount of combinations built and tested for 1312 & 8x24 based on latest V17 & V28 source are available under the releases section:
https://github.com/johnson442/custom-zyxel-firmware/releases
-
Cries quietly in the corner with his VMG3925.
-
Cries quietly in the corner with his VMG3925.
Its coming! Have the docker build working great but needs cleaning up. Was going to suggest https://github.com/trejan/VMG3925-B10B/releases but it seems they have removed the V13 for some reason.
Do you just want jumbo frames on the latest version Alex? Can build test and upload that fast if so.
-
Its coming! Have the docker build working great but needs cleaning up. Was going to suggest https://github.com/trejan/VMG3925-B10B/releases but it seems they have removed the V13 for some reason.
Do you just want jumbo frames on the latest version Alex? Can build test and upload that fast if so.
Yes, jumbo frames is the important thing but the custom stats stuff would be REALLY nice as AFAIK nobody has included it in any 3925 builds before.
In all honestly though I can probably wait however long it takes as my devices seem pretty stable as they are, so long as I do not enable WiFi AP mode. ;)
-
Brilliant!
8x24-B10A-28-jumbo-tel-x6-cmd.bin is loaded and working perfectly.
Thanks, ;D
-
Do I want to upgrade my modems - VMG1312-B10A devices ?
(To 1312-B10A-17-jumbo-tel-x6-stats-cmd.bin )
-
Do I want to upgrade my modems - VMG1312-B10A devices ?
(To 1312-B10A-17-jumbo-tel-x6-stats-cmd.bin )
I'd be inclined to say - why fool with a running piece? With lightning issues and engineers coming I would keep as many variables as possible the same.
That said, once you have stable lines they are some benefits from the new stats server. Everything under /data updates on access rather than having to perform a /getdata or relying on /data/varStats.
But I would not change the adsl_phy modem code unless you want to test, stick to 1312-B10A-17-jumbo-tel-stats-cmd.bin, or even one with less. No problems making a 1312-B10A-17-jumbo-stats.bin if it suits.
-
Got it. Will do as you suggest. Is the new phy module ‘under test/evaluation’ status?
-
Yes, jumbo frames is the important thing but the custom stats stuff would be REALLY nice as AFAIK nobody has included it in any 3925 builds before.
In all honestly though I can probably wait however long it takes as my devices seem pretty stable as they are, so long as I do not enable WiFi AP mode. ;)
yeah not sure why the 3925 has had the least attention, however that build on the github is stable in terms of vdsl connectivity I am using it right now, but the new UI on it is a joke. The holding page e.g. thinks my dsl is down at the moment.
What is special about v13 vs v5.13?
johnson can you do 3925 builds "before" cleaning up docker like you did with others? thanks.
-
yeah not sure why the 3925 has had the least attention, however that build on the github is stable in terms of vdsl connectivity I am using it right now, but the new UI on it is a joke. The holding page e.g. thinks my dsl is down at the moment.
What is special about v13 vs v5.13?
johnson can you do 3925 builds "before" cleaning up docker like you did with others? thanks.
Yeah it says mine is down too, I figured that just doesn't work in bridge mode.
I think both of mine came with the new UI, so never seen the old one to compare.
-
yeah not sure why the 3925 has had the least attention, however that build on the github is stable in terms of vdsl connectivity I am using it right now, but the new UI on it is a joke. The holding page e.g. thinks my dsl is down at the moment.
What is special about v13 vs v5.13?
johnson can you do 3925 builds "before" cleaning up docker like you did with others? thanks.
It has the least attention from me because its inferior to 1312s & 8x24s. It is missing the input filter that makes these modems the best syncing, I bought one to test and found these results.
The new GUI is really quite a step up from the old, it works well on smaller screens and mobile where the old one was broken.
Regarding v13 and v5.13, you are looking at the wrong part of the version number. V5.13(AAVF.12) vs V5.13(AAVF.13).
-
It has the least attention from me because its inferior to 1312s & 8x24s. It is missing the input filter that makes these modems the best syncing...
My experience has been the same - my 3925 languishes in a cupboard as a backup (one of quite a few different devices :-[) as my 8924-B10A trumps it and all the rest on sync speed. I still occasionally buy yet another cheap router from eBay in the hope that I will find something better, but with the exception of a Netgear D6220 (which synced equally well, and I used until it suffered a hardware failure) I've so far found nothing to match it.
:)
-
I saw no discernible difference to the HG612, does that not have the filter either?
I'd imagine the input filter would only make a difference under certain line conditions. Maybe would have more impact if I were on a Hauwei cabinet at 3dB rather than ECI?
-
The HG612 is old and syncs low also. Get an 8324 or 8924 and you will never go back ;)
If you are on a Huawei cab of course...
-
I'm waiting on g.FAST/FTTP and stuck on an ECI cabinet until then, so it makes no sense to replace them now. Just get the most I can from the hacked firmware.
-
It has the least attention from me because its inferior to 1312s & 8x24s. It is missing the input filter that makes these modems the best syncing, I bought one to test and found these results.
The new GUI is really quite a step up from the old, it works well on smaller screens and mobile where the old one was broken.
Regarding v13 and v5.13, you are looking at the wrong part of the version number. V5.13(AAVF.12) vs V5.13(AAVF.13).
I dont know how good those filters are as the 3925 on my line has the lowest ES rate and syncs as high as the older zyxel devices. I do own a 8924 but chose to use the 3925 over it for the better sync performance. Also the 8924 is ugly by design, the 3925 is a much more smaller unit and similar design to the 8800nl which I like :)
Please support this device thank you.
The mobile ui is the exact reason I think its a regression as usually mobile ui's on desktop screens pretty much suck. Wish developers learnt how to detect via agent type again and maintain two ui's instead of pushing mobile ui's to desktops. But aside from the design the new ui does have some bugs not in the old ui.
Since you have all the build tools setup isnt it just the case of compiling one extra image for each release or is there complications I dont know off?
I am guessing I am the only one that see's ES rate as a performance metric and can look past the headline sync speed? although the 3925 doesnt really sync any lower than the 8924 on my line.
-
It has the least attention from me because its inferior to 1312s & 8x24s. It is missing the input filter that makes these modems the best syncing, I bought one to test and found these results.
The new GUI is really quite a step up from the old, it works well on smaller screens and mobile where the old one was broken.
Regarding v13 and v5.13, you are looking at the wrong part of the version number. V5.13(AAVF.12) vs V5.13(AAVF.13).
I ordered one now, giving this famed filter a 3rd chance to improve my line :) My view on filters has always been they can help, they can make things worse, they may make no difference. The 3925 has a discrete dedicated switch chip, and gigabit ports, plus a dedicated wan port, so is superior spec wise to a 1312. The only downside is the lack of this filter. I will report back on here of course on how well the 1312 works.
https://support.aa.net.uk/VMG1312_Vs_VMG3925
I am guessing the 3925 devices have firmware differences tho that make custom builds a bit more of a challenge than the other two models? As I know the shell functions a bit different from discussions in the modem unlocking section.
-
https://support.aa.net.uk/VMG1312_Vs_VMG3925
Just a quick note to point out that the above quoted A&A wiki page is comparing the inferior ZyXEL VMG1312-B10D (and not the superior ZyXEL VMG1312-B10A) with the ZyXEL VMG3925-B10B.
-
The 3925 has a discrete dedicated switch chip, and gigabit ports, plus a dedicated wan port, so is superior spec wise to a 1312. The only downside is the lack of this filter. I will report back on here of course on how well the 1312 works.
I only ever recommend the VMG1312-B10A as a bridge modem.
It has a few flaws as a router.
As it's being used for UK FTTC with a max sync of 80/20 the lack of gigabit Ethernet ports makes no difference.
I'm yet to come across a modem that syncs higher, including 2 newer modems using the newer BCM63138.
The 8924 comes a close second.
I hope the 1312 has a positive effect on your line.
-
What j0hn said. AA support.aa.net.uk website has a page with bugs in the B10A (https://support.aa.net.uk/VMG1312-B10A:_Bugs). However if used in modem-only mode then these B10As work perfectly in my experience; I have four of them and I use IPv6; they have no clue about IPv6 the way I’m using them; everything carried is just a PPP frame of some sort or other.
-
I have had the 1312 boxed for a few days, but I suddenly gone back to the "not caring" mode. I guess for a week or so I was but now I am not, I will probably end up trying it at some point, but the enthusiasm has gone for now.
----
got round to doing it, extra 200kbps sync speed, which is easily within the normal level of variance expected from sync to sync. I will monitor ES to see if any differences on that.
The firmware is interesting tho, keeps the old zyxel UI.
-
Old thread, but for comparison on my line modems with broadcom chipset sync higher than lantiq only on interleave, on fast patch latiq sync good 3Mb/s faster than broadcom(without tweaking snr of course) . I tested asus dsl-ac88u, VMG1312-B10A, and eci BTOR unlocked. Zyxel sync same if not even lower than asus, but best for higher sync is eci, and by dropping 0.5db on snr I got full sync speed.
-
Hi All,
Is there any benefit in terms of performance in getting a VMG3925-B10B over a VMG1312-B10A?
-
Hi All,
Is there any benefit in terms of performance in getting a VMG3925-B10B over a VMG1312-B10A?
The VMG3925-B10B synced lower than my 1312.
In bridge mode it would likely be no better.
If used as a modem/router then the better spec'd hardware on the 3925 will provide other benefits.
-
ok, i have read that much on this topic i have brain-freeze lol.
what i would like to ask though is;
Given that my current setup is;
I have a John Lewis (partially unbranded) VMG8324-B10A with generic v.28 firmware installed and setup in bridge mode only.
I have a Asus Rog Rapture AX-GT11000 router attached. (BT Infinity 1492 MTU PPPoE connection)
I am connected to BT infinity 2 via a Huawei CABinet
I would like to try one of the .28 custom firmware's that i believe includes a better vdsl driver ?
If i upgrade to one of these ;
1. Will it allow supervisor password to be easily accessible from dumpmdm command ?
2. Since I'm already on the .28 generic zyxel version firmware, could I just simply upgrade to the .28 custom firmware without having to do any factory resets or anything and will current config settings remain intact ?
3. After changing firmware's (original .28 to custom .28) what settings would i need to change on the zyxel (if any) and what settings would i need to setup in Asus Rog rapture router , MTU and MRU values (currently at 1492 on both).
4. Which of the custom v28 firmware is my best option ? I still want to be able to telnet / putty and get stats from the modem using dsltstats utility.
5. will I see any noticeable difference by doing using one or any of the custom firmware's ?
These is my current stats from the VMG8324-B10A modem.
(https://i.postimg.cc/8c67m54B/telnet.jpg)
(https://i.postimg.cc/8cMRwDmW/stats.jpg)
many thanks in advance
-
1. Will it allow supervisor password to be easily accessible from dumpmdm command ?
You should be able to do that on your current (generic) firmware. Can you not?
2. Since I'm already on the .28 generic zyxel version firmware, could I just simply upgrade to the .28 custom firmware without having to do any factory resets or anything and will current config settings remain intact ?
I believe that should work. I've upgraded numerous times over the years (but always to a newer firmware) and have never lost any of my custom settings. I take a full backup of the config before I upgrade, just in case.
3. After changing firmware's (original .28 to custom .28) what settings would i need to change on the zyxel (if any) and what settings would i need to setup in Asus Rog rapture router , MTU and MRU values (currently at 1492 on both).
On the bridged modem, nothing. You will need to reconfigure your router to use 1500 MTU on the PPPoE connection. This is how I do it on my EdgeRouter:
ubnt@ubnt# show interfaces ethernet eth1
address 192.168.2.1/24
description "Internet (PPPoE)"
duplex auto
mtu 1508
poe {
output off
}
pppoe 0 {
default-route auto
dhcpv6-pd {
pd 0 {
interface switch0 {
host-address ::1
prefix-id :1
service slaac
}
prefix-length /48
}
rapid-commit enable
}
firewall {
in {
ipv6-name WAN6_IN
name WAN_IN
}
local {
ipv6-name WAN6_LOCAL
name WAN_LOCAL
}
}
ipv6 {
address {
autoconf
}
dup-addr-detect-transmits 1
enable {
}
}
mtu 1500
name-server auto
password xxxx
user-id xxxx
}
speed auto
As you can see, the interface MTU is set to 1508 and PPPoE MTU is set to 1500. I'm not familiar with your Asus unfortunately :no:
4. Which of the custom v28 firmware is my best option ? I still want to be able to telnet / putty and get stats from the modem using dsltstats utility.
I compiled one which only has the jumbo frames patch. If you want more functionality, check out one of johnson's more exotic variants ;D
Mine: https://forum.kitz.co.uk/index.php/topic,21273.msg403176.html#msg403176
johnson's: https://github.com/johnson442/custom-zyxel-firmware/releases
5. will I see any noticeable difference by doing using one or any of the custom firmware's ?
Depends on what you are after. My requirement was to only have RFC4638 support, that's it. But various others required more features, hence all the additional patches.
-
I use the Johnson ‘all the toppings’ build, with fancy added features such as easy-stats protocol (get stats via http, without login) and SNRM vs time graphing stats from a second separate small http server, as well as the basics : MTU 1508 and multiple telnet sessions support. It works beautifully, totally reliable.
-
thanks for all the info everyone, ill give it a blast over the weekend and see how it goes.
cheers ;D
-
I use the Johnson ‘all the toppings’ build, with fancy added features such as easy-stats protocol (get stats via http, without login) and SNRM vs time graphing stats from a second separate small http server, as well as the basics : MTU 1508 and multiple telnet sessions support. It works beautifully, totally reliable.
how do u access the stats from the "separate small http server" ? Do u just log into the router as normal and theres a new page , or is there another http url to use ? thanks
-
You should be able to do that on your current (generic) firmware. Can you not?
I believe that should work. I've upgraded numerous times over the years (but always to a newer firmware) and have never lost any of my custom settings. I take a full backup of the config before I upgrade, just in case.
On the bridged modem, nothing. You will need to reconfigure your router to use 1500 MTU on the PPPoE connection. This is how I do it on my EdgeRouter:
ubnt@ubnt# show interfaces ethernet eth1
address 192.168.2.1/24
description "Internet (PPPoE)"
duplex auto
mtu 1508
poe {
output off
}
pppoe 0 {
default-route auto
dhcpv6-pd {
pd 0 {
interface switch0 {
host-address ::1
prefix-id :1
service slaac
}
prefix-length /48
}
rapid-commit enable
}
firewall {
in {
ipv6-name WAN6_IN
name WAN_IN
}
local {
ipv6-name WAN6_LOCAL
name WAN_LOCAL
}
}
ipv6 {
address {
autoconf
}
dup-addr-detect-transmits 1
enable {
}
}
mtu 1500
name-server auto
password xxxx
user-id xxxx
}
speed auto
As you can see, the interface MTU is set to 1508 and PPPoE MTU is set to 1500. I'm not familiar with your Asus unfortunately :no:
I compiled one which only has the jumbo frames patch. If you want more functionality, check out one of johnson's more exotic variants ;D
Mine: https://forum.kitz.co.uk/index.php/topic,21273.msg403176.html#msg403176
johnson's: https://github.com/johnson442/custom-zyxel-firmware/releases
Depends on what you are after. My requirement was to only have RFC4638 support, that's it. But various others required more features, hence all the additional patches.
on my router i have these options that i can edit MTU and MRU, do i set these to 1500 or 1508 ?
do i need to do anything else on my LAN network for these baby jumbo frames to work correctly?
thanks
(https://i.postimg.cc/7LFYtd44/1492.jpg)
-
1500
Then do a test from a wired PC:
LINUX:
ping -c4 -M do -s 1472 1.1.1.1
WINDOWS:
ping -f -l 1472 1.1.1.1
The pings should be successful..
-
ugh!
after all that, my Asus router wont let me change the MTU to anything over 1492 using the GUI
What now ? is there a telnet command i can use to force it and each time the router is rebooted ?
thanks
-
It may simply not support MTU 1500+8=1508, if so you either get a better router or stick with the MTU 1492.
I can’t talk because I moved heaven and earth to ensure I got MTU 1508, but in practice it’s not important for most situations and I suspect even less important if you’re using IPv6 (which we are all moving towards more and more often; I use IPv6 all the time).
-
Maybe give pfsense a whirl on an old PC.... you can use your current router just as an AP
... or ebay it :)
-
Good plan.
Guys - can pfsense be run in a Raspberry Pi?
-
I need to use Merlin firmware on my Asus RT-AC68U to get 1500 MTU working.
The stock Asus firmware wouldn't allow it.
-
Good plan.
Guys - can pfsense be run in a Raspberry Pi?
nope
-
Good plan.
Guys - can pfsense be run in a Raspberry Pi?
opnsense can though, it's a fork of pfsense after the developers disagreed https://forum.opnsense.org/index.php?topic=12186.0
-
Hi
ugh!
after all that, my Asus router wont let me change the MTU to anything over 1492 using the GUI
What now ? is there a telnet command i can use to force it and each time the router is rebooted ?
thanks
You will see absolutely no difference setting MTU to 1500. In many cases servers we connect to are set to use 1492 (or less) anyway due to the sheer amount of PPPoE Internet connections in use around the world.
pfSense though does work and for me was easy, it took 5 seconds, the time it took to type 1508 and press Save. However that still needs support of the network interface pfSense is using and the port on the modem you are using.
Honestly though, it isn't worth the time and expense of new equipment just to get 1500, it's fools gold :-)
Regards
Phil
-
Hi
You will see absolutely no difference setting MTU to 1500. In many cases servers we connect to are set to use 1492 (or less) anyway due to the sheer amount of PPPoE Internet connections in use around the world.
pfSense though does work and for me was easy, it took 5 seconds, the time it took to type 1508 and press Save. However that still needs support of the network interface pfSense is using and the port on the modem you are using.
Honestly though, it isn't worth the time and expense of new equipment just to get 1500, it's fools gold :-)
Regards
Phil
I'm fairly sure all servers will be set to 1500 as people simply wont bother to change the default when MTU discovery will do its job just fine. They are also going to want traffic within the data centre to be as efficient as possible.
The only services I'm aware of that default lower are games console services which want to make absolutely sure nobody has to fragment packets as it would be detrimental to the latency.
-
what is the use of 1500 MTU i can only select 1492 as max
-
Hi
what is the use of 1500 MTU i can only select 1492 as max
Don't worry about it, its mostly a placebo effect for those of us making the change where our hardware allows ;D There is absolutely no need to change anything and 1492 is an optimal setting used by millions in the UK and many more across the world. If you want more of an explanation see my post here https://forum.kitz.co.uk/index.php/topic,24232.msg408064.html#msg408064
Regards
Phil
-
https://github.com/johnson442/custom-zyxel-firmware
Finally got the docker build cleaned up and put on github.
A reasonable amount of combinations built and tested for 1312 & 8x24 based on latest V17 & V28 source are available under the releases section:
https://github.com/johnson442/custom-zyxel-firmware/releases
I have just a few questions about the modem stats server:
1) Does it mean you don't need a monitoring software such as DSLstats ?
2) Are the stats always ON - as long as the modem is up and running - and saved into the internal memory ?
3) If yes, what will happen when the memory is full ?
4) Do you have a version with jumbo+stats+tel ?
Tia.
-
I was interested in the custom firmware purely for multi telnet sessions but wonder also how the webserver works?
-
The web server is a second small-code-size system which is listening on TCP port 8000. Instructions for its use are further back in this thread iirc. There is a recap post somewhere back here with a link to the latest good version, which iirc is Oct 2018. Johnson is the man. I would think that in your case there’s a good chance you’ll get IP MTU of 1500 in you use this build. The 8 bytes subtracted from 1500 is just the PPPoE overhead so increasing it to 1508 is the answer but not guaranteed, just try it and see if it’s possible with TT Business. It is never guaranteed: for example BT 20CN limits you to MTU 1492 no matter what you do.
-
Many thanks Mr Weaver I need to have a good read. Alas I also have an Asus router with standard firmware which is hardcoded to 1492 also and as far as I am aware no merlin fork for the DSL-N55U, there was but it is no longer being developed.
-
I use it all the time for i) the MTU 1508 feature, ii) for the “stats graphing”, and iii)“easy stats” over http (as I’ve named it) interface, as I’m using an iPad and so cannot run dslstats, and the stupid libraries I’m using on the iPad are limited in their support of lower level protocol functions and everything involving comms has to be http or nothing, so the ‘easy stats’ over http feature is a blessing for me. And Mr Johnson kindly wrote all these latter http based services specifically for me, after I had mentioned the limitations of the iPad. ;D
-
If you want a quick overview try:
https://github.com/johnson442/custom-zyxel-firmware/blob/master/README.md
https://github.com/johnson442/custom-zyxel-firmware/releases
-
It certainly works with Zen on TT Business backhaul.
-
Am I the only one having problems with both the web server, nothing showing in the stats, and the MTU size - can't ping with a packet size larger than 1464...
I'm also with Zen and I'm using Johnson's firmware 17jumbo-tel-stats-cmd. I did post a couple of screenshots here (https://forum.kitz.co.uk/index.php/topic,24392.msg410291.html#msg410291)
-
It only works when used in bridge mode.
The router needs to support it and for it to be enabled.
-
Indeed the VMG1312-B10A is in bridge mode attached to a NG R7800 where both MTU and MRU are set to 1500 for PPPoE interface (see pic), what else ?
Besides, the web server stats are not showing...
-
Am I the only one having problems with both the web server, nothing showing in the stats, and the MTU size - can't ping with a packet size larger than 1464...
I'm also with Zen and I'm using Johnson's firmware 17jumbo-tel-stats-cmd. I did post a couple of screenshots here (https://forum.kitz.co.uk/index.php/topic,24392.msg410291.html#msg410291)
webserver is broken for me also. Seems buggy. But I collect stats via dslstats anyway so didnt bother mentioning it.
-
webserver is broken for me also. Seems buggy. But I collect stats via dslstats anyway so didnt bother mentioning it.
If you could share the zip file of all gathered stats that the webserver will give you by clicking the "Save" button I could try and figure out what the issue is.
The stats server is by design very simple, you can view its source here:
https://github.com/johnson442/custom-zyxel-firmware/blob/master/stats-staging/mongoose/stats-server.c
If anything is wrong its in the javascript that parses the offered xdslctl outputs.
-
seems intact, I will also attach screenshot of what I see on the UI.
However it does seem to be partially working now, if I click the individual sections, SNRM, FEC, CRC all work, data works save button works, rest dont seem to work.
I had to upload zip to google drive as was too big to attach, and cannot attach a 7zip file.
https://drive.google.com/file/d/1FktSvMubKN2IZlFkhhR2gJKdlHDFtQIS/view?usp=sharing
If you wish it I can supply the errors from developer tools.
-
So initial issue seems to be with finding the vendor to apply the right split of down/up tones:
Mine is:
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 1205 Kbps, Downstream rate = 27712 Kbps
Bearer: 0, Upstream rate = 1205 Kbps, Downstream rate = 26436 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
ChipSet Vendor Id: BDCM:0xa48c
ChipSet VersionNumber: 0xa48c
ChipSet SerialNumber:
Yours:
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 29233 Kbps, Downstream rate = 79647 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79637 Kbps
ChipSet Vendor Id: IFTN:0xb206
ChipSet VersionNumber: 0xb206
ChipSet SerialNumber: 5501843597
As I said, probably a new line that my gross javascript doesn't cope with well.
Thanks for the debug info, will look more and make a fixed version.
I apologise for putting it out with such glaring errors, but its been hard to find people to test, and having tiny errors in the JS that need a full flash suck. I have been half working on a more unified firmware, with parts stored in the /data partition that could be updated by uploading a file, without a full flash of the firmware. Got as far as accepting large uploads via the mongoose server, checking a signature and using the /etc/password file for verification. But its hard to get excited about when its such a niche device and audience.
-
@Johnson - My friend, I have to flash a mountain of new modems - I have just lost four from two lighting strikes in a month and I have at least eight VMG1312 B10As that need flashing - so if you wish I would be a happy tester. Would that be of help to you, if I use the latest build to flash these?
Is there a way if guarding against format variation ? Maybe by using a regex if some sort? Perhaps transform all multiple new lines into one single \n in one regex substitution beforehand ?
-
@Johnson - My friend, I have to flash a mountain of new modems - I have just lost four from two lighting strikes in a month and I have at least eight VMG1312 B10As that need flashing - so if you wish I would be a happy tester. Would that be of help to you, if I use the latest build to flash these?
Is there a way if guarding against format variation ? Maybe by using a regex if some sort? Perhaps transform all multiple new lines into one single \n in one regex substitution beforehand ?
OMG from lighting strike. :(
-
seems intact, I will also attach screenshot of what I see on the UI.
However it does seem to be partially working now, if I click the individual sections, SNRM, FEC, CRC all work, data works save button works, rest dont seem to work.
I had to upload zip to google drive as was too big to attach, and cannot attach a 7zip file.
https://drive.google.com/file/d/1FktSvMubKN2IZlFkhhR2gJKdlHDFtQIS/view?usp=sharing
If you wish it I can supply the errors from developer tools.
So with a few lines added to skip over the empty lines, best I can test this should fix the issues on your and hushcodens lines:
https://github.com/johnson442/custom-zyxel-firmware/releases/tag/v1.1
Edit: 8x24 ones tested to boot and uploaded
-
So initial issue seems to be with finding the vendor to apply the right split of down/up tones:
Mine is:
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 1205 Kbps, Downstream rate = 27712 Kbps
Bearer: 0, Upstream rate = 1205 Kbps, Downstream rate = 26436 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
ChipSet Vendor Id: BDCM:0xa48c
ChipSet VersionNumber: 0xa48c
ChipSet SerialNumber:
interesting, on the old version I get:
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 27728 Kbps, Downstream rate = 73017 Kbps
Bearer: 0, Upstream rate = 19999 Kbps, Downstream rate = 72439 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
ChipSet Vendor Id: BDCM:0xa4a1
ChipSet VersionNumber: 0xa4a1
ChipSet SerialNumber: eq nr port:09 oemid softwarerevµ
I assumed the Serial Number mess was just gobbledy gook, but now I'm not so sure? :-\
-
So with a few lines added to skip over the empty lines, best I can test this should fix the issues on your and hushcodens lines:
https://github.com/johnson442/custom-zyxel-firmware/releases/tag/v1.1
Edit: 8x24 ones tested to boot and uploaded
I switched to V17-tel-stats1.1-cmd this morning after a run with an x6 version. I don't see any change in the built in stats graphs etc. Only the snrm, fec and crc show anything and the rest are blank. It is on an ECI DSLAM. If you think it useful I could try another stats1.1 version in case the issue is just with that particular one. I don't mind a few resyncs a day.
-
So with a few lines added to skip over the empty lines, best I can test this should fix the issues on your and hushcodens lines:
https://github.com/johnson442/custom-zyxel-firmware/releases/tag/v1.1
Edit: 8x24 ones tested to boot and uploaded
Thanks, may be a while before I apply it, but probably when I move a UPS into the other room (so I finally get a UPS for modem) I will flash it then.
-
I switched to V17-tel-stats1.1-cmd this morning after a run with an x6 version. I don't see any change in the built in stats graphs etc. Only the snrm, fec and crc show anything and the rest are blank. It is on an ECI DSLAM. If you think it useful I could try another stats1.1 version in case the issue is just with that particular one. I don't mind a few resyncs a day.
In case it is not clear I have the same issue with the stats as Hushcoden and Chryalis. As I intended to say more clearly the update to stats1.1 made no difference to the missing graphs and stats.
-
In case it is not clear I have the same issue with the stats as Hushcoden and Chryalis. As I intended to say more clearly the update to stats1.1 made no difference to the missing graphs and stats.
Thats disappointing, could you upload the zip file from hitting "Save" on the stats page to dropbox/megaupload/etc for me to test?
-
Here is the file. I had gone back to plain 1.00(AAJZ.17)C0.bin for testing so the file is small as it has only been running V17-tel-stats1.1-cmd for about 10 minutes. If you need a longer time let me know.
I can't say that I have properly tested things but I have the impression that the stats versions don't like a gui firmware change done with the vdsl connected. Such changes seemed to have failed a couple of times. Since then I have disconnected first. It hardly matters and if happens a 20sec reset upload method is subsequently needed.
-
Thank you for the upload. As far as I can test that dataset works as expected with the 1.1 stats server.
Could you try with a different browser or device? I'm just trying to avoid a possible cached page.
On a PC while accessing the stats page could you hit F12 and see what the debug output is?
-
Sorry for the false alarm -- it is indeed working just fine. An incognito is all it needed. I will try to disable cache on the those pages.
Thanks for the fix and advice.
-
Having run both 39x6 and 39v versions for more than 4 days each in both 1 day runs and a longer run, I find the day to day ES variations are about 30% with either code whilst the overall error rates for each version differ by only about 15%. The error rates on my line thus look very similar with either of the two dsl codes. It will take lot longer to sure of a real difference and I am inclined to accept the error rates as essentialy the same. The 39x6 has the slightly lower error rate so far and given that over 3 resyncs it has been about .5mb/s faster in sync I think I will now use it for an extended period.
I notice that with the stats1.1 versions you provided a version without jumbo for just the 39v code. I have been assuming that the jumbo versions work just as well as non jumbo versions when not in bridge mode and using standard 1492 MTU. Is there any reason for using a non jumbo version when in combined modem-router mode?
-
As for me, just flashed the 17-jumbo-tel-stats1.1-cmd and yes I can see the stats :)
A big thank you johnson !
P.S.
Quick note on the DSL code: I did also try the x6, and my ECI line lost 1.5Mbs in downstream and 1Mbs in upstream, so will stick with the 39v :graduate:
-
Where did you get that bin file from guys?
-
Where did you get that bin file from guys?
From here: https://github.com/johnson442/custom-zyxel-firmware/releases
-
I need to use Merlin firmware on my Asus RT-AC68U to get 1500 MTU working.
Did you set the value at 1500 or 1508 ?
-
@hushcoden - thanks for that url, hushcoden.
-
A new version of the VMG3925-B10B firmware is now up on:
https://github.com/trejan/VMG3925-B10B
This contains (i) the jumbo frames patch; and (ii) a mechanism to sync the admin user password to supervisor + root.
Is that (password sync) still the case for release V5.13(AAVF.12)C0-Jumbo ?
It is not what I am seeing here on just upgraded unit...
sebus
-
Is that (password sync) still the case for release V5.13(AAVF.12)C0-Jumbo ?
It is not what I am seeing here on just upgraded unit...
sebus
Sadly not, they removed that feature and it seems are no longer working on the firmware.
-
Has anyone got johnson's firmware for the VMG3925-B10B ?
I believe he posted his own version a while ago, but I can't find where...
Tia.
-
Has anyone got johnson's firmware for the VMG3925-B10B ?
I believe he posted his own version a while ago, but I can't find where...
Tia.
Just the jumbo frames or all the bells and whistles? Will need to compile a new one with the javascript fixes if its the latter.
-
3925 version would be awesome
-
Heres a dropbox link with the just jumbo frames one:
https://www.dropbox.com/sh/rp946xws7c4i8js/AAB38b-3kpdOztLcoNRaLAt7a?dl=0&lst=
Compiling the others now.
Edit: updated link for list view
-
Heres a dropbox link with the just jumbo frames one:
https://www.dropbox.com/sh/rp946xws7c4i8js/AAB38b-3kpdOztLcoNRaLAt7a?dl=0
Compiling the others now.
Thank you !
-
Uploaded with the stats server to the same dropbox link.
As always, tested to boot on real hardware and have correct features.
-
Uploaded with the stats server to the same dropbox link.
As always, tested to boot on real hardware and have correct features.
This was unexpected, thanks.
However I uploaded the file, the Zyxel rebooted but I'm not seeing any difference.
Are the stats supposed to be on port 8000? Can I even tell if it flashed at all?
-
This was unexpected, thanks.
However I uploaded the file, the Zyxel rebooted but I'm not seeing any difference.
Are the stats supposed to be on port 8000? Can I even tell if it flashed at all?
Not sure what to suggest, have just tried flashing back to stock then flashing the 3925-B10B-13-jumbo-statsV1.1.bin downloaded from dropbox, has the stats server present at modemip:8000.
Unfortunately I have tried and failed to find a way to update the version string on the 3925, so you can check it has flashed this version by logging into telnet with supervisor and:
$ cd /var/tmp/stats/
$ ls
data gz manifest.json
favicon.ico icons stats-logging.sh
getdata index.html stats-server-bin
$
-
The whole process of loading firmware into the modem is very dodgy and error prone. I have a written procedure now which I use. I start with a hole-poke 20s reset - described elsewhere but I can post up my procedure if you wish.
Coming back to uploading firmware in the usual web UI though, iirc, without looking at my notes, you might have to hit refresh in the browser after you have selected the firmware file and clicked go-for-it and then you go to any other item in the menu then back into the config loading menu option, this should make an in-progress menu appear.
-
@johnson I’ve just loaded your latest (mid-Feb) release into one of my new modems and it is absolutely superb. A stunning job and I appreciate just how much work you have put in for me and all of us. Thank you so much! ;D
-
Here’s the full-reset procedure I use, with firmware loading and then config loading:
• Set your machine to 192.168.1.11 / 255.255.255.0 / gateway 192.168.1.1
• Plug ethernet cable into modem’s port 2 or 3 and into main switch
• Power the modem off
• insert a pokey implement into the modem’s reset hole to depress the switch (there is a similarly sized but protruding WPS)
• Power modem on, keeping poker poked in all the time still
• Keeping poker in, LED will flash for 20s then go solid red
• Release poker
• If the device is left in the solid red light mode then a recovery page should appear at http://192.168.1.1, but only if the ethernet cable is connected to port 2 or 3. Port 1 or is it 4 -which is it -will not work, depending on which way you read the port numbering. (I think the port on the far right is the bad one.)
• file selector prompt, select the firmware file something.bin
• After you hit enter at the load firmware prompt, after so many secs the screen should change to show a [back] button. (If not, then you may have put cable in the wrong port, so check it is in port 2 or 3)
• Takes forever to blow flash, no UI feedback
• after 2 mins the modem will reboot (no progress indication)
• When the modem web UI comes up, at http://192.168.1.1: log in with username=admin, password=1234
• Forcible password change, set password to your choice
If you are loading your own saved standard config file:
[ • using menu option "configuration" > "restore", choose an XML config file
• When you have waited for a minute or so, hit refresh in browser
• you have to make sure you go back into the the "configuration" menu again, then modem will reboot
• Modem’s IP address will now change - it might be wrong when the modem boots if the config file specified something other than the default, so change your machine’s address if necessary accordingly
• Wait an age until the modem config is loaded (v. approx 4 min for me)
Then when config loading has completed
]
Main part all done.
First job:
• telnet into modem, log in as "supervisor", with your standard supervisor password - ask if you don’t know this
• Telnet CLI : Enter the command : save_default clean
• enter the command: exit
All done.
-
Thanks for all the advise, its just tricky as that is the modem currently in the Plusnet g.INP trial so I don't want to mess with it too much.
Of course I've misplaced my second modem which would be a perfect candidate for this, grrrr.
-
Hi everyone.
I am having issues with a suspected faulty ECI openreach modem (circa 5mb speeds on fibre) so have picked up a VMG1312-B10A on eBay. It could be the opnsense box, although it's a reasonably performant thin client.
I plan on installing Johnson's firmware and using it in bridge mode. I see there are a few versions available at https://github.com/johnson442/custom-zyxel-firmware/releases
I take it X6 is better in some way to X1? What does V17 / V26 signify?
Thanks
-
x1 is the modem code that johnson used in his older custom firmwares that aren't on github, but on this forum as dropbox links.
x1 was generally only beneficial on vectoring lines and had stability issues for regular lines [or just performed horribly for some other guy on this forum], so it wasn't recommended to anyone without vectoring.
x6 is should be better than x1 and i am currently testing it [i tested x1 in the past] - i can't tell you if it's good yet, i have to wait until i'm 7 days uptime [i had line drops every 6 hours the past week due to external interference which is what led me to trying it. it didn't solve the issue but the last time i had interference was more than a day ago so maybe i would get 7 days uptime to know if x6 is stable. so far it's stable but specific people can get completely negative results so i would say that even then, it still depends].
what i recommend for now is getting the .bin without "x6" in its name because it contains the version "v" which is the original modem code that is "truly" compatible with the dsl driver which is d26a. x6 was taken from a newer ZyXEL modem with the dsl driver d26s so it may have the same issues as x1.
for now, unless you have a line with vectoring, get 1312-B10A-17-jumbo-tel-stats1.1-cmd.bin [modem code version "v"].
i personally chose one with "stats" in it since the program "DSLStats" seemed to consistently crash my router into a forced restart after a certain period of time whenever i used it. even if i used it once. the stats server doesn't take much or any processing from the device so it can't hurt. v17 signifies the 1312-B10A firmware version released by ZyXEL, before johnson added the other things. v26 is for 8924 and 8324 so it's not for your device.
i still telnet "ifconfig ppp1.1 mtu 1500" [i have pppoe 1492 mtu without the baby jumbo frames] on each ISP connection establishment because i still have to for some reason. it could be because i didn't reset the device to default after upgrading from v14 with jumbo frames by Olipro. if you don't use the device in bridge mode you might have to do that to the PPP link. maybe i misunderstood what johnson said though:
1508 MTU 'baby' jumbo frames
Changes to to the ethernet driver to allow > 1500 MTU ethernet frames & changes to the PTM network driver to bring the link up with an MTU of 1508 by default.
not a problem though.
here is what the SNR graph showed for x1: https://imgur.com/a/xsJ6DEu
at the last tones you see a curve downward. that did not happen on V which had a spiral upward.
so far into day 2, x6 doesn't have that problem. [i don't have vectoring] but, actually, i don't have DLM on my line. so i can experiment with anything and do whatever i want without consequences, unlike most people. you probably have DLM on your line, so i recommend sticking to V until i test this one. [its compatibility with the older dsl driver d26a, that is].
you can jump in on x6 right now but without vectoring that decision is questionable, as i still don't know how it performs. you can see in this thread that "one guy" who had horrible results from day 1 with x1: https://forum.kitz.co.uk/index.php/topic,21683.msg376325.html#msg376325
edit: this post (https://forum.kitz.co.uk/index.php/topic,21273.msg375848.html#msg375848) has three graphs, one of x1 and two of V showing what i mean about SNR graphs differences. [because it has a deeper meaning than just less downstream sync or whatever].
i attached x6 close up image and those last tones are pretty similar to V's as you can see [so far, as i can't tell what will happen by day 7]. V had a bit of an upward curve rather than straight but it's a very tiny difference in terms of SNR gained. i'll test V after 3 weeks with x6 or something like that. i'll also take in consideration the error rate differences but those can vary on their own. looking at overall rates over 3 weeks on both should be conclusive. other people could have very different results than mine though.
-
Just to feed back, I did get my modems updated in the end and the stats work fine. Huge thanks to Johnson for adding this to the VMG3925-B10B.
-
thank you for the 3925 firmwares, I will be glad to switch back to it.
-
+1. Great work johnson!
:yay:
-
SPRING!
Wonderful to hear from you and thank you for the perfect description of the differences between modem code/firmware version etc.
:)
-
So far into day 4, x6 has been working on par with V overall. Might actually be better for me. Attached is some spike that I think might not happen with V. However the rest of the graph looked very clean, cleaner than with V. Error rates are as stable as V [but I don't know yet, haven't tested V yet, just used it for 3 years].
"x6 downward spike 2.PNG" is kind of nit-picking ['logical' graph-view-mode] but there's some truth to it. the other image is a linear and general view of a different spike. those spikes appeared around today and might go away [they fluctuate].
not much conclusion yet though since 3 days to go for 7 days uptime. i think i'll test it for 3 weeks total then switch back to V.
don't mind the errors in the stats, they are external interference [as can be seen that last 24 hours are clean]
xdslctl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 4
Last initialization procedure status: 0
Max: Upstream rate = 27544 Kbps, Downstream rate = 81868 Kbps
Bearer: 0, Upstream rate = 5024 Kbps, Downstream rate = 78590 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 8.7 16.1
Attn(dB): 12.0 0.0
Pwr(dBm): -11.5 -11.7
VDSL2 framing
Bearer 0
MSGc: -6 363
B: 243 29
M: 1 1
T: 0 1
R: 6 16
S: 0.0000 0.1840
L: 20230 2000
D: 1 59
I: 250 46
N: 250 46
Q: 8 0
V: 0 0
RxQueue: 57 0
TxQueue: 19 0
G.INP Framing: 18 0
G.INP lookback: 19 0
RRC bits: 0 24
Bearer 1
MSGc: 186 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 5.3333 0.0000
L: 48 0
D: 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 302468
OHFErr: 551 0
RS: 1519034440 1123580
RSCorr: 60835 242
RSUnCorr: 0 0
Bearer 1
OHF: 22250334 0
OHFErr: 575 0
RS: 267003269 0
RSCorr: 295 0
RSUnCorr: 6657 0
Retransmit Counters
rtx_tx: 212874383 0
rtx_c: 2697 0
rtx_uc: 200845 0
G.INP Counters
LEFTRS: 37 0
minEFTR: 78571 0
errFreeBits: 522577136 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 2473811584 0
Data Cells: 166220579 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 40 0
SES: 36 0
UAS: 339 67
AS: 357457
Bearer 0
INP: 44.00 1.50
INPRein: 0.00 0.00
delay: 0 3
PER: 0.00 17.04
OR: 0.01 173.23
AgR: 78670.61 5197.09
Bearer 1
INP: 4.00 0.00
INPRein: 4.00 0.00
delay: 3 0
PER: 16.06 0.01
OR: 95.62 0.01
AgR: 95.62 0.01
Bitswap: 256/256 0/0
Total time = 4 days 12 hours 20 min 0 sec
FEC: 247163 437
CRC: 2021 0
ES: 40 0
SES: 36 0
UAS: 339 67
LOS: 0 0
LOF: 0 0
LOM: 29 0
Latest 15 minutes time = 5 min 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 4 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 12 hours 20 min 0 sec
FEC: 349 8
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 2502 131
CRC: 8 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 4 days 3 hours 17 min 35 sec
FEC: 60835 242
CRC: 551 0
ES: 14 0
SES: 10 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 9 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
i think resilient is the word to describe x6. i've been using the internet, gaming, and my dad as well. no complaints from him or me. downloads are stable. the best way to describe x6 is smoothness. for V it's more like "old fashioned cautions" that get through the hardest times. that's why x6 might not work for everyone. especially since (theoretically) it's a bit incompatible with dsl driver d26a. in practice i haven't seen that "incompatibility" manifest yet. [except maybe in SNR graph spikes... dunno yet]. it also bitswaps much better than x1 and even V. x6 is less conservatory than V. if that makes sense. so it's both more prone to errors but also better results. whether that potential is worth it i dunno yet.
edit: i think the overall approval test is gaming. [on an old game without lag compensation and with real-time sync - named Rakion] hard to observe since ISP's are in the mix there but i'll take that approach in consideration. hard to notice too. but it goes a longer way than watching SNR graphs.
-
Johnson how do I use the cap feature that is remembered across reboots etc?
-
@ johnson, could you please provide an updated custom version for VMG3925-B10B with stats and jumbo frame support in line with the latest available version v5.13(AAVF.17)C0 which was released in 22 Jan 2021? Looks like there were several changes since v5.13(AAVF.13)C0
Link for the generic version here:
https://www.dropbox.com/s/ag157wvrfnhftzg/VMG3925-B10B_Firmware_5.13%28AAVF.17%29C0.zip?dl=1
The aforementioned link was obtained from: https://support.zyxel.eu/hc/en-us/articles/4403361365778-Advanced-Downloads-for-CPE-devices
Thanks
-
Welcome to the forum, Ok-League-3645!
You might also want to be aware of the thread https://forum.kitz.co.uk/index.php/topic,21545.0.html - where software maintenance is also handled. Some overlap, which is my fault.
-
@ johnson, could you please provide an updated custom version for VMG3925-B10B with stats and jumbo frame support in line with the latest available version v5.13(AAVF.17)C0 which was released in 22 Jan 2021? Looks like there were several changes since v5.13(AAVF.13)C0
Link for the generic version here:
https://www.dropbox.com/s/ag157wvrfnhftzg/VMG3925-B10B_Firmware_5.13%28AAVF.17%29C0.zip?dl=1
The aforementioned link was obtained from: https://support.zyxel.eu/hc/en-us/articles/4403361365778-Advanced-Downloads-for-CPE-devices
Thanks
I have used the GPL form (https://service-provider.zyxel.com/global/en/gpl-oss-software-notice) to request source for AAVF.17, but it took a loooonge time (6 months?) last time we asked for new versions for the 1312/8342.
If anyone else has asked and got a copy please share it. :)
-
It may be worth asking for AAVF.18:
Date: Jan 10 , 2022
Supported Platforms:
Zyxel VMG3926-B10A/VMG3925-B10A/VMG3925-B/VMG3925-B10C
Firmware Version : V5.13(AAVF.18)C0
Bootbase version : V1.63 | 07/22/2020
Kernel version :3.4.11
DSL modem code version :A2pv6F039x6
DSL driver version :d26ud26ud26ud26u
WLAN code version :7.14.164.23.cpe4.16L05.0-kdb
3G WWAN package version: 1. 20
[BUG FIX]
1. [Vulnerability] BRCM "DeAgg & DeFrag Attacks" [
-
I have used the GPL form (https://service-provider.zyxel.com/global/en/gpl-oss-software-notice) to request source for AAVF.17, but it took a loooonge time (6 months?) last time we asked for new versions for the 1312/8342.
If anyone else has asked and got a copy please share it. :)
Hi, good news. I obtained the source code for the v18 firmware of VMG3925-B10B from Zyxel.
I had to use this link to request for the source code:
https://support.zyxel.eu/hc/en-us/articles/360017067100-How-to-Access-Zyxel-Open-Source-Code-for-Programmers-GPL-
Zyxel responded within a couple of days.
As the file is 500mb large, shall I send you the download link via PM to do your magic? The link expires in 7 days! Thanks!
-
Yes please. (And that will hopefully be with my y-axis title units change too, of course, which you very kindly did for me, and which I version-numbered v08. So I will version-number the next release as v09.)
Do you know where the release notes are? Can only see older ones.
-
Ah brilliant, thanks @Ok-League-3645.
Have downloaded it, just need to get my docker/podman build running again and 3925 out to test.
Looking through my emails it seems I didnt even get a received confirmation, will use the supplied link in future.
-
I’ll be happy to test with a VMG1312-B10A.
-
Heres jumbo frames + stats on V5.13(AAVF.18)C0:
https://www.dropbox.com/sh/huk6k0wyikesl9a/AAAbpXPAFMnEYdMhJdO9U2oKa?dl=0
Sorry for taking so long @Ok-League-3645 and thanks again for the source link.
-
I’ll be happy to test with a VMG1312-B10A.
Apologies Weaver, the new version is for the 3925 not our trusty 1312s, but the new firmware does of course add the more informative axis labels we discussed. ;D
-
Heres jumbo frames + stats on V5.13(AAVF.18)C0:
https://www.dropbox.com/sh/huk6k0wyikesl9a/AAAbpXPAFMnEYdMhJdO9U2oKa?dl=0
Sorry for taking so long @Ok-League-3645 and thanks again for the source link.
@johnson Thanks a lot for providing this :thumbs:
-
Could someone post the source link for VMG3925-B10B V5.13(AAVF.18)C0 ?
-
Sure, added to the same link.
https://www.dropbox.com/sh/huk6k0wyikesl9a/AAAbpXPAFMnEYdMhJdO9U2oKa?dl=0
-
thank you Johnson, does the below work for the B10C version as well ?
https://service-provider.zyxel.com/global/en/products/dsl-cpe/vdsl/modemresidential-gateways/vmg3925-b-series
also, on dropbox there are 3 files for the B10B, could I kindly ask for a laymans description of each of them, I think GPL.zip are the source files
3925-B10B-18-jumbo-statsV1.1.bin 7/6/2022 2:09 am
3925-B10B-18-jumbo.bin 7/6/2022 2:09 am
VMG3925-B10B_V513AAVF18C0_GPL.zip 6/22/2022 5:27 am
and last thing, are the Zyxel 3925's in bridge mode ( modem passthrough / bridge mode ) still the best bet with VDSL lines, now that the "Baby Jumbo" fix has been implemented ?
-
thank you Johnson, does the below work for the B10C version as well ?
They appear to use the same firmware, this (https://support.zyxel.eu/hc/en-us/articles/4403361365778-Advanced-Downloads-for-CPE-devices) zyxel page lists the same firmware for both, and AAISPs wiki (https://support.aa.net.uk/Category:ZyXEL_VMG3925_B10C) has:
The specification is very similar to the VMG3925-B10B that it replaces (in fact the same firmware is used on the B10B and B10C)
but I don't have a B10C to test.
also, on dropbox there are 3 files for the B10B, could I kindly ask for a laymans description of each of them, I think GPL.zip are the source files
3925-B10B-18-jumbo.bin - V18 firmware, just the patches for 1508 baby jumbo frames
3925-B10B-18-jumbo-statsV1.1.bin - Same but including a small websever with easy access to line stats and a 48 hour log, screenshots and details here (https://github.com/johnson442/custom-zyxel-firmware).
VMG3925-B10B_V513AAVF18C0_GPL.zip - Source package from zyxel.
and last thing, are the Zyxel 3925's in bridge mode ( modem passthrough / bridge mode ) still the best bet with VDSL lines, now that the "Baby Jumbo" fix has been implemented ?
Depends on your line! Second hand 8x24/3925 etc are cheap enough that they are always worth trying IMO.
-
super, thank you for that johnson - much appreciated :cool:
the version I want is the included webserver one, to use with the VMG3925-B10C, so I can test this and report back, will be running in "Bridge Mode" with a Ubiquiti EdgeRouter X router ( ER-X) behind it
"Modem stats server with logging and web interface - a small mongoose based http server with simple visualisation of real time and logged statistics avaliable by default on modem-ip:8000 "
how do I remotely see the http server when I'm not on site, can I port forward to :8000 to see the Zyxel even when its in bridge mode, or does the Zyxel need one its ethernet switch ports ( LAN 1 ) to be plugged into the ER-X with a LAN ip of 192.168.1.1 for the :8000 to work ?
-
With the zyxel in bridge mode the PPPoE connection terminates on your router (the ERX), so accessing it remotely will require the same steps as exposing any other device on your network to the internet.
Lan access will require a second cable or the routing tricks to use one, and I would stop there. I wouldn't recommend exposing either the default interface or the stats server to the internet just as I wouldn't recommend exposing other devices on your network. I would look into VPN protocol like wireguard for secure remote access to a network. :)
-
I was able to set ptm0 and ptm0.1 MTU in modem settings to 1508 and it was showing MTU 1508 in ifconfig command.
but setting the MTU in ETH1 interface in openwrt didn't change the mtu for pppoe-wan interface it stayed 1492 and I also tried changing it manually but still was same 1492, tested via ping -f -l command.
-
Does anyone has an archive of mostly vmg4005 firmwares, but also similar? Its a simple bonding /modem/bridge and a nice piece for trying. Unfortunately zyxel ftp gone, and sources....just newest. Got few branded, will decide for jtag TP or nand reading. I hope under the nand is an SPI flash footprint...
-
Here’s the full-reset procedure I use, with firmware loading and then config loading:
• Set your machine to 192.168.1.11 / 255.255.255.0 / gateway 192.168.1.1
• Plug ethernet cable into modem’s port 2 or 3 and into main switch
• Power the modem off
• insert a pokey implement into the modem’s reset hole to depress the switch (there is a similarly sized but protruding WPS)
• Power modem on, keeping poker poked in all the time still
• Keeping poker in, LED will flash for 20s then go solid red
• Release poker
• If the device is left in the solid red light mode then a recovery page should appear at http://192.168.1.1, but only if the ethernet cable is connected to port 2 or 3. Port 1 or is it 4 -which is it -will not work, depending on which way you read the port numbering. (I think the port on the far right is the bad one.)
• file selector prompt, select the firmware file something.bin
• After you hit enter at the load firmware prompt, after so many secs the screen should change to show a [back] button. (If not, then you may have put cable in the wrong port, so check it is in port 2 or 3)
• Takes forever to blow flash, no UI feedback
• after 2 mins the modem will reboot (no progress indication)
• When the modem web UI comes up, at http://192.168.1.1: log in with username=admin, password=1234
• Forcible password change, set password to your choice
If you are loading your own saved standard config file:
[ • using menu option "configuration" > "restore", choose an XML config file
• When you have waited for a minute or so, hit refresh in browser
• you have to make sure you go back into the the "configuration" menu again, then modem will reboot
• Modem’s IP address will now change - it might be wrong when the modem boots if the config file specified something other than the default, so change your machine’s address if necessary accordingly
• Wait an age until the modem config is loaded (v. approx 4 min for me)
Then when config loading has completed
]
Main part all done.
First job:
• telnet into modem, log in as "supervisor", with your standard supervisor password - ask if you don’t know this
• Telnet CLI : Enter the command : save_default clean
• enter the command: exit
All done.
Hi, I dont know my supervisor password? Thanks gabtar