Yes, everything was present in the Wireless tab before I upgraded. I've since downgraded back to 17.01 r6953 and everything works fine.
I did some more testing with the mentioned cert partition. Here's what I did:
- I already had OpenWrt with the expanded ubi partition flashed so I filled it up to the brim with only a couple of tens of kilobytes to spare.
- Flashed the NETGEAR firmware.
- Set up internet.
- Ran a speedtest which reached my ISP cap of 500/500 over wire.
- Gave WiFi a spin; all normal.
- Enabled streamboost; works fine.
- Browsed some news sites; all OK.
I then flashed a vanilla snapshot for the R7800 to check out the cert partition:
root@OpenWrt:~# cat /dev/ubi1_0 | gunzip -c
cert.info0000644000000000000000000000001613260272112011357 0ustar rootroot4H58755P0041B
ca.crt0000644000000000000000000000245213260272045010655 0ustar rootroot-----BEGIN CERTIFICATE-----
MIIDojCCAwugAwIBAgIJAPzbqheTfjshMA0GCSqGSIb3DQEBCwUAMIGTMQswCQYD
VQQGEwJUVzELMAkGA1UECBMCVFcxDzANBgNVBAcTBlRhaXBlaTEQMA4GA1UEChMH
bmV0Z2VhcjEQMA4GA1UECxMHbmV0Z2VhcjETMBEGA1UEAxMKbmV0Z2VhciBDQTEQ
MA4GA1UEKRMHRWFzeVJTQTEbMBkGCSqGSIb3DQEJARYMbWFpbEBuZXRnZWFyMB4X
DTE4MDQwMjAwMDcwMVoXDTM4MDMyODAwMDcwMVowgZMxCzAJBgNVBAYTAlRXMQsw
CQYDVQQIEwJUVzEPMA0GA1UEBxMGVGFpcGVpMRAwDgYDVQQKEwduZXRnZWFyMRAw
DgYDVQQLEwduZXRnZWFyMRMwEQYDVQQDEwpuZXRnZWFyIENBMRAwDgYDVQQpEwdF
YXN5UlNBMRswGQYJKoZIhvcNAQkBFgxtYWlsQG5ldGdlYXIwgZ8wDQYJKoZIhvcN
AQEBBQADgY0AMIGJAoGBAOvQyR2QfjHKRYTv3DTzV9k2Efh5FEIzEr+50tY9bx7h
J6OwMzWBZ06jrZucbo4we6+mUajxkx/QS67m5id3nHZCjR/O5FTu0JbAqUk9tn5T
vI/YchHu0Cr150QFHLJmqyrze1NiJVGZ9CzjONERosy2Cc3vrsEMPWlJIYqxKzv9
AgMBAAGjgfswgfgwHQYDVR0OBBYEFCWAA595pnXgBSnR8WwW0aJW1PvqMIHIBgNV
HSMEgcAwgb2AFCWAA595pnXgBSnR8WwW0aJW1PvqoYGZpIGWMIGTMQswCQYDVQQG
EwJUVzELMAkGA1UECBMCVFcxDzANBgNVBAcTBlRhaXBlaTEQMA4GA1UEChMHbmV0
Z2VhcjEQMA4GA1UECxMHbmV0Z2VhcjETMBEGA1UEAxMKbmV0Z2VhciBDQTEQMA4G
A1UEKRMHRWFzeVJTQTEbMBkGCSqGSIb3DQEJARYMbWFpbEBuZXRnZWFyggkA/Nuq
F5N+OyEwDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOBgQDAVDi+mqOWd280
jXHqLo62B2ndVDQjo7FZdsWafOInPdwapSHub1u9D8I46ZpcFocgmn0BoqAr6dEH
JHDyWb4pdgmIfAjerdwWRZ63KireR6pAjLmu8lKvz6LJh8C2GNNe3N6vEJR7+Hlo
8hY9zAlWetLmHiKyQRTJfGuCoFBD0w==
-----END CERTIFICATE-----
dh1024.pem0000644000000000000000000000036513260272111011160 0ustar rootroot-----BEGIN DH PARAMETERS-----
MIGHAoGBAN7KxAVcooxCWeq+kvkWJArNuxdDChOaZwKEBc6rW0QLFSUciMvIYW2l
HKGUFB5v4Yx4afcEZOHypg9Cn4XKy/mn+xCEhGz2SLHH54q8HIbchHpEEDww03Fm
1fn6Era9BMsdYOXp/bgrAPAgzTD1W+Kv8ujbpn8dG50G6x86z87jAgEC
-----END DH PARAMETERS-----
client.crt0000644000000000000000000000746213260272112011551 0ustar rootrootCertificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=TW, ST=TW, L=Taipei, O=netgear, OU=netgear, CN=netgear CA/name=EasyRSA/emailAddress=mail@netgear
Validity
Not Before: Apr 2 00:07:38 2018 GMT
Not After : Mar 28 00:07:38 2038 GMT
Subject: C=TW, ST=TW, L=Taipei, O=netgear, OU=netgear, CN=client/name=EasyRSA/emailAddress=mail@netgear
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:dd:b9:93:20:a1:19:eb:33:2b:1b:44:49:2e:2a:
67:fd:27:ab:83:ed:a1:1d:5a:f8:79:28:9d:39:e6:
07:a2:c2:d2:65:b7:b1:7f:47:41:2e:f0:86:2f:fe:
50:f6:51:cc:17:9f:69:4d:a1:f7:ea:41:15:0d:fa:
8b:dd:72:15:71:8c:01:2c:58:7e:f0:41:bb:12:fc:
ed:2b:2b:e7:de:23:af:04:bb:5a:71:41:39:60:ec:
63:a6:4c:6c:e3:51:25:59:8e:9e:67:33:75:9c:de:
37:26:f3:70:74:7b:cb:3e:ff:e5:b5:30:07:25:02:
74:53:1c:32:19:34:f2:63:dd
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
Easy-RSA Generated Certificate
X509v3 Subject Key Identifier:
83:02:77:BD:D5:F6:30:80:23:A2:ED:9C:1B:09:5D:60:FE:5A:62:45
X509v3 Authority Key Identifier:
keyid:25:80:03:9F:79:A6:75:E0:05:29:D1:F1:6C:16:D1:A2:56:D4:FB:EA
DirName:/C=TW/ST=TW/L=Taipei/O=netgear/OU=netgear/CN=netgear CA/name=EasyRSA/emailAddress=mail@netgear
serial:FC:DB:AA:17:93:7E:3B:21
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature
Signature Algorithm: sha256WithRSAEncryption
14:39:28:33:38:6d:02:8e:5d:0b:80:18:d1:09:97:e9:e5:e7:
09:a0:f5:48:53:a2:a3:8b:c4:c2:71:59:e5:1e:b4:94:8b:93:
8b:d9:f9:b3:d3:d5:7a:42:33:b6:ea:06:b1:00:24:0e:2a:81:
ac:21:2a:8c:b5:17:38:64:ab:93:b2:a9:8e:60:bb:82:62:7f:
07:6a:5f:62:42:a2:19:96:03:b4:60:12:0b:e9:76:1f:64:e2:
1c:7b:4d:b4:1d:c3:35:5c:a8:e6:c5:72:35:ea:47:8f:65:b9:
80:b3:3b:91:15:c2:6c:8a:9b:b4:36:5c:09:e4:e6:3e:28:fc:
4e:b6
-----BEGIN CERTIFICATE-----
MIID5jCCA0+gAwIBAgIBAjANBgkqhkiG9w0BAQsFADCBkzELMAkGA1UEBhMCVFcx
CzAJBgNVBAgTAlRXMQ8wDQYDVQQHEwZUYWlwZWkxEDAOBgNVBAoTB25ldGdlYXIx
EDAOBgNVBAsTB25ldGdlYXIxEzARBgNVBAMTCm5ldGdlYXIgQ0ExEDAOBgNVBCkT
B0Vhc3lSU0ExGzAZBgkqhkiG9w0BCQEWDG1haWxAbmV0Z2VhcjAeFw0xODA0MDIw
MDA3MzhaFw0zODAzMjgwMDA3MzhaMIGPMQswCQYDVQQGEwJUVzELMAkGA1UECBMC
VFcxDzANBgNVBAcTBlRhaXBlaTEQMA4GA1UEChMHbmV0Z2VhcjEQMA4GA1UECxMH
bmV0Z2VhcjEPMA0GA1UEAxMGY2xpZW50MRAwDgYDVQQpEwdFYXN5UlNBMRswGQYJ
KoZIhvcNAQkBFgxtYWlsQG5ldGdlYXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBAN25kyChGeszKxtESS4qZ/0nq4PtoR1a+HkonTnmB6LC0mW3sX9HQS7whi/+
UPZRzBefaU2h9+pBFQ36i91yFXGMASxYfvBBuxL87Ssr594jrwS7WnFBOWDsY6ZM
bONRJVmOnmczdZzeNybzcHR7yz7/5bUwByUCdFMcMhk08mPdAgMBAAGjggFKMIIB
RjAJBgNVHRMEAjAAMC0GCWCGSAGG+EIBDQQgFh5FYXN5LVJTQSBHZW5lcmF0ZWQg
Q2VydGlmaWNhdGUwHQYDVR0OBBYEFIMCd73V9jCAI6LtnBsJXWD+WmJFMIHIBgNV
HSMEgcAwgb2AFCWAA595pnXgBSnR8WwW0aJW1PvqoYGZpIGWMIGTMQswCQYDVQQG
EwJUVzELMAkGA1UECBMCVFcxDzANBgNVBAcTBlRhaXBlaTEQMA4GA1UEChMHbmV0
Z2VhcjEQMA4GA1UECxMHbmV0Z2VhcjETMBEGA1UEAxMKbmV0Z2VhciBDQTEQMA4G
A1UEKRMHRWFzeVJTQTEbMBkGCSqGSIb3DQEJARYMbWFpbEBuZXRnZWFyggkA/Nuq
F5N+OyEwEwYDVR0lBAwwCgYIKwYBBQUHAwIwCwYDVR0PBAQDAgeAMA0GCSqGSIb3
DQEBCwUAA4GBABQ5KDM4bQKOXQuAGNEJl+nl5wmg9UhToqOLxMJxWeUetJSLk4vZ
+bPT1XpCM7bqBrEAJA4qgawhKoy1Fzhkq5OyqY5gu4JifwdqX2JCohmWA7RgEgvp
dh9k4hx7TbQdwzVcqObFcjXqR49luYCzO5EVwmyKm7Q2XAnk5j4o/E62
-----END CERTIFICATE-----
client.key0000600000000000000000000000162413260272112011533 0ustar rootroot-----BEGIN PRIVATE KEY-----
MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBAN25kyChGeszKxtE
SS4qZ/0nq4PtoR1a+HkonTnmB6LC0mW3sX9HQS7whi/+UPZRzBefaU2h9+pBFQ36
i91yFXGMASxYfvBBuxL87Ssr594jrwS7WnFBOWDsY6ZMbONRJVmOnmczdZzeNybz
cHR7yz7/5bUwByUCdFMcMhk08mPdAgMBAAECgYEAw+XFDwwnaT3xNQsVGRvQesQE
7vAR7GzGoc13dIM/dddpqwMsaMbc2YsbE+Y/RBIrHyfyEuwqrSbJYmteDc5REDdI
fg6cdTGW/Xm9HRFtq+jObsfZQ+WNF8jkS9i27PKTWApeXf5TUm6yW4Uxl/lJhXKT
0IFqSBlwKuFE2zDQaCUCQQDziK8Z+7LRBgYZtzOy06dDlzvWkUSYGRxppj5m/14Y
KYufz5zicGH2i9IPAAhDYk1cdxPY/hSElhEmFEpr9P2LAkEA6RMZ34VrpnoVrZVo
X9pSZAYnpbenh9osMbnF1Uc5vwznIWXKOHfa2IKLkjah9d1NR8Q6fSfkHhGYVzKy
IgMhNwJAGrbSpmIC0oT7pFSBWkt3XKW5TacvxBN1F23CCKBYnQPpqgUnK3uyc04R
I84YGfQtkkgJqFLuw0CG7wtowoDkUwJAZ/paf4oxBTrPsvnFb4WhXfgU9ewhtAyT
zLc417YHwACMmCyl810c55wNkfQHevz4Pfz/rtf9/6AP207Fg0DsLwJARRq8ws1t
d7xRmh/f0JwYCZZd52FQtLgOkjoNUcsWAZ3EhLCygveLVn3lMt4CMuQ0kAc29eh2
ZiLzmk4KjXbCHw==
-----END PRIVATE KEY-----
server.crt0000644000000000000000000000765413260272046011612 0ustar rootrootCertificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=TW, ST=TW, L=Taipei, O=netgear, OU=netgear, CN=netgear CA/name=EasyRSA/emailAddress=mail@netgear
Validity
Not Before: Apr 2 00:07:02 2018 GMT
Not After : Mar 28 00:07:02 2038 GMT
Subject: C=TW, ST=TW, L=Taipei, O=netgear, OU=netgear, CN=server/name=EasyRSA/emailAddress=mail@netgear
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:ab:c4:87:05:de:b8:85:d2:03:3c:e6:a5:72:7b:
29:6e:88:b2:53:d6:98:d6:33:38:5c:32:c9:0b:7b:
ba:21:cb:1c:9c:b4:79:ca:96:65:cb:7d:11:e3:1a:
29:0b:0e:70:e0:82:9f:9e:02:c9:ac:f4:09:c1:5a:
f8:84:be:9d:81:cf:26:fe:13:ec:38:f1:26:c5:6e:
df:38:96:cb:ab:34:00:0f:28:31:e8:67:59:cc:31:
62:37:5c:05:eb:7f:ff:51:33:da:b5:62:6a:bd:6d:
cd:a1:f2:69:a5:2a:55:b5:f2:5a:9c:8e:c6:18:13:
74:9f:4e:e8:d1:2a:66:d9:b7
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Cert Type:
SSL Server
Netscape Comment:
Easy-RSA Generated Server Certificate
X509v3 Subject Key Identifier:
D5:D4:CB:91:14:5F:B9:F6:EB:0E:2E:7B:EE:4A:E6:B4:E5:06:38:29
X509v3 Authority Key Identifier:
keyid:25:80:03:9F:79:A6:75:E0:05:29:D1:F1:6C:16:D1:A2:56:D4:FB:EA
DirName:/C=TW/ST=TW/L=Taipei/O=netgear/OU=netgear/CN=netgear CA/name=EasyRSA/emailAddress=mail@netgear
serial:FC:DB:AA:17:93:7E:3B:21
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage:
Digital Signature, Key Encipherment
Signature Algorithm: sha256WithRSAEncryption
8e:1d:2b:b1:67:26:a5:72:a5:50:5e:74:78:c9:c4:c5:06:c3:
63:43:9c:5f:51:15:00:b3:99:f9:05:78:e1:2e:7d:83:83:a3:
d9:f0:02:07:fb:f1:39:7e:06:67:d5:d8:dc:e9:37:db:23:58:
b1:90:38:6f:23:b2:73:e1:36:94:b3:dc:8f:56:39:2d:19:e1:
b9:6b:26:6b:eb:e1:77:62:c2:31:8d:09:dc:99:05:68:18:9f:
e4:e1:cd:c5:5d:7c:75:fb:03:ad:a5:18:8c:e0:ea:a8:a9:d2:
22:90:a1:a2:ec:18:85:d4:56:02:27:74:64:cc:2a:83:2d:20:
4e:22
-----BEGIN CERTIFICATE-----
MIIEADCCA2mgAwIBAgIBATANBgkqhkiG9w0BAQsFADCBkzELMAkGA1UEBhMCVFcx
CzAJBgNVBAgTAlRXMQ8wDQYDVQQHEwZUYWlwZWkxEDAOBgNVBAoTB25ldGdlYXIx
EDAOBgNVBAsTB25ldGdlYXIxEzARBgNVBAMTCm5ldGdlYXIgQ0ExEDAOBgNVBCkT
B0Vhc3lSU0ExGzAZBgkqhkiG9w0BCQEWDG1haWxAbmV0Z2VhcjAeFw0xODA0MDIw
MDA3MDJaFw0zODAzMjgwMDA3MDJaMIGPMQswCQYDVQQGEwJUVzELMAkGA1UECBMC
VFcxDzANBgNVBAcTBlRhaXBlaTEQMA4GA1UEChMHbmV0Z2VhcjEQMA4GA1UECxMH
bmV0Z2VhcjEPMA0GA1UEAxMGc2VydmVyMRAwDgYDVQQpEwdFYXN5UlNBMRswGQYJ
KoZIhvcNAQkBFgxtYWlsQG5ldGdlYXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ
AoGBAKvEhwXeuIXSAzzmpXJ7KW6IslPWmNYzOFwyyQt7uiHLHJy0ecqWZct9EeMa
KQsOcOCCn54Cyaz0CcFa+IS+nYHPJv4T7DjxJsVu3ziWy6s0AA8oMehnWcwxYjdc
Bet//1Ez2rViar1tzaHyaaUqVbXyWpyOxhgTdJ9O6NEqZtm3AgMBAAGjggFkMIIB
YDAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIGQDA0BglghkgBhvhCAQ0EJxYl
RWFzeS1SU0EgR2VuZXJhdGVkIFNlcnZlciBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU
1dTLkRRfufbrDi577krmtOUGOCkwgcgGA1UdIwSBwDCBvYAUJYADn3mmdeAFKdHx
bBbRolbU++qhgZmkgZYwgZMxCzAJBgNVBAYTAlRXMQswCQYDVQQIEwJUVzEPMA0G
A1UEBxMGVGFpcGVpMRAwDgYDVQQKEwduZXRnZWFyMRAwDgYDVQQLEwduZXRnZWFy
MRMwEQYDVQQDEwpuZXRnZWFyIENBMRAwDgYDVQQpEwdFYXN5UlNBMRswGQYJKoZI
hvcNAQkBFgxtYWlsQG5ldGdlYXKCCQD826oXk347ITATBgNVHSUEDDAKBggrBgEF
BQcDATALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQELBQADgYEAjh0rsWcmpXKlUF50
eMnExQbDY0OcX1EVALOZ+QV44S59g4Oj2fACB/vxOX4GZ9XY3Ok32yNYsZA4byOy
c+E2lLPcj1Y5LRnhuWsma+vhd2LCMY0J3JkFaBif5OHNxV18dfsDraUYjODqqKnS
IpChouwYhdRWAid0ZMwqgy0gTiI=
-----END CERTIFICATE-----
server.key0000600000000000000000000000162413260272046011571 0ustar rootroot-----BEGIN PRIVATE KEY-----
MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBAKvEhwXeuIXSAzzm
pXJ7KW6IslPWmNYzOFwyyQt7uiHLHJy0ecqWZct9EeMaKQsOcOCCn54Cyaz0CcFa
+IS+nYHPJv4T7DjxJsVu3ziWy6s0AA8oMehnWcwxYjdcBet//1Ez2rViar1tzaHy
aaUqVbXyWpyOxhgTdJ9O6NEqZtm3AgMBAAECgYA7HhzKrGkdxbZPk6KF0FXmMS4P
JODdeCuBsAj55s+dKebjGEqCq1jFvHoXi71sjL/UxaBiJdt7p1JkNgcqyOA0aK57
iFIKYuuuwwP8GRqrdKqSyUaiPc//r8G7VY6kBU/IB418VjUAHJHjaheR3avZT+jO
YDXgllircUGGbe4IoQJBANxGHKi2IUAiZs353zg+95EklyGGMdaTQaYnj4+o+13C
+OEXLWFk9ANvTYELZveJHl8uDdTt27vYaak/xZIVSXMCQQDHoGmsET5zV8rTtesK
H4NLcWExSJGyex4ua1Ui6jL11q7zUdsKZ6OJIC4U51iD5/qLqMlHKoiQKXfccePg
uS2tAkB5aV/EklbzfcLCh5bE7tgQNWXkAY6Y4iPOTIHxwkeC38PEdbz6sOVau0+x
8DH6AKcv+TeAhPaXrGpY8qCYq4kHAkAogYIvqegUG3JKdxVUHoTToBPqniECKD09
igXiacchXwhs0uUxPUpPnrn6/95UFZQfFoaQ7C59ogxyLKHijXCZAkEAktcWYCMy
uWqX1oKuoxSrDBnlBbeepUysRoyJHN4oxPmV3q7pJuggs6RCEM7JnH/PrG4f/c+A
R79YuxwbCyJy2Q==
-----END PRIVATE KEY-----
This doesn't say all that much about the state of other partitions, but this one is intact as far as I can see.
I using that patch too,but I can get 100Mbps bandwidth which my isp provide max.
Could you do iperf test which is your local machine as server (-s) and router as client (-c)?
What I meant was data flow from router itself is capped at 20Mbits such as samba copy files from router USB port. Otherwise it's fine I can get max port speed too.
i used iperf3 and let pc as server,it get less than 17 mbps
there is a new firmware for qca9984
https://github.com/kvalo/ath10k-firmware/commit/bc6552ce5bbc5cae2efd275f97248512dbd63831
Sounds good.
Looking more closely at the OEM source:
- the six UBI partitions inside "netgear" are defined in netgear.cfg: https://github.com/paul-chambers/netgear-r7800/blob/eeac2e10190f6f45e32e4c7012c4babc351898d8/target/linux/ipq806x/base-files/etc/netgear.cfg
- Netgear's preinit script seems to contain code that checks those partitions at preinit, and if necessary, reads the UBI definitions from netgear.cfg and rewrites those partitions: https://github.com/paul-chambers/netgear-r7800/blob/eeac2e10190f6f45e32e4c7012c4babc351898d8/target/linux/ipq806x/base-files/etc/preinit#L26
if [ "x`grep overlay_volume /proc/mtd`" = "x" -a "x`grep netgear /proc/mtd`" != "x" ]; then
ubinize -m 2048 -p 128KiB -o /tmp/ubi.image /etc/netgear.cfg
mtdn=`grep netgear /proc/mtd | awk -F ':' '{print $1}' | awk -F 'd' '{print $2}'`
ubidetach /dev/ubi_ctrl -m $mtdn
flash_erase /dev/mtd$mtdn 0 0
nandwrite -p /dev/mtd$mtdn /tmp/ubi.image
ubiattach /dev/ubi_ctrl -m $mtdn
if [ "x`grep overlay_volume /proc/mtd`" = "x" ]; then
echo "Error: attach overlay_volume mtd device fail!"
fi
fi
If I read that code right, it checks if the last sub-partition "overlay_volume" is found. If not, then a new UBI volume is initialised to /tmp using netgear.cfg, "netgear" flash area erased, and the new UBI image written into it.
Based on that, it looks like six partitions are re-populated as empty. Likely the certificates are there since the first contact to Netgear, or something like that.
It really might be safe to take that extra area into use.
1 Like
2,125MiB to be exact - 17 erase blocks by 128KiB.
I verified it myself: the OEM firmware clears and re-populates the six sub-partitions that form the netgear partition, if their contents do not match expectations.
"cert" gets a new generated certificate for VPN connections.
Validity
Not Before: Jun 3 12:40:05 2018 GMT
Not After : May 29 12:40:05 2038 GMT
Other sub-partitions are also initialised.
I flashed a modified build (master-r7093-4fdc6ca31b-20180603-large-70MB-flash) and filled it up with random data, flashed the newest OEM firmware V1.0.2.52, played with OEM settings and let it re-create the certificate for VPN, and then flashed vanilla Openwrt to see the outcome.
Works ok, so I will likely author a pull request about that flash space allocation change.
When the TFTP is needed in any case with transition to 4.14, it might well be the right time to make the other flash allocation change at the same time, as @steom suggested.
1 Like
Did you remove the reserve partition as well, or only the netgear partition? I've removed both.
Just the netgear, as there is clear re-initialisation logic for it.
EDIT:
the "reserve" contains 4 actual OEM partitions:
{"crashdump", 0x03c8, 0x0004},
{"language", 0x03cc, 0x001c},
{"config", 0x03e8, 0x0009},
{"pot", 0x03f1, 0x0009},
At least the "config" contains all your current OEM settings. So, overwriting that will pretty much garble your current settings in case your ever want to revert to the OEM. (The settings are visible even to Openwrt:
less /dev/mtd8
or
hexdump -C /dev/mtd8 | less
(and scroll to quite end, then a bit back)
...
usbDeviceName=/mntsda1@lltd_enable=0@guest_enable=0@ripd_enable=0@
upnp_scanType=1@upnp_TimeToLive=4@wan_pppoe_username=guest@
wla1_auth_mode=none@wlg1_auth_mode=none@wla_implicit_bf=1@
...
So, I do not see it as a good idea to overwrite that "reserve" partition.
1 Like
well.... we should check if the firmware recreate them too...
I'm fine with keeping the reserved partition, but I would like to point out that the NETGEAR firmware offers a possibility to back up the configuration:
Additionally, I find it a bit odd that the reserved partition doesn't cover all of the OEM partitions succeeding the netgear partition.
It's missing:
You are wrong.
"reserve" covers all those, and it is not missing anything.
cert, pot.bak, tracffic_meter +.bak and dongle are actually all part of the "netgear", like have I explained in the previous messages about "netgear".
mtd partition numbering does not correspond to the partition order on the flash. Note also that /proc/mtd does not show the start location, it only shows the size.
Kernel log shows the location better:
Openwrt:
[ 1.102678] 0x000000c80000-0x000001180000 : "APPSBL"
[ 1.111854] 0x000001180000-0x000001200000 : "APPSBLENV"
[ 1.113467] 0x000001200000-0x000001340000 : "art"
[ 1.118816] 0x000001340000-0x000001480000 : "artbak"
[ 1.123597] 0x000001480000-0x000001880000 : "kernel"
[ 1.133283] 0x000001880000-0x000003480000 : "ubi"
[ 1.181240] 0x000003480000-0x000007900000 : "netgear"
[ 1.297114] 0x000007900000-0x000008000000 : "reserve"
[ 1.309652] 0x000001480000-0x000003480000 : "firmware"
You need to look at the start offsets to understand the "reserve" contents properly.
Like I explained above:
the âreserveâ contains 4 actual OEM partitions (defined as 128 kB blocks):
OEM:
{"crashdump", 0x03c8, 0x0004},
{"language", 0x03cc, 0x001c},
{"config", 0x03e8, 0x0009},
{"pot", 0x03f1, 0x0009},
Those are 128 kB blocks, not 64 kB, so the hex math goes this way:
starts at 0x3c8 of 128 kB blocks = 0x7900000
size is 0x0004 + 0x001c + 0x0009 + 0x0009 = 0x0032 of 128 kB block = 0x0640000
So, those 4 start at 0x7900000 and their combined size is 0x0640000, which leaves some free space at the flash end (from 0x7f40000 to 0x8000000).
"reserve" has been defined as starting 0x7900000 and size 0x0700000, so even the remaining empty space is included in the definition.
1 Like
Sorry, it seems I got a lot of things mixed up. Thanks for taking your time to explain it =)
which dsa commit should i pick?
this or #338 in this topic
1 Like
I think that I tracked that down: the sysupgrade process uses ubi-based write tool "ubiupdatevol" instead of the old good mtd. Kernel and rootfs are written separately using that tool into an existing mtd partition, and the tool reads the mtd partition info from the currently running firmware. (there is no practical way to check inside the image for the new partition structure)
Apparently that tool also sets the ubi volume size info, so even if the new mtd partition is larger, the ubi volume is locked into its original smaller size.
platform_do_upgrade --> nand_do_upgrade --> nand_upgrade_tar
https://github.com/openwrt/openwrt/blob/a367645f23d2ed93ea29c7237fa1b2d6c3ded7e4/package/base-files/files/lib/upgrade/nand.sh#L273
It was maybe easier with the old approach (e.g. in ar71xx), where kernel and rootfs were just concatenated into one unified image.
(But there is also the "ubirsvol" tool included in the firmware, which is supposed to resize ubi volumes on the fly. So, it might be possibly to resize the volume after flashing to cover to the whole new area. But I have not tried that, and it might be that it is impossible to run it for the active rootfs partition.)
Well with sysupgrade we switch to ramfs so all ubi partition are unloaded
Think it's not a problem...
How can I test it? Also we should be able to scan the ubi size of the packed firmware and check if that is greater than the installed kernel
Will be difficult during sysupgrade, as you need to uncompress the firmware, then read and parse the binary DTS blob. I don't see that as easily feasible in the sysupgrade script.
After sysupgrade, in a running system it might be possible more easily to scrape the mtd partition size from /proc/mtd and compare that to the ubi volume size of the ubi volume in that mtd.
Testing could be done by flashing a large partition firmware image from a router running traditional small partition, and then after the boot use command line ubi tools to first try expanding that rootfs ubi volume.
ubirsvol is installed by default?
so we don't have some tool to just analyze ubi structure without decompress it?