LWAPP AP - DHCP Option 43

Similar Questions

• The EA8500 supports DHCP Option 60/61?

  Hello

  I was wondering the EA8500 can be used with sky fiber Pro service to the United Kingdom? Obviously I would need to extract the username of the SR101/102 and then intend to use the modem Openreach VDSL2 with the EA8500 (btw brilliant router) but after some research, I understand the router needs to support DHCP option 60 & 61 in order to connect with the sky. The EA8500 does it take?

  See you soon

  psycho

  Linksys engineering has notified me that the EA8500 is not compatible DHCP Option 60/61.

  Filed a feature request in support of these DHCP Options. Lets hope it is approved and included.

• Question of DHCP Option 50

  I understand that the DHCP 50 option is for the customer asked the IP address.

  I have 3 questions about this...

  1. the DHCP server on the router maintains the MAC--> IP mapping during 24 hours right?

  What happens if I ask a non assigned a different IP address in the 24 hour window? My request will be granted each time?

  What happens if I ask for an IP address not assigned different after the 24 hour window? I guess that my request will be granted every time in this case.

  2. always in the window of 24 hours, if the requested IP address is leased to another network device, but the device has long been disconnected,

  I get the requested IP address?

  2 do all versions of routers support this option?

  Depends on the implementation of the DHCP server. The RFC does not say how to handle 50 option. The DHCP server can but should not affect the requested IP address. It can completely ignore this option.

  So:

  How long the server retains the mapping? Depends on the server. It may or may not remove the mapping after the lease has expired (which I assume is the 24 hours, that you reference).

  Ask a different IP address during the valid lease? Depends on the server. The server may grant each time. Another server can refuse each time.

  I think it is more common to not to grant the request. Internally the DHCP server manages static IP mappings and pool all the same except the static IP mapping has an unlimited lease duration. As long as a request from a computer comes that already has a mapping (static or pool) he always attributes known IP address and the other does not.

  After the expiry of the lease? Depends on the server. A DHCP server keep the maps even after the expiry of the lease. The simple purpose of this is that if you have a fairly large pool that gets not exhausted you basically assignments to static IP addresses to DHCP clients. Even if a client releases the lease (because the computer is stopped) or the lease expires, he will always keep this information. Next time (for example, you turn on the computer after the weekend) it will always go to the same IP. But again, it is up to the implementation of the server. Other servers follow other policies and do differently.

  Address IP lease request? N ° never. The DHCP server must not assign an IP address that has been rented elsewhere. There is no reliable way to make sure that the DHCP server as other devices is indeed off. If a unit is stopped, it must release the DHCP lease. If it is not the case, the IP address is blocked until the lease expired. The only case that a transfer could occur is if the DHCP server has been reset and lost its DHCP lease table. In this case, the DHCP server does not know before granted leases.

  Supported? All DHCP servers must be able to receive DHCP requests include this option. It is the implementation of the DHCP server if the DHCP option is really accepted or not. Some servers may completely ignore this option.

• Cisco SPA with problem of DHCP Options 66

  Dear all,

  I have a problem of my phone Cisco SPA for the autodeploiement.

  If I manually enter the page configuration and paste "[- pwd - password user uid] http:///dms/def/spa$PSN.cfg" in the profile rule. Everything works perfectly.

  However, we would like to do in the provision of zero touch, I add the "[- pwd - password user uid] http:///dms/def/spa$PSN.cfg"DHCP Options 66. " The SPA phone seems impossible to get the 66 Options parameter. It shows that "/ spa$ PSN.cfg" in the rule of profiles.

  I'm sure that the DHCP server works perfectly.

  Can anyone help on this?

  Kind regards

  Desmond

  You cannot use the custom during initial deployment (zero touch) password. DHCP can be used to deliver key to the device in this way.

  Ok. What are the options you have?

  You my use of the configuration file, compiled with SPC type -target option. It encrypt the file by using the password from each device Mac so you need no password given to the device - device can calculate the password required their Mac. It provides just basic security level - insensitive user, like me, know the algorithm used for password generation so that it can calculate the password and decrypt the file.

  You can use HTTPS with mutual certificate authentication to deliver XML or SPC configuration form. All phones have the unique client certificate, then you can be sure that the request has been issued by the unit. It offers a high level of security.

  There are also a few other possibilities, but disclosed so that information on the goal you want to hit, so I can't list.

  Just note that DHCP will meet anyone, in addition, the answer may broadcast (therefore handed to anyone, even without prior request). If you deliver critical data via DHCP, you can consider them publicly available. Security resulting is without security.

• Microsoft DHCP - Option 43 Setup Server

  I have the scope properly configured insofar as the 241 Option with Option 43 and the VCI in for both the series 1130 and 1200 AP however, how can you do this job if your subnet has 1200 and 1130's inside? Basically if I have two 241 options set, the 1130 comes by first allowing the 1130 s associated, but not the 1200. If I remove the Option 241, the associated 1200 1130. Basically, how can I get both working properly the scope?

  Thank you

  Raun

  Hi Pierre Roussy.

  Here is some additional info;

  This section contains an example configuration DHCP Option 43 on a Windows 2003 Enterprise DHCP server for use with the lightweight access points. For other implementations of DHCP server, see DHCP Server documentation to configure DHCP Option 43. In 43 of the Option, you must use the IP address of the management interface of the controller.

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

  Note that DHCP Option 43 is limited to a single access point type by DHCP pool. You must configure a separate DHCP pool for each access point type.* *.

  This doc.

  http://www.Cisco.com/en/us/docs/wireless/access_point/1200/installation/guide/120h_g.html

  The DHCP OPTION 43 to light Cisco Aironet Access Points Configuration example

  http://www.Cisco.com/en/us/Tech/tk722/tk809/technologies_configuration_example09186a00808714fe.shtml#T1

  I hope this helps!

  Rob

• DHCP option to set the controller IP for Access Points (Airespace)

  Hello world.

  Does anyone have an idea to specify the controller using DHCP options.

  We use:

  -Controller AIR-WLC4404-100-K9

  -AP-1010-AP-5312 poinst access

  -Server dhcp DHCPd ISC 3.0.1

  Newspapers on DHCP server indicates that access points become the IP addresses, but the controller information are not "read" / "included".

  In the productive environment, controllers will be redundant.

  So far, we couldn't sucsessful with eighter of these configurations:

  Block i. using VTL:

  http://www.Cisco.com/en/us/products/HW/wireless/ps430/products_quick_start09186a00805100f5.html#wp49287

  subnet 10.50.107.0 netmask 255.255.255.0 {}

  option subnet-mask 255.255.255.0;

  routers option 10.50.107.1;

  option domain-name-servers 10.20.51.11, 10.20.51.12;

  option vendor-class-identify Airespace 1200;

  the option dhcp-client-identifier 0xf1, 8, 10.20.51.254, 10.20.51.249;

  DDNS-updates

  DDNS-rev-domainname "in - addr.arpa.";

  DDNS-domain name "xxyy.local.";

  default-lease-time 28800;

  range 10.50.107.101 10.50.107.200;

  }

  II. using the DHCP Next-Server option:

  subnet 10.50.107.0 netmask 255.255.255.0 {}

  option subnet-mask 255.255.255.0;

  routers option 10.50.107.1;

  option domain-name-servers 10.20.51.11, 10.20.51.12;

  Next-server 10.20.51.254;

  III. use of Header Information Option 43 described such in DHCP Manual:

  WLAN-apc code 60 option = text;

  ip address wlan code option 43 = controller;

  subnet 10.50.107.0 netmask 255.255.255.0 {}

  option subnet-mask 255.255.255.0;

  routers option 10.50.107.1;

  option domain-name-servers 10.20.51.11, 10.20.51.12;

  option wlan-apc "Airespace.AP1200"

  option wlan controller - 10.20.51.254;

  IV. using header to the DHCP server information:

  class "-classes of suppliers ' {}

  vendor-class-identifier option match; }

  {"Airespace.AP1200" subclass "-classes of suppliers '}

  Next-server 10.20.51.254;

  }

  Does anyone have a working (using the SAI?) configuration or advice?

  Best regards

  Jarle Steffensen

  Yes, finally got it work.

  I just followed this guide:

  http://www.Cisco.com/univercd/CC/TD/doc/product/wireless/control/C44/DEP.PDF

  and it worked the first time :)

• RV042 150 DHCP Option

  Hi people

  I have a RV042 VPN router with the latest firmware v4.2.1.02.

  This router is connected to the main site through a VPN Tunnel.

  Now, I want to configure a DHCP Option if I can put an IP phone

  behind the RV042. The IP phone should receive an IP by DHCP

  the RV042 and of course, the IP address of the Director with the

  Option of 150.

  I can configure DHCP and it works fine but I can't find where I

  or can configure Option 150.

  Does anyone know ho it works?

  Thank you for your help...

  Kind regards

  Pascal

  Unfortunately RV042 isn't compatible DHCP Option 150.

• vShield Edge DHCP Options

  Hi guys,.

  I play a vCHS TPOC. I was wondering if it was possible to set any other advanced DHCP option on the edge of vshield like WINS etc?

  As far as I can see there is not, but thought I would ask.

  Concerning

  D

  It is not possible today.

  Is WIN what you are looking for? Or other options as well?

  Thank you.

• LWAPP AP and DHCP option 43

  Hello

  I have configured option 43 on server dhcp, restarted 1131 AP, but AP still try to resolve the CISCO-LWAPP-CONTROLLER instead of the ip provided by dhcp. How can I debug this?

  Router config:

  IP dhcp pool seg20

  F104.0a0f.64fd hexagonal option 43

  Thanx.

  A CUWN AP, through all the methods of discovery.  So it always attempts to use DNS, 43, dissemination of L3, L2 broadcast option.  Once it was discovered, then it will be unicast the join query.

  Normal/expected behavior

• A SG300 Cisco SMB Switch will support DHCP Option 156?

  Hi all

  Is it possible to configure the 156 on a Sx300 Cisco DHCP scope option? Its for Shoretel IPT... I noticed that the option is not available through the user interface. But I tried the other day on a switch with the latest firmware via the CLI and it almost worked but I couldn't switch to accept the exact string that I needed... For example below (the Cisco classic):

  the option ascii 156 'ftpservers = 172.16.250.21, country = 7, language = 4, layer2tagging = 1, vlanid = 100 '.

  Guidance gratefully received...

  Thanks in advance

  Matt

  Hi Matthew, the options supported on the DHCP server are as follows:

  1,3,4,6, 12, 15, 44, 46, 50, 51, 53. 54, 55, 56, 58, 59 and 61.

  -Tom
  Please mark replied messages useful

• DHCP Option 82 SG300, decipher the bytes circuitid

  Hey guys,.

  I can't know the meaning of the bytes in Option82 that send SG300 of Cisco switches. The switch is in mode of l3, and I relay dhcp installation and works very well.

  By looking at the packet capture, the switch always send this is the MAC address as optional 82 remote-id:

  Suboption option 82: (2) Agent remote ID

  Length: 8

  Remote agent ID: 000634bdc8xxxxxx

  34:BD:C8 is a YES registered to Cisco Systems.

  I can't decipher the circuitid. The last bytes of couple have something to do with the port:

  Port 1:

  0131 0004007d

  Port 2:

  0004007d 0132

  Port 3

  0004007d 0133

  Port 4

  0004007d 0134

  Port 49:

  0004007d 0161

  Port 50:

  0162 0004007d

  But what makes me scratch my head is really byte would be ' after the 0004007, call it the mystery figure. This system of byte to have a meaning related to the type of device connected immediately. When I connected to a computer, there's a ' he. When I connect an aastra phone, I get a '8'. When I connect a Ubiquiti networks AP, I got a '7'.

  I can't understand the numbering for the ports scheme or the meaning of the mystery figure. Any help is appreciated!

  Hi Jonathan sub option 2, your example D is the identifier of the node.

  Seeing the variable by type of connection, I give it a safe assumption that it is wordy padding type void 1.

  The detailed format for package cushion should contain

  Sub option

  length

  node identifier

  port type

  Number of the interface

  ID of the VLAN

  For the format of normal buffer it should contain

  Sub option

  length

  circuit

  length

  ID of the VLAN

  Number of the interface

  -Tom
  Please mark replied messages useful

• Apply the Option DHCP SPA100 Series 60

  Hello

  Is there any plan to apply the DHCP Option 60 (class id of the seller) in the series SPA100 materials in future FWs? CISCO SPA5xx series already has this option for implementation.

  Kind regards

  Josep.

  I do not know what exact device you hear "Materials of the SPA100 series", but in SPA112 and SPA122, it is already implemented. I use it for a long time. See the package caught:

  0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, request

  ...
  Hostname Option 12, length 6: "SPA112."
  Provider Option 60, length 12 class: "CISCO SPA112.

  ...

  Don't forget to mark the thread as answered if it answers your question...

• Cisco WLC 2504 internal DHCP does not work properly

  Hi all

  I m trials with a Cisco WLC 2504 and some APs of 1832. I set up a DHCP scope on the interface of the controller with 2

  a large number of different configurations, but the DHCP protocol does not work and Don t Access Point to obtain an IP address. My first question: is it possible to do DHCP for Access Points or only for wireless clients?

  These are my interfaces:

  Interfaces

  

  Interface of the PA-Manager:

  Interfaces1

  

  Interfaces2

  

  My DHCP scope:

  Scope1 DHCP

  

  Portee2 DHCP

  

  Advanced DHCP:

  DHCP Scope3

  

  I forgot something? Is there anyone using DHCP for its access points?

  Thank you!

  Hello

  On Cisco WLC internal DHCP, you can add the option 43 to say where APs must register. In this case, they will try to resolve the DNS CISCO-CAPWAP-CONTROLLER or CISCO-LWAPP entry.

  Let me explain briefly how AP-Manager works on WLC:

  1. Boots of Access Point and sends a discovery request to the management interface of the controller using the intellectual property you configured as DHCP Option 43 (as described above, it can be resolved by the DNS entry)
  2. Controller, sends it a response discovered that contains the name of the system, addresses AP-Manager, the number of access points already connected to each interface AP-Manager and the overall capacity of the controller.
  3. Joints access point controller using the less loaded interface AP Manager.

  With this, every AP Manager must have a good configured interface and be connected to a different port, no LAG.

  I drop a post here sometimes there is which might help:

  https://supportforums.Cisco.com/document/118311/configuring-multiple-AP-...

  Thank you

  PS: Please do not forget to rate and score as correct answer if this answered your question

• WRT320N dhcp dynamic

  Hello

  I have a linksys WRT320N router. I want my computer to have an internal IP address fixed. Can my router assign an IP address to my computers MAC address? I've known that I can assign a fixed IP address in my settings TCP/IP (Windows Vista). But when I do it is not possible that my router will assign THAT IP address to another device (when my computer is off)?

  Another solution would be to set up a fixed IP on all my devices...

  Thank you

  Jan

  He solved. my router has a 'Réserve DHCP' option. This will do the trick.

  You can also use xxx.xxx.xxxx.50 to xxx.xxx.xxx.100 for dynamic IP address IP address, and then set the other devices to a fixed IP address. in this way it cannot be any conflict of IP

• DHCP Snooping

  Scenerio:

  As part of a modernization project of tech in a big campus and because of several problems caused by users (l) connect the routers on the network and causing DHCP issues, I'm looking to turn on DHCP snooping. During the tech switches access update will be updated first and then the kernel. The new access switches are 4510R + E/Sup7, running the latest IOS XE base license and just passing through. New carrots are 6509 Sup 720's configured as a cluster VSS, manage all routing for VIRTUAL local area networks and have the statements of support IP. The DHCP server which takes care of all the VLAN is a Windows 2008 server that is directly connected to the base.

  I also read all the info I could find on DHCP snooping, but I'm still a little fuzzy on if it changes the way that the DHCP server handles requests.

  Issues related to the:

  • Because the access switches pass only, they only need monitoring DHCP enabled (in the world and on VIRTUAL local area networks) and their uplinks to the core set as being approved, right? In particular, they only declarations of support IP or Layer-3 interfaces for all of their VIRTUAL local networks, right?
  • While I understand that DHCP snooping will be ineffective if it is not lit on the kernel, there is no reason I can't deploy it first to the access layer without touching the basic configurations to avoid large amounts of documents of change control, right? Then, when the kernel is put at level and DHCP snooping successfully activated that will work.
  • I got that on the layer to access the switches uplink to the core are approved, but I'm not 100% on the question of whether the same interfaces are approved on the carrots. I don't think but want to be sure. Carrots of course trust the real interface on that server DHCP is plugged
  • The most confusing part is all the stuff from the Option-82. As near as I can tell its option for the server to use the information from the Option-82. I think that if all I do is enable DHCP snooping on worldwide and on the right VIRTUAL LANs the DHCP relay between the core and the DHCP server will continue to work as it is today, is that correct?

  Is there really this traps or in my case I really just need to turn it on in the world and by vlan, trust the uplinks on the access switches and the DHCP server on the kernel interface and call it a day?

  Thank you

  Nathan Spitzer

  SR Network Communications analyst.

  Lockheed Martin

  Hello Nathan,.

  Given that the access switches are only switching, they only need DHCP snooping turned on (both globally and on the VLANS) and their uplinks to the core set as trusted, right?

  Fix.

  In particular they dont need IP helper statements or layer-3 interfaces for all of their VLANS, right?

  Fix. The statement of support ip address would only be necessary if switches performed routing inter - VLAN and the DHCP server is located in a VLAN different.

  While I understand that DHCP snooping will only be marginally effective if it is not turned on on the core, there is no reason I cannot deploy it first at the access layer without touching the core configurations to avoid large amounts of change-control paperwork, right? Then when the core is upgraded and DHCP snooping properly enabled it will work. 

  To my knowledge, the opposite is true. DHCP Snooping is a service of access protection layer - is it not in the core of the network. It has nothing to protect in the kernel once DHCP messages have beein properly disinfected at the edge of the network. For some inexplicable reason, many people think that the DHCP Snooping should be enabled on the network. The fact is that the DHCP Snooping protects against

  • DHCP messages are sent to ineligible devices
  • Ineligible devices posing as DHCP servers

  From this it naturally follows that it is the limit of the network, or the layer of access, where such protection is the most effective. So in your case, I believe that the activation of the DHCP Snooping only on the access layer is actually what you want to do.

  I got that on the access layer switches the uplinks to the core are trusted, but I am not 100% on whether the same interfaces are trusted on the cores. I dont think so but want to be sure. Of cource the cores do trust the actual interface the DHCP server is plugged in on

  If you enable the DHCP Snooping on the basic features and uplink between the access switches and core would have to be configured as confidence both on the basic switches and access. Otherwise, the base ports would pass DHCP messages received from customers because the access layer switches running DHCP Snooping insert DHCP Option 82 in the DHCP messages sanitized and ports untrustred delete all DHCP messages including 82 of the present Option.

  2960 Configuration Guide to

  http://www.Cisco.com/en/us/docs/switches/LAN/catalyst2960/software/release/12.2_55_se/configuration/guide/swdhcp82.html#wp1078853

  The switch removes a DHCP packet when one of these situations occurs:

  • Comes from a packet to a DHCP server, for example a DHCPOFFER, DHCPACK, DHCPNAK or DHCPLEASEQUERY package, outside the network or firewall.

  • A packet is received on an interface that is not reliable, and do not match the source MAC address and hardware address of the DHCP client.

• The switch receives a message DHCPRELEASE or DHCPDECLINE with a MAC address in the DHCP snooping database binding, but the information in the database of linking interface does not correspond to the interface on which the message was received.

• A DHCP relay agent sends a DHCP packet that includes a relay agent IP address which is not 0.0.0.0 or relay agent transmits a packet that includes information of option-82 to an untrusted port.

As I have indicated, however, I personally discourage running DHCP Snooping on the basic devices - I see no reason for this. Please correct if I am wrong!

The most confusing part is all the Option-82 stuff. As near as I can tell its optional for the server to use the Option-82 information. I believe that if all I do is turn DHCP snooping on globally and on the right VLANS the DHCP relaying between the core and the DHCP server will continue working just like it is today, is that correct?

LOL, my favorite on the DHCP Snooping things is the Option 82 interesting how much this topic brings confusion...

The Option 82 was created to provide DHCP relay agent the ability to identify itself and the customer who sent the original message from DHCP unmodified. The DHCP server can then use this information to perform certain policies of customer trust. The format of the Option 82 is not strictly specified, only its basic structure is fixed. You can read more on this and the whole reason to be in the RFC 3046. One of the key points to remember here, however, is that the DHCP server may or may not recognize the Option 82, but apart from that, to copy the value of the Option 82A received in the message to a DHCP client for all its replies sent to this client.

DHCP Snooping uses the Option 82 differently. He didn't expect and doesn't require that the DHCP Server includes the Option of 82 or manages a special way. The Option 82 is inserted by switches access performing DHCP Snooping and it contains two important parts:

• The Circuit ID that identifies the port to which the client is connected (VLAN and the location of the physical port in a switch)
• The remote ID that identifies the access switch to which the client is connected (by the MAC address of the switch)

See http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/12.2_55_se/configuration/guide/swdhcp82.html#wp1105589

Now, when an access switch performing DHCP Snooping receives a message from DHCP client on an untrusted port, this will happen:

• The switch will insert the 82 Option in the message of the DHCP client. The Option 82 will identify the specific switch and the port to which the client is attached
• The switch will forward the DHCP message according to its MAC address of destination (i.e. in a completely normal way)
• The server receives the DHCP message containing the Option 82. It is not relevant for DHCP Snooping if the server takes into account the value of the Option 82. However, when the server replies, it will insert the original value of the Option of 82 to the answer.
• Access switch will finally receive the DHCP response. Looking at the Option 82, he knows exactly in which port is the message transmitted to the customer - and only the customer - even if the answer was broadcast!

Note that the Option 82 contributes enormously to identify exactly the access switch and its port where the client is attached. If other switches with DHCP Snooping has received this DHCP message (in reason of the flood or address broadcast requested by the client), they would pass this message because they understand once glancing at the 82 Option that the customer is attached elsewhere. The 82 Option allowing to ensure DHCP communication between a particular client and the DHCP server doesn't leak not to other customers.

There is a hunt for witches, associated with the Option 82. A switch run DHCP Snooping inserts the Option 82 messages DHCP clients. However, each DHCP message contains a field named GIADDR where the IP address of the relay agent is registered, where the DHCP message was relayed. Clearly, when a DHCP message goes through a switch DHCP Snooping, it is not relayed (drawn from one VLAN and rerouted to another), so an access switch does not change the GIADDR that remains set to 0.0.0.0. However, at least the implementation of server DHCP Cisco IOS performs a validation on a test received DHCP messages and it drops DHCP messages containing the Option 82, but which the GIADDR field is set to 0.0.0.0 (i.e. unitialized). This can be seen in the output of the debug ip dhcp server packet :

Router# debug ip dhcp server packet

*Sep 9 01:59:40: DHCPD: inconsistent relay information.

*Sep 9 01:59:40: DHCPD: relay information option exists, but giaddr is zero

Under normal circumstances, such a mental health check makes sense - how is it that a DHCP message contains the Option 82 (i.e. the Relay Agent Information Option DHCP) when there is no DHCP relay identified in the GIADDR? However, with DHCP Snooping on the access layer switches, DHCP messages are normal and expected. Therefore, it is essential to disable this check of mental health on the Cisco box that is running the DHCP server configuration using global ip dhcp relay confidence all information or only is selected routed (i.e. L3) interfaces with command level interface ip dhcp relay reliable information.

To summarize:

• The 82 Option is A Good Thing (TM) because it allows to deliver DHCP messages only to the client for which they are intended. Any suggestions to disable the insertion of the Option 82 on access DHCP Snooping Switches are useless 82 Option is inserted by DHCP Snooping Switches in DHCP messages by default - no additional configuration is necessary.
• Through the easiest way - when you deploy DHCP Snooping, does not initially change anything about the Option 82. Make sure that your customers can receive their config IP via DHCP. If yes then there is nothing to resolve. If not, go further.
• If you run a DHCP server on a Device IOS base (router, switch), you may need to use the command ip dhcp relay information confidence-everything (global config) or ip dhcp relay reliable information (level interface) to allow the DHCP messages with the Add Option 82 and unitialized field GIADDR to be accepted. These commands are required only on the device where the DHCP server is running, not on the access layer switches. You may want to first perform debugging as I suggested previously, and only if you see that packets are dropped, add these commands to the configuration.
• I don't know if these commands should be added also to a DHCP relay function efficient switch - I can check that tomorrow in a laboratory.
• If you are using another DHCP server you have to try experimentally whether happy with the DHCP messages with 82 Option present and unitialized GIADDR field

Sorry for the long answer... I hope that I do not bore you to death. We invite you to ask for more! I'll try to be more concise next time

Best regards

Peter