Mixed Topic2

PPP uses two sub ptotocol

LCP and NCP

RIP deamons    

There are two versions of RIP that we must consider. The first

version of RIP communicates its routing information relative to itself.

For instance, a RIP v1 message looks like this: "If you would like to send

your packets to this subnet, they will get there in X hops if you send

them through me." A RIP v2 messages, on the other hand, communicates a lot

more information. It says: "If you would like to send your packets to this

subnet (with a subnet mask of X), then you can send it to this person and

it will be X hops away from it's destination." RIP version 2 communicates

the knowledge of other routers to the network, while RIP version 1

communicates just the knowledge of its routes.

RIP daemons can run in two modes: passive, or active. A passive

daemon will sit on the network and watch the routers communicate their

route information with each other. It will record this information, and

the machine it is running on will have an updated routing table. The

passive mode daemon will never advertise it's routes, unless a special

condition occurs. (We will cover that later). The active mode daemon will

continually advertise its routes to the network, and it will send its

routing information to any machine that requests it. The active mode

daemon is, of course, listening to the other routers advertisements and

incorporating them into it's routing table.

disk space

df -h

du shows disk space taken by files and directory

regexp to match all email address

\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b

#to match any email address

set a "Raj_btech23@rediffmail.com"

if {[regexp -- {^[A-Za-z0-9._-]+@[[A-Za-z0-9.-]+$} $a b]} {

puts $b

} else {

puts fail

}

#puts $a

In python:

Creating a regular expression to match all email addresses is a complex task due to the various formats allowed by the email specification (RFC 5322). The following regular expression is a basic one that covers a wide range of email formats:

```python

import re

email_regex = r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b'

# Example usage:

text = "Some text with emails user@example.com and another.email@example.co.uk"

matches = re.findall(email_regex, text)

print(matches)

```

This regular expression breaks down as follows:

- `\b`: Word boundary to ensure the email is not part of a larger word.

- `[A-Za-z0-9._%+-]+`: Local part of the email, which can include letters, digits, dots, underscores, percent signs, plus signs, and hyphens.

- `@`: The at symbol, separating the local part from the domain part.

- `[A-Za-z0-9.-]+`: Domain name, which can include letters, digits, dots, and hyphens.

- `\.`: Dot separating the domain from the top-level domain (TLD).

- `[A-Z|a-z]{2,}`: TLD, which must be at least two characters long.

Keep in mind that this regex is not exhaustive and may not cover all possible edge cases. The complete validation of email addresses is a complex task, and in some cases, it might be more appropriate to use a library or service that specializes in email validation.

#match infinite spaces at start and end.

set str "  sjkhf sdhj   "

set rest [regexp {^ +.* +$} $str match]

puts $rest

#to match the ip address

set str 66.70.7.154

regexp "(\[0-9]{1,3})\.(\[0-9]{1,3})\.(\[0-9]{1,3})\.(\[0-9]{1,3})" $str all first second third fourth

puts "$all \n $first \n $second \n $third \n $fourth \n"

expect_out(0,start) Index of the first character of the string that matched the entire expression
expect_out(0,end) Index of the last character of the string that matched the entire expression
expect_out(0,string) String that matched the entire expression
expect_out(1..9,start) Index of the first character of the string that matched the pattern enclosed in the 1st - 9th set of parentheses
expect_out(1..9,end) Index of the last character of the string that matched the pattern enclosed in the 1st - 9th set of parentheses
expect_out(1..9,string) String that matched the pattern enclosed in the 1st - 9th set of parentheses
expect_out(buffer) Entire contents of the buffer when a match was found
expect_out(spawn_id) Spawn id of the process which produced the matching pattern


Python script:

To match all valid IPv4 addresses using a Python program, you can use the `ipaddress` module, which is part of the Python standard library starting from Python 3.3. Here's an example program:

```python

import ipaddress

import re

def extract_ipv4_addresses(text):

    # Use regular expression to find potential IPv4-like strings

    potential_ips = re.findall(r'\b(?:\d{1,3}\.){3}\d{1,3}\b', text)

    # Validate each potential IP address using ipaddress module

    valid_ipv4_addresses = [ip for ip in potential_ips if is_valid_ipv4(ip)]

    return valid_ipv4_addresses

def is_valid_ipv4(ip):

    try:

        # Use ipaddress module to check if the string is a valid IPv4 address

        ipaddress.IPv4Address(ip)

        return True

    except ipaddress.AddressValueError:

        return False

# Example usage:

text = "Some text with IPs 192.168.1.1 and 256.1.1.1 and 10.0.0.1"

valid_ipv4_addresses = extract_ipv4_addresses(text)

print("Valid IPv4 Addresses:")

print(valid_ipv4_addresses)

```

In this example:

1. The `extract_ipv4_addresses` function uses a regular expression to find potential IPv4-like strings in the given text.

2. The `is_valid_ipv4` function uses the `ipaddress` module to check if a potential IP address is a valid IPv4 address.

3. The example usage demonstrates how to extract and validate IPv4 addresses from a sample text.

Keep in mind that this method may not cover all possible edge cases, and it's generally recommended to use a specialized library or module, such as `ipaddress`, for robust IPv4 address validation in real-world applications.

SSL

The Secure Sockets Layer (SSL) protocol uses a combination of public-key and symmetric-key encryption. Symmetric-key encryption is much faster than public-key encryption; however, public-key encryption provides better authentication techniques. An SSL session always begins with an exchange of messages called the SSL handshake. The handshake allows the server to authenticate itself to the client by using public-key techniques and then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption, decryption, and tamper detection during the session that follows. Optionally, the handshake also allows the client to authenticate itself to the server.

MORE INFORMATION

The steps involved in the SSL handshake are as follows (note that the following steps assume the use of the cipher suites listed in Cipher Suites with RSA Key Exchange: Triple DES, RC4, RC2, DES):

   1. The client sends the server the client's SSL version number, cipher settings, session-specific data, and other information that the server needs to communicate with the client using SSL.

   2. The server sends the client the server's SSL version number, cipher settings, session-specific data, and other information that the client needs to communicate with the server over SSL. The server also sends its own certificate, and if the client is requesting a server resource that requires client authentication, the server requests the client's certificate.

   3. The client uses the information sent by the server to authenticate the server (see Server Authentication for details). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client proceeds to step 4.

   4. Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending on the cipher being used) creates the pre-master secret for the session, encrypts it with the server's public key (obtained from the server's certificate, sent in step 2), and then sends the encrypted pre-master secret to the server.

   5. If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case, the client sends both the signed data and the client's own certificate to the server along with the encrypted pre-master secret.

   6. If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). If the client cannot be authenticated, the session ends. If the client can be successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then performs a series of steps (which the client also performs, starting from the same pre-master secret) to generate the master secret.

   7. Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity (that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection).

   8. The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the client portion of the handshake is finished.

   9. The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypted) message indicating that the server portion of the handshake is finished.

  10. The SSL handshake is now complete and the session begins. The client and the server use the session keys to encrypt and decrypt the data they send to each other and to validate its integrity.

  11. This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus (either automation or user intervention), either side may renegotiate the connection, in which case, the process repeats itself.

An emulator in computer sciences duplicates (provides an emulation of) the functions of one system  using a different system, so that the second system behaves like (and appears to be) the first system. This focus on exact reproduction of external behavior is in contrast to some other forms of computer simulation, which can concern an abstract model of the system being simulated.

An integrated development environment (IDE) also known as integrated design environment or integrated debugging environment is a software application that provides comprehensive facilities to computer programmers for software development. An IDE normally consists of:

    * a source code editor

    * a compiler and/or an interpreter

    * build automation tools

    * a debugger

Universal Mobile Telecommunications System (UMTS) is one of the third-generation (3G) mobile telecommunications technologies, which is also being developed into a 4G technology. The first deployment of the UMTS is the release99 (R99) architecture. It is specified by 3GPP and is part of the global ITU IMT-2000 standard. The most common form of UMTS uses W-CDMA (IMT Direct Spread) as the underlying air interface but the system also covers TD-CDMA and TD-SCDMA (both IMT CDMA TDD). Being a complete network system, UMTS also covers the radio access network (UMTS Terrestrial Radio Access Network, or UTRAN) and the core network (Mobile Application Part, or MAP), as well as authentication of users via USIM cards (Subscriber Identity Module).

General packet radio service (GPRS) is a packet oriented mobile data service available to all users of the 2G cellular communication systems global system for mobile communications (GSM), as well as in the 3G systems. In 2G systems, GPRS provides data rates of 56-114 kbit/second [1

GSM (Global System for Mobile Communications: originally from Groupe Spécial Mobile) is the most popular standard for mobile telephony systems in the world. The GSM Association, its promoting industry trade organization of mobile phone carriers and manufacturers, estimates that 80% of the global mobile market uses the standard

Processors were originally developed with only one core. The core is the part of the processor that actually performs the reading and executing of the instruction. Single-core processors can only process one instruction at a time. (To improve efficiency, processors commonly utilize pipelines  internally, which allow several instructions to be processed together, however they are still consumed into the pipeline one at a time.)

A multi-core processor is a processing system composed of two or more independent cores. One can describe it as an integrated circuit to which two or more individual processors (called cores in this sense) have been attached.[1] Manufacturers typically integrate the cores onto a single integrated circuit die (known as a chip multiprocessor or CMP), or onto multiple dies in a single chip package. A many-core processor is one in which the number of cores is large enough that traditional multi-processor techniques are no longer efficient — this threshold is somewhere in the range of several tens of cores — and probably requires a network on chip.

SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on eXtensible Markup Language (XML) as its message format, and usually relies on other Application Layer protocols (most notably Remote Procedure Call (RPC) and HTTP) for message negotiation and transmission. SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework upon which web services can be built. This XML based protocol consists of three parts: an envelope (which defines what is in the message and how to process it), a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing procedure calls and response

Hot Standby Router Protocol (HSRP) is a Cisco proprietary redundancy protocol for establishing a fault-tolerant default gateway, and has been described

The protocol establishes a framework between network routers in order to achieve default gateway failover if the primary gateway should become inaccessible,[1] in close association with a rapid-converging routing protocol like EIGRP or OSPF. By multicasting packets, HSRP sends its hello messages to the multicast address 224.0.0.2 (all routers) using UDP port 1985, to other HSRP-enabled routers, defining priority between the routers. The primary router with the highest configured priority will act as a virtual router with a pre-defined gateway IP and will respond to the ARP request from machines connected to the LAN with the mac address 0000.0c07.acXX where XX is the group ID in hex. If the primary router should fail, the router with the next-highest priority would take over the gateway IP and answer ARP requests with the same mac address, thus achieving transparent default gateway fail-over.

NMS:

A network element is usually defined as a manageable logical entity uniting one or more physical devices. This allows distributed devices to be managed in a unified way using one management system. According to Telecommunications Act of 1996, the term `network element' means a facility or equipment used in the provision of a telecommunications service. Such term also includes features, functions, and capabilities that are provided by means of such facility or equipment, including subscriber numbers, databases, signaling systems, and information sufficient for billing and collection or used in the transmission, routing, or other provision of a telecommunications service

An Element Manager Software (EMS) manages one or more of a specific type of telecommunications network element (NE), for example, a Router, Switch, Blade Server etc.