Skip to content

Commit aea1da4

Browse files
committed
Update readme for new install/persist/rearm/serial discovery
1 parent ed70682 commit aea1da4

1 file changed

Lines changed: 137 additions & 50 deletions

File tree

README.md

Lines changed: 137 additions & 50 deletions
Original file line numberDiff line numberDiff line change
@@ -1,20 +1,18 @@
11
# FS.com XGS-ONU-25-20NI AT&T Modification Utility
2-
This utility makes the necessary changes to the FS.com XGS-PON module to allow it to operate on AT&T's XGS-PON fiber offerings. It attempts to do so as safely as possible, reverting automatically to a stock state if it is ever power cycled twice in quick succession.
3-
4-
## Disclaimers
5-
Bypass the provided BGW320 at your own risk -- no matter how you go about it it is detectable and AT&T will find you if they go looking. This modification makes the minimum set of changes that I believe are necessary to get online but is intentionally trivially detectable. My rationale for this is that if anybody goes looking for these then chances are the devices are misbehaving and I'm not interested in making anybody's job harder than it needs to be.
6-
7-
Bypasses are detectable regardless of whether this device is used or any other (e.g. Azores D20 or WAS-110) -- the BGW320 hosts a variety of management services that won't be accessible from any customer bypassing provided equipment.
2+
This utility makes the necessary changes to the FS.com XGS-PON ONU to allow it to operate on AT&T (USA), Orange (FR), and other XGS-PON fiber offerings. It attempts to do so as safely as possible, reverting automatically to a stock state if it is ever power cycled twice in quick succession.
83

94
This particular FS.com device is actually a CIG XG-99S which is available under a variety of different brands. There is an entire family of devices running very similar firmwares that can likely also be modified in roughly the same way, though modifications to this utility would be required to support them. Of particular interest are the CIG XG-99M devices (best known as the FOX-222) which can be found for $30-$50 online as of writing and which I plan to look at in the near future.
105

116
While this modification attempts to be as safe _as possible_ it's much less safe than running an unmodified device. Although the device has two firmware slots they share the userdata partition that gets mounted to `/mnt/rwdir/`. During boot all CIG firmwares check for `/mnt/rwdir/setup.sh` and run it if it exists. This is done before the PON stack starts, so if anything goes wrong *it will never come online* and you will need UART access and micro-soldering skills to recover the device. For this reason, the modification disarms itself as the first action it takes during every boot -- that is the _only_ safety mechanism available.
127

8+
Bypassing an ISP's ONT with your own is relatively trivial to detect if they care to look. If this concerns you, don't do it.
9+
1310
## Requirements
1411
- Python 3.6+
15-
- The `install` command requires layer 2 adjacency to the stick (e.g. NO ROUTERS between you and the device, you have an address in `192.168.100.0/24`)
16-
- The `GPONxxxxxxxx` serial of the stick (you generally need to ask your FS.com rep for this, it's not included with the device as of August 2023)
12+
- The `install` command requires layer 2 adjacency to the stick (e.g. NO ROUTERS between you and the device, you must have an address in `192.168.100.0/24`, port `8172` must be opened)
13+
- The `GPONxxxxxxxx` serial of the stick (you generally need to ask your FS.com rep for this, it's not included with the device, or use the included brute force tools)
1714
- Stick running firmware `R4.4.20.018` or `R4.4.20.022` (other versions _may_ be safe)
15+
- If using the backdoor brute force feature (Linux only), the `pyroute2` pip package must be installed
1816

1917
This utility has been tested on:
2018
- openSUSE Leap 15.4
@@ -25,96 +23,185 @@ This utility is built on:
2523
- Ubuntu 22.04.2 LTS
2624

2725
## Features
28-
- Ethernet UNI moved from slot 10 to slot 1 in MIB entities, thus becoming compatible with AT&T bridge pack configurations
26+
- Ethernet UNI can be moved from slot 10 to slot 1 in MIB entities, thus becoming compatible with AT&T and Orange services
2927
- Disables traffic filtering when the Dot1X Port Extension Package (ME 290) is configured to filter all traffic
30-
- Uses serial provided to mod instead of the serial in EEPROM to allow the device to revert cleanly if the fail-safe triggers
31-
- Sets appropriate equipment id for NOKA/HUMA BGW320 devices depending on the provided serial
32-
- Starts `dropbear` 2 minutes or so after device boot for more convenient administration (no idle timeout)
28+
- Uses serial provided to mod instead of the serial in EEPROM to allow the device to revert cleanly to stock config if the fail-safe triggers
29+
- Sets appropriate equipment ID/hwver/swver automatically if it can be determined from the ISP/serial combo provided as arguments
30+
- Starts `dropbear` sshd 2 minutes or so after device boot for more convenient administration (no idle timeout)
31+
- Limited ability to modify/suppress Received Frame VLAN Tagging Operations Table rules found in Extended VLAN Tagging Operation Configuration Data (ME 171) (needed for Orange support)
3332

3433
## Usage
3534

36-
By convention the documentation below uses `GPON227000fe` to refer to the serial of the FS.com device and `HUMA12ab34cd` to refer to the ONT ID of your AT&T BGW320 device found on the bottom label.
35+
1. Download the mod from [the Releases page](https://github.com/rssor/fs_xgspon_mod/releases) and extract it on a device with L2 connectivity to the module
36+
2. Obtain the serial for the FS.com ONU, either by emailing your FS.com rep, or using the [serial brute forcing](#serial-brute-forcing) functionality of this tool.
37+
3. Run the [install](#installation) command with the information required by your ISP (at minimum serial, possibly also hwver, swver, and equipment ID)
38+
4. Wait several minutes for device to reboot, ensure you have internet connectivity
39+
5. Run the [persist](#enabling-persistence) command
40+
6. (Optional) Add a cron job on your gateway/router (NOT THIS DEVICE) to run the [rearm](#rearm) command regularly to recover from the failsafe condition if it triggers due to poorly timed power interruptions
3741

38-
Skip to [Installation](#installation) and [Enabling Persistence](#enabling-persistence) if you just want to get online.
42+
By convention the documentation below uses `GPON227000fe` to refer to the serial of the FS.com device and `HUMA12ab34cd` to refer to the serial of your ISP's ONT.
3943

40-
### Password Generation
44+
### Installation
4145

42-
Helper command to generate both sets of credentials from a provided serial. This is helpful if FS.com assigned you a sales rep that doesn't know how to get users online with these sticks and you're forced to brute force your stick credentials. By default only the telnet credentials are usable as nothing starts `dropbear` on stock firmwares.
46+
Ensure that you're sitting adjacent to the stick on the network and that you have an address in the `192.168.100.0/24` subnet. The stick is at `192.168.100.1`. Ensure that your machine is configured to accept conncections on port `8172` (you may need to add a firewall allow rule for this!). Activating the mod for a single boot only requires one command:
4347

4448
```
45-
./fs_xgspon_mod.py genpw GPON227000fe
46-
Creds for FS.com XGS-PON stick with serial GPON227000fe:
47-
Telnet: GPON227000fe / mbdu7pVX
48-
SSH: ONTUSER / vjyKsHYsU2Aym5Nn
49+
# ATT
50+
./fs_xgspon_mod.py install GPON227000fe att HUMA12ab34cd
51+
52+
# Frontier, with an assigned FRX523
53+
./fs_xgspon_mod.py install GPON227000fe frontier FTRO12ab34cd --eqvid FRX523
54+
55+
# Any arbitrary ISP as long as you know the equipment id/hwver/swver and necessary ethernet uni slot
56+
./fs_xgspon_mod.py install GPON227000fe manual ALCL12ab34cd --hwver SOMETHING --swver ELSE --eqvid EQUIPMENT --eth_slot 10
57+
58+
# Orange, with full example output
59+
./fs_xgspon_mod.py install GPON227000fe orange SMBSXXXXXXXX
60+
[+] Generated payload configuration:
61+
ETH10GESLOT=1
62+
EepEqVendorID=SMBS
63+
EepEqSerialNumber=SMBSXXXXXXXX
64+
EepVDSL2SerialNumber= VDSLSerialNumberSMBSXXXXXXXX
65+
EepEqVersionID=SMBSXLB7400
66+
VLAN_MOD_RULES=838,2,8,8 838,-1,-2,0 840,5,-1,-1 840,0,8,8 840,-1,-2,0 851,5,-1,-1 851,6,-1,-1 851,0,8,8 851,-1,-2,0
67+
[+] Telnet connection established, login successful
68+
[+] Webserver listening on 192.168.100.10:8172
69+
70+
[!] If this doesn't complete almost immediately, ensure there is no router between you and the device!
71+
[!] The stick MUST be able to connect back to this machine to retrieve the payload!
72+
[!] Also double check that there are no firewall rules blocking traffic to port 8172.
73+
74+
[+] Disarmed any potential existing install
75+
[+] Disabled auto-rearming if it was previously enabled
76+
192.168.100.1 - - [05/Jan/2024 22:19:06] "GET /config HTTP/1.1" 200 -
77+
[+] Stick retrieved payload configuration
78+
192.168.100.1 - - [05/Jan/2024 22:19:06] "GET /payload.tgz HTTP/1.1" 200 -
79+
[+] Stick retrieved and extracted payload
80+
[+] Payload extracted -- press enter to reboot the ONU!
81+
reboot
82+
83+
#ONT/system/shell>*** Connection closed by remote host ***
4984
```
5085

51-
The HMAC key used to derive passwords appears to be different between the various OEM customers, so I don't think this works for anything except the FS.com sticks.
86+
If installation fails chances are the stick isn't able to connect back to the machine you're running the utility from. It runs an HTTP server on port `8172` for the duration of installation that the stick needs to be able to connect to. I recommend punching a hole for all connections from `192.168.100.1` to port `8172`, at least when you need to run the installation command.
5287

53-
I suspect the serials take the form `GPONyymsssss` where `yy` is year, `m` is month, and `sssss` is number within run, but `yym` could be just batch numbers. Production runs seem to be very small so brute force won't take much time if you can guess roughly when your stick was manufactured. I have yet to see any serial with `sssss` greater than `000fe`.
88+
This will install everything necessary into `/mnt/rwdir/` on the device and set it up so that the next boot will take place with the mod active. It installs in a non-persistent mode, requiring use of the [rearm][#rearm] command after every boot or the use of the [persist](#enabling-persistence) command.
5489

55-
### Telnet
90+
### Enabling Persistence
5691

57-
Helper command so that you only need to remember the serial. Drops you immediately to an enabled `#ONT>` prompt.
92+
Persistence allows the modification to automatically re-arm itself approximately 100 seconds after PON stack initialization. It can only be turned on while the mod is active and the device has been powered on for several minutes in order to prove that the configuration results in a reachable device.
5893

5994
```
60-
./fs_xgspon_mod.py telnet GPON227000fe
61-
enable
62-
#ONT>
95+
# remember to use the serial of your ISP's ONT, not the one the FS stick came with!
96+
./fs_xgspon_mod.py persist HUMA12ab34cd
97+
[+] Telnet connection established, login successful
98+
[+] Persistence enabled
99+
[+] As a fail safe, power cycling shortly after initial boot (~30-120 seconds) will deactivate persistence until rearmed
63100
```
64101

65-
Automatically connects to the device, runs the `enable` command, and drops you do the ONT command prompt directly. If you want access to a shell, run `/s/s`. Ctrl-c to exit.
102+
### Rearm
66103

67-
### Installation
104+
Rearm is used to either re-enable persistence after the fail-safe triggers, or to enable the mod for the next boot if it's in non-persistent mode. If it detects that the failsafe had been triggered it will automatically reboot.
68105

69-
Ensure that you're sitting adjacent to the stick on the network and that you have an address in the `192.168.100.0/24` subnet. The stick is at `192.168.100.1`. Ensure that your machine is configured to allow conncections on port `8172`. Activating the mod for a single boot only requires one command:
106+
Recommended use is to set this up on an hourly or similar cron job on your gateway (using the original serial as an argument!) so that if the failsafe triggers it will be automatically re-enabled.
70107

71108
```
72-
./fs_xgspon_mod.py install GPON227000fe HUMA12ab34cd
109+
# remember to use the original serial
110+
./fs_xgspon_mod.py rearm GPON227000fe
111+
[+] Telnet connection established, login successful
112+
[+] Disarmed state cleared
113+
[+] Detected that the failsafe triggered, rebooting device...
73114
```
74115

75-
If installation fails chances are the stick isn't able to connect back to the machine you're running the utility from. It runs an HTTP server on port `8172` for the duration of installation that the stick needs to be able to connect to. I recommend punching a hole for all connections from `192.168.100.1` to port `8172`, at least when you need to run the installation command.
116+
While the mod is active it will simply do nothing because the ISP serial is active, but if the mod ever inactivates it will be able to connect and thus re-enable persistence and reboot back into the mod.
76117

77-
This will install everything necessary into `/mnt/rwdir/` on the device and set it up so that the next boot will take place with the mod active. By default every boot will delete the file necessary to support persistence so you'll need to run this command again if there's more than one power cycle.
118+
### Serial Brute Forcing
78119

79-
After reboot the device will come up with the serial you provided as the second argument, and therefore you would use that new serial to connect via telnet. This also provides a quick way to determine what state your stick is in: see which serial needs to be passed to get dropped to a prompt, then you know if the mod is active or not.
120+
FS.com doesn't distribute these with the serial you need to log in, requiring you to email your rep with the FS.com serial so they can look up the GPON serial for the stick. Fortunately, the serial number assignments are predictable and so there are two other options: brute forcing via telnet and brute forcing via a backdoor that CIG implements in a lot of their ONU offerings.
80121

81-
After the stick has rebooted and you've confirmed that you can get online you may then want to move on to [enabling persistence](#enabling-persistence).
122+
The serials take the form `GPONyymsssss` where `yy` is year (decimal, `23` for 2023), `m` is month (hex, `a` for October), and `sssss` is number within run. Production runs seem to be very small so brute force won't take much time if you can guess roughly when your stick was manufactured. I have yet to see any serial with `sssss` greater than `000fe`. These tools will try up through `00119` for each month.
82123

83-
### Enabling Persistence
124+
#### CIG Backdoor Brute Force (Linux only!)
84125

85-
Persistence allows the modification to automatically re-arm itself for the next boot after a ~100 second timer expires.
126+
Brute forcing all possible serials should take around 20-30 seconds as of Jan 2024. It starts from the current month/year and works backwards, and assumes there were no units produced before Jan 2022.
86127

87128
```
88-
./fs_xgspon_mod.py persist HUMA12ab34cd
129+
# must be root (or have CAP_NET_RAW), raw sockets are needed to send frames with the CIG backdoor ethertype!
130+
sudo ./fs_xgspon_mod.py discoverserial_cig
131+
[+] Validated target reachable via telnet, check for ARP entries...
132+
[+] Target reachable at MAC xxxxxxxxx from interface enp6s0 with MAC xxxxxxxxxx
133+
[!] Beginning processing chunk of 1000 serials (next: GPON24100000)
134+
[!] Beginning processing chunk of 1000 serials (next: GPON23b000e8)
135+
...
136+
[+] Telnet credentials: GPONXXXXXXXX / YYYYYYYY
89137
```
90138

91-
Several minutes after the device has been booted with the mod active it becomes possible to enable persistent mode. The wait is implemented in order to attempt to make it impossible to enable persistence without proving the device can come online _enough_ to be recoverable. While this is implemented as a 100 second wait in the `libvos` shim, realistically it winds up being a bit over 2 minutes.
92139

93-
This will fail if the device wasn't booted with the mod active or if you haven't waited long enough since it booted with the mod active.
140+
#### Telnet Brute Force
94141

95-
If you are able to connect to the device via SSH then this command should be functional. The shim starts dropbear at the same time as persistence becomes allowed.
142+
This is able to test around one password every 3 seconds or so. Should be able to tell you your serial if you run it overnight. As of Jan 2024 it needs to test up to 7200 serials.
143+
144+
```
145+
./fs_xgspon_mod.py discoverserial
146+
[!] Attempting GPON24100000
147+
...
148+
[+] Telnet credentials: GPONXXXXXXXX / YYYYYYYY
149+
```
96150

97-
### Fail-safe Recovery
151+
### Telnet Wrapper
98152

99-
In the event the failsafe triggers due to poorly timed power outages recovery is possible with only a few commands. Remember to use the serial in the device's EEPROM, either the one provided by FS.com reps if you didn't change it, or whatever you changed it to if you used the built-in commands to do so. Simply remove `/mnt/rwdir/disarmed` and reboot and the modification should be active again.
153+
Helper command so that you only need to remember the serial. Drops you immediately to an enabled `#ONT>` prompt.
100154

101155
```
102156
./fs_xgspon_mod.py telnet GPON227000fe
103157
enable
104-
#ONT> /s/s
105-
/s/s
106-
#ONT/system/shell>rm /mnt/rwdir/disarmed
107-
rm /mnt/rwdir/disarmed
108-
#ONT/system/shell>reboot
109-
reboot
158+
#ONT>
159+
```
160+
161+
Automatically connects to the device, runs the `enable` command, and drops you do the ONT command prompt directly. If you want access to a shell, run `/s/s`. Ctrl-c to exit.
162+
163+
### Telnet/SSH Password Generation
164+
165+
Helper command to generate both sets of credentials from a provided serial. This is helpful if FS.com assigned you a sales rep that doesn't know how to get users online with these sticks and you're forced to brute force your stick credentials. By default only the telnet credentials are usable as nothing starts `dropbear` on stock firmwares.
166+
110167
```
168+
./fs_xgspon_mod.py genpw GPON227000fe
169+
Creds for FS.com XGS-PON stick with serial GPON227000fe:
170+
Telnet: GPON227000fe / mbdu7pVX
171+
SSH: ONTUSER / vjyKsHYsU2Aym5Nn
172+
```
173+
174+
The HMAC key used to derive passwords appears to be different between the various OEM customers, so I don't think this works for anything except the FS.com sticks.
175+
176+
177+
## Troubleshooting / Advanced
178+
179+
### Finding right ETH10GESLOT
180+
181+
If you appear to be in a real O5 state (VLAN rules populated by the OLT) but traffic isn't passing, check the bridgepack configuration to see how the OLT is configuring the bridge. If the wrong slot is in use, you'll see an error in the MEC log (`/system/log/show mec`) along the lines of the following:
182+
183+
```
184+
c161 31 mec_cc.c 515 4 -------->MEC update all connections [START]
185+
c166 31 mec_cc.c 965 4 update mp port
186+
c167 31 mec_cc.c 1249 4 Eth uni [0x0101] not found
187+
c167 31 mec_cc.c 1002 4 bridge port cfg data not complete [0x0101]
188+
c167 31 mec_cfg.c 1406 1 mec_CfgDscpChangedInRuntime[0]: this conneciton is not completed!
189+
c168 31 mec_cc.c 629 4 <--------MEC update all connections [END + 1]
190+
```
191+
192+
This was taken from an unmodified stick (which defaults to using slot `10`, so the ETH UNI entity ID is `0x0a01`), but ATT was pushing a bridge config that would only work with an entity ID of `0x0101`. If you see an error like this, you'd need to add `--eth_slot 1` to your `install` command.
193+
194+
### VLAN_MOD_RULES
195+
196+
This device only supports up to 17 rules in the Received Frame VLAN Tagging Operation Table per UNI in ME 171. Some ISPs (namely Orange) require more than this number. This provides a facility through which rules can be effectively dropped before they are used during UNI configuration. Rules can be supplied using the `--vlan_rules` optional argument to the `install` command. Look at the rules in the Orange ISP implementation in the Python script for an explanation of how to craft them.
111197

112-
Wait a few minutes and it should come back online, responding to your AT&T NOKA/HUMA serial and getting you back online.
198+
If you run `/s/m/show 506` from telnet and see 17 or fewer rules, you almost certainly don't need to use this functionality.
113199

114200
## Thanks To
115201
- [miguemely](https://github.com/miguemely) - Initial testing, firmware dumps
116202
- [YuukiJapanTech](https://github.com/YuukiJapanTech) - Assembling the spectacular resources at https://github.com/YuukiJapanTech/CA8271x/
117203
- SipWannabe - Testing
204+
- Mastah - Testing/Debugging Orange connectivity issues
118205

119206
## References
120207
- https://github.com/YuukiJapanTech/CA8271x

0 commit comments

Comments
 (0)