[PATCH v3] ath10k: rebuild crypto header in rx data frames
From: Vasanthakumar Thiagarajan Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done on host (mac80211) rather than firmware. Rebuild cipher header in every received data frames (that are notified through those HTT interfaces) from the rx_hdr_status tlv available in the rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED flag for the packets which requires mac80211 PN/TSC check support and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the rebuilding of cipher header to perform PN/TSC check for replay attack. Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers in raw mode needs to be fixed. Since Rx with these ciphers in raw mode does not work in the current form even without this patch and removing crypto tail for these chipers needs clean up, raw mode related issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up patches. Tested-by: Manikanta Pubbisetty Signed-off-by: Vasanthakumar Thiagarajan Signed-off-by: Kalle Valo --- v3: * Fix cipher header construction for CCMP-256, GCMP and GCMP-256 ciphers. * Fix bug in raw mode when RX_FLAG_IV_STRIPPED is set. v2: * Construct cipher header from rx_hdr_status tlv rather than from the msdu_start and mpdu_start tlvs. This fixes connection issues, also reduces the amount of code change. * Make sure the frame is qos data before clearing AMSDU_PRESENT bit of qos control field. * Fix traffic issue with QCA988X and QCA9887 hw by taking care of padding bytes added for 4-byte alignment before the cipher header. drivers/net/wireless/ath/ath10k/htt_rx.c | 105 +- drivers/net/wireless/ath/ath10k/rx_desc.h | 3 + 2 files changed, 92 insertions(+), 16 deletions(-) diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c index a3f5dc78353f..5beb6ee0f091 100644 --- a/drivers/net/wireless/ath/ath10k/htt_rx.c +++ b/drivers/net/wireless/ath/ath10k/htt_rx.c @@ -550,6 +550,11 @@ static int ath10k_htt_rx_crypto_param_len(struct ath10k *ar, return IEEE80211_TKIP_IV_LEN; case HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2: return IEEE80211_CCMP_HDR_LEN; + case HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2: + return IEEE80211_CCMP_256_HDR_LEN; + case HTT_RX_MPDU_ENCRYPT_AES_GCMP_WPA2: + case HTT_RX_MPDU_ENCRYPT_AES_GCMP256_WPA2: + return IEEE80211_GCMP_HDR_LEN; case HTT_RX_MPDU_ENCRYPT_WEP128: case HTT_RX_MPDU_ENCRYPT_WAPI: break; @@ -575,6 +580,11 @@ static int ath10k_htt_rx_crypto_tail_len(struct ath10k *ar, return IEEE80211_TKIP_ICV_LEN; case HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2: return IEEE80211_CCMP_MIC_LEN; + case HTT_RX_MPDU_ENCRYPT_AES_CCM256_WPA2: + return IEEE80211_CCMP_256_MIC_LEN; + case HTT_RX_MPDU_ENCRYPT_AES_GCMP_WPA2: + case HTT_RX_MPDU_ENCRYPT_AES_GCMP256_WPA2: + return IEEE80211_GCMP_MIC_LEN; case HTT_RX_MPDU_ENCRYPT_WEP128: case HTT_RX_MPDU_ENCRYPT_WAPI: break; @@ -1051,9 +1061,21 @@ static void ath10k_htt_rx_h_undecap_raw(struct ath10k *ar, hdr = (void *)msdu->data; /* Tail */ - if (status->flag & RX_FLAG_IV_STRIPPED) + if (status->flag & RX_FLAG_IV_STRIPPED) { skb_trim(msdu, msdu->len - ath10k_htt_rx_crypto_tail_len(ar, enctype)); + } else { + /* MIC */ + if ((status->flag & RX_FLAG_MIC_STRIPPED) && + enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2) + skb_trim(msdu, msdu->len - 8); + + /* ICV */ + if (status->flag & RX_FLAG_ICV_STRIPPED && + enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2) + skb_trim(msdu, msdu->len - +ath10k_htt_rx_crypto_tail_len(ar, enctype)); + } /* MMIC */ if ((status->flag & RX_FLAG_MMIC_STRIPPED) && @@ -1075,7 +1097,8 @@ static void ath10k_htt_rx_h_undecap_raw(struct ath10k *ar, static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k *ar, struct sk_buff *msdu, struct ieee80211_rx_status *status, - const u8 first_hdr[64]) + const u8 first_hdr[64], + enum htt_rx_mpdu_encrypt_type enctype) { struct ieee80211_hdr *hdr; struct htt_rx_desc *rxd; @@ -1083,6 +1106,7 @@ static void ath10k_htt_rx_h_undecap_nwifi(struct ath10k *ar, u8 da[ETH_ALEN]; u8 sa[ETH_ALEN]; int l3_pad_bytes; + int bytes_aligned = ar->hw_params.decap_align_bytes; /* D
Re: [v3] ath10k: rebuild crypto header in rx data frames
Kalle Valo wrote: > Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and > HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done > on host (mac80211) rather than firmware. Rebuild cipher header > in every received data frames (that are notified through those > HTT interfaces) from the rx_hdr_status tlv available in the > rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED > flag for the packets which requires mac80211 PN/TSC check support > and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, > QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the > rebuilding of cipher header to perform PN/TSC check for replay > attack. > > Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers > in raw mode needs to be fixed. Since Rx with these ciphers in raw > mode does not work in the current form even without this patch and > removing crypto tail for these chipers needs clean up, raw mode related > issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up > patches. > > Tested-by: Manikanta Pubbisetty > Signed-off-by: Vasanthakumar Thiagarajan > Signed-off-by: Kalle Valo Any comments or feedback about this? I'm hoping to apply this during the weekend so that it will make it to v4.14 in time. So if there are any issues with this patch please let me know ASAP. -- https://patchwork.kernel.org/patch/10028621/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [v3] ath10k: rebuild crypto header in rx data frames
Kalle Valo wrote: > Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and > HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done > on host (mac80211) rather than firmware. Rebuild cipher header > in every received data frames (that are notified through those > HTT interfaces) from the rx_hdr_status tlv available in the > rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED > flag for the packets which requires mac80211 PN/TSC check support > and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, > QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the > rebuilding of cipher header to perform PN/TSC check for replay > attack. > > Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers > in raw mode needs to be fixed. Since Rx with these ciphers in raw > mode does not work in the current form even without this patch and > removing crypto tail for these chipers needs clean up, raw mode related > issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up > patches. > > Tested-by: Manikanta Pubbisetty > Signed-off-by: Vasanthakumar Thiagarajan > Signed-off-by: Kalle Valo Patch applied to ath-current branch of ath.git, thanks. 7eccb738fce5 ath10k: rebuild crypto header in rx data frames -- https://patchwork.kernel.org/patch/10028621/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [v3] ath10k: rebuild crypto header in rx data frames
will check it tomorrow including gcmp-256, ccmp-256. was out for weekend :-) Am 30.10.2017 um 09:39 schrieb Kalle Valo: Kalle Valo wrote: Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done on host (mac80211) rather than firmware. Rebuild cipher header in every received data frames (that are notified through those HTT interfaces) from the rx_hdr_status tlv available in the rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED flag for the packets which requires mac80211 PN/TSC check support and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the rebuilding of cipher header to perform PN/TSC check for replay attack. Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers in raw mode needs to be fixed. Since Rx with these ciphers in raw mode does not work in the current form even without this patch and removing crypto tail for these chipers needs clean up, raw mode related issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up patches. Tested-by: Manikanta Pubbisetty Signed-off-by: Vasanthakumar Thiagarajan Signed-off-by: Kalle Valo Patch applied to ath-current branch of ath.git, thanks. 7eccb738fce5 ath10k: rebuild crypto header in rx data frames -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
Re: [v3] ath10k: rebuild crypto header in rx data frames
the following patchlines in the v3 patch look wrong + /* ICV */ + if (status->flag & RX_FLAG_ICV_STRIPPED && + enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2) + skb_trim(msdu, msdu->len - + ath10k_htt_rx_crypto_tail_len(ar, enctype)); the enctype != wpa2 isnt enough since it also belongs to ccmp-256, gcmp modes etc. my proposal if (status->flag & RX_FLAG_ICV_STRIPPED) { switch(enctype) { case HTT_RX_MPDU_ENCRYPT_WEP40: case HTT_RX_MPDU_ENCRYPT_WEP104: - case HTT_RX_MPDU_ENCRYPT_TKIP_WITHOUT_MIC: case HTT_RX_MPDU_ENCRYPT_TKIP_WPA: skb_trim(msdu, msdu->len - ath10k_htt_rx_crypto_tail_len(ar, enctype)); break; default: break; } - } Am 30.10.2017 um 10:32 schrieb Sebastian Gottschall: will check it tomorrow including gcmp-256, ccmp-256. was out for weekend :-) Am 30.10.2017 um 09:39 schrieb Kalle Valo: Kalle Valo wrote: Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done on host (mac80211) rather than firmware. Rebuild cipher header in every received data frames (that are notified through those HTT interfaces) from the rx_hdr_status tlv available in the rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED flag for the packets which requires mac80211 PN/TSC check support and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the rebuilding of cipher header to perform PN/TSC check for replay attack. Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers in raw mode needs to be fixed. Since Rx with these ciphers in raw mode does not work in the current form even without this patch and removing crypto tail for these chipers needs clean up, raw mode related issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up patches. Tested-by: Manikanta Pubbisetty Signed-off-by: Vasanthakumar Thiagarajan Signed-off-by: Kalle Valo Patch applied to ath-current branch of ath.git, thanks. 7eccb738fce5 ath10k: rebuild crypto header in rx data frames -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
Re: [v3] ath10k: rebuild crypto header in rx data frames
the same is for the MIC + /* MIC */ + if ((status->flag & RX_FLAG_MIC_STRIPPED) && + enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2) + skb_trim(msdu, msdu->len - 8); this code looks wrong too Am 30.10.2017 um 10:32 schrieb Sebastian Gottschall: will check it tomorrow including gcmp-256, ccmp-256. was out for weekend :-) Am 30.10.2017 um 09:39 schrieb Kalle Valo: Kalle Valo wrote: Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done on host (mac80211) rather than firmware. Rebuild cipher header in every received data frames (that are notified through those HTT interfaces) from the rx_hdr_status tlv available in the rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED flag for the packets which requires mac80211 PN/TSC check support and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the rebuilding of cipher header to perform PN/TSC check for replay attack. Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers in raw mode needs to be fixed. Since Rx with these ciphers in raw mode does not work in the current form even without this patch and removing crypto tail for these chipers needs clean up, raw mode related issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up patches. Tested-by: Manikanta Pubbisetty Signed-off-by: Vasanthakumar Thiagarajan Signed-off-by: Kalle Valo Patch applied to ath-current branch of ath.git, thanks. 7eccb738fce5 ath10k: rebuild crypto header in rx data frames -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
Re: [v3] ath10k: rebuild crypto header in rx data frames
Sebastian Gottschall writes: > the following patchlines in the v3 patch look wrong > > + /* ICV */ > + if (status->flag & RX_FLAG_ICV_STRIPPED && > + enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2) > + skb_trim(msdu, msdu->len - > + ath10k_htt_rx_crypto_tail_len(ar, > enctype)); > > > the enctype != wpa2 isnt enough since it also belongs to ccmp-256, > gcmp modes etc. 4.14 doesn't support CCMP-256 nor GCMP modes yet. Did you check the separate patch for 4.15: https://patchwork.kernel.org/patch/10029097/ -- Kalle Valo
Re: [v3] ath10k: rebuild crypto header in rx data frames
Sorry top posting. The issues in raw mode with CCMP-256, GCMP and GCMP-256 were already known and the same was captured in the commit log. As mentioned in the commit log, raw mode with these ciphers does not work even without this particular patch and it needs some cleanup like done in the follow up patch https://patchwork.kernel.org/patch/10029099/. Vasanth From: Sebastian Gottschall Sent: Tuesday, October 31, 2017 8:24 PM To: Kalle Valo Cc: ath...@lists.infradead.org; linux-wireless@vger.kernel.org; Vasanthakumar Thiagarajan Subject: Re: [v3] ath10k: rebuild crypto header in rx data frames the same is for the MIC + /* MIC */ + if ((status->flag & RX_FLAG_MIC_STRIPPED) && + enctype == HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2) + skb_trim(msdu, msdu->len - 8); this code looks wrong too Am 30.10.2017 um 10:32 schrieb Sebastian Gottschall: > will check it tomorrow including gcmp-256, ccmp-256. was out for > weekend :-) > > Am 30.10.2017 um 09:39 schrieb Kalle Valo: >> Kalle Valo wrote: >> >>> Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and >>> HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done >>> on host (mac80211) rather than firmware. Rebuild cipher header >>> in every received data frames (that are notified through those >>> HTT interfaces) from the rx_hdr_status tlv available in the >>> rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED >>> flag for the packets which requires mac80211 PN/TSC check support >>> and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, >>> QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the >>> rebuilding of cipher header to perform PN/TSC check for replay >>> attack. >>> >>> Please note that removing crypto tail for CCMP-256, GCMP and >>> GCMP-256 ciphers >>> in raw mode needs to be fixed. Since Rx with these ciphers in raw >>> mode does not work in the current form even without this patch and >>> removing crypto tail for these chipers needs clean up, raw mode related >>> issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up >>> patches. >>> >>> Tested-by: Manikanta Pubbisetty >>> Signed-off-by: Vasanthakumar Thiagarajan >>> Signed-off-by: Kalle Valo >> Patch applied to ath-current branch of ath.git, thanks. >> >> 7eccb738fce5 ath10k: rebuild crypto header in rx data frames >> > -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
Re: [v3] ath10k: rebuild crypto header in rx data frames
Am 31.10.2017 um 16:00 schrieb Kalle Valo: Sebastian Gottschall writes: the following patchlines in the v3 patch look wrong + /* ICV */ + if (status->flag & RX_FLAG_ICV_STRIPPED && + enctype != HTT_RX_MPDU_ENCRYPT_AES_CCM_WPA2) + skb_trim(msdu, msdu->len - + ath10k_htt_rx_crypto_tail_len(ar, enctype)); the enctype != wpa2 isnt enough since it also belongs to ccmp-256, gcmp modes etc. 4.14 doesn't support CCMP-256 nor GCMP modes yet. Did you check the separate patch for 4.15: for me ccmp-256 and gcmp works but my current tree is based on a very recent mac80211 version but did not check if this support is included in 4.14 since i'm developing embedded wireless firmwares on different kernel versions using wireless backports based on recent mac80211 /ath10k etc. versions https://patchwork.kernel.org/patch/10029097/ thanks for notifying me. havent seen it -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565
Re: [v3] ath10k: rebuild crypto header in rx data frames
Is this patch destined for stable? I was expecting to see it show up in the older stable releases, but it has not so far as far as I can tell. Thanks, Ben On 10/30/2017 02:32 AM, Sebastian Gottschall wrote: will check it tomorrow including gcmp-256, ccmp-256. was out for weekend :-) Am 30.10.2017 um 09:39 schrieb Kalle Valo: Kalle Valo wrote: Rx data frames notified through HTT_T2H_MSG_TYPE_RX_IND and HTT_T2H_MSG_TYPE_RX_FRAG_IND expect PN/TSC check to be done on host (mac80211) rather than firmware. Rebuild cipher header in every received data frames (that are notified through those HTT interfaces) from the rx_hdr_status tlv available in the rx descriptor of the first msdu. Skip setting RX_FLAG_IV_STRIPPED flag for the packets which requires mac80211 PN/TSC check support and set appropriate RX_FLAG for stripped crypto tail. Hw QCA988X, QCA9887, QCA99X0, QCA9984, QCA9888 and QCA4019 currently need the rebuilding of cipher header to perform PN/TSC check for replay attack. Please note that removing crypto tail for CCMP-256, GCMP and GCMP-256 ciphers in raw mode needs to be fixed. Since Rx with these ciphers in raw mode does not work in the current form even without this patch and removing crypto tail for these chipers needs clean up, raw mode related issues in CCMP-256, GCMP and GCMP-256 can be addressed in follow up patches. Tested-by: Manikanta Pubbisetty Signed-off-by: Vasanthakumar Thiagarajan Signed-off-by: Kalle Valo Patch applied to ath-current branch of ath.git, thanks. 7eccb738fce5 ath10k: rebuild crypto header in rx data frames -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [v3] ath10k: rebuild crypto header in rx data frames
Ben Greear writes: > Is this patch destined for stable? > > I was expecting to see it show up in the older stable releases, > but it has not so far as far as I can tell. We are working on it, but not sure yet to which releases, it doesn't directly apply to all active stable releases. -- Kalle Valo
Re: [v3] ath10k: rebuild crypto header in rx data frames
On 12/02/2017 06:34 AM, Kalle Valo wrote: Ben Greear writes: Is this patch destined for stable? I was expecting to see it show up in the older stable releases, but it has not so far as far as I can tell. We are working on it, but not sure yet to which releases, it doesn't directly apply to all active stable releases. I had no luck trying to apply it to a 3.17-ish ath10k. Gave up after a bit and tried backporting the whole stack instead :P Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com
Re: [v3] ath10k: rebuild crypto header in rx data frames
you need a recent ath10k version. use the backports project to compile a recent ath10k/mac80211 for 3.17 or take a look into lede, it has a complete recent backports tree which can be used on 3.17 with small modifications Am 02.12.2017 um 22:41 schrieb Ben Greear: On 12/02/2017 06:34 AM, Kalle Valo wrote: Ben Greear writes: Is this patch destined for stable? I was expecting to see it show up in the older stable releases, but it has not so far as far as I can tell. We are working on it, but not sure yet to which releases, it doesn't directly apply to all active stable releases. I had no luck trying to apply it to a 3.17-ish ath10k. Gave up after a bit and tried backporting the whole stack instead :P Thanks, Ben -- Mit freundlichen Grüssen / Regards Sebastian Gottschall / CTO NewMedia-NET GmbH - DD-WRT Firmensitz: Stubenwaldallee 21a, 64625 Bensheim Registergericht: Amtsgericht Darmstadt, HRB 25473 Geschäftsführer: Peter Steinhäuser, Christian Scheele http://www.dd-wrt.com email: s.gottsch...@dd-wrt.com Tel.: +496251-582650 / Fax: +496251-5826565