Menu
▾
▴
openadsl-devel — openadsl developers list
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
(4) |
Jun
(30) |
Jul
(42) |
Aug
(33) |
Sep
(12) |
Oct
(16) |
Nov
(5) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
|
Nov
(1) |
Dec
(4) |
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
(1) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
(19) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: David M. <da...@da...> - 2012-02-23 21:54:25
|
From: Eric Dumazet <eri...@gm...> Date: Thu, 23 Feb 2012 21:55:02 +0100 > Niccolo Belli reported ipsec crashes in case we handle a frame without > mac header (atm in his case) > > Before copying mac header, better make sure it is present. > > Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809 > > Reported-by: Niccolò Belli <dar...@li...> > Tested-by: Niccolò Belli <dar...@li...> > Signed-off-by: Eric Dumazet <eri...@gm...> Applied and queued up for -stable, thanks. BTW, if anyone wants to see what's queued up for -stable I have a public patchwork bundle for it: http://patchwork.ozlabs.org/bundle/davem/stable/ Just FYI. |
|
From: Eric D. <eri...@gm...> - 2012-02-23 20:55:17
|
Niccolo Belli reported ipsec crashes in case we handle a frame without mac header (atm in his case) Before copying mac header, better make sure it is present. Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809 Reported-by: Niccolò Belli <dar...@li...> Tested-by: Niccolò Belli <dar...@li...> Signed-off-by: Eric Dumazet <eri...@gm...> --- V2: added skb_mac_header_rebuild() helper as David suggested. include/linux/skbuff.h | 10 ++++++++++ net/ipv4/xfrm4_mode_beet.c | 5 +---- net/ipv4/xfrm4_mode_tunnel.c | 6 ++---- net/ipv6/xfrm6_mode_beet.c | 6 +----- net/ipv6/xfrm6_mode_tunnel.c | 6 ++---- 5 files changed, 16 insertions(+), 17 deletions(-) diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 50db9b0..ae86ade 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -1465,6 +1465,16 @@ static inline void skb_set_mac_header(struct sk_buff *skb, const int offset) } #endif /* NET_SKBUFF_DATA_USES_OFFSET */ +static inline void skb_mac_header_rebuild(struct sk_buff *skb) +{ + if (skb_mac_header_was_set(skb)) { + const unsigned char *old_mac = skb_mac_header(skb); + + skb_set_mac_header(skb, -skb->mac_len); + memmove(skb_mac_header(skb), old_mac, skb->mac_len); + } +} + static inline int skb_checksum_start_offset(const struct sk_buff *skb) { return skb->csum_start - skb_headroom(skb); diff --git a/net/ipv4/xfrm4_mode_beet.c b/net/ipv4/xfrm4_mode_beet.c index 6341818..e3db3f9 100644 --- a/net/ipv4/xfrm4_mode_beet.c +++ b/net/ipv4/xfrm4_mode_beet.c @@ -110,10 +110,7 @@ static int xfrm4_beet_input(struct xfrm_state *x, struct sk_buff *skb) skb_push(skb, sizeof(*iph)); skb_reset_network_header(skb); - - memmove(skb->data - skb->mac_len, skb_mac_header(skb), - skb->mac_len); - skb_set_mac_header(skb, -skb->mac_len); + skb_mac_header_rebuild(skb); xfrm4_beet_make_header(skb); diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c index 534972e..ed4bf11 100644 --- a/net/ipv4/xfrm4_mode_tunnel.c +++ b/net/ipv4/xfrm4_mode_tunnel.c @@ -66,7 +66,6 @@ static int xfrm4_mode_tunnel_output(struct xfrm_state *x, struct sk_buff *skb) static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb) { - const unsigned char *old_mac; int err = -EINVAL; if (XFRM_MODE_SKB_CB(skb)->protocol != IPPROTO_IPIP) @@ -84,10 +83,9 @@ static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb) if (!(x->props.flags & XFRM_STATE_NOECN)) ipip_ecn_decapsulate(skb); - old_mac = skb_mac_header(skb); - skb_set_mac_header(skb, -skb->mac_len); - memmove(skb_mac_header(skb), old_mac, skb->mac_len); skb_reset_network_header(skb); + skb_mac_header_rebuild(skb); + err = 0; out: diff --git a/net/ipv6/xfrm6_mode_beet.c b/net/ipv6/xfrm6_mode_beet.c index a81ce94..9949a35 100644 --- a/net/ipv6/xfrm6_mode_beet.c +++ b/net/ipv6/xfrm6_mode_beet.c @@ -80,7 +80,6 @@ static int xfrm6_beet_output(struct xfrm_state *x, struct sk_buff *skb) static int xfrm6_beet_input(struct xfrm_state *x, struct sk_buff *skb) { struct ipv6hdr *ip6h; - const unsigned char *old_mac; int size = sizeof(struct ipv6hdr); int err; @@ -90,10 +89,7 @@ static int xfrm6_beet_input(struct xfrm_state *x, struct sk_buff *skb) __skb_push(skb, size); skb_reset_network_header(skb); - - old_mac = skb_mac_header(skb); - skb_set_mac_header(skb, -skb->mac_len); - memmove(skb_mac_header(skb), old_mac, skb->mac_len); + skb_mac_header_rebuild(skb); xfrm6_beet_make_header(skb); diff --git a/net/ipv6/xfrm6_mode_tunnel.c b/net/ipv6/xfrm6_mode_tunnel.c index 261e6e6..9f2095b 100644 --- a/net/ipv6/xfrm6_mode_tunnel.c +++ b/net/ipv6/xfrm6_mode_tunnel.c @@ -63,7 +63,6 @@ static int xfrm6_mode_tunnel_output(struct xfrm_state *x, struct sk_buff *skb) static int xfrm6_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb) { int err = -EINVAL; - const unsigned char *old_mac; if (XFRM_MODE_SKB_CB(skb)->protocol != IPPROTO_IPV6) goto out; @@ -80,10 +79,9 @@ static int xfrm6_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb) if (!(x->props.flags & XFRM_STATE_NOECN)) ipip6_ecn_decapsulate(skb); - old_mac = skb_mac_header(skb); - skb_set_mac_header(skb, -skb->mac_len); - memmove(skb_mac_header(skb), old_mac, skb->mac_len); skb_reset_network_header(skb); + skb_mac_header_rebuild(skb); + err = 0; out: |
|
From: Eric D. <eri...@gm...> - 2012-02-23 20:28:16
|
Le jeudi 23 février 2012 à 15:23 -0500, David Miller a écrit : > I think the work to backport is equal whether you use a helper function > or not. Heck, use an inline function so you don't have to worry about > module exports or any details like that. > > Besides, I'm the one who likely has to backport this thing, so... :-) Great, I'll send an updated version in a couple of minutes ;) |
|
From: David M. <da...@da...> - 2012-02-23 20:23:52
|
From: Eric Dumazet <eri...@gm...> Date: Thu, 23 Feb 2012 21:17:23 +0100 > Le jeudi 23 février 2012 à 15:11 -0500, David Miller a écrit : >> Three instances of the same piece of code, maybe a helper function is >> appropriate at that point? :-) You might even get ambitious and add a >> big comment to that helper function explaining the situation. > > I did have this idea but refrained because this kind of things is harder > to backport to stable kernels. > > I'll make a cleanup in net-next if you agree ? I think the work to backport is equal whether you use a helper function or not. Heck, use an inline function so you don't have to worry about module exports or any details like that. Besides, I'm the one who likely has to backport this thing, so... :-) |
|
From: Eric D. <eri...@gm...> - 2012-02-23 20:17:37
|
Le jeudi 23 février 2012 à 15:11 -0500, David Miller a écrit : > Three instances of the same piece of code, maybe a helper function is > appropriate at that point? :-) You might even get ambitious and add a > big comment to that helper function explaining the situation. I did have this idea but refrained because this kind of things is harder to backport to stable kernels. I'll make a cleanup in net-next if you agree ? |
|
From: David M. <da...@da...> - 2012-02-23 20:12:09
|
From: Eric Dumazet <eri...@gm...> Date: Thu, 23 Feb 2012 15:36:26 +0100 > [PATCH] ipsec: be careful of non existing mac headers > > Nicollo Belli reported ipsec crashes in case we handle a frame without > mac header (atm in his case) > > Before copying mac header, better make sure it is present. > > Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809 > > Reported-by: Niccolò Belli <dar...@li...> > Tested-by: Niccolò Belli <dar...@li...> > Signed-off-by: Eric Dumazet <eri...@gm...> Three instances of the same piece of code, maybe a helper function is appropriate at that point? :-) You might even get ambitious and add a big comment to that helper function explaining the situation. |
|
From: Niccolò B. <dar...@li...> - 2012-02-23 19:08:31
|
Il 23/02/2012 15:39, Eric Dumazet ha scritto: > Oops sorry for your name being mangled in changelog, its Niccolò as > correctly spelled in the "Reported-by" and "Tested-by" tags Don't worry and thanks for your help. I'm currently running the official patch you submitted for review. Niccolò |
|
From: Eric D. <eri...@gm...> - 2012-02-23 14:39:23
|
Le jeudi 23 février 2012 à 15:36 +0100, Eric Dumazet a écrit : > [PATCH] ipsec: be careful of non existing mac headers > > Nicollo Belli reported ipsec crashes in case we handle a frame without > mac header (atm in his case) Oops sorry for your name being mangled in changelog, its Niccolò as correctly spelled in the "Reported-by" and "Tested-by" tags |
|
From: Eric D. <eri...@gm...> - 2012-02-23 14:36:45
|
> Your patch does solve the problem, thanks! > Thanks for testing. Here is the official patch I submit for review then. [PATCH] ipsec: be careful of non existing mac headers Nicollo Belli reported ipsec crashes in case we handle a frame without mac header (atm in his case) Before copying mac header, better make sure it is present. Bugzilla reference: https://bugzilla.kernel.org/show_bug.cgi?id=42809 Reported-by: Niccolò Belli <dar...@li...> Tested-by: Niccolò Belli <dar...@li...> Signed-off-by: Eric Dumazet <eri...@gm...> --- net/ipv4/xfrm4_mode_beet.c | 9 +++++---- net/ipv4/xfrm4_mode_tunnel.c | 10 ++++++---- net/ipv6/xfrm6_mode_beet.c | 9 +++++---- net/ipv6/xfrm6_mode_tunnel.c | 10 ++++++---- 4 files changed, 22 insertions(+), 16 deletions(-) diff --git a/net/ipv4/xfrm4_mode_beet.c b/net/ipv4/xfrm4_mode_beet.c index 6341818..d3451f6 100644 --- a/net/ipv4/xfrm4_mode_beet.c +++ b/net/ipv4/xfrm4_mode_beet.c @@ -111,10 +111,11 @@ static int xfrm4_beet_input(struct xfrm_state *x, struct sk_buff *skb) skb_push(skb, sizeof(*iph)); skb_reset_network_header(skb); - memmove(skb->data - skb->mac_len, skb_mac_header(skb), - skb->mac_len); - skb_set_mac_header(skb, -skb->mac_len); - + if (skb_mac_header_was_set(skb)) { + memmove(skb->data - skb->mac_len, skb_mac_header(skb), + skb->mac_len); + skb_set_mac_header(skb, -skb->mac_len); + } xfrm4_beet_make_header(skb); iph = ip_hdr(skb); diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c index 534972e..a646f30 100644 --- a/net/ipv4/xfrm4_mode_tunnel.c +++ b/net/ipv4/xfrm4_mode_tunnel.c @@ -66,7 +66,6 @@ static int xfrm4_mode_tunnel_output(struct xfrm_state *x, struct sk_buff *skb) static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb) { - const unsigned char *old_mac; int err = -EINVAL; if (XFRM_MODE_SKB_CB(skb)->protocol != IPPROTO_IPIP) @@ -84,9 +83,12 @@ static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb) if (!(x->props.flags & XFRM_STATE_NOECN)) ipip_ecn_decapsulate(skb); - old_mac = skb_mac_header(skb); - skb_set_mac_header(skb, -skb->mac_len); - memmove(skb_mac_header(skb), old_mac, skb->mac_len); + if (skb_mac_header_was_set(skb)) { + const unsigned char *old_mac = skb_mac_header(skb); + + skb_set_mac_header(skb, -skb->mac_len); + memmove(skb_mac_header(skb), old_mac, skb->mac_len); + } skb_reset_network_header(skb); err = 0; diff --git a/net/ipv6/xfrm6_mode_beet.c b/net/ipv6/xfrm6_mode_beet.c index a81ce94..74c4b92 100644 --- a/net/ipv6/xfrm6_mode_beet.c +++ b/net/ipv6/xfrm6_mode_beet.c @@ -80,7 +80,6 @@ static int xfrm6_beet_output(struct xfrm_state *x, struct sk_buff *skb) static int xfrm6_beet_input(struct xfrm_state *x, struct sk_buff *skb) { struct ipv6hdr *ip6h; - const unsigned char *old_mac; int size = sizeof(struct ipv6hdr); int err; @@ -91,10 +90,12 @@ static int xfrm6_beet_input(struct xfrm_state *x, struct sk_buff *skb) __skb_push(skb, size); skb_reset_network_header(skb); - old_mac = skb_mac_header(skb); - skb_set_mac_header(skb, -skb->mac_len); - memmove(skb_mac_header(skb), old_mac, skb->mac_len); + if (skb_mac_header_was_set(skb)) { + const unsigned char *old_mac = skb_mac_header(skb); + skb_set_mac_header(skb, -skb->mac_len); + memmove(skb_mac_header(skb), old_mac, skb->mac_len); + } xfrm6_beet_make_header(skb); ip6h = ipv6_hdr(skb); diff --git a/net/ipv6/xfrm6_mode_tunnel.c b/net/ipv6/xfrm6_mode_tunnel.c index 261e6e6..edb7091 100644 --- a/net/ipv6/xfrm6_mode_tunnel.c +++ b/net/ipv6/xfrm6_mode_tunnel.c @@ -63,7 +63,6 @@ static int xfrm6_mode_tunnel_output(struct xfrm_state *x, struct sk_buff *skb) static int xfrm6_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb) { int err = -EINVAL; - const unsigned char *old_mac; if (XFRM_MODE_SKB_CB(skb)->protocol != IPPROTO_IPV6) goto out; @@ -80,9 +79,12 @@ static int xfrm6_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb) if (!(x->props.flags & XFRM_STATE_NOECN)) ipip6_ecn_decapsulate(skb); - old_mac = skb_mac_header(skb); - skb_set_mac_header(skb, -skb->mac_len); - memmove(skb_mac_header(skb), old_mac, skb->mac_len); + if (skb_mac_header_was_set(skb)) { + const unsigned char *old_mac = skb_mac_header(skb); + + skb_set_mac_header(skb, -skb->mac_len); + memmove(skb_mac_header(skb), old_mac, skb->mac_len); + } skb_reset_network_header(skb); err = 0; |
|
From: chas w. - C. <ch...@cm...> - 2012-02-23 14:04:05
|
On Thu, 23 Feb 2012 02:54:39 +0100 Eric Dumazet <eri...@gm...> wrote: > Le jeudi 23 février 2012 à 02:38 +0100, Eric Dumazet a écrit : > > > Which driver handles this Traverse Solos card ? > > If br2684_push() is used, it seems it lacks proper call to > skb_reset_mac_header(skb) in paths where eth_type_trans() is not called. > > Later in xfrm4_mode_tunnel_input() we crash because we assume > skb_mac_header() is valid. when br2684_push() doesnt call eth_type_trans() the underlying packet doesnt have a mac address header -- just an llc header that says 'ip packet is next'. |
|
From: Niccolò B. <dar...@li...> - 2012-02-23 13:45:48
|
Il 23/02/2012 03:06, Eric Dumazet ha scritto:
> Thanks !
>
> Please try following patch.
>
> diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c
> index 534972e..f170933 100644
> --- a/net/ipv4/xfrm4_mode_tunnel.c
> +++ b/net/ipv4/xfrm4_mode_tunnel.c
> @@ -84,9 +84,11 @@ static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
> if (!(x->props.flags& XFRM_STATE_NOECN))
> ipip_ecn_decapsulate(skb);
>
> - old_mac = skb_mac_header(skb);
> - skb_set_mac_header(skb, -skb->mac_len);
> - memmove(skb_mac_header(skb), old_mac, skb->mac_len);
> + if (skb_mac_header_was_set(skb)) {
> + old_mac = skb_mac_header(skb);
> + skb_set_mac_header(skb, -skb->mac_len);
> + memmove(skb_mac_header(skb), old_mac, skb->mac_len);
> + }
> skb_reset_network_header(skb);
> err = 0;
>
Your patch does solve the problem, thanks!
Niccolò
|
|
From: Niccolò B. <dar...@li...> - 2012-02-23 02:12:41
|
Il 23/02/2012 03:06, Eric Dumazet ha scritto:
> Please try following patch.
>
> diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c
> index 534972e..f170933 100644
> --- a/net/ipv4/xfrm4_mode_tunnel.c
> +++ b/net/ipv4/xfrm4_mode_tunnel.c
> @@ -84,9 +84,11 @@ static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
> if (!(x->props.flags& XFRM_STATE_NOECN))
> ipip_ecn_decapsulate(skb);
>
> - old_mac = skb_mac_header(skb);
> - skb_set_mac_header(skb, -skb->mac_len);
> - memmove(skb_mac_header(skb), old_mac, skb->mac_len);
> + if (skb_mac_header_was_set(skb)) {
> + old_mac = skb_mac_header(skb);
> + skb_set_mac_header(skb, -skb->mac_len);
> + memmove(skb_mac_header(skb), old_mac, skb->mac_len);
> + }
> skb_reset_network_header(skb);
> err = 0;
Wow, thanks! It will try it as soon as possible tomorrow, going sleeping
now :)
Niccolò
|
|
From: Eric D. <eri...@gm...> - 2012-02-23 02:06:43
|
Le jeudi 23 février 2012 à 03:02 +0100, Niccolò Belli a écrit :
> Il 23/02/2012 02:38, Eric Dumazet ha scritto:
> > Which driver handles this Traverse Solos card ?
>
> drivers/atm/solos-pci.c
>
> ~# lsmod | grep solos
> solos_pci 20009 2
> atm 32378 7 pppoatm,br2684,solos_pci
>
Thanks !
Please try following patch.
diff --git a/net/ipv4/xfrm4_mode_tunnel.c b/net/ipv4/xfrm4_mode_tunnel.c
index 534972e..f170933 100644
--- a/net/ipv4/xfrm4_mode_tunnel.c
+++ b/net/ipv4/xfrm4_mode_tunnel.c
@@ -84,9 +84,11 @@ static int xfrm4_mode_tunnel_input(struct xfrm_state *x, struct sk_buff *skb)
if (!(x->props.flags & XFRM_STATE_NOECN))
ipip_ecn_decapsulate(skb);
- old_mac = skb_mac_header(skb);
- skb_set_mac_header(skb, -skb->mac_len);
- memmove(skb_mac_header(skb), old_mac, skb->mac_len);
+ if (skb_mac_header_was_set(skb)) {
+ old_mac = skb_mac_header(skb);
+ skb_set_mac_header(skb, -skb->mac_len);
+ memmove(skb_mac_header(skb), old_mac, skb->mac_len);
+ }
skb_reset_network_header(skb);
err = 0;
|
|
From: Jason W. <ja...@ja...> - 2012-02-23 02:04:18
|
Eric Dumazet <eri...@gm...> wrote: > Which driver handles this Traverse Solos card ? solos_pci, which also requires the atm module. (I'm just trying to help here; I'm not affected by the bug.) |
|
From: Niccolò B. <dar...@li...> - 2012-02-23 02:02:30
|
Il 23/02/2012 02:38, Eric Dumazet ha scritto: > Which driver handles this Traverse Solos card ? drivers/atm/solos-pci.c ~# lsmod | grep solos solos_pci 20009 2 atm 32378 7 pppoatm,br2684,solos_pci Niccolò |
|
From: Niccolò B. <nic...@li...> - 2012-02-23 01:55:12
|
Il 23/02/2012 02:38, Eric Dumazet ha scritto: > Which driver handles this Traverse Solos card ? drivers/atm/solos-pci.c ~# lsmod | grep solos solos_pci 20009 2 atm 32378 7 pppoatm,br2684,solos_pci Niccolò |
|
From: Eric D. <eri...@gm...> - 2012-02-23 01:54:51
|
Le jeudi 23 février 2012 à 02:38 +0100, Eric Dumazet a écrit : > Which driver handles this Traverse Solos card ? If br2684_push() is used, it seems it lacks proper call to skb_reset_mac_header(skb) in paths where eth_type_trans() is not called. Later in xfrm4_mode_tunnel_input() we crash because we assume skb_mac_header() is valid. |
|
From: Eric D. <eri...@gm...> - 2012-02-23 01:38:17
|
Le jeudi 23 février 2012 à 01:59 +0100, Niccolò Belli a écrit : > Hi, > The bug is still present in latest 3.2.7 vanilla kernel. I wasted the > whole day debugging that damn thing and I finally discovered the root cause. > The problem is with my Traverse Solos multi-port ADSL2+ PCI card[1] > (which has open source drivers included in the kernel) when using RFC > 2684 routed. > I have two adsl lines, the first one connected using RFC 2684 routed, > the second one using PPPoA. > If I create a vpn toward the PPPoA line it works flawlessly, while if I > create a vpn toward the RFC 2684 routed line the whole system hangs in a > kernel panic (with both 2.6.32.54 and 3.2.7). > I really don't know how to fix it and I need to setup that damn ipsec vpn :( > > This is the bug on bugzilla.kernel.org: > https://bugzilla.kernel.org/show_bug.cgi?id=42809 > > Niccolò > > > [1]http://www.traverse.com.au/productview.php?product_id=116 Which driver handles this Traverse Solos card ? |
|
From: Niccolò B. <dar...@li...> - 2012-02-23 01:19:13
|
Hi, The bug is still present in latest 3.2.7 vanilla kernel. I wasted the whole day debugging that damn thing and I finally discovered the root cause. The problem is with my Traverse Solos multi-port ADSL2+ PCI card[1] (which has open source drivers included in the kernel) when using RFC 2684 routed. I have two adsl lines, the first one connected using RFC 2684 routed, the second one using PPPoA. If I create a vpn toward the PPPoA line it works flawlessly, while if I create a vpn toward the RFC 2684 routed line the whole system hangs in a kernel panic (with both 2.6.32.54 and 3.2.7). I really don't know how to fix it and I need to setup that damn ipsec vpn :( This is the bug on bugzilla.kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=42809 Niccolò [1]http://www.traverse.com.au/productview.php?product_id=116 |
|
From: José L. S. B. <jl...@al...> - 2011-10-19 17:01:51
|
OK. Where can I get that firmware from? Thank you On 10/19/2011 06:22 PM, Guy Ellis wrote: > Hi again, > > Ah, you need to upgrade the firmware to 1.10 > > What hardware do you have Solos or Geos? > > Cheers, > - Guy. > > On 19/10/2011 5:17 PM, José Luis Sanz Boixader wrote: > >> On insmod solos-pci: >> Solos PCI Driver Version 1.03 svn-35 >> solos 0000:00:0c.0: Solos FPGA Version 0.03 svn-39 >> solos 0000:00:0c.0: Registered ATM device 0 >> >> # soloscli -g 0 Version >> 1.08 >> >> # cat /sys/class/atm/solos-pci0/parameters/FirmwareVersion >> E.25.41.65 A >> # cat /sys/class/atm/solos-pci0/parameters/Version >> 1.08 >> # cat /sys/class/atm/solos-pci0/parameters/DriverVersion >> 1.75 >> # cat /sys/class/atm/solos-pci0/parameters/APIVersion >> GS_API_653 >> >> Cheers >> >> >> On 10/19/2011 06:08 PM, Guy Ellis wrote: >> >> >>> Hi Jose, >>> >>> Can you please check which firmware version you are using? >>> >>> soloscli -g 0 Version >>> >>> Cheers, >>> - Guy. >>> >>> On 19/10/2011 5:02 PM, José Luis Sanz Boixader wrote: >>> >>> >>> >>>> Hi, >>>> >>>> Looking at code ( linux-solos-driver/v1.03 ), there is function that >>>> seems to process status messages from ADSL to send them to syslog: >>>> .... >>>> case PKT_STATUS: >>>> if (process_status(card, port, skb)&& >>>> .... >>>> >>>> I would like to receive this information from syslog to process some >>>> events regarding ADSL, but I have made several tests (sync, drop, init) >>>> and I have never seen any PKT_STATUS packet. >>>> Do I have to activate this type of status packets via any parameter at >>>> /sys/class/atm/..../params/.. ? >>>> Any other way to receive ADSL status events without constantly reading a >>>> file on /sys ? >>>> >>>> Thank you >>>> >>>> ------------------------------------------------------------------------------ >>>> All the data continuously generated in your IT infrastructure contains a >>>> definitive record of customers, application performance, security >>>> threats, fraudulent activity and more. Splunk takes this data and makes >>>> sense of it. Business sense. IT sense. Common sense. >>>> http://p.sf.net/sfu/splunk-d2d-oct >>>> _______________________________________________ >>>> openadsl-devel mailing list >>>> ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/openadsl-devel >>>> >>>> >>>> >>>> >>>> >>> >>> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2d-oct >> _______________________________________________ >> openadsl-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openadsl-devel >> >> >> > > |
|
From: José L. S. B. <jl...@al...> - 2011-10-19 16:27:40
|
Geos On 10/19/2011 06:22 PM, Guy Ellis wrote: > Hi again, > > Ah, you need to upgrade the firmware to 1.10 > > What hardware do you have Solos or Geos? > > Cheers, > - Guy. > > On 19/10/2011 5:17 PM, José Luis Sanz Boixader wrote: >> On insmod solos-pci: >> Solos PCI Driver Version 1.03 svn-35 >> solos 0000:00:0c.0: Solos FPGA Version 0.03 svn-39 >> solos 0000:00:0c.0: Registered ATM device 0 >> >> # soloscli -g 0 Version >> 1.08 >> >> # cat /sys/class/atm/solos-pci0/parameters/FirmwareVersion >> E.25.41.65 A >> # cat /sys/class/atm/solos-pci0/parameters/Version >> 1.08 >> # cat /sys/class/atm/solos-pci0/parameters/DriverVersion >> 1.75 >> # cat /sys/class/atm/solos-pci0/parameters/APIVersion >> GS_API_653 >> >> Cheers >> >> >> On 10/19/2011 06:08 PM, Guy Ellis wrote: >>> Hi Jose, >>> >>> Can you please check which firmware version you are using? >>> >>> soloscli -g 0 Version >>> >>> Cheers, >>> - Guy. >>> >>> On 19/10/2011 5:02 PM, José Luis Sanz Boixader wrote: >>> >>>> Hi, >>>> >>>> Looking at code ( linux-solos-driver/v1.03 ), there is function that >>>> seems to process status messages from ADSL to send them to syslog: >>>> .... >>>> case PKT_STATUS: >>>> if (process_status(card, port, skb)&& >>>> .... >>>> >>>> I would like to receive this information from syslog to process some >>>> events regarding ADSL, but I have made several tests (sync, drop, >>>> init) >>>> and I have never seen any PKT_STATUS packet. >>>> Do I have to activate this type of status packets via any parameter at >>>> /sys/class/atm/..../params/.. ? >>>> Any other way to receive ADSL status events without constantly >>>> reading a >>>> file on /sys ? >>>> >>>> Thank you >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> All the data continuously generated in your IT infrastructure >>>> contains a >>>> definitive record of customers, application performance, security >>>> threats, fraudulent activity and more. Splunk takes this data and >>>> makes >>>> sense of it. Business sense. IT sense. Common sense. >>>> http://p.sf.net/sfu/splunk-d2d-oct >>>> _______________________________________________ >>>> openadsl-devel mailing list >>>> ope...@li... >>>> https://lists.sourceforge.net/lists/listinfo/openadsl-devel >>>> >>>> >>>> >>> >> >> ------------------------------------------------------------------------------ >> >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2d-oct >> _______________________________________________ >> openadsl-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openadsl-devel >> > > |
|
From: Guy E. <gu...@tr...> - 2011-10-19 16:23:23
|
Hi again, Ah, you need to upgrade the firmware to 1.10 What hardware do you have Solos or Geos? Cheers, - Guy. On 19/10/2011 5:17 PM, José Luis Sanz Boixader wrote: > On insmod solos-pci: > Solos PCI Driver Version 1.03 svn-35 > solos 0000:00:0c.0: Solos FPGA Version 0.03 svn-39 > solos 0000:00:0c.0: Registered ATM device 0 > > # soloscli -g 0 Version > 1.08 > > # cat /sys/class/atm/solos-pci0/parameters/FirmwareVersion > E.25.41.65 A > # cat /sys/class/atm/solos-pci0/parameters/Version > 1.08 > # cat /sys/class/atm/solos-pci0/parameters/DriverVersion > 1.75 > # cat /sys/class/atm/solos-pci0/parameters/APIVersion > GS_API_653 > > Cheers > > > On 10/19/2011 06:08 PM, Guy Ellis wrote: > >> Hi Jose, >> >> Can you please check which firmware version you are using? >> >> soloscli -g 0 Version >> >> Cheers, >> - Guy. >> >> On 19/10/2011 5:02 PM, José Luis Sanz Boixader wrote: >> >> >>> Hi, >>> >>> Looking at code ( linux-solos-driver/v1.03 ), there is function that >>> seems to process status messages from ADSL to send them to syslog: >>> .... >>> case PKT_STATUS: >>> if (process_status(card, port, skb)&& >>> .... >>> >>> I would like to receive this information from syslog to process some >>> events regarding ADSL, but I have made several tests (sync, drop, init) >>> and I have never seen any PKT_STATUS packet. >>> Do I have to activate this type of status packets via any parameter at >>> /sys/class/atm/..../params/.. ? >>> Any other way to receive ADSL status events without constantly reading a >>> file on /sys ? >>> >>> Thank you >>> >>> ------------------------------------------------------------------------------ >>> All the data continuously generated in your IT infrastructure contains a >>> definitive record of customers, application performance, security >>> threats, fraudulent activity and more. Splunk takes this data and makes >>> sense of it. Business sense. IT sense. Common sense. >>> http://p.sf.net/sfu/splunk-d2d-oct >>> _______________________________________________ >>> openadsl-devel mailing list >>> ope...@li... >>> https://lists.sourceforge.net/lists/listinfo/openadsl-devel >>> >>> >>> >>> >> >> > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > openadsl-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openadsl-devel > > -- Guy Ellis gu...@tr... www.traverse.com.au T: +61 3 9386 4430 M: +61 419 398 234 |
|
From: José L. S. B. <jl...@al...> - 2011-10-19 16:16:31
|
On insmod solos-pci: Solos PCI Driver Version 1.03 svn-35 solos 0000:00:0c.0: Solos FPGA Version 0.03 svn-39 solos 0000:00:0c.0: Registered ATM device 0 # soloscli -g 0 Version 1.08 # cat /sys/class/atm/solos-pci0/parameters/FirmwareVersion E.25.41.65 A # cat /sys/class/atm/solos-pci0/parameters/Version 1.08 # cat /sys/class/atm/solos-pci0/parameters/DriverVersion 1.75 # cat /sys/class/atm/solos-pci0/parameters/APIVersion GS_API_653 Cheers On 10/19/2011 06:08 PM, Guy Ellis wrote: > Hi Jose, > > Can you please check which firmware version you are using? > > soloscli -g 0 Version > > Cheers, > - Guy. > > On 19/10/2011 5:02 PM, José Luis Sanz Boixader wrote: > >> Hi, >> >> Looking at code ( linux-solos-driver/v1.03 ), there is function that >> seems to process status messages from ADSL to send them to syslog: >> .... >> case PKT_STATUS: >> if (process_status(card, port, skb)&& >> .... >> >> I would like to receive this information from syslog to process some >> events regarding ADSL, but I have made several tests (sync, drop, init) >> and I have never seen any PKT_STATUS packet. >> Do I have to activate this type of status packets via any parameter at >> /sys/class/atm/..../params/.. ? >> Any other way to receive ADSL status events without constantly reading a >> file on /sys ? >> >> Thank you >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2d-oct >> _______________________________________________ >> openadsl-devel mailing list >> ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openadsl-devel >> >> >> > > |
|
From: Guy E. <gu...@tr...> - 2011-10-19 16:08:46
|
Hi Jose, Can you please check which firmware version you are using? soloscli -g 0 Version Cheers, - Guy. On 19/10/2011 5:02 PM, José Luis Sanz Boixader wrote: > Hi, > > Looking at code ( linux-solos-driver/v1.03 ), there is function that > seems to process status messages from ADSL to send them to syslog: > .... > case PKT_STATUS: > if (process_status(card, port, skb)&& > .... > > I would like to receive this information from syslog to process some > events regarding ADSL, but I have made several tests (sync, drop, init) > and I have never seen any PKT_STATUS packet. > Do I have to activate this type of status packets via any parameter at > /sys/class/atm/..../params/.. ? > Any other way to receive ADSL status events without constantly reading a > file on /sys ? > > Thank you > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2d-oct > _______________________________________________ > openadsl-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/openadsl-devel > > -- Guy Ellis gu...@tr... www.traverse.com.au T: +61 3 9386 4430 M: +61 419 398 234 |
|
From: José L. S. B. <jl...@al...> - 2011-10-19 16:02:14
|
Hi,
Looking at code ( linux-solos-driver/v1.03 ), there is function that
seems to process status messages from ADSL to send them to syslog:
....
case PKT_STATUS:
if (process_status(card, port, skb) &&
....
I would like to receive this information from syslog to process some
events regarding ADSL, but I have made several tests (sync, drop, init)
and I have never seen any PKT_STATUS packet.
Do I have to activate this type of status packets via any parameter at
/sys/class/atm/..../params/.. ?
Any other way to receive ADSL status events without constantly reading a
file on /sys ?
Thank you
|
