Revert "can: raw: instantly reject unsupported CAN frames"

Commit 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") caused a sequence of dependency and linker fixes.

The entire problem was caused by the requirement that a new network layer feature needed to know about the protocol capabilities of the CAN devices. Instead of accessing CAN device internal data structures which caused the dependency problems this patch introduces capability information into the CAN specific ml_priv data which is accessible from both sides.

With this change the CAN network layer can check the required features and the decoupling of the driver layer and network layer is restored.

Fixes 1a620a723853 ("can: raw: instantly reject unsupported CAN frames")

Cc Marc Kleine-Budde <[email protected]>

Cc Arnd Bergmann <[email protected]>

Cc Vincent Mailhol <[email protected]>

Signed-off-by Oliver Hartkopp <[email protected]>

---
  drivers/net/can/dev/dev.c     | 24 ++++++++++++++++++++++++
  drivers/net/can/dev/netlink.c |  1 +
  drivers/net/can/vcan.c        | 15 +++++++++++++++
  drivers/net/can/vxcan.c       | 15 +++++++++++++++
  include/linux/can/can-ml.h    | 25 +++++++++++++++++++++++++
  include/linux/can/dev.h       |  1 +
  6 files changed, 81 insertions(+)

drivers/net/can/dev/dev.c +24 -0

index 091f30e94c61..aaa669fc0d2b 100644
@@ -373,10 +373,33 @@ void can_set_default_mtu(struct net_device *dev)
  		dev->min_mtu = CAN_MTU;
  		dev->max_mtu = CAN_MTU;
  	}
  }
 
+void can_set_cap_info(struct net_device *dev)
+{
+	struct can_priv *priv = netdev_priv(dev);
+	u32 can_cap = CAN_CAP_CC;
+
+	if (can_dev_in_xl_only_mode(priv)) {
+		/* XL only mode => no CC/FD capability */
+		can_cap = CAN_CAP_XL;
+	} else {
+		if (priv->ctrlmode & CAN_CTRLMODE_FD)
+			can_cap |= CAN_CAP_FD;
+
+		if (priv->ctrlmode & CAN_CTRLMODE_XL)
+			can_cap |= CAN_CAP_XL;
+	}
+
+	if (priv->ctrlmode & (CAN_CTRLMODE_LISTENONLY |
+			      CAN_CTRLMODE_RESTRICTED))
+		can_cap |= CAN_CAP_RO;
+
+	can_set_cap(dev, can_cap);
+}
+
  /* helper to define static CAN controller features at device creation time */
  int can_set_static_ctrlmode(struct net_device *dev, u32 static_mode)
  {
  	struct can_priv *priv = netdev_priv(dev);
 

@@ -388,10 +411,11 @@ int can_set_static_ctrlmode(struct net_device *dev, u32 static_mode)
  	}
  	priv->ctrlmode = static_mode;
 
  	/* override MTU which was set by default in can_setup()? */
  	can_set_default_mtu(dev);
+	can_set_cap_info(dev);
 
  	return 0;
  }
  EXPORT_SYMBOL_GPL(can_set_static_ctrlmode);
 

drivers/net/can/dev/netlink.c +1 -0

index d6b0e686fb11..0498198a4696 100644
@@ -375,10 +375,11 @@ static int can_ctrlmode_changelink(struct net_device *dev,
  		memset(&priv->xl.tdc, 0, sizeof(priv->xl.tdc));
  		memset(&priv->xl.pwm, 0, sizeof(priv->xl.pwm));
  	}
 
  	can_set_default_mtu(dev);
+	can_set_cap_info(dev);
 
  	return 0;
  }
 
  static int can_tdc_changelink(struct data_bittiming_params *dbt_params,

drivers/net/can/vcan.c +15 -0

index fdc662aea279..76e6b7b5c6a1 100644
@@ -128,10 +128,23 @@ static netdev_tx_t vcan_tx(struct sk_buff *skb, struct net_device *dev)
  		consume_skb(skb);
  	}
  	return NETDEV_TX_OK;
  }
 
+static void vcan_set_cap_info(struct net_device *dev)
+{
+	u32 can_cap = CAN_CAP_CC;
+
+	if (dev->mtu > CAN_MTU)
+		can_cap |= CAN_CAP_FD;
+
+	if (dev->mtu >= CANXL_MIN_MTU)
+		can_cap |= CAN_CAP_XL;
+
+	can_set_cap(dev, can_cap);
+}
+
  static int vcan_change_mtu(struct net_device *dev, int new_mtu)
  {
  	/* Do not allow changing the MTU while running */
  	if (dev->flags & IFF_UP)
  		return -EBUSY;

@@ -139,10 +152,11 @@ static int vcan_change_mtu(struct net_device *dev, int new_mtu)
  	if (new_mtu != CAN_MTU && new_mtu != CANFD_MTU &&
  	    !can_is_canxl_dev_mtu(new_mtu))
  		return -EINVAL;
 
  	WRITE_ONCE(dev->mtu, new_mtu);
+	vcan_set_cap_info(dev);
  	return 0;
  }
 
  static const struct net_device_ops vcan_netdev_ops = {
  	.ndo_start_xmit = vcan_tx,

@@ -160,10 +174,11 @@ static void vcan_setup(struct net_device *dev)
  	dev->hard_header_len	= 0;
  	dev->addr_len		= 0;
  	dev->tx_queue_len	= 0;
  	dev->flags		= IFF_NOARP;
  	can_set_ml_priv(dev, netdev_priv(dev));
+	vcan_set_cap_info(dev);
 
  	/* set flags according to driver capabilities */
  	if (echo)
  		dev->flags |= IFF_ECHO;
 

drivers/net/can/vxcan.c +15 -0

index b2c19f8c5f8e..f14c6f02b662 100644
@@ -123,10 +123,23 @@ static int vxcan_get_iflink(const struct net_device *dev)
  	rcu_read_unlock();
 
  	return iflink;
  }
 
+static void vxcan_set_cap_info(struct net_device *dev)
+{
+	u32 can_cap = CAN_CAP_CC;
+
+	if (dev->mtu > CAN_MTU)
+		can_cap |= CAN_CAP_FD;
+
+	if (dev->mtu >= CANXL_MIN_MTU)
+		can_cap |= CAN_CAP_XL;
+
+	can_set_cap(dev, can_cap);
+}
+
  static int vxcan_change_mtu(struct net_device *dev, int new_mtu)
  {
  	/* Do not allow changing the MTU while running */
  	if (dev->flags & IFF_UP)
  		return -EBUSY;

@@ -134,10 +147,11 @@ static int vxcan_change_mtu(struct net_device *dev, int new_mtu)
  	if (new_mtu != CAN_MTU && new_mtu != CANFD_MTU &&
  	    !can_is_canxl_dev_mtu(new_mtu))
  		return -EINVAL;
 
  	WRITE_ONCE(dev->mtu, new_mtu);
+	vxcan_set_cap_info(dev);
  	return 0;
  }
 
  static const struct net_device_ops vxcan_netdev_ops = {
  	.ndo_open	= vxcan_open,

@@ -165,10 +179,11 @@ static void vxcan_setup(struct net_device *dev)
  	dev->ethtool_ops	= &vxcan_ethtool_ops;
  	dev->needs_free_netdev	= true;
 
  	can_ml = netdev_priv(dev) + ALIGN(sizeof(struct vxcan_priv), NETDEV_ALIGN);
  	can_set_ml_priv(dev, can_ml);
+	vxcan_set_cap_info(dev);
  }
 
  /* forward declaration for rtnl_create_link() */
  static struct rtnl_link_ops vxcan_link_ops;
 

include/linux/can/can-ml.h +25 -0

index 8afa92d15a66..ff77097ae79f 100644
@@ -44,10 +44,16 @@
 
  #include <linux/can.h>
  #include <linux/list.h>
  #include <linux/netdevice.h>
 
+/* exposed CAN device capabilities for network layer */
+#define CAN_CAP_CC 0x1U /* CAN CC aka Classical CAN */
+#define CAN_CAP_FD 0x2U /* CAN FD */
+#define CAN_CAP_XL 0x4U /* CAN XL */
+#define CAN_CAP_RO 0x8U /* read-only mode (LISTEN/RESTRICTED) */
+
  #define CAN_SFF_RCV_ARRAY_SZ (1 << CAN_SFF_ID_BITS)
  #define CAN_EFF_RCV_HASH_BITS 10
  #define CAN_EFF_RCV_ARRAY_SZ (1 << CAN_EFF_RCV_HASH_BITS)
 
  enum { RX_ERR, RX_ALL, RX_FIL, RX_INV, RX_MAX };

@@ -62,10 +68,11 @@ struct can_dev_rcv_lists {
  struct can_ml_priv {
  	struct can_dev_rcv_lists dev_rcv_lists;
  #ifdef CAN_J1939
  	struct j1939_priv *j1939_priv;
  #endif
+	u32 can_cap;
  };
 
  static inline struct can_ml_priv *can_get_ml_priv(struct net_device *dev)
  {
  	return netdev_get_ml_priv(dev, ML_PRIV_CAN);

@@ -75,6 +82,24 @@ static inline void can_set_ml_priv(struct net_device *dev,
  				   struct can_ml_priv *ml_priv)
  {
  	netdev_set_ml_priv(dev, ml_priv, ML_PRIV_CAN);
  }
 
+static inline bool can_cap_enabled(struct net_device *dev, u32 cap)
+{
+	struct can_ml_priv *can_ml = can_get_ml_priv(dev);
+
+	if (!can_ml)
+		return true;
+
+	return (can_ml->can_cap & cap);
+}
+
+static inline void can_set_cap(struct net_device *dev, u32 cap)
+{
+	struct can_ml_priv *can_ml = can_get_ml_priv(dev);
+
+	if (can_ml)
+		can_ml->can_cap = cap;
+}
+
  #endif /* CAN_ML_H */

include/linux/can/dev.h +1 -0

index 52c8be5c160e..6d0710d6f571 100644
@@ -114,10 +114,11 @@ void free_candev(struct net_device *dev);
  struct can_priv *safe_candev_priv(struct net_device *dev);
 
  int open_candev(struct net_device *dev);
  void close_candev(struct net_device *dev);
  void can_set_default_mtu(struct net_device *dev);
+void can_set_cap_info(struct net_device *dev);
  int __must_check can_set_static_ctrlmode(struct net_device *dev,
  					 u32 static_mode);
  int can_hwtstamp_get(struct net_device *netdev,
  		     struct kernel_hwtstamp_config *cfg);
  int can_hwtstamp_set(struct net_device *netdev,

Quoted 9 lines · Oliver Hartkopp

Commit 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") caused a sequence of dependency and linker fixes.

The entire problem was caused by the requirement that a new network layer feature needed to know about the protocol capabilities of the CAN devices. Instead of accessing CAN device internal data structures which caused the dependency problems this patch introduces capability information into the CAN specific ml_priv data which is accessible from both sides.

Quoted 4 lines

With this change the CAN network layer can check the required features and the decoupling of the driver layer and network layer is restored.

Fixes 1a620a723853 ("can: raw: instantly reject unsupported CAN frames")

Are you fine with this patch set?
I've tested it and it works as expected.

IMO the two patches after the revert should have no problems to be accepted as they restore the functionality we already had in 6.19-rc1.

Quoted 15 lines · Oliver Hartkopp

Quoted 13 lines · Oliver Hartkopp

Commit 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") caused a sequence of dependency and linker fixes.

The entire problem was caused by the requirement that a new network layer feature needed to know about the protocol capabilities of the CAN devices. Instead of accessing CAN device internal data structures which caused the dependency problems this patch introduces capability information into the CAN specific ml_priv data which is accessible from both sides.

With this change the CAN network layer can check the required features and the decoupling of the driver layer and network layer is restored.

Fixes 1a620a723853 ("can: raw: instantly reject unsupported CAN frames")

Quoted 2 lines

Are you fine with this patch set?
I've tested it and it works as expected.

It seems to be OK as an interim solution, that fixes current mess.

But the main problem is, that we don't have the "struct can_priv can" in the netdev_priv of virtual devices. That should be fixed sooner or later.

Quoted 2 lines

IMO the two patches after the revert should have no problems to be accepted as they restore the functionality we already had in 6.19-rc1.

Yes, I think so.

Commit 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") caused a sequence of dependency and linker fixes.

The entire problem was caused by the requirement that a new network layer feature needed to know about the protocol capabilities of the CAN devices. Instead of accessing CAN device internal data structures which caused the dependency problems this patch introduces capability information into the CAN specific ml_priv data which is accessible from both sides.

With this change the CAN network layer can check the required features and the decoupling of the driver layer and network layer is restored.

Fixes 1a620a723853 ("can: raw: instantly reject unsupported CAN frames")

Cc Marc Kleine-Budde <[email protected]>

Cc Arnd Bergmann <[email protected]>

Cc Vincent Mailhol <[email protected]>

Signed-off-by Oliver Hartkopp <[email protected]>

---
 drivers/net/can/dev/dev.c     | 24 ++++++++++++++++++++++++
 drivers/net/can/dev/netlink.c |  1 +
 drivers/net/can/vcan.c        | 15 +++++++++++++++
 drivers/net/can/vxcan.c       | 15 +++++++++++++++
 include/linux/can/can-ml.h    | 25 +++++++++++++++++++++++++
 include/linux/can/dev.h       |  1 +
 6 files changed, 81 insertions(+)

drivers/net/can/dev/dev.c +0 -0

index 091f30e94c61..aaa669fc0d2b 100644

drivers/net/can/dev/dev.c +19 -0

+
+	if (can_dev_in_xl_only_mode(priv)) {
+		/* XL only mode => no CC/FD capability */
+		can_cap = CAN_CAP_XL;
+	} else {
+		if (priv->ctrlmode & CAN_CTRLMODE_FD)
+			can_cap |= CAN_CAP_FD;
+
+		if (priv->ctrlmode & CAN_CTRLMODE_XL)
+			can_cap |= CAN_CAP_XL;
+	}
+
+	if (priv->ctrlmode & (CAN_CTRLMODE_LISTENONLY |
+			      CAN_CTRLMODE_RESTRICTED))
+		can_cap |= CAN_CAP_RO;
+
+	can_set_cap(dev, can_cap);
+}
+

include/linux/can/can-ml.h +0 -0

index 8afa92d15a66..ff77097ae79f 100644

include/linux/can/can-ml.h +2 -0

+
 #define CAN_SFF_RCV_ARRAY_SZ (1 << CAN_SFF_ID_BITS)
 #define CAN_EFF_RCV_HASH_BITS 10
 #define CAN_EFF_RCV_ARRAY_SZ (1 << CAN_EFF_RCV_HASH_BITS)
 
 enum { RX_ERR, RX_ALL, RX_FIL, RX_INV, RX_MAX };

@@ -62,10 +68,11 @@ struct can_dev_rcv_lists {
 struct can_ml_priv {
 	struct can_dev_rcv_lists dev_rcv_lists;
 #ifdef CAN_J1939
 	struct j1939_priv *j1939_priv;
 #endif
+	u32 can_cap;
 };
 
 static inline struct can_ml_priv *can_get_ml_priv(struct net_device *dev)
 {
 	return netdev_get_ml_priv(dev, ML_PRIV_CAN);

@@ -75,6 +82,24 @@ static inline void can_set_ml_priv(struct net_device *dev,
 				   struct can_ml_priv *ml_priv)

Can you please add a cover letter to this series.

more comments inline...

Quoted 36 lines · Oliver Hartkopp

Commit 1a620a723853 ("can: raw: instantly reject unsupported CAN frames") caused a sequence of dependency and linker fixes.

The entire problem was caused by the requirement that a new network layer feature needed to know about the protocol capabilities of the CAN devices. Instead of accessing CAN device internal data structures which caused the dependency problems this patch introduces capability information into the CAN specific ml_priv data which is accessible from both sides.

With this change the CAN network layer can check the required features and the decoupling of the driver layer and network layer is restored.

Fixes 1a620a723853 ("can: raw: instantly reject unsupported CAN frames")

Cc Marc Kleine-Budde <[email protected]>

Cc Arnd Bergmann <[email protected]>

Cc Vincent Mailhol <[email protected]>

Signed-off-by Oliver Hartkopp <[email protected]>

---
  drivers/net/can/dev/dev.c     | 24 ++++++++++++++++++++++++
  drivers/net/can/dev/netlink.c |  1 +
  drivers/net/can/vcan.c        | 15 +++++++++++++++
  drivers/net/can/vxcan.c       | 15 +++++++++++++++
  include/linux/can/can-ml.h    | 25 +++++++++++++++++++++++++
  include/linux/can/dev.h       |  1 +
  6 files changed, 81 insertions(+)

drivers/net/can/dev/dev.c +0 -0

index 091f30e94c61..aaa669fc0d2b 100644
@@ -373,10 +373,33 @@ void can_set_default_mtu(struct net_device *dev)
  		dev->min_mtu = CAN_MTU;
  		dev->max_mtu = CAN_MTU;
  	}
  }
 

drivers/net/can/dev/dev.c void can_set_default_mtu(struct net_device *dev) · line 381

Quoted 4 lines

drivers/net/can/dev/dev.c +4 -0

+void can_set_cap_info(struct net_device *dev)
+{
+	struct can_priv *priv = netdev_priv(dev);
+	u32 can_cap = CAN_CAP_CC;

I personally I would move the CAN_CAP_CC into the else branch. YMMV.

Quoted 19 lines

drivers/net/can/dev/dev.c +19 -0

+
+	if (can_dev_in_xl_only_mode(priv)) {
+		/* XL only mode => no CC/FD capability */
+		can_cap = CAN_CAP_XL;
+	} else {
+		if (priv->ctrlmode & CAN_CTRLMODE_FD)
+			can_cap |= CAN_CAP_FD;
+
+		if (priv->ctrlmode & CAN_CTRLMODE_XL)
+			can_cap |= CAN_CAP_XL;
+	}
+
+	if (priv->ctrlmode & (CAN_CTRLMODE_LISTENONLY |
+			      CAN_CTRLMODE_RESTRICTED))
+		can_cap |= CAN_CAP_RO;
+
+	can_set_cap(dev, can_cap);
+}
+

[...]

Quoted 10 lines

include/linux/can/can-ml.h +0 -0

index 8afa92d15a66..ff77097ae79f 100644
@@ -44,10 +44,16 @@
 
  #include <linux/can.h>
  #include <linux/list.h>
  #include <linux/netdevice.h>
 

include/linux/can/can-ml.h line 53

Quoted 5 lines

include/linux/can/can-ml.h +5 -0

+/* exposed CAN device capabilities for network layer */
+#define CAN_CAP_CC 0x1U /* CAN CC aka Classical CAN */
+#define CAN_CAP_FD 0x2U /* CAN FD */
+#define CAN_CAP_XL 0x4U /* CAN XL */
+#define CAN_CAP_RO 0x8U /* read-only mode (LISTEN/RESTRICTED) */

Can we use BIT() here?

Quoted 24 lines

include/linux/can/can-ml.h +2 -0

+
  #define CAN_SFF_RCV_ARRAY_SZ (1 << CAN_SFF_ID_BITS)
  #define CAN_EFF_RCV_HASH_BITS 10
  #define CAN_EFF_RCV_ARRAY_SZ (1 << CAN_EFF_RCV_HASH_BITS)
 
  enum { RX_ERR, RX_ALL, RX_FIL, RX_INV, RX_MAX };

@@ -62,10 +68,11 @@ struct can_dev_rcv_lists {
  struct can_ml_priv {
  	struct can_dev_rcv_lists dev_rcv_lists;
  #ifdef CAN_J1939
  	struct j1939_priv *j1939_priv;
  #endif
+	u32 can_cap;
  };
 
  static inline struct can_ml_priv *can_get_ml_priv(struct net_device *dev)
  {
  	return netdev_get_ml_priv(dev, ML_PRIV_CAN);

@@ -75,6 +82,24 @@ static inline void can_set_ml_priv(struct net_device *dev,
  				   struct can_ml_priv *ml_priv)
  {
  	netdev_set_ml_priv(dev, ml_priv, ML_PRIV_CAN);
  }
 

include/linux/can/can-ml.h static inline void can_set_ml_priv(struct net_device *dev, · line 92

Quoted 6 lines

include/linux/can/can-ml.h +6 -0

+static inline bool can_cap_enabled(struct net_device *dev, u32 cap)
+{
+	struct can_ml_priv *can_ml = can_get_ml_priv(dev);
+
+	if (!can_ml)
+		return true;

Why is the capability enabled, if the device doesn't have a CAN ml_priv?

Quoted 4 lines

include/linux/can/can-ml.h +4 -0

+
+	return (can_ml->can_cap & cap);
+}
+

include/linux/can/can-ml.h static inline void can_set_ml_priv(struct net_device *dev, · line 101

Quoted 5 lines

include/linux/can/can-ml.h +5 -0

+static inline void can_set_cap(struct net_device *dev, u32 cap)
+{
+	struct can_ml_priv *can_ml = can_get_ml_priv(dev);
+
+	if (can_ml)

IMHO it's a bug if can_ml is NULL, it should not be ignored silently. Maybe just de-ref the NULL pointer?

include/linux/can/can-ml.h static inline void can_set_ml_priv(struct net_device *dev, · line 105

Quoted 5 lines

include/linux/can/can-ml.h +3 -0

+		can_ml->can_cap = cap;
+}
+
  #endif /* CAN_ML_H */

Thanks,
Marc

Quoted 8 lines

include/linux/can/can-ml.h static inline void can_set_ml_priv(struct net_device *dev, · line 92

Quoted 6 lines

include/linux/can/can-ml.h +6 -0

+static inline bool can_cap_enabled(struct net_device *dev, u32 cap)
+{
+	struct can_ml_priv *can_ml = can_get_ml_priv(dev);
+
+	if (!can_ml)
+		return true;

Why is the capability enabled, if the device doesn't have a CAN ml_priv?

I have been thought about virtual CAN interfaces first but they also have a can_ml.

It's just a double-check if we really have a CAN interface here. But returning false would make more sense then. Will change.

For real CAN interfaces the CAN_CTRLMODE_FD and CAN_CTRLMODE_XL control modes indicate whether an interface can handle those CAN FD/XL frames.

In the case a CAN XL interface is configured in CANXL-only mode with disabled error-signalling neither CAN CC nor CAN FD frames can be sent.

The checks are now performed on CAN_RAW sockets to give an instant feedback to the user when writing unsupported CAN frames to the interface or when the CAN interface is in read-only mode.

Fixes 1a620a723853 ("can: raw: instantly reject unsupported CAN frames")

Cc Marc Kleine-Budde <[email protected]>

Cc Arnd Bergmann <[email protected]>

Cc Vincent Mailhol <[email protected]>

Signed-off-by Oliver Hartkopp <[email protected]>

---
 net/can/raw.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)

net/can/raw.c +0 -0

index f36a83d3447c..aa6e8b19be22 100644

Quoted 19 lines · Oliver Hartkopp

For real CAN interfaces the CAN_CTRLMODE_FD and CAN_CTRLMODE_XL control modes indicate whether an interface can handle those CAN FD/XL frames.

In the case a CAN XL interface is configured in CANXL-only mode with disabled error-signalling neither CAN CC nor CAN FD frames can be sent.

The checks are now performed on CAN_RAW sockets to give an instant feedback to the user when writing unsupported CAN frames to the interface or when the CAN interface is in read-only mode.

Fixes 1a620a723853 ("can: raw: instantly reject unsupported CAN frames")

Cc Marc Kleine-Budde <[email protected]>

Cc Arnd Bergmann <[email protected]>

Cc Vincent Mailhol <[email protected]>

Signed-off-by Oliver Hartkopp <[email protected]>

---
  net/can/raw.c | 23 ++++++++++++++---------
  1 file changed, 14 insertions(+), 9 deletions(-)

net/can/raw.c line 53

Quoted 12 lines

net/can/raw.c +1 -1

index f36a83d3447c..aa6e8b19be22 100644
@@ -48,11 +48,11 @@
  #include <linux/socket.h>
  #include <linux/if_arp.h>
  #include <linux/skbuff.h>
  #include <linux/can.h>
  #include <linux/can/core.h>
-#include <linux/can/dev.h> /* for can_is_canxl_dev_mtu() */
+#include <linux/can/can-ml.h> /* for can_cap_enabled() */

I think we can remove the comment, please keep the list sorted.

otherwise LGTM, thanks
Marc

--

Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |

Vertretung Nürnberg | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |