The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:11:36Zhttps://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/30947Add a source line to the header, because type must always be fallback2020-06-27T14:11:36ZteorAdd a source line to the header, because type must always be fallbackThe dir list spec says that fallback files start with:
`/* type=fallback */`
https://gitweb.torproject.org/torspec.git/tree/dir-list-spec.txt#n140
But in legacy/trac#24953, we change type to whitelist by default. This might cause some p...The dir list spec says that fallback files start with:
`/* type=fallback */`
https://gitweb.torproject.org/torspec.git/tree/dir-list-spec.txt#n140
But in legacy/trac#24953, we change type to whitelist by default. This might cause some parsers to break.
Instead, we should add a new `/* source=whitelist|fallback*/` line.Tor: 0.4.1.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/30948Copy the relevant parts of .gitignore to fallback-scripts2020-06-27T14:11:36ZteorCopy the relevant parts of .gitignore to fallback-scriptsteorteorhttps://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/30951Follow up broken relays from fallback opt-ins2020-06-27T14:11:36ZteorFollow up broken relays from fallback opt-insThese relays couldn't be added to the fallback whitelist:
```
## Relays that need follow up ##
# https://lists.torproject.org/pipermail/tor-relays/2019-May/017325.html
# 2206C72ECC0D55593BC7B698F982533F1E141DD2 not found in recent descr...These relays couldn't be added to the fallback whitelist:
```
## Relays that need follow up ##
# https://lists.torproject.org/pipermail/tor-relays/2019-May/017325.html
# 2206C72ECC0D55593BC7B698F982533F1E141DD2 not found in recent descriptors
# Email sent directly to gus
# AFD1E28D6BFDFF03E715AF06259167ADA0E0CB1D not found in recent descriptors
# https://lists.torproject.org/pipermail/tor-relays/2019-June/017393.html
# A85FF376759C994A8A1168D8D8219C8C43F6C5E1 not found in recent descriptors
# https://lists.torproject.org/pipermail/tor-relays/2019-June/017394.html
# A850B6A31ED83FB92B34FB3AE0513902D053A1C8 needs a DirPort
# https://lists.torproject.org/pipermail/tor-relays/2019-June/017395.html
# E8D114B3C78D8E6E7FEB1004650DD632C2143C9E needs a DirPort
# https://lists.torproject.org/pipermail/tor-relays/2019-June/017398.html
# C6B656BA6BC16E31115A1B2D56396A53165F3408 needs a DirPort
```teorteorhttps://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/30952Work out why the latest fallback list only has 127 entries2020-06-27T14:11:36ZteorWork out why the latest fallback list only has 127 entriesWe seem to have dropped 25 since last time, which isn't great.
I should also look at the long-term number of fallbacks.We seem to have dropped 25 since last time, which isn't great.
I should also look at the long-term number of fallbacks.teorteorhttps://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/31305Add more useful logging to fallback scripts variable config2020-06-27T14:11:34ZteorAdd more useful logging to fallback scripts variable configIn legacy/trac#29100, nickm says:
> As a followup, I suggest changing the definition of getvar_conf() so that on error, it gives a more useful explaining what the problem is, and changing the definition of opt() so that it turns the empt...In legacy/trac#29100, nickm says:
> As a followup, I suggest changing the definition of getvar_conf() so that on error, it gives a more useful explaining what the problem is, and changing the definition of opt() so that it turns the empty string and/or a missing option into None, but reports errors otherwise.teorteorhttps://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/32632Fallback Scripts Travis: Use the latest dependencies2020-06-27T14:11:34ZteorFallback Scripts Travis: Use the latest dependenciesUse the latest dependencies in Chutney Travis:
* Linux and macOS images
* python versionsUse the latest dependencies in Chutney Travis:
* Linux and macOS images
* python versionsteorteorhttps://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/32699Rename the fallback input list to an "offer list"2020-06-27T14:11:34ZteorRename the fallback input list to an "offer list"In legacy/trac#24839, we want to replace the list of relay operators who have offered their relays as fallbacks, with signed statements in descriptors via a torrc option.
As part of that transition, we should rename the internal variabl...In legacy/trac#24839, we want to replace the list of relay operators who have offered their relays as fallbacks, with signed statements in descriptors via a torrc option.
As part of that transition, we should rename the internal variables in the script, and the file in the repository. I suggest we use "fallback offer list".
We should also delete any remaining references to the blacklist, because it is obsolete, and the actual list was removed from the repository some time ago.
This change also has the benefit of avoiding the "white = good" metaphor, which can be confusing and problematic. For more details, see:
https://tools.ietf.org/id/draft-knodel-terminology-00.htmlteorteorhttps://gitlab.torproject.org/tpo/core/fallback-scripts/-/issues/32959Catch HTTPError in generateFallbackDirLine.py when descriptors are missing2020-06-27T14:11:34ZteorCatch HTTPError in generateFallbackDirLine.py when descriptors are missing```
$ $PYTHON generateFallbackDirLine.py 9695DFC35FFEB861329B9F1AB04C46397020CE31 BA44A889E64B93FAA2B114E02C2A279A8555C533 001524DD403D729F08F7E5D77813EF12756CFA8D 5AFAC3D00E97D6733112CC9CA2A788691FA87125 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA...```
$ $PYTHON generateFallbackDirLine.py 9695DFC35FFEB861329B9F1AB04C46397020CE31 BA44A889E64B93FAA2B114E02C2A279A8555C533 001524DD403D729F08F7E5D77813EF12756CFA8D 5AFAC3D00E97D6733112CC9CA2A788691FA87125 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
128.31.0.34:9131 orport=9101 id=9695DFC35FFEB861329B9F1AB04C46397020CE31 # moria1
66.111.2.131:9030 orport=9001 id=BA44A889E64B93FAA2B114E02C2A279A8555C533 ipv6=[2610:1c0:0:5::131]:9001 # Serge
Traceback (most recent call last):
File "generateFallbackDirLine.py", line 25, in <module>
desc = stem.descriptor.remote.get_server_descriptors(fingerprint).run()[0]
File "/usr/local/lib/python2.7/site-packages/stem/descriptor/remote.py", line 536, in run
return list(self._run(suppress))
File "/usr/local/lib/python2.7/site-packages/stem/descriptor/remote.py", line 547, in _run
raise self.error
stem.DownloadFailed: Failed to download from http://154.35.175.225:80/tor/server/fp/001524DD403D729F08F7E5D77813EF12756CFA8D (HTTPError): Servers unavailable
The command "$PYTHON generateFallbackDirLine.py 9695DFC35FFEB861329B9F1AB04C46397020CE31 BA44A889E64B93FAA2B114E02C2A279A8555C533 001524DD403D729F08F7E5D77813EF12756CFA8D 5AFAC3D00E97D6733112CC9CA2A788691FA87125 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" exited with 1.
```
https://travis-ci.org/torproject/fallback-scripts/jobs/637451068#L406teorteorhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/12661Some directory authorities reject IP ranges long after we ask them to stop2020-06-27T14:11:32ZTracSome directory authorities reject IP ranges long after we ask them to stopWhat's going on here?
-------------------
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '193.23.244.244:80'. Please correct.
Jul 20 00:45:16.000 [warn] http status 40...What's going on here?
-------------------
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '193.23.244.244:80'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '171.25.193.9:443'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '194.109.206.212:80'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '128.31.0.34:9131'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '154.35.32.5:80'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '76.73.17.194:9030'. Please correct.
Jul 20 00:45:16.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '208.83.223.34:443'. Please correct.
**Trac**:
**Username**: tmpname0901https://gitlab.torproject.org/tpo/core/dirauth/-/issues/14044"Authdir is rejecting routers in this range." from 146.148.0.0/172020-06-27T14:11:32ZTrac"Authdir is rejecting routers in this range." from 146.148.0.0/17283491B211C8BF1B259A136294263DF9EA1CC28A started reporting yesterday:
[WARN] http status 400 ("Authdir is rejecting routers in
this range.") response from dirserver '171.25.193.9:443'. Please
correct. [10 duplicates hidden]
[WARN] http ...283491B211C8BF1B259A136294263DF9EA1CC28A started reporting yesterday:
[WARN] http status 400 ("Authdir is rejecting routers in
this range.") response from dirserver '171.25.193.9:443'. Please
correct. [10 duplicates hidden]
[WARN] http status 400 ("Authdir is rejecting routers in
this range.") response from dirserver '193.23.244.244:80'. Please
correct. [10 duplicates hidden]
[WARN] http status 400 ("Authdir is rejecting routers in
this range.") response from dirserver '86.59.21.38:80'. Please
correct. [10 duplicates hidden]
[WARN] http status 400 ("Authdir is rejecting routers in
this range.") response from dirserver '194.109.206.212:80'. Please
correct. [10 duplicates hidden]
[WARN] http status 400 ("Authdir is rejecting routers in
this range.") response from dirserver '208.83.223.34:443'. Please
correct. [10 duplicates hidden]
I believe the netblock of this router in Google's cloud may have been recently blacklisted due to "Lizard Squad" abuse. If so, where can I find more information about it, and when the block will be lifted?
One of the affected GCE relays:
https://atlas.torproject.org/#details/283491B211C8BF1B259A136294263DF9EA1CC28A
**Trac**:
**Username**: tmpname0934https://gitlab.torproject.org/tpo/core/dirauth/-/issues/15500faravahar is missing to vote HSDir and Stable too often2020-06-27T14:11:32Zs7rfaravahar is missing to vote HSDir and Stable too oftenWhile asn and I were investigating the HSDir votes in the consensus for relays without V2Dir flag (no DirPort open) we discovered a strange behavior for faravahar:
Consensus:
network-status-version 3 microdesc
vote-status consensus
cons...While asn and I were investigating the HSDir votes in the consensus for relays without V2Dir flag (no DirPort open) we discovered a strange behavior for faravahar:
Consensus:
network-status-version 3 microdesc
vote-status consensus
consensus-method 18
valid-after 2015-03-24 23:00:00
fresh-until 2015-03-25 00:00:00
valid-until 2015-03-25 02:00:00
voting-delay 300 300
consensus: 2503 HSDir relays
faravahar: 1376 HSDir relays
consensus: 5302 Stable relays
faravahar: 3236 Stable relays
consensus: 2437 Stable and HSDir relays
faravahar: 1309 Stable and HSDir relays
consensus: 66 not Stable but HSDir relays
faravahar: 67 not Stable but HSDir relays
All HSDir relays in the consensus have also the V2Dir flag, because the majority of DAs haven't upgraded to mitigate legacy/trac#14202.
However, faravahar voted the HSDir flag for 520 relays who do not have the V2Dir flag and, obviously, these relays are not in the network agreed consensus. So, we can say faravahar actually voted for 1376 - 520 = 856 HSDir relays from the network agreed (useable by clients) consensus.
(From these 520 non-V2Dir HSDir relays:
- 23 relays are missing Stable falag.
- 497 are Stable.)
Results:
faravahar missed to vote 1647 HSDir flags
faravahar missed to vote 2066 Stable flags
We cannot say exactly that it missed to vote, since faravahar does not have to agree with the rest of DAs on each and every vote - this is why we have a consensus based on votes / majority. Still, the difference should be smaller than we currently see.
While it is normal for each DA not to vote exactly identical, we see a difference for the HSDir relays of 1647. This is more than 50% of all HSDirs voted by the rest of 8 DAs.
For the HSDir flags missed by faravahar, we thought that it has a very high value for MinUptimeHidServDirectoryV2 and it only votes HSDir flag for relays with very high uptime. A closer look on faravahar HSDir votes eliminates that assumption. For reference:
Fingerpints of relays for which faravahar voted HSDir | uptime at time of writing (24.03.2015):
003000C32D9E16FCCAEFD89336467C01E16FB00D 5 days
00339258B444376593E069201C4A4AA45F95AA87 15 days
0063D0DE32C80691A0AC1A968A8CCF5ABA420E29 57 days
0086EF7F056983D5A0EBB37F36A44CB738B16D97 20 days
0124398EE6783F402A6FC430D0AD110982E503AC 16 days
016DD78B2C3A468DDD48AF63F48D25660F93DAAC 4 days
0192067CFC14F3E3022F99D32FC39016C270AC4C 9 days
0473E3701C9EA2F8367DBAB453B6DC4EE78DEE1B 17 days
0522B7D9FBDFA6FDA81DC6B12A8FA0BA1F7084B4 6 days
C309A31AD772FFDD0805C9FECB6D4748A7CBF684 4 days
5 days later the behavior did not change:
network-status-version 3
vote-status vote
consensus-methods 13 14 15 16 17 18 19 20
published 2015-03-28 21:50:01
valid-after 2015-03-28 22:00:00
fresh-until 2015-03-28 23:00:00
valid-until 2015-03-29 01:00:00
3145 HSDir relays in the consensus
1585 HSDir relays seen by faravahar
5165 Stable relays in the consensus
3214 Stable relays seen by faravahar
And, it is missing just HSDir and Stable flags, because it sees almost all relays in the consensus as running:
running relays in consensus: 6623
running relays seen by faravahar: 6443
The difference is not so big for the running relays as it is for HSDirs and Stables.Aaron GibsonAaron Gibsonhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/17299Standardize comment in dirauth-conf2020-06-27T14:11:32ZDavid Gouletdgoulet@torproject.orgStandardize comment in dirauth-confAfter discussions in Berlin, I would like to propose a standard format for the comment of an entry(ies). Benefits are that we can validate the format of the file easily with a verifier script and also automatically cleanup on a regular b...After discussions in Berlin, I would like to propose a standard format for the comment of an entry(ies). Benefits are that we can validate the format of the file easily with a verifier script and also automatically cleanup on a regular basis the file of old entries with a simple script.
Furthermore, it makes it much more readable and traceable for each rules.
Format would look like this:
```
# Reported-by: Gargamel <gargamel@smurf.com>
# Date: Tue, 5 May 1987 20:45:57
# Time-Period: 3 months
# MessageID: <ID of first email on bad-relays@>
# Reason: <why was it blocked. add any relevant data about this>
# [...] (as many line as we need for this)
# Fingerprints: FP1[,FP2,FP3,...]
AuthDirBadExit 0.0.0.0
```
`Date`: the UTC timestamp of when the bad relay was detected.
`Time-Period`: time period for which we keep blocking this entry. In this example, it would be OK to remove the entry on August 5th (3 months later).
`Reason`: description on why it was blocked. Can be multiple lines.
`Fingerprints`: [optional] fingerprint of the blocked relay (or list seperated by comma) if applicable. If we blacklist a whole network because we got 1000+ relays, we can omit it.
The rest is self explainable.
phw already uses a nice format in the latest commit, this just makes it more formal. I'll attach a small script to the ticket that we can at some point add to the repository that will print to the user the template with some defaults for which the user can only fill in the blanks.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/17303Bad exits inject port 8123 into HTTP redirects2020-06-27T14:11:31ZTracBad exits inject port 8123 into HTTP redirectsSomeone who running Tor exit is using Polipo to analyze traffic.
I'm browsing HTTP via Tor and suddenly I was redirected to
host:8123. TCP 8123 is used by Polipo.
Please stop this f**ker by adding "Fraud detection" system on tor itself...Someone who running Tor exit is using Polipo to analyze traffic.
I'm browsing HTTP via Tor and suddenly I was redirected to
host:8123. TCP 8123 is used by Polipo.
Please stop this f**ker by adding "Fraud detection" system on tor itself.
e.g.,
Tor should add its fingerprint to temporary blacklist and share to Tor
project if any conditions apply:
1. all HTTP requests are redirected to !HTTP. (80--->8123)
2. make a HTTP connection to known website(not HTTPS), and verify it.
**Trac**:
**Username**: ikurua22Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/17337urras is down2020-06-27T14:11:31ZDamian Johnsonurras is downTracking ticket for urras' ongoing outage. Jake is well aware of the issue and working on it.Tracking ticket for urras' ongoing outage. Jake is well aware of the issue and working on it.Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/dirauth/-/issues/17338High latency from Faravahar2020-06-27T14:11:31ZDamian JohnsonHigh latency from FaravaharFaravahar is experiencing elevated latency, for instance when fetching the consensus...
| maatuska | tor26 | longclaw | dizum | gabelmoo | moria1 | dannenberg | Faravahar |
|----------|-------|----------|-------|----------|--------|---...Faravahar is experiencing elevated latency, for instance when fetching the consensus...
| maatuska | tor26 | longclaw | dizum | gabelmoo | moria1 | dannenberg | Faravahar |
|----------|-------|----------|-------|----------|--------|------------|-----------|
| 5.4s | 4.9s | 4.0s | 4.9s | 4.7s | 5.3s | 5.1s | timed out |
| 5.9s | 5.0s | 3.8s | 5.2s | 5.0s | 4.7s | 4.9s | 70.1s |
| 7.4s | 5.0s | 3.8s | 5.0s | 5.1s | 5.0s | 5.3s | 18.3s |
| 7.3s | 5.0s | 4.2s | 5.0s | 5.2s | 4.6s | 5.6s | 69.7s |
| 7.4s | 5.1s | 3.8s | 5.1s | 5.1s | 4.2s | 5.3s | 70.2s |
| 7.6s | 5.2s | 3.9s | 5.1s | 5.2s | 4.3s | 5.5s | 33.7s |
This is a relatively new issue (just started a couple weeks ago) and Sina has already reached out to his hosting provider to look into it.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/17339Reject relay cycling fingerprint2020-06-27T14:11:31ZDamian JohnsonReject relay cycling fingerprintHi lovely dirauths. The relay at 67.173.119.40 is rapidly cycling its fingerprint at the rate of twice an hour (aka, 5,184,000 times per 30 days). This is likely an attempt to get a privileged position in hidden service hash rings, and w...Hi lovely dirauths. The relay at 67.173.119.40 is rapidly cycling its fingerprint at the rate of twice an hour (aka, 5,184,000 times per 30 days). This is likely an attempt to get a privileged position in hidden service hash rings, and warrants a Reject clause.
Unfortunately rejection requires a lot of coordination, hence the ticket. **Please remove your keyword from this ticket when done.**
```
The following relays are frequently changing their fingerprints...
* 67.173.119.40:51256
04F8A4780C76D0D3253457A8C77C4F855A4DAAE8 at 2015-10-10 13:37:10
12589E3275A2E0CC4C6297057748AF367233368F at 2015-10-10 13:12:25
1B817440B2FA7AF5DA8E71FD0F00D08171B4F209 at 2015-10-10 12:37:15
246CACF6B30789927E8BCD66BF88E86B9BB987F0 at 2015-10-10 12:27:20
179D8614B501C50E9250B668421C08970FAC408D at 2015-10-10 11:37:21
118513A0EF1DD12886C33A8929AB125AC66E14C8 at 2015-10-10 11:17:17
01230FD73BD69DCC67713FE987FCA6D84FDB0521 at 2015-10-10 10:42:21
0E535EE773B476A897EAA9C2A2F4219A4ED8E5DF at 2015-10-10 10:17:52
155F3598587F7B54C33A17F0DE0DCCDC047BB077 at 2015-10-10 09:42:53
... and 262 more since 2015-10-04 20:42:08
```https://gitlab.torproject.org/tpo/core/dirauth/-/issues/17813IPv6 address for urras2020-06-27T14:11:31ZteorIPv6 address for urrasI'm trying to get Tor clients to bootstrap over IPv6 (legacy/trac#17281).
This requires adding directory authorities' IPv6 addresses to the tor source code.
urras has an IPv6 address (legacy/trac#17298), but it isn't being displayed in ...I'm trying to get Tor clients to bootstrap over IPv6 (legacy/trac#17281).
This requires adding directory authorities' IPv6 addresses to the tor source code.
urras has an IPv6 address (legacy/trac#17298), but it isn't being displayed in Globe at the moment.
Can you let me know if there's an IPv6 address for urras you want me to add, or if I should leave it out for the moment?https://gitlab.torproject.org/tpo/core/dirauth/-/issues/18164Clean out old dirauth bad.conf entries2020-06-27T14:11:31Zmicahmicah@torproject.orgClean out old dirauth bad.conf entriesIn an effort to move towards standardizing bad.conf so it can be machine parseable (legacy/trac#17229 and legacy/trac#12261), because there is no process for cleaning out this file, and because there are entries in this file from 2007......In an effort to move towards standardizing bad.conf so it can be machine parseable (legacy/trac#17229 and legacy/trac#12261), because there is no process for cleaning out this file, and because there are entries in this file from 2007... we need to clean out the old entries in this file.
It was discussed in Berlin among some DA's about different approaches, at least three who used the repository indicated that they were fine with removing every entry in that file that was more than 6 months old.
We haven't done this yet. It is relatively easy to do, but before I just go in and delete most of that file and commit it, I wanted to give people the chance to comment on the proposed plan here.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/18350Directory Authorities bind DirPort to IPv62020-06-27T14:11:31ZteorDirectory Authorities bind DirPort to IPv6We should encourage directory authorities on IPv6 - gabelmoo, tor26, and longclaw - to bind their existing DirPort to IPv6 as well as IPv4.
maatuska does this already.
From legacy/trac#18348:
Currently most of the dir auths Dir port...We should encourage directory authorities on IPv6 - gabelmoo, tor26, and longclaw - to bind their existing DirPort to IPv6 as well as IPv4.
maatuska does this already.
From legacy/trac#18348:
Currently most of the dir auths Dir ports are only listening on their ipv4 address, including the dir auths with ipv6 OR addresses. An easy (but not necessary correct) solution is Dir Auth Op configure their dirauths so they accept ipv6 connections on the dir port. A better solution is tor knows when a dir port is ipv4 or ipv6 and chooses the correct corresponding ip address.https://gitlab.torproject.org/tpo/core/dirauth/-/issues/18493What is 213.251.199.174?2020-06-27T14:11:30ZcypherpunksWhat is 213.251.199.174?Whois says it is related to ZAO Countrycom (countrycom.ru which is redirected to alloincognito.ru).
It is a cellular network operator holding brandname alloincognito.
You can get information about the organization from https://egrul.nal...Whois says it is related to ZAO Countrycom (countrycom.ru which is redirected to alloincognito.ru).
It is a cellular network operator holding brandname alloincognito.
You can get information about the organization from https://egrul.nalog.ru/download/CC43C3392FC5792F3E57E55B6E28EB9ED923F8CC17EE963DB67C641EB4B88E68522F932D2301BA4F349CE8DDEAD737AB7E271009A7A197157281A5B84E7D6A93
I see nothing special in it, it looks like a usual card of a little company.
I want to thank them for their contribution, but I think their contribution should be analyzed, because they have all licenses the telecom company in Russia must have to operate legally, to have the licenses they must send all the traffic from their networks to FSB.