1.3 Source of Available Information about Health Professionals and Institutions
Information about healthcare professionals, their specialisations and about institutions is currently available by a governmental/public organisation (e.g., Ministry of Health, CNS). Information about the relationship between professionals and institutions are distributed within the different institution databases. According to the Ministry, the frequency of updating in the governmental database is currently not sufficient to ensure the accuracy of data. The database of the CNS is not complete enough to cover all the relationships between institutions and physicians, because of the reimbursement focus of this database. Independent of the decision whether a LuxTrust card or a Health Professional Card is preferred, a database is proposed which covers all information about Health Professionals, institutions, specialisations and relationships. The database therefore contains three main elements: Information about the healthcare professionals: identity, specialisations and the current legal status (authorisation to work by the Ministry; contractual arrangements with CNS; not under a sanction) Information about institutions and their main areas of activities The set of relationships between healthcare professionals and institutions
This database would be accessible to verify the status of the Healthcare professionals in order to assign their access rights. Information of the Health Professionals and institutions must be updated with information of authentic sources. For this, update messages from the sources need to be processed on a regular base (preferred daily). For the link between Health Professionals and institutions, it is proposed to name representatives of the institutions, which update information as professionals joins the institution, when they leave, or when a Health Professional changes the responsibility2 inside the institution. This information maybe

The practiced profession

10 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
is sent as automated update messages of the HR system or is managed via a special web portal of the database. It is clear, that such representatives are only able to change information related to their institution and that the context of work inside the institution only covers the specialisations which are assigned to the Health Professionals.

Figure: Example of the database structure
1.4 Storage of Identifying Data
The storage of data inside the card is useful for offline-access of the data, giving the option to check the information without having an online connection to a central server. For some applications this is necessary. But for reasons of accuracy not all information can be stored inside the cards, as it might be outdated during the reading of the information. Additionally, if the information inside the card is outdated, the card must be replaced or if stored in the RAM of the card, an authority needs to update the information. Both options lead to administrative overhead. Type of Card Health Professional Card All Work Context Health Professional Card Selective Work Context LuxTrust Work Context Specialisation Institution of Work Specialisation Institution of Work Specialisation Institution of Work The table shows the options, which are possible, including the use of a LuxTrust card. If the work place has been identified as information that is needed for a fine-grained access control management, it is more accurate if handled in ordinary central databases. As the specialisation of a user only change less frequent, this information is best stored in the card. Having such information In Card

Table: Work Context

In Database
11 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
stored inside the card gives the possibility to use the card for some additional offline-based use cases. In the following document the focus lies in this type of Health Professional Cards compared with the LuxTrust Card as an alternative. It limits the physical media not only to cards, but for today, cards are the most likely used form of media.
12 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
2 Identification of Institutions
Identifying institutions is independent of identifying individuals working for an institution. Such identification is always necessary in automated processes, where machines or processes need to authenticate towards other machines or towards individuals, or where authenticity of an action is required. In these cases, no user interaction is possible or wanted. It is possible to identify machines or processes individually as belonging to an institution, or as the institution itself. A good example is the authenticity of web sites. In this case, the machine that handles the https communication is identified by its fully qualified domain name, which is covered by a certificate. There are two possibilities to handle these certificates: For web servers, soft certificates or SSL certificates are normally used. In more secure environments, the use of hardware security modules is first choice.

2.1 Soft Certificates / SSL Certificates
Soft certificates are cheap and easy to use. No further hardware is required. These types of certificates can be created with or without a password. If a password was used during the creation of the certificate, the password needs to be typed in during the start-up of the service or kept stored inside a key store or file. From the security perspective, certificates without password might be a risk, as they can be copied and used somewhere else. Certificates with password, where the passwords can be accessed automatically by the service are also of risk, if the password can be found inside an unprotected file. It might be more secure, if the name inside the certificate is the fully qualified name of the machine, as this is the case for web servers. Here, the communication partner might check if the communication partner has the correct fully qualified name3 and take further actions. Password protected certificates without passwords stored in a file or key store demand user interaction at some point. In environments of high availability, this might be a problem, as a restart of the service or machine always requires a user typing in the password. On the other side, the administrative access to the system could be less restrictive, as the certificate without knowledge of the password is useless.
2.2 Hardware Security Modules (HSM)
Not only for the storage of certificates are Hardware Security Modules. It is an internal or external device, which is used for the secure operation of cryptographic functions in mission critical environments. It allows the protection of cryptographic keys against software based and physical attacks and non-authorised used. A Hardware Security Module might be used for the secure generation or random numbers, keys and pins, for secure storage of cryptographic and sensitive data material. As these modules are specially designed hardware, cryptographic functions are potentially faster then implemented in software.
Returned by the DNS with the given IP address.
13 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
Hardware Security Modules should be certified. Standards concerning Hardware Security Modules are listed in Part 2.

2.3 Proposition

It is proposed to use password protected soft certificates for the first phase. In case of higher throughput of data, a FIPS 140-2 Level-3-based module should be used in the mid-term. This will be an additional investment, then.

15 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
Figure: Production and Distribution of Smart Cards
Issuer The Issuer is the organisation, which is responsible for the issuing of the card. This organisation is the legal responsible in all aspects of the card. In case of the Health Professional Card there might be several organisations possible. The Medical Council of Luxembourg could be a good candidate, but the council only covers doctors, dental doctors and pharmacists. Therefore the Ministry of Health would be a better candidate, as they are responsible for the legal framework and cover also other types of legal recognized healthcare professions. Whenever a Health Profession should receive a (new) Health Professional Card, the card must be produces and shipped. For that, a set of information needs to be collected. Some will be integrated on the card, while others are used for the shipping of the card or other administrative tasks. Also information is needed to create the certificates and keys that are stored in the card. The issuer delivers all this information to the certification authority to initiate the production process. In case of change of the status of a Health Professional, the issuer also might inform the certification authority about suspension, reactivation and revocation of certificates of Health Professionals. Certification Authority Having all relevant information received from the issuer, the certification authority is able to create certificates for a Health Professional. This includes the private and public key and the initial PIN to access the private key. As all certificates are only used for authentication and signing, no backup of the private key should be stored, as this would affect the legal value of the smart cards concerning non-repudiation. The certificates and keys that are needed to customise the smartcard are sent in as secure way to the production environment of the producer. The communication goes directly to the production
16 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
machines, so the producer is not able to copy the private keys. Additional information is also transmitted to the producers, for administrative purposes. The certification authority will also run the environment of a public key infrastructure including the ability to manage revocation lists and public directory services. Support Portal / Helpdesk The activation, suspension, reactivation and revocation of cards and certificates will be performed via a support portal or a helpdesk, which is associated with the certification authority Producer The producer finally produces and customises the smartcards. This includes the integration of the certificates with public and private key on the chip and the printing of additional information on the surface of the card. The producer also ships the card and sends the PIN mailer to the Health Professional. Health Professional It depends on the implemented process, if the Health Professional needs to order the Health Professional Card personally, or if the issuer initiates the production. If the Health Professional needs to order the card personally, he needs to be informed if the card is running out of the validity period. In case of loss, the Health Professional is able to suspend or revoke his card via the support portal or helpdesk of the certification authority. 3.1a (3) Activation

After the reception of the card and the PIN mailer, the card needs to be activated. The support portal will offer a possibility for that. After the card is activated, the eHealth infrastructure will notice the card as usable. 3.1a (4) Revocation and Suspension
In case of loss, it is possible to revoke or temporally suspend the Health Professional Card. This process can be performed at the support portal of the certification authority. In case of suspension it is possible to reactivate the card via this portal, or by phone. It is clear, that the access of the portal needs to be protected via login/password, to prevent the reactivation of stolen cards by the thief. 3.1a (5) Re-Keying
The Health Professional Card contains a validity period. After that time, it is not possible to use the card for authentication or signing of documents. If the Health Professional needs to order the Health Professional Card manually, the issuer will notify the user in advanced so that he or she is able to order and activate the new card before the old card drops out of validity. If the issuer delivers the card proactively, it will be delivered in time before the old card gets invalid.
17 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
3.1a (6) Lost or Invalidity of the Card
If both cards are broken, lost or deactivated, an urgent ordering process should be implemented to receive a new card during one day. As both cards have different validity periods, a second card should normally be available, so urgent ordering should only occur in rare situations. It is not recommended to use spare cards as a temporary solution (cards which are not linked to an individual person), as they do not contain qualified certificates. Spare smartcards are for that reason not legally equivalent to qualified Health Professional Cards.
3.1b Authorisation and Authentication
3.1b (1) Information Stored in the Card The issuer defines the datasheet, which will be integrated in the Health Professional Card. This should be at least. Serial number of the card (fixed to a user) Running number of the card (starting with 1, 2, 3,.) Name of the Health Professional ID, of the Health Professional (e.g. Matriculation Number, CNS-codes) List of codes of the specialisations and sub-specialisations Serials of the authentication certificates Authentication certificate Serials of the signing certificates Signing certificate Validity period

3.1c Technical Properties
In Part 2 of this deliverable, standards are listed, which are relevant for potential Health Professional Cards. Currently most smartcards are contact based. Smartcard readers are cheap and often build into the PC. There are some arguments that are against the use of contact based smartcards in the context of medical environments: The number of in-out cycles of the cards in the card readers is limited. In a daily use it can be assumed, that this limit is reached in the first year. A second argument is about hygiene. Each time a card is put into the card reader, it needs to be touched by the user, which could be a way to distribute infections around the institutes. By the use of contactless cards, no higher wearout is performed during the use, so it can be assumed, that such a card will last longer. The contactless communication with the card gives the possibility to use disposable wrappers around the card, which might be replaced if needed (e.g, before entering the operating room) or by time. This will help to fulfil higher hygiene standards. For that Health Professional Cards should base on contactless card technology.

3.2 LuxTrust Card

If LuxTrust cards are used to indentify Health Professionals, LuxTrust covers several tasks. On the other side, all health related information must be stored inside a database.

3.2a Card Lifecycle

The card lifecycle is mainly the original LuxTrust Smartcard lifecycle. 3.2a (1) Ordering
As an individual, one has to fill out an application from, which can be downloaded from the website of LuxTrust. The further registration process requires a face-to-face verification of the applicant, which can be performed at the registration authorities of LuxTrust. After successful registration, the individual will receive the smartcard and a PIN Mailer, as two independent letters, which are delivered with a time gap.
Without network access, esp. without access to the eHealth infrastructure.
19 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
3.2a (2) Production and Distribution
For LuxTrust, no special production and distribution processes need to be implemented, as LuxTrust has already established these process. Health Professionals who are requesting a LuxTrust Card are acting towards LuxTrust as individuals. The link between the individual and his specialisation has to be managed in a second process. 3.2a (3) Activation
The LuxTrust card needs activation before it can be used. One has to visit the LuxTrust website and needs to enter the initial PIN of the PIN Mailer. 3.2a (4) Revocation and Suspension
In case of loss, it is possible to revoke or temporally suspend the LuxTrust card. This process can be performed at the website of LuxTrust. In case of suspension it is possible to reactivate the card via the website, by phone or by visiting a registration authority. 3.2a (5) Re-Keying

The LuxTrust card contains a validity period. After that time, it is not possible to use the card for authentication or signing of documents. LuxTrust will notify the user in advanced so that he or she is able to order and activate the new card before the old card drops out of validity. In the close future, the serial number of the new card will be identical to the serial number of the old card. This is relevant for applications, which rely on the serial number as an identifying number. In this case, no further re-registration inside the application needs to be performed as the serial number stays the same. The next time the new card is used, the application is able to update the certificate and public key of the new card inside its database. The continuity of the serial number will end, if a new card has been ordered after the end of the validity period or if the card is listed inside the revocation list. 3.2a (6) Lost or Invalidity of the Card
If the card is dropping out of the validity period or the card is lost or damaged, the user is not able to authenticate or to sign documents. The process to receive a new card takes several days in which the user is not able to perform his work. This situation might not be acceptable as it hinders the individual to perform his job. There are three possible solutions to overcome this problem. Urgent Ordering LuxTrust offers the possibility to order a new card with an "URGENT" option. In this case, the user needs to order the new card until 10:30 and might retrieve the card between 17:00 and 19:00 the same day. The last step has to be done personally. The card will be charged with a higher (nearly doubled) price. It is clear, that even an urgent ordering of a new card will lead to at least one day, where the user is not able to authenticate himself or to sign documents. The personal presence for the retrieval of the card is another negative aspect. Additional the card has to be activated. This step requires additional time as a function of the chosen activation process.
20 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
Spare Smartcards Another possibility offered by LuxTrust is the use of Spare Smartcards. These cards do not contain qualified certificates, because they are not linked to an individual person during the production time. Spare Smartcards are for that reason not legally equivalent to qualified LuxTrust cards. Spare cards can be handed to persons who have forgotten their cards, who have lost their cards or who need to bypass the time until a new card arrives. Spare cards need a special management of the identity and the rights, associated with the card during the limited time. If the cardholder of such a card signs documents, the identity of the signer depends on the time of usage, which is not directly oblivious to the receiver of a signed document. To make the link between SPARE certificate and user directly transparent to the receiver, one needs to introduce attribute certificates, which contain information about the identity of the cardholder and a validity period of the certificate. The attribute certificate needs to be created by a trustworthy entity. Additionally a time stamping services is needed, which guarantees, that the attribute certificate was used during its validity period. Two Cards The easiest solution needs at least two LuxTrust cards, which at best have different validity periods. Because the users serial number of the user will be different, the user needs to register all cards inside the application (see 3.1b (2)). The user profile inside the database of the application will then contain and all serial numbers of the cards.

Authentication and De-Identification TTP (4.2a): A de-identification Service, located at a Trusted Third Party will needed to deidentify medical data. The service itself will only build the link between pseudonym and patient identifying data, but will not deal in any way with medical data STS (4.2b): A security token service will authenticate the user and delivers security tokens, which contain the credentials of a user.
25 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
External sources HPRO: Information about Health Professionals, their specialisations and their current status, will be provided either by the authentic source or from other sources, e.g. Health Professional himself, institution of work. Certification Authority: If LuxTrust smartcards are used as a Health Professional Card, this service will give information about the status of certificates. Alternatively a certification authority other than LuxTrust may overtake this task.

4.2 Systems in Detail

4.2a Trusted Third Party
The Trusted Third Party offers a de-identification service, which is used to de-identify medical data. The Trusted Third Party will build a link between patient identifying data and a pseudonym. The medical data then can be stored using the pseudonym without and patient identifying information.
4.2b Security Token Service
If systems need to know the identity of the user of the system, first the user needs to authenticate, e.g. with username-password. To avoid that each system has its own user management, a centralised authentication service is state-of-the-art. A Security Token Server (STS) is such an authentication server: After successful authentication the user receives a security token, which contain the credentials of a user (e.g. the roles of the user, permitted services). As the token is signed by the STS, each service that trusts the STS will accept the token and the credentials inside the token.

4.2c Local Sign-In

Inside the institution, a user logs in to systems at different levels. First at system level the user needs to authenticate to access the machine, fileserver and printers. On application level, other authentication procedures have to be performed. A SSO solution might be used to synchronise all these authentication processes. Additionally a CCOW context management might be used to synchronise additionally the working context of several applications, running on the same office PC. This synchronisation includes the authenticated user and the currently selected patient. It is highly dependent on the local infrastructure, which systems exists and how they are configured. We subsume these systems in all figures as SignIn.

4.2d Gate Server

The key to access the national eHealth infrastructure from inside an institution will be a gate server. The gate server will need to handle all IHE, HL7 and DICOM related communication and might (if necessary) behave as a PACS towards the locally installed medical applications. This server-service is responsible for the authentication process and the access of the eHealth infrastructure. Other tasks are (optional institutional) signing, encryption and/or de-identification of the document. Institutional signing is useful in cases, where signing by individuals is not possible and where the institution guarantees the authenticity of the document.

26 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011 4.2e Staging Area
In many cases, it is useful to store medical data at the source of creation. As it is not useful to allow the access of the primary systems from the Internet, a special staging area will host all the data that is registered in the eHealth infrastructure, but kept in the institution.

4.2f Medical Application

There are a variety of medical front-end applications, which might be installed in the organisation. It is neither possible to know all these applications, nor is it possible to force all the producers of the applications to do modifications. For that, the integration of a national eHealth storage must rely on the existing standards, which are usable during the exchange of medical data inside the organisation.
Figure: Overview of Medical Application Integration
Each medical application will access the primary systems of the institution as usual. The gate server behaves like another primary system. It will cover each communication with the eHealth infrastructure and the authentication and de-identification services. The existence of gate server cannot be enforced in the case of physicians at the doctors office. In this case either a web browser needs to be used or a client needs to be installed, which is able to connect to the web services of the eHealth infrastructure. In the second case, the use of the eHealth infrastructure out of the medical application would be performed via context-calls (redirects to an external application).
27 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011 4.2g Web(Service)Client
The idea behind the use of a web client is the access of medical data via a generally available tool as an alternative way to access the data. The central point of access in this case is the web server, which will control the communication with the involved systems. The proposed solution will guarantee, that at no time, patient data is rendered at the web server, nor will it be available in that server in plaintext. Only on the client side all previously encrypted or de-identified data will be decrypted and re-identified and displayed. This will be mainly done by the use of applets that access the web service functionality of the eHealth web server. These web-service calls can also be performed by stand-alone applications. In this case, the gate server is not needed, as the software directly communicates with the eHealth infrastructure. This is also an advantage for physicians, who are not inside an institution and where the installation of a gate server is too expensive. Having a stand-alone application, one can foresee the access of the private key of the user and does not need to rely on an institutional certificate. It is open to the final specification, if the application communicates directly with all relevant systems of the eHealth infrastructure, or if the application uses the Web Server as a central web service contact point.

Figure: Overview of Web (Service) Client Integration
4.2h Internet- / Intranet
There are two options, where the services of the eHealth infrastructure might be installed: In an external DMZ accessible from the Internet or in an internal DMZ accessible only from an Intranet. A
28 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
good firewall concept already protects the system critical infrastructure, but for machines in an external DMZ the risk of unknown security flaws with the possibility to hijack this machine is always possible. These security flaws might also exist if the machine runs inside an internal DMZ, but the group of users, which could try to hijack the machine, is limited and known. For this reason it could be of importance, that not each service of the eHealth infrastructure is accessible from the Internet. It needs to be defined, which of all services are of such importance. This intranet might be restricted only to an organisational internal network. The option of a larger private data-exchange network would give the possibility to define the quality of service, e.g. throughput or latency, which is not possible if services are accessed via the Internet.
Figure: Access of Services
4.3 Identification and Authentication
Participants of the eHealth System need to authenticate themselves to receive credentials. These credentials are needed to determine the rights to access data or to perform actions. Authentication should always rely on strong cryptography, but this is not always possible or useful. Processes inside the institutions give limitations that need to be discussed with the stakeholder. This analysis covers cases on a higher level. It is not going into technical details.

4.3a Medical Application

The identification of the physician can be done by the use of the existing authentication mechanisms inside the institution (SignIn). If it is accepted that the authentication in the institution is sufficient, the institution authenticates towards the eHealth infrastructure with identifying information of the physician piggybacked, e.g. as security token. The institution now guarantees that the physician has authenticated inside the institution and that this process can be audited if requested. The security token system checks the credentials of the institution and the information of the given physician and compares this information with its databases. The STS will use the given information to create a security token, which it delivers to the gate.
29 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
For the creation of new medical data, this process might be sufficient, as it only adopts the way medical data is produced and linked to the physician inside the institution. There are good reasons, that this process is not sufficient for the access of medical data of the national eHealth system. One might think of a malicious administrator, creating fake doctors to access the data. Creating fake doctors to produce useless medical data is a risk, but not a data and privacy protection risk. As consequence, the access of patient information should be treated specially concerning the authentication of the user. It is proposed, that for the national wide read access to medical data only the authentication with strong cryptography is sufficient (e.g. as provided with the LuxTrust smartcard). Strong cryptography is a general term applied to cryptographic systems or components that are considered highly resistant to cryptanalysis and attacks. Without the possibility to change the installed medical application, an additional demon process needs to be installed locally close to the doctors PC. This demon communicates with the gate server and accesses the card reader to access the LuxTrust or Health Professional Card. The gate server might trigger the demon if strong authentication is needed. This daemon might be installed in the machine of the medical application, or if not possible at a second machine. In any case, the mapping between authentication demon and medical application needs to be done in the gate server. If the medical application sends a request to the gate server via IHE, HL7 or DICOM, the gate server sends an event to the pre-defined authentication daemon to perform the authentication via LuxTrust. The authentication procedure is performed between the authentication demon and the security token server with the gate server as a proxy, using a challenge-response process. As a result the Security Token Service receives the certificate of the LuxTrust/Health Professional card, which is used to identify the user. If the local institution already uses strong authentication mechanisms to authenticate the user, but without the use of LuxTrust/Health Professional cards, a registration process of these cards/tokens in the national eHealth infrastructure could be possible, if some requirements are fulfilled. One is the definite binding of the card/token to a user, which cannot be transferred to other users at any time and a binding to this users to a known physician. It must not be possible, that a local administrator creates fake physicians, even with cards/tokens, to access medical data.

4.3b Web (Service) Client
The authentication process inside a browser must be performed by an applet, as this is the only way to access the locally installed card-reader, to control the communication with the security token service during the authentication, and to preserve the received security token. The Web Server inside the eHealth infrastructure foresees the existence of a web service interface to act as a proxy for the access of the eHealth infrastructure. This includes the secure token service. This interface could alternatively be used during the authentication process instead of the direct access of the Security Token Service. The web server is not able to monitor the communication between applet and Security Token Service, as it is end-to-end-encrypted. The described authentication process is of cause valid for stand-alone applications, which are aware of the eHealth infrastructure and the eHealth web services.
30 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
4.4 Data Providing and Signing
During the writing of data to the national eHealth infrastructure the originator and source of the medical data is crucial for the further processing of the data. Identifying the source of medical data is an important property of platforms that share sensible data. This is the case of this eHealth platform where the authenticity and integrity of data intends to be guaranteed by the use of digital signatures.
4.4a Institution vs. Person
There are two possibilities to sign medical data inside the institution to ensure authenticity: The person that creates or enters the medical data, signs the data with his personal certificate An institutional certificate will be used to sign the data. In that case, the institution (hospitals, laboratories, etc.) will take the responsibility for the authenticity of the data sent.
Each of these two options has its advantages and disadvantages: The first option needs user interaction at some time. Processes can be foreseen, which allow bulk signing of several documents at one time to minimise the time of the process. The second option could be performed independent of the user. As there are legal constrains, it is not likely that the institution is willing to guarantee the authenticity.

34 eSant - Work Package WP12 - Health Professional Card Part 1 - Concept Deliverable Uwe Roth Final Version 1.0, 04.02.2011
5 Concluding Recommendations
This chapter summarises the recommendations of the individual chapters. There are several options to identify Health Professionals towards the national eHealth platform, e.g. Login/Password, Fingerprint, Cryptographic Smartcards. Due to the sensitivity of the data, the usage of strong cryptography using certificates and public/private keys is a necessary condition for the identification and authentication of the Health Professional (4.3). As a medium to store the certificates and the private key, SANTEC proposes smartcards with a cryptographic chip (1.1). Such smartcards should be enabled for authentication and electronic signing of documents. This can be achieved with special Health Professional Cards as proposed by the HPRO Card Project, national e-IDs or general singing cards as provided by LuxTrust for example. It is proposed by SANTEC to use special HPRO Card compliant Smartcards, for several reasons (3.3): First, the HPRO Card consortium proposes a certain look of the card (visible surface layout), which enables the cardholder to identify him and his profession without the need of card readers or special software (Part 2, 4.4a). Additionally the European Parliament and Commission are requesting Health Professional Cards (Part 2, 2) to simplify the movement of health professionals cross border. Secondly, special HPRO Cards can be produced as contactless cards, which is state-of the-art. Contactless cards are in sense of wearout or hygiene easier to integrate into existing processes of hospitals and doctor's offices, than contact based cards. Finally, the possibility to deliver backup-cards to the user is another reason for the use of special Health Professional Cards is. The use of such cards will be an integral part of the daily work. It must be possible to use a second or third card in case of lost, forgotten or broken cards. A national e-ID card will be unique and could block the work if the described cases occur. All three arguments lead SANTEC to recommend special Health Professional Cards. It is proposed to store information inside the smartcard, which is already visible on the surface of the HPRO Card (name, surname, identifier, validity data). Additional the professions of the Health Professional should be integrated to enable off-line proof of the professions (1.4, 3.1b (1)). Further information, like legal status, place of work, the relationship between health professional and institution, should be stored in a central database (1.3) as this information is sensitive and potentially changes more often. The source of this information mostly is taken from governmental and public organisations (e.g. Ministry of Health, CNS), as a Health Professional Register. Representatives of the workplace of the health professional must update information about the relationship of health professional and institution in the Health Professional Register to ensure the accuracy of the information and that it is up-to-date (1.3). Issuer of the card can be the Ministry of Health (3.1a (2)). The first set of two cards (one as a backup) with validity periods of two and three years should be issued on request, the following with validity periods of two years should be issued pro-active. The existence of a backup-card and the initial difference in the validity period helps to minimise the chance of downtime.

O <CMD> version....36 O <CMD> mac....36 O <CMD> rdevclass....37 O <CMD> rname....37 O <CMD> rsetvoice....37 O <CMD> testmode....37 O <CMD> total_debug....37 O <CMD> vendor....37 O <CMD> wname....37 O <CMD> wsetvoice....37 17) O <LIST> dhcpserver...37 O <CMD> host....37 O <CMD> lease....38 O <CMD> start.....38 O <CMD> stop....38 O <CMD> subnet....38 18) O <LIST> h323....38 A <CMD> announce....38 A <CMD> clearstat....38 A <CMD> configdest....38 A <CMD> configdtmf....38 A <CMD> configep....39 A <CMD> configprefix....39 A <CMD> configretry....39 A <CMD> configrg.....39 A <CMD> configtimer...39 A <CMD> configttl.....39 A <CMD> configVDN....39 A <CMD> debugport....40 A <CMD> deletedest....40 A <CMD> dellock....40 A <CMD> displayci....40 A <CMD> dsptimer....40 A <CMD> faststart.....40 A <CMD> fasttunnel....40 A <CMD> faxpassthru....40 A <CMD> framenego....41 A <CMD> useport....41 O <CMD> listepinfo....41 O <CMD> listdest....42 O <CMD> listlock....42 O <CMD> listrginfo....42 A <CMD> lock....43 A <CMD> maxdigits....44 A <CMD> memalloc....44 A <CMD> prefix....44 A <CMD> presentci....44 A <CMD> sendGRQ....45 A <CMD> tracecall....45 A <CMD> tracemsg....45 A <CMD> tunnel....45 A <CMD> usegk....45 A <CMD> h323id....45 A <LIST> h450....45 A <CMD> activate....45
A <CMD> CFNR....46 A <CMD> deactivate....46 A <CMD> history....46 A <CMD> listCFNR....46 A <CMD> listdvr....46 A <LIST> voice....46 A <CMD> countryopt....46 A <CMD> portdiag....46 O <CMD> 1si3216....47 O <CMD> 2si3050....47 O <CMD> 3si3216....47 O <CMD> codecdownload...47 O <CMD> DetectTone...47 O <CMD> DSPConnect....47 O <CMD> dspdownload....47 O <CMD> DSPQuit....47 O <CMD> Dtmfenable...47 O <CMD> ecparams....47 O <CMD> gc.....48 O <CMD> jitter....48 O <CMD> listgc.....48 O <CMD> QuitTone....48 O <CMD> TestTone....48 O <CMD> voiceopt...48 O <CMD> callstat....48 O <CMD> listdest....49 O <CMD> listepinfo....49 O <CMD> listlock....50 O <CMD> listrginfo....50 O <LIST> h235....50 A <CMD> security....50 A <CMD> subscript....50 A <CMD> list....51 19) O <LIST> http....51 O <CMD> language....51 O <CMD> url....51 20) O <LIST> pstnclass....51 O <CMD> clear.....51 O <CMD> clip....51 O <CMD> default....51 O <CMD> incall....51 O <CMD> info....51 O <CMD> list....52 O <CMD> localcode....52 O <CMD> set....52 O <CMD> test....52 O <CMD> timer....52 O <CMD> trace....52 21) O <LIST> relayvoice....52 O <CMD> force....52 O <CMD> icall....52 O <CMD> status....52 O <CMD> trace....53 22) O <LIST> rip....53 O <CMD> list....53

A <CMD> nat

Syntaxe : nat <interface> [-alias_address <addr>] [-unregistered_only yes|no] [-same_ports yes|no] [-status] [-disable] [-enable] Options: -alias_address a.b.c.d Address to use for aliasing -unregistered_only [yes|no] Alias only unregistered addresses -same_ports [yes|no] Try to keep original port numbers for connections -status Display currently configured NAT options -disable Disable NAT -enable Enable NAT

A <CMD> nataction

Syntaxe : nataction add static/rdaddr/rdport <addr1 [addr2]> [-tp port1 [port2]] nataction delete/list/enable/disable <action-id>

A <CMD> policy

Syntaxe : policy set <RxIfName> <TxIfName> <Sequence> {Allow|Deny} [srcip <a.b.c.d> [<e.f.g.h>]] [dstip <a.b.c.d> [<e.f.g.h>]] [sport <p1> [<p2>]] [dport <p1> [<p2>]] [proto <Protocol>] [tc <TC-Action-ID>] [nat <NAT-Action-ID>] <QoS-Policy-ID> <Policy-ID> <RxIfName> <TxIfName> <Sequence>{Allow|Deny} [srcip <a.b.c.d> [<e.f.g.h>]] [dstip <a.b.c.d> [<e.f.g.h>]] [sport <p1> [<p2>]] [dport <p1> [<p2>]] [proto <Protocol>] [tc <TC-Action-ID>] [nat <NAT-Action-ID>]
policy delete policy modify

policy enable

<QoS-Policy-ID>
policy disable <QoS-Policy-ID> policy list [default] [<IfName1>] [<IfName2>]

A <CMD> publicip

Syntaxe : publicip add/delete <public address> publicip list

A <CMD> qstat

Syntaxe : qstat $interface_name

A <CMD> remove

Syntaxe : remove $interface_name

A <CMD> rft

Quitte Telnet !

A <CMD> setwt

Syntaxe : setwt <default_wt> <low_wt> <high_wt> <medium_wt> <critical_wt> <real-time_wt> <premium_wt> <urgent_wt> Weight Zero queues traffic will use default queue bandwidth

A <CMD> spoof

Syntaxe : spoof [ list | enable | disable | <If name> [ trusted | untrusted ] ] spoof list : list the all the trusted and untrusted interfaces along with status spoof enable : Enable spoof protection spoof disable : Disable spoof protection spoof eth1 trusted : Set eth1 as trusted interface spoof eth1 untrusted : Set eth1 as untrusted interface

O <CMD> attack

Syntaxe : attack set/enable/disable <attack_type> [<threshold> <timeout>] attack enable/disable <attack_type> attack listInsufficient number of arguments

O <CMD> createtc

createtc <dfmark/dfnomark> <priority_class> -o assuredbw <value> maxbw <value>

O <CMD> debug

(rpte laction prcdente)

O <CMD> deletetc

Syntaxe : deletetc <action_id/all( which are not attached to any policy)

O <CMD> listtc

Syntaxe : listtc <action_id/all>

O <CMD> tcstat

listtc <action_id>

A <LIST> logger

A <CMD> logger
Syntaxe : logger list logger add <facility-name> <severity-name> <destination-id> logger delete <facility-name> <severity-name> facility-name -> kernel/user/mail/deamon/auth/syslog/lpr/new/uucp/clock/secauth ftpdeamon/ntp/logaduit/logalert/cron/local0/local1/local2/local3 local4/local5/local6/local7/ip/tcp/udp/sockets/rawip/icmp/arp igmp/app/cdcli/if/telnet/dns/snmp/http/ping/ftp/ftpd/tftp/bootp dhcpc/dhcps/qosbw/ipsec/ike/nat/firewall/diffserv/logger/queuing ipoa/pppoa/ethoa/httpproxy/ftpproxy/misc/cbq/mgcp/rtp/dhcpr severity-name -> emergency/alert/critical/error/warning/notice/info/debug trace/accounting

A <CMD> loggerdest

loggerdest loggerdest loggerdest loggerdest loggerdest loggerdest add syslog <syslog-server-addr> [syslog-server-port] add local add user <user-name> add adminalert <sender-mail-id> <admin-mail-id> <smtp-server-addr> list [<destination-id>] delete <destination-id>

A <CMD> logmsg

Syntaxe : logmsg list logmsg delete

A <LIST> rarpd

Syntaxe : H/W ADDR IP ADDRESS

A <CMD> add

Syntaxe : add {0xH/Waddress} {IPAddress)

A <CMD> delete

Syntaxe : delete {0xH/Waddress}

A <CMD> rarpd

Syntaxe : rarpd {-a | interface}

A <LIST> snmp

SNMP Agent ======================================================== STATUS : Running TRANSPORT : 192.168.1.1/161 System Version Description : F@st3202 System Contact : SAGEM SA Phone: System Location : Le Ponant de Paris,27, rue Leblanc 75512 PARIS CEDEX 15 System ID : 4242 ======================================================== Trap Server Configurations ========================== -------------------------------------------------------Index Version IP-Address Community Status -------------------------------------------------------1 SNMP-V1 0.0.0.0 public disable 2 SNMP-V2 0.0.0.0 public disable -----------------------------------------------Communities =============== ----------------------------------------------------Index IP-Address Community Access

-----------------------------------------------------

A <CMD> agconfig

Syntaxe : agconfig $interface -o $port $interface - interface on which agent will run $port: Port Number ( DEFAULT Port No : 161

A <CMD> comconf

Syntaxe : comconf $ipaddress $community_name -o $access $ipaddress: IP Address of accessing station $community_name: community string to access MIB $access: 1 - ReadOnly[default]/ 2 ReadWrite
comconf @ip-de-ta-machine nom-de-ta-communaut -o readonly (cest suffisant pour rcuprer des graphes type MRTG ou PRTG) et ensuite start [root @ snmp]$ start SNMP Agent Is Already Running[root @ snmp]$

A <CMD> delcomm

Syntaxe : delcomm $index index: Community index in list

A <CMD> shutdown

Syntaxe : (Arrte le serveur snmp) Si le serveur est art, => SNMP Agent Is Already Stopped

A <CMD> start

Syntaxe : (Dmarre le serveur snmp) Si le serveur est dmarr, => SNMP Agent Is Already Running

A <CMD> sysconf

Syntaxe : sysconf [-d] [-c] [-l] [-i] value -d : System Version Description -c : System Contact -l : System Location -i : Assigned Enterprise Number

A <CMD> trap

trap [1][2] enable/disable 1 - SNMP Version-1,

2 - SNMP Version-2

A <CMD> trapconf
Syntaxe : trapconf [1][2] $IPADDRESS $community 1 - SNMP Version-1, 2 - SNMP Version-2 IPADDRESS - IP Address of Trap Server community: community string to authenticate at manager side
5. Listing des commandes ORDIN
1) O <CMD> apregdump
Syntaxe : *apregdump <ap_id> ap_id - 1 - ETH1, 2 - ETH2, 3 - ETH3(ATM), 4 - SEC, 5 BM

2) O <CMD> aread

Syntaxe : aread <ap_id> <offset> <size> <type> ap_id - 1 - ETH1, 2 - ETH2, 3 - ETH3, 4 - SEC, 5 - BM, 6 - ATM offset = 0x0 - 0x7ff size = 1 - 256 (decimal) type = b - byte, w - word, l long

3) O <CMD> awrite

Syntaxe : awrite <ap_id> <offset> <value> <type> ap_id - 1 - ETH1, 2 - ETH2, 3 - ETH3, 4 - SEC, 5 - BM, 6 - ATM offset = 0x0 - 0x7ff value = 0 - ff for byte, 0 - ffff for word, 0 - ffffffff for long type = b - byte, w - word, l long

4) O <CMD> date

Syntaxe : DATE (MM:DD:YYYY) 10:28:2004 TIME (H:M:S) 20:50:55

5) O <CMD> list

Syntaxe : list <udp/tcp/routes>

6) O <CMD> memshow

Name State MacAddr eth0 Transitaire 00:60:4c:55:aa:ba atm1 Transitaire 00:00:00:00:00:00 atm2 Transitaire 00:00:00:00:00:00 atm3 Transitaire 00:00:00:00:00:00 atm4 Transitaire 00:00:00:00:00:00 Station Cache Timeout : 300 Priority 128 LinkCost 250 Vci/Vpi/Encap VpnOUI 0/0/LLC (VPN) 0 8/38/LLC (VPN) 0 8/39/LLC (VPN) 0 8/40/LLC (VPN) 0 8/41/LLC (VPN) 0 VpnId 0

O <CMD> listAll

Syntaxe : Bridge status = Active Spanning Tree status = InActive VLAN status = Active Maximum bridge filters allowed = 1024 Maximum layer2 filters allowed per port = 100 Maximum classify rules allowed per port = 100 Maximum VLANs allowed = 8 Maximum VLANs allowed per port = 8 No of ports in bridge group = 5 bridge timeout (secs) = 600 bridge management Ip Address = 192.168.1.1 igmpsnoop status (V1/V2) = disable

O <CMD> listmcast

Syntaxe : No Entries present in the filter list

O <CMD> pvc

Syntaxe : pvc add/delete port vpi where port vpi vci encapsulation -vpn OUI vpnId vci encapsulation -o <-vpn OUI vpnId> (atm0-atm7) (0-255) (0-65535) llc\vc Enable VPN Encapsulation on this interface. OUI : Organizationally Unique Identifier. vpnId : VPN Index
O <CMD> setmultiport
Syntaxe : setmultiport <enable/disable> setmultiport enable allows flooding between ATM pvcs.
Statistics Summary ----------------RxTotal: 9128 TxTotal: 15 Name eth0 atm1 atm2 atm3 atm4 Rxcount 0 FloodTotal: 3423 Txcount 3 RxFail 0 DropTotal: 0 TxFail 0 FwdTotal: 3423 SenttoIP 0

O <CMD> tableflush

O <CMD> tablelist
Syntaxe : Name _ eth0 _ PortNo/Vid 0:-1 1:2 0:-1 MacAddr Age Action 0:60:4c:55:aa:ba S Fwd 0:50:ba:21:be:8b D ff:ff:ff:ff:ff:ff S : : : : Fwd Fwd
Maximum Filter Entries Total Filter Entries Total Static Entries Total Dynamic Entries

O <LIST> l2filter

O <CMD> list Syntaxe : list <filter_id/all> where filter_id - filter id to be listed or all - keyword all to list all l2 filters O <CMD> add Syntaxe :
add <port_name> <drop/allow> <priority> -o [ -smac <mac_value> | -dmac <mac_value> | bilateralmac <mac_value> | -ethertype <type_value> | -ethertype <type_name> | -vlan <vlan_name>] where port_name - name of a particular port (32 characters) -smac <mac_value> - if souce mac needs to be dropped or allowed <drop/allow> - drop - to drop and allow - to allow <priority> - priority of the filter rule. It can have values in the range 0-7. or -dmac <mac_value> - if souce mac needs to be dropped or allowed or -bilateralbmac <mac_value> - if souce mac needs to be dropped or allowed or -ether_type <protocol_value> - if ether type is needs to be dropped or allowed or -ether_type <protocole_name> - if ether type is needs to be dropped or allowed. For valid names, please use ethertypes command --vlan <vlan_name> - vlan name from the existing vlans if VLAN is enabled The mac addresses should be of the format xx:xx:xx:xx:xx:xx. The list of valid protocol names can be found using the 'ethertypes' command. The protocol value should be of the format 0xAAAA or 0XAAAA. This command will return a unique Filter Id which can be used in delete and list commands.

O <CMD> delete Syntaxe : delete <filer_id> where filter_id
- filter id returned while adding
O <CMD> deleteall Syntaxe : deleteall <port_name> where port_name - name of a particular port (32 characters) O <CMD> ethertypes Syntaxe : Protocol Names Protocol vlaue arp rarp ip btn lan_test x25 banyan cdp xns mop_dl mop lat ethertalk aarp 0x806 0x8035 0x800 0x1000 0x708 0x805 0xbad 0x2000 0x6000 0x6001 0x6002 0x6004 0x809b 0x80f3

Explaination

Address Resolution Protocol Reverse Address Resolution Protocol Internet Protocol Berkeley Trailer Negotiation LAN test X.25 level 3 BANYAN CDP Dec XNS Dec MOP Dump/Load Dec MOP Dec LAT Ethertalk appletalk arp
ipx_o ipx_n eapol_o eapol_n txp ddp ect netbui pppoe_disc pppoe_sess
0x8137 0x8138 0x8180 0x888e 0x8729 0x872d 0x9000 0xf0f0 0x8863 0x8864
Novell IPX (old) Novell IPX (new) EAPOL (old) EAPOL (new) Telxon TXP Aironet DDP Enet Config Test NETBUI PPPOE discovery stage PPPOE session stage

O <LIST> stp

O <CMD> list Syntaxe : Stp : BridgeId : HelloTime : Max Age : FwdDelay : DISABLED ActivePorts:5 00:00:00:00:00:00 RootId :00:00:00:00:00:RootPathCost :RootPort :HoldTime :1
LinkCost TxCBpdu RxCBpdu TxTBpdu RxTBpdu Timers 0 _._ _ MeFwHo 0 _ _ _ MeFwHo 0 _ _ _ MeFwHo 0 _ _ _ MeFwHo 0 _ _ _ MeFwHo
Port State PortId eth0 F 32769 atm1 F 32770 atm2 F 32771 atm3 F 32772 atm4 F 32773
O <CMD> config Syntaxe : Aucun effet apparent O <CMD> port Syntaxe : port portname -o [-priority] [-linkcost] where portname - eth0\eth1\(atm0-atm7) priority - (0-255) linkcost - (0-65535) O <CMD> span span enable\disable Enable stops all network connections for about ~30sec to rebuild the new bridge table based on spanning Tree

O <LIST> bt

O <CMD> mac
Syntaxe : 00:03:C9:4E:43:75

O <CMD> rdevclass

Syntaxe : (rien)

O <CMD> rname

O <CMD> rsetvoice

O <CMD> testmode

O <CMD> total_debug
Syntaxe : (ma bloqu Telnet => reboot de la box pour reprendre la main)

O <CMD> vendor

O <CMD> wname

O <CMD> wsetvoice

(rien)
O <LIST> dhcpserver

O <CMD> host

host add -o -macaddr <mac-address> -ipaddr <ipaddr> -leasetime <lease time> -broadcast <broadcast-address> -dns <name-server> -gateway <gateway> -server <server-name> -file <filename> host delete -o -macaddr <mac-address> host list

A <CMD> configretry

A <CMD> configrg

Syntaxe : configrg <ifname> ifname - interface name
A <CMD> configtimer

A <CMD> configttl

Syntaxe : configttl <ttlValue>

A <CMD> configVDN

Syntaxe : configVDN <portno> <yes/no> -o <number> portno - RJ11 port on RG. yes/no - yes - enable no- disable. Optional parameter is mandatory to enable VDN.

number

- VirtualDialNumber(VDN) used for this port.

A <CMD> debugport

Syntaxe : debugport <port> port - RG Port (1--2)

A <CMD> deletedest

Syntaxe : Do you want to delete all the entries? (Y/N) (et la suite)

A <CMD> dellock

Syntaxe : dellock {area|phone}. Example :
Pour supprimer un verrou, il suffit dutiliser la commande dellock suivit du numro. [root @ h323]$ dellock 0620

A <CMD> displayci

displayci <yes/no> -o <portno> yes - Displayss calling party number if presentation is allowed no - Doesn't display the calling party number even if presentation is allowed portno - RJ11 port on which gateway receives

A <CMD> dsptimer

dsptimer <interdigtimervalue(in secs)

A <CMD> faststart

faststart <on/off> faststart - Enable fast connect procedures. OFF/off indicates disable faststart. ON/on indicates enable faststart.

A <CMD> fasttunnel

fasttunnel <on/off> fasttunnel - Enables h.245 tunneling in parallel with fast connect. off disables h.245 tunneling in parallel with fast connect. on enables h.245 tunneling in parallel with fast connect.
A <CMD> faxpassthru
faxpassthru <port> <enable/disable>

port enable

- FXS Number (1 or 2). - Enables fax passthrough on given port.
disable - Disables fax passthrough on given port.

A <CMD> framenego

framenego <auto/manual> auto - Number of frames will be auto negotiated. manual - Number of frames will be set according to configured value of number frames with codec.

A <CMD> useport

useport <port> <yes/no> portno - Activates/deactivates port to register to gatekeeper. (1 to maximum number of ports). yes - Activates port number.This port (alias address) will be. registered to gatekeer if the user executes 'usegk' command with appropriate parameters no - Deactivates port number.This port(alias address) will not be registered to gatekeeper

O <CMD> listepinfo

06 | area 0620 | area 0492156436 | phone Pour supprimer un verrou, il suffit dutiliser la commande dellock suivit du numro, comme pour lock [root @ h323]$ dellock 0620 Vrification : [root @ h323]$ listlock Restricted calls: ========================== -------------------------------------number | TypeOfNumber -------------------------------------06 | area 0492156436 | phone

A <CMD> maxdigits

maxdigits <1-17>. Default value is 4. if Less than maxdigits, then use '#' at the end of digit string

A <CMD> memalloc

pcibitmap : Used = pcbbitmap : Used = q931msgs : Used = rtpsess : Used = H245CtlBlks : Used = H245BigBufs : Used = H245Reqs : Used = Cap2CM : Used = Lcs2CM : Used = RlcPams : Used = LcsAck2CM : Used = H245Respses : Used = CMD MODE : Used = TunPDU : Used = ReqMode : Used = AudioMode : Used = VoiceBufs : Used = Timers : Used = Max 0 Max 0 Max 0 Max 0 Max 1 Max 0 Max 0 Max 0 Max 0 Max 0 Max 0 Max 0 Max 0 Max 0 Max 0 Max 0 Max Max = = 9 = 10 = 20 = 9 = 20 = 2 = 20 = 20 = 20 = 20 = 20 = 20 = 2 = 10 = 5 = 25 = 100 100

A <CMD> prefix

prefix <in/out> <add/delete> <on/off> in - Indicates prefix for inbound calls. out - Indicates prefix for outbound calls. add - Indicates prefix to be added. delete - Indicates prefix to be deleted. on - Indicates configuration is active. off - Indicates configuration is inactive.

A <CMD> presentci

presentci <yes/no> -o <port> <prefix> yes - Gives the authority to Called Party to display Calling Number no - Restricts the Called Party from displaying Calling Number portno - RJ11 port on which calling party number display has to be enabled/disabled

A <CMD> sendGRQ

sendGRQ yes/no

A <CMD> tracecall

tracecall <on/off>

A <CMD> tracemsg

tracemsg <ras/q931/h245> <on/off>

A <CMD> tunnel

tunnel <on/off> tunnel - Enable encapsulation procedures. NO/no indicates disable tunnel mode. YES/yes indicates enable tunnel mode.

A <CMD> usegk

usegk <flag> -o primary <GKADDR> port <portno1> secondary <GKADDR1><port><portno2> flag - flag specifies if the specific RG has to be registered or unregistered with GateKeeper. - NO/no indicates unregister with GateKeeper. - YES/yes indicates register with GateKeeper. GKADDR - Primary Gatekeeper IPV4 Address. portno1 - Primary Gatekeeper's port no.If not specified it will assume default port number. GKADDR1 - Secondary Gatekeeper IPV4 Address. portno2 - Secondary Gatekeeper's Port no.If not specified it will assume default port number.

West Central Asia Adthens, Istanbul, Minsk Adthens, Istanbul, Minsk: Daylight Time Bucharest Bucharest Daylight Time Cairo Cairo Daylight Time
(GMT+02:00) (GMT+02:00) (GMT+03:00) (GMT+02:00) (GMT+03:00) (GMT+04:00) (GMT+03:00) (GMT+03:00) (GMT+04:00) (GMT+03:00) (GMT+03.00) (GMT+04.00) (GMT+04:00) (GMT+04:00) (GMT+05:00) (GMT+04:30) (GMT+05:00) (GMT+06:00) (GMT+05:00) (GMT+05:30) (GMT+05:45) (GMT+06:00) (GMT+07:00) (GMT+06:00) (GMT+06:00) (GMT+06:30) (GMT+07:00) (GMT+07:00) (GMT+08:00) (GMT+08:00) (GMT+08:00) (GMT+09:00) (GMT+08:00) (GMT+08:00) (GMT+08:00) (GMT+09:00) (GMT+09:00) (GMT+09:00) (GMT+10:00) (GMT+09:30) (GMT+10:30) (GMT+09:30) (GMT+10:00) (GMT+10:00) (GMT+11:00) (GMT+10:00) (GMT+10:00) (GMT+11:00) (GMT+10:00) (GMT+11:00) (GMT+11:00) (GMT+12:00) (GMT+13:00) (GMT+12:00) (GMT+13:00)
Harare, Pretoria Helsinki, Ringa, Talinn Helsinki, Ringa, Talinn :Daylight Time Jeruslam Baghdad Baghdad Daylight Time Kuwait, Riyadh Moscow, St.Peterburg, Volgograd Moscow, St.Peterburg, Volgograd :Daylight Time Nairobi Tehran Tehran Daylight Time Abu Dhabi,Muscat Baku, Tbilisi, Yerevan Baku, Tbilisi, Yerevan :Daylight Time Kabul Ekaterinburg Ekaterinburg Daylight Time Islamabad, Karachi, Tashkent Calcutta, Chennai, Mumbai, New Delhi Kathmandu Almaty, Novosibirsk Almaty, Novosibirsk Daylight Time Astana, Dhaka Sri Jayawardenepura Rangoon Babgkok, Hanoi, Jakarta Krasnoyarsk Krasnoyarsk Daylight Time Beijing, Chongqing, Hong Kong, Urumqi Irkutsk, Ulaan Bataar Irkutsk, Ulaan Bataar Daylight Time Kuala Lumpur, Singapore perth Taipei Asaka, Sapporo, Tokyo Seoul Yakutsk Yakutsk Daylight Time Adelaide Adelaide Daylight Time Darwin Brisbane Canberra, Melboune, Sidney Canberra, Melboune, Sidney: Daylight Time Guam, Port Moresby Hobart Hobart Daylight Time Vladivostok Vladivostok Daylight Time Magadan, Solomon Is., New Caledonia Auckland, Wellington Auckland, Wellington :Daylight Time Fiji, Kamchatka, Marshall Is. Nuku'alofa
O <CMD> timezone_disp
Syntaxe : TimeZone Index Explaination

39 London

(GMT-00) Greenwich Mean Time: Dublin, Edinburgh, Lisbon,

O <LIST> vlan

O <CMD> create
Syntaxe : create <vlan_name> <vlan_id> <vlan mode> where vlan_name - name of the vlan (32 characters) vlan_id - id of the vlan (2 - 4094) vlan_mode - either bridge or router

The valid list of protocol names can be found using the 'ethertypes' command in 'l2filter'
O <CMD> delete Syntaxe : delete <filter_id> where filter_id O <CMD> deleteall Syntaxe : deleteall <vlan_name> where vlan_name
- unique id returned while adding
- name of a particular vlan (32 characters)
O <CMD> list Syntaxe : list <vlan_name/all> where vlan_name - name of a particular vlan (32 characters) or all - for all ports exemple : list all filter id vlan name port name type value

O <LIST> egress

O <CMD> addport Syntaxe :
addport <port_name> <vlan_name> [-adctrl <forbidden/fixed/normal>] [-txtagctrl <untagged/tagged>] where port_name - name of a particular port (32 characters) vlan_name - name of a particular vlan (32 characters) -adctrl <forbidden/fixed/normal> - administration control parameter. Default value is forbidden -txtagctrl <untagged/tagged> - the forwarded packets should be tagged or untagged. Default value is untagged
O <CMD> deleteport Syntaxe : deleteport <port_name> <vlan_name> where port_name - name of the port, to be deleted (32 characters) vlan_name - name of the vlan, to be deleted from (32 characters) O <CMD> list Syntaxe : list <vlan_name/all> where vlan_name - name of a particular vlan (32 characters) or all - for all ports exemple : list all vlan name port name tx tag ctrl tx admin ctrl default eth0 untagged Fixed default atm1 untagged Fixed default atm2 untagged Fixed default atm3 untagged Fixed default atm4 untagged Fixed stb1 eth0 tagged Fixed stb1 atm1 untagged Fixed stb1 atm2 untagged Fixed

stb1 stb1 visio

atm3 atm4 eth0

untagged untagged tagged

Fixed Fixed Fixed

O <LIST> wlan

O <CMD> accesslist

O <CMD> addstation

Syntaxe : addstation <macaddr> Mac address should be specified as xx:xx:xx:xx:xx:xx

O <CMD> apname

Syntaxe : apname <name>

7. Ls sur un firmwware 220160
[root @ home]$ ls A <CMD> reboot O <CMD> date O <CMD> version O <CMD> show A <LIST> ipqos O <CMD> list O <CMD> stats A <CMD> ifconfig O <CMD> route A <CMD> bitmap O <LIST> sndcp A <CMD> save A <CMD> erase O <LIST> bridge O <LIST> bt

modifi

A <LIST> ethernet A <LIST> rarpd O <LIST> arp A <LIST> auth A <LIST> logger A <LIST> snmp A <LIST> atm O <LIST> adsl O <LIST> usbhost O <CMD> usb O <CMD> rndis A <CMD> dhcp O <LIST> sntp O <LIST> dhcpserver A <CMD> dhcpr A <LIST> dns A <LIST> igmp O <LIST> wlan O <LIST> relayvoice O <LIST> pstnclass O <LIST> http O <LIST> rip O <LIST> h323 A <LIST> rtp O <LIST> vlan O <LIST> acf O <LIST> wpost O <CMD> mread O <CMD> mwrite O <CMD> memshow O <CMD> aread O <CMD> awrite O <CMD> apregdump [root @ home]$

nouveau nouveau nouveau

3) LIST> usbhost
O <CMD> rdsr Syntaxe : rdsr HPI STATUS REGISTER = 0x30 O <CMD> wraddr Syntaxe : wraddr <addr> addr = 0 - ffff (hexadecimal) O <CMD> wreldata Syntaxe : wreldata <data> ata = 0 - ffff (hexadecimal) O <CMD> rdeldata Syntaxe : rdeldata
Data = 0x0 O <CMD> wrdata Syntaxe : wrdata <addr> <data> addr = 0 - ffff (hexadecimal) data = 0 - ffff (hexadecimal) O <CMD> memget Syntaxe : memget <addr> <nb> addr = 0 - ffff (hexadecimal) nb = 0 - 65535 (decimal) O <CMD> wrmlbx Syntaxe : wrmlbx <data> data = 0 - ffff (hexadecimal) O <CMD> rdmlbx Syntaxe : rdmlbx Mailbox Data = 0x0 O <CMD> rdint Syntaxe : rdint USBH Interrupt = 0x1 (0x1:off 0x0:on ) O <CMD> wrctrlreg Syntaxe : wrctrlreg <ctrl_reg_addr> <ctrl_reg_value> <ctrl_reg_logic> ctrl_reg_addr = 0 - ffff (hexadecimal) ctrl_reg_value = 0 - ffff (hexadecimal) ctrl_reg_logic = 0,1,2 {0:direct write, 1:AND the register value, 2:OR the register value} O <CMD> rdctrlreg Syntaxe : rdctrlreg <ctrl_reg_addr> ctrl_reg_addr = 0 - ffff (hexadecimal) O <CMD> memset Syntaxe : memset <mem_addr> <length> <mem_value> mem_addr = 0 - ffff (hexadecimal) length : size of buffer in byte (decimal) mem_value : a 4 bytes word (hexadecimal) O <CMD> rsthusb Syntaxe : rsthusb <port_nb> <time_reset> port_nb : 0, 1, 2 or 3 (decimal) time_reset : time interval in ms (decimal) must be >= 10ms

O <CMD> dwiw Syntaxe : dwiw <chip_addr> <addr> <length> <endpoint> Do What I Want : is used to try something defined at debug moment chip_addr, addr : (hexadecimal) length, endpoint : (decimal) O <CMD> exe_td Syntaxe : exe_td <TD_addr> TD_addr : addr of TD (hexadecimal) O <CMD> prep_td Syntaxe : prep_td <TD_addr> TD_addr : addr (in controller memory) where TD is stored (hexadecimal) O <CMD> sendb Syntaxe : sendb <buff_addr> <buff_length> <sending_state> buff_addr : addr (in controller memory) of buffer (hexadecimal) buff_length : buffer length <= 0x3ff (hexadecimal) sending_state : 1 (send buffer) or 0 (don't send buffer) (decimal) O <CMD> rst Syntaxe : rst hard resets the host controller

4) O <CMD> usb

Syntaxe : usb <number>

5) O <CMD> rndis

Syntaxe : rndis <number> [root @ home]$rndis -help Retourne : rndiscmd stub