Abratel Telecom & Info

1- Baixar os arquivos e instalar (install)

https://github.com/stascorp/rdpwrap/releases

2 – Abrir o cmd em modo administrador e, dar um stop no servico
C:\Program Files\RDP Wrapper>net stop termservice

2 – Testar abrindo o RDPConf e verificar que o Lister State esta Listening mas nao suportado. Pegar o Numero da Ver do Service State, no meu caso 10.0.14393.3503 e
tentar achar o complemento para voce colar no rdpwrap.ini (final do arquivo deixando a ultima linha em branco). No meu caso foi esse complemento (Abrir o notepad em modo administrador):

[10.0.14393.3503]
LocalOnlyPatch.x86=1
LocalOnlyOffset.x86=A6578
LocalOnlyCode.x86=jmpshort
LocalOnlyPatch.x64=1
LocalOnlyOffset.x64=8D8A1
LocalOnlyCode.x64=jmpshort
SingleUserPatch.x86=1
SingleUserOffset.x86=36CE5
SingleUserCode.x86=nop
SingleUserPatch.x64=1
SingleUserOffset.x64=1B6A4
SingleUserCode.x64=Zero
DefPolicyPatch.x86=1
DefPolicyOffset.x86=31209
DefPolicyCode.x86=CDefPolicy_Query_eax_ecx
DefPolicyPatch.x64=1
DefPolicyOffset.x64=F185
DefPolicyCode.x64=CDefPolicy_Query_eax_rcx
SLInitHook.x86=1
SLInitOffset.x86=45912
SLInitFunc.x86=New_CSLQuery_Initialize
SLInitHook.x64=1
SLInitOffset.x64=22C80
SLInitFunc.x64=New_CSLQuery_Initialize

[10.0.14393.3503-SLInit]
bInitialized.x86 =C2F94
bServerSku.x86 =C2F98
lMaxUserSessions.x86 =C2F9C
bAppServerAllowed.x86 =C2FA0
bRemoteConnAllowed.x86=C2FA4
bMultimonAllowed.x86 =C2FA8
ulMaxDebugSessions.x86=C2FAC
bFUSEnabled.x86 =C2FB0
bServerSku.x64 =E73D0
lMaxUserSessions.x64 =E73D4
bAppServerAllowed.x64 =E73D8
bInitialized.x64 =E8470
bRemoteConnAllowed.x64=E8474
bMultimonAllowed.x64 =E8478
ulMaxDebugSessions.x64=E847C
bFUSEnabled.x64 =E8480

4 – Altera o arquivo colando isso acima (no meu caso) e a data dele somente para que voce ao executar o update veja que realmente esta fazendo o carregamento desse arquivo.

C:\Program Files\RDP Wrapper>update.bat

5 – Inicie o trem service novamente

C:\Program Files\RDP Wrapper>net stop termservice

6 – Cheque o status, deve ver em Listener state: listening [fully supported]

7 – Desabilita as atualizacoes automaticacs do windows.

:)

Fonte: clubedohardware.com.br

A maioria dos fabricantes de radios usa dBm – potencia em decibéis – (abbreviation for the power ratio in decibels (dB)) como medida de potencia de sinal.

Alguns poucos usam RSSI -potencia em porcentagem (received signal strength indication (RSSI)) como forma de medir a potencia do sinal.

Neste site você encontra a forma de calcular e comparar as duas formas de medir a potencia dos rádios

http://www.wildpackets.com/elements/whitepapers/Converting_Signal_Strength.pdf

Veja a tabela comparativa RSSI x dBm

Conversion for Cisco

Cisco has the most granular dBm lookup table.

RSSI_Max = 100

Convert % to RSSI and lookup the result in the following table. The RSSI is on the left,

and the corresponding dBm value (a negative number) is on the right.

0 = -113

1 = -112

2 = -111

3 = -110

4 = -109

5 = -108

6 = -107

7 = -106

8 = -105

9 = -104

10 = -103

11 = -102

12 = -101

13 = -99

14 = -98

15 = -97

16 = -96

17 = -95

18 = -94

19 = -93

20 = -92

21 = -91

22 = -90

23 = -89

24 = -88

25 = -87

26 = -86

27 = -85

28 = -84

29 = -83

30 = -82

31 = -81

32 = -80

33 = -79

34 = -78

35 = -77

36 = -75

37 = -74

38 = -73

39 = -72

40 = -70

41 = -69

42 = -68

43 = -67

44 = -65

45 = -64

46 = -63

47 = -62

48 = -60

49 = -59

50 = -58

51 = -56

52 = -55

53 = -53

54 = -52

55 = -50

56 = -50

57 = -49

58 = -48

59 = -48

60 = -47

61 = -46

62 = -45

63 = -44

64 = -44

65 = -43

66 = -42

67 = -42

68 = -41

69 = -40

70 = -39

71 = -38

72 = -37

73 = -35

74 = -34

75 = -33

76 = -32

77 = -30

78 = -29

79 = -28

80 = -27

81 = -25

82 = -24

83 = -23

84 = -22

85 = -20

86 = -19

87 = -18

88 = -17

89 = -16

90 = -15

91 = -14

92 = -13

93 = -12

94 = -10

95 = -10

96 = -10

97 = -10

98 = -10

99 = -10

100 = -10

Notice that this gives a range of –10dBm to –113dBm. Bearing in mind that a Cisco card

will have a Receive Sensitivity of –96dBm at its lowest, it is impossible to obtain an RSSI

value of less than 16. Note, also, that all RSSI values greater than 93 are assigned

–10dBm, and that there are multiple places in the table where two adjacent RSSI values

are assigned the same dBm value.

by https://wiki.mikrotik.com/wiki/Hairpin_NAT

Hairpin NAT
In the below network topology a web server behind a router is on private IP address space, and the router performs NAT to forward traffic to its public IP address to the web server behind it.

The NAT configuration would look like below:

/ip firewall nat
add chain=dstnat dst-address=1.1.1.1 protocol=tcp dst-port=80 \
action=dst-nat to-address=192.168.1.2
add chain=srcnat out-interface=WAN action=masquerade
When a client out on the Internet with IP address 2.2.2.2 establishes a connection to the web server, the router performs NAT as configured.

the client sends a packet with a source IP address of 2.2.2.2 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 2.2.2.2.
the server replies to the client’s request and the reply packet has a source IP address of 192.168.1.2 and a destination IP address of 2.2.2.2.
the router determines that the packet is part of a previous connection and undoes the destination NAT, and puts the original destination IP address into the source IP address field. The destination IP address is 2.2.2.2, and the source IP address is 1.1.1.1.
The client receives the reply packet it expects, and the connection is established.

When a client on the same internal network as the web server requests a connection to the web server’s public IP address, the connection breaks.

the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. The source IP address stays the same: 192.168.1.10.
the server replies to the client’s request. However, the source IP address of the request is on the same subnet as the web server. The web server does not send the reply back to the router, but sends it back directly to 192.168.1.10 with a source IP address in the reply of 192.168.1.2.
The client receives the reply packet, but it discards it because it expects a packet back from 1.1.1.1, and not from 192.168.1.2. As far as the client is concerned the packet is invalid and not related to any connection the client previously attempted to establish.

To fix the issue, an additional NAT rule needs to be introduced on the router to enforce that all reply traffic flows through the router, despite the client and server being on the same subnet. The rule below is very specific to only apply to the traffic that the issue could occur with – if there are many servers the issue occurs with, the rule could be made broader to save having one such exception per forwarded service.

/ip firewall nat
add chain=srcnat src-address=192.168.1.0/24 \
dst-address=192.168.1.2 protocol=tcp dst-port=80 \
out-interface=LAN action=masquerade
Hairpin nat 4.png

With that additional rule, the flow now changes:

the client sends a packet with a source IP address of 192.168.1.10 to a destination IP address of 1.1.1.1 on port tcp/80 to request some web resource.
the router destination NATs the packet to 192.168.1.2 and replaces the destination IP address in the packet accordingly. It also source NATs the packet and replaces the source IP address in the packet with the IP address on its LAN interface. The destination IP address is 192.168.1.2, and the source IP address is 192.168.1.1.
the web server replies to the request and sends the reply with a source IP address of 192.168.1.2 back to the router’s LAN interface IP address of 192.168.1.1.
the router determines that the packet is part of a previous connection and undoes both the source and destination NAT, and puts the original destination IP address of 1.1.1.1 into the source IP address field, and the original source IP address of 192.168.1.10 into the destination IP address field.
The client receives the reply packet it expects, and the connection is established.

However, the web server only ever sees a source IP address of 192.168.1.1 for all requests from internal clients regardless of the internal client’s real IP address. There is no way to avoid this without either using a router that can do application level DNS inspection and can rewrite A records accordingly, or a split DNS server that serves the internal clients the internal server IP address and external clients the external server IP address.

This is called – among other terms – hair pin NAT because the traffic flow has clients enter the router through the same interface it leaves through, which when drawn looks like a hair pin.