linux-atm-general — General discussion of ATM networking under linux

[Linux-ATM-General] Fwd: Re: [PATCH 1/1] atm/solos-pci: Don't flap VCs when carrier state changes

[Philip P. <phi...@re...>]

Heads up.

Don't know if this will make 2.6.38 or we'll have to wait for .1


-------- Original Message --------
Subject: 	Re: [PATCH 1/1] atm/solos-pci: Don't flap VCs when carrier state changes
Date: 	Wed, 30 Mar 2011 16:56:14 -0700 (PDT)
From: 	David Miller <da...@da...>
To: 	phi...@re...
CC: 	ne...@vg...



All 3 patches applied, thanks.

Re: [Linux-ATM-General] Fwd: [PATCH 1/1] solos-pci: Don't clear open VCs when we detect carrier state (or state changes)

[chas w. - C. <ch...@cm...>]

you should just merge 87650 and 87965.  that way
atm_dev_release_vccs() doesnt get EXPORTED yet have no users.

also, make you git comments a little more compatible with the
"standard" way of doing it for the kernel.  something like:

atm: driver: what i fixed summary

explanation (if the summary isnt clear)

and wrap the lines around 72 cols i guess.

On Sun, 27 Mar 2011 12:36:13 -0700
Philip Prindeville <phi...@re...> wrote:

> By the way, I need someone to add "Signed-off-by:" to the following patches to speed them along...
> 
> http://patchwork.ozlabs.org/patch/87650/
> http://patchwork.ozlabs.org/patch/87676/
> http://patchwork.ozlabs.org/patch/87965/
> http://patchwork.ozlabs.org/patch/88026/
> 
> if anyone is interested in doing so...
> 
> Thanks,
> 
> -Philip
> 
> 
> 
> On 3/22/11 11:16 PM, Philip Prindeville wrote:
> > Following Chas' suggestion....
> >
> > Should have Cc'd the list, sorry.
> >
> >
> > -------- Original Message --------
> > Subject: 	[PATCH 1/1] solos-pci: Don't clear open VCs when we detect carrier state (or state changes)
> > Date: 	Tue, 22 Mar 2011 23:12:56 -0700
> > From: 	Philip Prindeville<phi...@re...>
> > To: 	Netdev<ne...@vg...>
> >
> >
> >
> > Initialize device state to UP, as is done for Ethernet.  If firmware supports communicating carrier state to us, we'll be notified then, and we can indicate it via atm_dev_signal_change().
> >
> > In any case: (1) higher level protocols will detect a dead link, and (2) loss of carrier is not a reason to tear down the VCs... this is overly zealous.
> >
> > Signed-off-by: Philip Prindeville<ph...@re...>
> > ---
> >
> >    drivers/atm/solos-pci.c |    3 +--
> >    1 files changed, 1 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
> > index 265bbdf..cd0ff66 100644
> > --- a/drivers/atm/solos-pci.c
> > +++ b/drivers/atm/solos-pci.c
> > @@ -383,7 +383,6 @@ static int process_status(struct solos_card *card, int port, struct sk_buff *skb
> >    	/* Anything but 'Showtime' is down */
> >    	if (strcmp(state_str, "Showtime")) {
> >    		atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
> > -		atm_dev_release_vccs(card->atmdev[port]);
> >    		dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
> >    		return 0;
> >    	}
> > @@ -1246,7 +1245,7 @@ static int atm_init(struct solos_card *card, struct device *parent)
> >    		card->atmdev[i]->ci_range.vci_bits = 16;
> >    		card->atmdev[i]->dev_data = card;
> >    		card->atmdev[i]->phy_data = (void *)(unsigned long)i;
> > -		atm_dev_signal_change(card->atmdev[i], ATM_PHY_SIG_UNKNOWN);
> > +		atm_dev_signal_change(card->atmdev[i], ATM_PHY_SIG_FOUND);
> >
> >    		skb = alloc_skb(sizeof(*header), GFP_ATOMIC);
> >    		if (!skb) {
> >
> 
> 
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software 
> be a part of the solution? Download the Intel(R) Manageability Checker 
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Linux-atm-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-atm-general
> 

Re: [Linux-ATM-General] Fwd: [PATCH 1/1] solos-pci: Don't clear open VCs when we detect carrier state (or state changes)

[Philip P. <phi...@re...>]

By the way, I need someone to add "Signed-off-by:" to the following patches to speed them along...

http://patchwork.ozlabs.org/patch/87650/
http://patchwork.ozlabs.org/patch/87676/
http://patchwork.ozlabs.org/patch/87965/
http://patchwork.ozlabs.org/patch/88026/

if anyone is interested in doing so...

Thanks,

-Philip



On 3/22/11 11:16 PM, Philip Prindeville wrote:
> Following Chas' suggestion....
>
> Should have Cc'd the list, sorry.
>
>
> -------- Original Message --------
> Subject: 	[PATCH 1/1] solos-pci: Don't clear open VCs when we detect carrier state (or state changes)
> Date: 	Tue, 22 Mar 2011 23:12:56 -0700
> From: 	Philip Prindeville<phi...@re...>
> To: 	Netdev<ne...@vg...>
>
>
>
> Initialize device state to UP, as is done for Ethernet.  If firmware supports communicating carrier state to us, we'll be notified then, and we can indicate it via atm_dev_signal_change().
>
> In any case: (1) higher level protocols will detect a dead link, and (2) loss of carrier is not a reason to tear down the VCs... this is overly zealous.
>
> Signed-off-by: Philip Prindeville<ph...@re...>
> ---
>
>    drivers/atm/solos-pci.c |    3 +--
>    1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
> index 265bbdf..cd0ff66 100644
> --- a/drivers/atm/solos-pci.c
> +++ b/drivers/atm/solos-pci.c
> @@ -383,7 +383,6 @@ static int process_status(struct solos_card *card, int port, struct sk_buff *skb
>    	/* Anything but 'Showtime' is down */
>    	if (strcmp(state_str, "Showtime")) {
>    		atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
> -		atm_dev_release_vccs(card->atmdev[port]);
>    		dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
>    		return 0;
>    	}
> @@ -1246,7 +1245,7 @@ static int atm_init(struct solos_card *card, struct device *parent)
>    		card->atmdev[i]->ci_range.vci_bits = 16;
>    		card->atmdev[i]->dev_data = card;
>    		card->atmdev[i]->phy_data = (void *)(unsigned long)i;
> -		atm_dev_signal_change(card->atmdev[i], ATM_PHY_SIG_UNKNOWN);
> +		atm_dev_signal_change(card->atmdev[i], ATM_PHY_SIG_FOUND);
>
>    		skb = alloc_skb(sizeof(*header), GFP_ATOMIC);
>    		if (!skb) {
>

[Linux-ATM-General] Fwd: [PATCH 1/1] solos-pci: Don't clear open VCs when we detect carrier state (or state changes)

[Philip P. <phi...@re...>]

Following Chas' suggestion....

Should have Cc'd the list, sorry.


-------- Original Message --------
Subject: 	[PATCH 1/1] solos-pci: Don't clear open VCs when we detect carrier state (or state changes)
Date: 	Tue, 22 Mar 2011 23:12:56 -0700
From: 	Philip Prindeville <phi...@re...>
To: 	Netdev <ne...@vg...>



Initialize device state to UP, as is done for Ethernet.  If firmware supports communicating carrier state to us, we'll be notified then, and we can indicate it via atm_dev_signal_change().

In any case: (1) higher level protocols will detect a dead link, and (2) loss of carrier is not a reason to tear down the VCs... this is overly zealous.

Signed-off-by: Philip Prindeville<ph...@re...>
---

  drivers/atm/solos-pci.c |    3 +--
  1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/atm/solos-pci.c b/drivers/atm/solos-pci.c
index 265bbdf..cd0ff66 100644
--- a/drivers/atm/solos-pci.c
+++ b/drivers/atm/solos-pci.c
@@ -383,7 +383,6 @@ static int process_status(struct solos_card *card, int port, struct sk_buff *skb
  	/* Anything but 'Showtime' is down */
  	if (strcmp(state_str, "Showtime")) {
  		atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
-		atm_dev_release_vccs(card->atmdev[port]);
  		dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
  		return 0;
  	}
@@ -1246,7 +1245,7 @@ static int atm_init(struct solos_card *card, struct device *parent)
  		card->atmdev[i]->ci_range.vci_bits = 16;
  		card->atmdev[i]->dev_data = card;
  		card->atmdev[i]->phy_data = (void *)(unsigned long)i;
-		atm_dev_signal_change(card->atmdev[i], ATM_PHY_SIG_UNKNOWN);
+		atm_dev_signal_change(card->atmdev[i], ATM_PHY_SIG_FOUND);

  		skb = alloc_skb(sizeof(*header), GFP_ATOMIC);
  		if (!skb) {

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[chas w. - C. <ch...@cm...>]

On Tue, 22 Mar 2011 13:13:05 -0700
Philip Prindeville <phi...@re...> wrote:

> On 3/22/11 12:55 PM, chas williams - CONTRACTOR wrote:
> > On Tue, 22 Mar 2011 12:36:25 -0700
> > Philip Prindeville<phi...@re...>  wrote:
> >
> >> So for users with the older FPGA firmware, that doesn't see the carrier state change messages, how should we handle this?
> > just update the carrier/signal status of the adapter.  initially
> > configure that state to SIG_UNKNOWN.  the logic to determine the value
> > of the carrier sysfs value will get the rest right.
> 
> Ok, but I thought we had agreed to change the initial state to LOST instead of UNKNOWN?

it is a little confusing/muddled.  when you create/allocate the driver
it is set to UNKNOWN for you.  really it should be set to FOUND on the
assumption that the driver does not handle carrier for you.  carrier is
assumed to be 1 in the FOUND or UNKNOWN state otherwise 0.  the
UNKNOWN state probably should just go away but we preserved it for
the time being.  of course, if your driver supports determining the
signal/carrier status, you should initialize to LOST.  but this
might/will yeild a transition from UNKNOWN to LOST.  part of the
problem here is that the device registration for the linux-atm stack is
monolithic.  you dont allocate the device, set it up and then register
otherwise you could avoid the 'false' transition.

> BTW:  Is there an easy way to detect which version of firmware we're talking to?  Or do we need to add a module parameter?

got me.  i would just handle it as above.  assume you have carrier. if
the firmware happens to tell you otherwise, update the carrier status.
this is what ethernet does and it seems to work well enough.

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[Philip P. <phi...@re...>]

On 3/22/11 12:55 PM, chas williams - CONTRACTOR wrote:
> On Tue, 22 Mar 2011 12:36:25 -0700
> Philip Prindeville<phi...@re...>  wrote:
>
>> So for users with the older FPGA firmware, that doesn't see the carrier state change messages, how should we handle this?
> just update the carrier/signal status of the adapter.  initially
> configure that state to SIG_UNKNOWN.  the logic to determine the value
> of the carrier sysfs value will get the rest right.

Ok, but I thought we had agreed to change the initial state to LOST instead of UNKNOWN?

BTW:  Is there an easy way to detect which version of firmware we're talking to?  Or do we need to add a module parameter?


>> My inclination is to think that tearing down the circuits was never the correct behavior...
> i dont believe it is correct either.  no other driver does this because
> the carrier status shouldnt be used to reset any of the protocols
> running over a pvc or svc.  signalling used a seperate channel (0.5) to
> keep track of whether or not you are alive and well (sscop).  i gather
> that pvc circuits used ppp to keep track of link state.  so the carrier
> state bouncing briefly shouldnt bother them really.

Yeah, that sounds right to me too.

-Philip

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[chas w. - C. <ch...@cm...>]

On Tue, 22 Mar 2011 12:36:25 -0700
Philip Prindeville <phi...@re...> wrote:

> So for users with the older FPGA firmware, that doesn't see the carrier state change messages, how should we handle this?

just update the carrier/signal status of the adapter.  initially
configure that state to SIG_UNKNOWN.  the logic to determine the value
of the carrier sysfs value will get the rest right.  

> My inclination is to think that tearing down the circuits was never the correct behavior...

i dont believe it is correct either.  no other driver does this because
the carrier status shouldnt be used to reset any of the protocols
running over a pvc or svc.  signalling used a seperate channel (0.5) to
keep track of whether or not you are alive and well (sscop).  i gather
that pvc circuits used ppp to keep track of link state.  so the carrier
state bouncing briefly shouldnt bother them really.

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[Philip P. <phi...@re...>]

On 3/21/11 2:08 PM, Chas Williams (CONTRACTOR) wrote:
> In message<4D8...@re...>,Philip Prindeville writes:
>> Yeah, it turns out there was... the transition from UNKNOWN to LOST.
>>
>> Should we (a) initialize the driver state as LOST, and (b) not release all VCs when the carrier flaps?
>>
>> I'm thinking that now that we have correct carrier state indication, maybe user-space apps should pay attention to that instead?
> i dont think that pvc's should give a damn about carrier state.
> they certainly shouldnt close because carrier state flapped.  svc's are
> a different story -- tearing down svc's on carrier state change does
> sort of make sense.  this should already happen though since atmsigd is
> smart enough to make this happen.
>
> SIG_UNKNOWN and SIG_FOUND should mean the same thing.  the carrier
> state cant be followed or is found so the application should go ahead
> with its business.  if the solos pci driver can track state perhaps it
> should init the signal to SIG_LOST.  UKNOWN was really meant (i gather)
> to indicate that the carrier isnt tracked by the driver.
>
> if applications are curious about the line state, yes they should be
> asking the driver about the line state not hoping that the pvc gets
> torn down and rebuilt.

So for users with the older FPGA firmware, that doesn't see the carrier state change messages, how should we handle this?

My inclination is to think that tearing down the circuits was never the correct behavior...

-Philip

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[Philip P. <phi...@re...>]

On 3/21/11 2:08 PM, Chas Williams (CONTRACTOR) wrote:
> In message<4D8...@re...>,Philip Prindeville writes:
>> Yeah, it turns out there was... the transition from UNKNOWN to LOST.
>>
>> Should we (a) initialize the driver state as LOST, and (b) not release all VCs when the carrier flaps?
>>
>> I'm thinking that now that we have correct carrier state indication, maybe user-space apps should pay attention to that instead?
> i dont think that pvc's should give a damn about carrier state.
> they certainly shouldnt close because carrier state flapped.  svc's are
> a different story -- tearing down svc's on carrier state change does
> sort of make sense.  this should already happen though since atmsigd is
> smart enough to make this happen.
>
> SIG_UNKNOWN and SIG_FOUND should mean the same thing.  the carrier
> state cant be followed or is found so the application should go ahead
> with its business.  if the solos pci driver can track state perhaps it
> should init the signal to SIG_LOST.  UKNOWN was really meant (i gather)
> to indicate that the carrier isnt tracked by the driver.
>
> if applications are curious about the line state, yes they should be
> asking the driver about the line state not hoping that the pvc gets
> torn down and rebuilt.
Can you commit the debug skb_pull() fix and I'll work up a fix for the flapping/initialization issue?

Thanks,

-Philip

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[Chas W. (CONTRACTOR) <ch...@cm...>]

In message <4D8...@re...>,Philip Prindeville writes:
>Yeah, it turns out there was... the transition from UNKNOWN to LOST.
>
>Should we (a) initialize the driver state as LOST, and (b) not release all VCs when the carrier flaps?
>
>I'm thinking that now that we have correct carrier state indication, maybe user-space apps should pay attention to that instead?

i dont think that pvc's should give a damn about carrier state.
they certainly shouldnt close because carrier state flapped.  svc's are
a different story -- tearing down svc's on carrier state change does
sort of make sense.  this should already happen though since atmsigd is
smart enough to make this happen.

SIG_UNKNOWN and SIG_FOUND should mean the same thing.  the carrier
state cant be followed or is found so the application should go ahead
with its business.  if the solos pci driver can track state perhaps it
should init the signal to SIG_LOST.  UKNOWN was really meant (i gather)
to indicate that the carrier isnt tracked by the driver.

if applications are curious about the line state, yes they should be
asking the driver about the line state not hoping that the pvc gets
torn down and rebuilt.

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[Philip P. <phi...@re...>]

On 3/21/11 4:41 AM, chas williams - CONTRACTOR wrote:
> On Sun, 20 Mar 2011 13:34:25 -0700
> Philip Prindeville<phi...@re...>  wrote:
>
>> Ok, so my previous posting fixed the preamble issue...  I'm digging more into the driver and had a few more questions.
>>
>> First, it calls a local (static) function release_vccs(struct atm_dev *dev) but from what I can tell, this is identical to what the function atm_dev_release_vccs(struct atm_dev *dev) does in net/atm/common.c, right?
> appears to be.  this isnt an exported function so the author needed to
> duplicate it to make it work out of tree for his driver.

Yeah, I sent a patch for that.  Hopefully no one has any objections...


>> The function find_vcc() is duplicated (almost verbatim) in solos-pci.c and atmtcp.c ... why not move it into atm/common.c?
> which is also pretty similar to the find_vcc() in he.c as well.  they
> all probably share the same lineage relating to the consolidation of
> the vcc table a while back.
>
>> Getting into /proc/net/atm/ and looking at the files, I get:
>>
>> root@OpenWrt:/proc/1485/net/atm# pwd
>> /proc/net/atm
>> root@OpenWrt:/proc/1485/net/atm# head *
>> ==>   br2684<==
>> dev nas0: num=1, mac=00:0a:fa:22:00:84 (set)
>>     vcc 0.0.35: encaps=LLC payload=bridged, failed copies 0/236
>>
>> ==>   devices<==
>> Itf Type    ESI/"MAC"addr AAL(TX,err,RX,err,drop) ...               [refcnt]
>>     0 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 236 0 0 0 0 )   [2]
>>     1 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 0 0 0 0 0 )     [1]
>>
>> ==>   pvc<==
>> Itf VPI VCI   AAL RX(PCR,Class) TX(PCR,Class)
>>
>> ==>   svc<==
>> Itf VPI VCI           State      Remote
>>
>> ==>   vc<==
>> Address Itf VPI VCI   Fam Flags Reply Send buffer     Recv buffer      [refcnt]
>> root@OpenWrt:/proc/1485/net/atm#
>>
>>
>>
>> so it seems that there really is something broken, at least in that the VPI/VCI failed to get plumbed if it's not showing up in the "vc" file.
> something must be erroring that is causing the socket/vcc to be removed
> from the list.  perhaps release_vccs()?  if you manage to enter
> process_status() before the vcc is in "Showtime" it seems it will be
> dropped regardless of the open status?  i gather that br2684ctl
> probably doesnt reopen the vcc in question (actually i have no idea
> what it does)
>

Yeah, it turns out there was... the transition from UNKNOWN to LOST.

Should we (a) initialize the driver state as LOST, and (b) not release all VCs when the carrier flaps?

I'm thinking that now that we have correct carrier state indication, maybe user-space apps should pay attention to that instead?

-Philip

Re: [Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware

[chas w. - C. <ch...@cm...>]

i suspect gcc's memcmp can handle 4 bytes at a time after it gets to
proper alignment (which it already likely is given it is the
initial skb->data area) this also appears to be coming back from the
fpga on the card, so the author probably didnt have much choice in the
matter.

besides, you cant go fast enough for this matter on your dsl link
anyway :)

On Sun, 20 Mar 2011 19:19:07 -0700
Philip Prindeville <phi...@re...> wrote:

> I'm not especially worried about it...  Gcc has a lot of __builtin functions for memcpy, memcmp, strcmp, etc. and usually does a fairly efficient job of it...  I've not had to check lately, but I wouldn't be surprised if it even does a string unroll for short strings.  The test could be changed to:
> 
> if (state_str[0] != 'S' || strcmp(&state_str[1], "howtime"))
> 
> 
> and I wouldn't especially mind, but I did want to keep the amount of fingerprints down to a minimum.
> 
> Yes, I'm also old and grouchy... I remember having to write in BAL-360 and manage my own stack-frame... The PDP-11 was a breath of fresh air...
> 
> But anyway, like I said... wanted to keep patches to "low touch", especially since a lot of folks will be back-porting these fixes to 2.6.32 or even 2.6.27...
> 
> 
> On 3/20/11 7:11 PM, MIke Westall wrote:
> > I'll be the first to admit that (1) I'm a grouchy old guy who (2) first programmed on an IBM 1620 and then on a 360  Model 30 with 32K ram.  But why oh why do we need to use 9 byte string constants with per character compare to decide if the device is up or not :-(
> >
> >
> >
> >
> > Philip Prindeville wrote:
> >> The newest FPGA firmware on the Solos processors correctly signals carrier transitions, bitrate, etc.
> >>
> >> The driver previously ignored these messages, and the physical state was always ATM_PHY_SIG_UNKNOWN.
> >>
> >> Now that the board reports its state, we expose a bug whereby the transition from UNKNOWN to LOST causes us to release all VC's.
> >>
> >> We don't delete any VC's, but instead just send an indication of carrier change.
> >>
> >> Signed-off-by: Philip A Prindeville <ph...@re...>
> >> ---
> >>
> >> --- a/drivers/atm/solos-pci.c    2011-03-20 15:27:40.000000000 -0600
> >> +++ b/drivers/atm/solos-pci.c    2011-03-20 16:32:11.000000000 -0600
> >> @@ -382,8 +382,10 @@ static int process_status(struct solos_c
> >>
> >>       /* Anything but 'Showtime' is down */
> >>       if (strcmp(state_str, "Showtime")) {
> >>           atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
> >> +#if 0
> >>           atm_dev_release_vccs(card->atmdev[port]);
> >> +#endif
> >>           dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
> >>         return 0;
> >>     }
> >>
> >>
> 
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Linux-atm-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-atm-general
> 

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[chas w. - C. <ch...@cm...>]

On Sun, 20 Mar 2011 13:34:25 -0700
Philip Prindeville <phi...@re...> wrote:

> Ok, so my previous posting fixed the preamble issue...  I'm digging more into the driver and had a few more questions.
> 
> First, it calls a local (static) function release_vccs(struct atm_dev *dev) but from what I can tell, this is identical to what the function atm_dev_release_vccs(struct atm_dev *dev) does in net/atm/common.c, right?

appears to be.  this isnt an exported function so the author needed to
duplicate it to make it work out of tree for his driver.

> The function find_vcc() is duplicated (almost verbatim) in solos-pci.c and atmtcp.c ... why not move it into atm/common.c?

which is also pretty similar to the find_vcc() in he.c as well.  they
all probably share the same lineage relating to the consolidation of
the vcc table a while back.
 
> Getting into /proc/net/atm/ and looking at the files, I get:
> 
> root@OpenWrt:/proc/1485/net/atm# pwd
> /proc/net/atm
> root@OpenWrt:/proc/1485/net/atm# head *
> ==>  br2684<==
> dev nas0: num=1, mac=00:0a:fa:22:00:84 (set)
>    vcc 0.0.35: encaps=LLC payload=bridged, failed copies 0/236
> 
> ==>  devices<==
> Itf Type    ESI/"MAC"addr AAL(TX,err,RX,err,drop) ...               [refcnt]
>    0 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 236 0 0 0 0 )   [2]
>    1 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 0 0 0 0 0 )     [1]
> 
> ==>  pvc<==
> Itf VPI VCI   AAL RX(PCR,Class) TX(PCR,Class)
> 
> ==>  svc<==
> Itf VPI VCI           State      Remote
> 
> ==>  vc<==
> Address Itf VPI VCI   Fam Flags Reply Send buffer     Recv buffer      [refcnt]
> root@OpenWrt:/proc/1485/net/atm#
> 
> 
> 
> so it seems that there really is something broken, at least in that the VPI/VCI failed to get plumbed if it's not showing up in the "vc" file.

something must be erroring that is causing the socket/vcc to be removed
from the list.  perhaps release_vccs()?  if you manage to enter
process_status() before the vcc is in "Showtime" it seems it will be
dropped regardless of the open status?  i gather that br2684ctl
probably doesnt reopen the vcc in question (actually i have no idea
what it does)

Re: [Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware

[Philip P. <phi...@re...>]

On 3/20/11 11:04 PM, David Miller wrote:
> From: Philip Prindeville<phi...@re...>
> Date: Sun, 20 Mar 2011 22:56:43 -0700
>
>> It's not clear that dropping all VCs abruptly when carrier flapped was
>> ever the right thing to do.
> So you've tested your change with the older firmware present?

I haven't, no: back-revving firmware has been known to brick cards.

I'm waiting to hear back from Guy and Nathan, they have old cards on hand that they can test.

Re: [Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware

[Philip P. <phi...@re...>]

On 3/20/11 9:57 PM, David Miller wrote:
> From: Ben Hutchings<bhu...@so...>
> Date: Mon, 21 Mar 2011 03:01:36 +0000
>
>> On Sun, 2011-03-20 at 18:52 -0700, Philip Prindeville wrote:
>>> The newest FPGA firmware on the Solos processors correctly signals
>>> carrier transitions, bitrate, etc.
>>>
>>> The driver previously ignored these messages, and the physical state
>>> was always ATM_PHY_SIG_UNKNOWN.
>>>
>>> Now that the board reports its state, we expose a bug whereby the
>>> transition from UNKNOWN to LOST causes us to release all VC's.
>>>
>>> We don't delete any VC's, but instead just send an indication of
>>> carrier change.
>>>
>>> Signed-off-by: Philip A Prindeville<ph...@re...>
>>> ---
>>>
>>> --- a/drivers/atm/solos-pci.c	2011-03-20 15:27:40.000000000 -0600
>>> +++ b/drivers/atm/solos-pci.c	2011-03-20 16:32:11.000000000 -0600
>>> @@ -382,8 +382,10 @@ static int process_status(struct solos_c
>>>
>>>    	/* Anything but 'Showtime' is down */
>>>    	if (strcmp(state_str, "Showtime")) {
>>>    		atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
>>> +#if 0
>>>    		atm_dev_release_vccs(card->atmdev[port]);
>>> +#endif
>> Either remove it or don't.  #if 0 is for people without version control.
> Also, this would seem to break those using the older firmware.

It's not clear that dropping all VCs abruptly when carrier flapped was ever the right thing to do.

-Philip

Re: [Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware

[MIke W. <we...@cs...>]

I'll be the first to admit that (1) I'm a grouchy old guy who (2) first 
programmed on an IBM 1620 and then on a 360  Model 30 with 32K ram.  But 
why oh why do we need to use 9 byte string constants with per character 
compare to decide if the device is up or not :-(




Philip Prindeville wrote:
> The newest FPGA firmware on the Solos processors correctly signals carrier transitions, bitrate, etc.
>
> The driver previously ignored these messages, and the physical state was always ATM_PHY_SIG_UNKNOWN.
>
> Now that the board reports its state, we expose a bug whereby the transition from UNKNOWN to LOST causes us to release all VC's.
>
> We don't delete any VC's, but instead just send an indication of carrier change.
>
> Signed-off-by: Philip A Prindeville <ph...@re...>
> ---
>
> --- a/drivers/atm/solos-pci.c	2011-03-20 15:27:40.000000000 -0600
> +++ b/drivers/atm/solos-pci.c	2011-03-20 16:32:11.000000000 -0600
> @@ -382,8 +382,10 @@ static int process_status(struct solos_c
>
>   	/* Anything but 'Showtime' is down */
>   	if (strcmp(state_str, "Showtime")) {
>   		atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
> +#if 0
>   		atm_dev_release_vccs(card->atmdev[port]);
> +#endif
>   		dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
> 		return 0;
> 	}
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Linux-atm-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-atm-general
>
>
>   

Re: [Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware

[MIke W. <we...@cs...>]

I definitely concur with keeping patch fingerprints as small as 
possible.   And  since state change is (hopefully) a rare event,  the 
impact of one instance stuff like this is clearly minimal,   but enough 
of this stuff wastes memory.   I guess we should just be thankful the 
original programmer did not feel like writing

if (strcmp(state_str, "man we are up, rocking and rolling and kicking 
a$$ now"))



 
Philip Prindeville wrote:
> I'm not especially worried about it...  Gcc has a lot of __builtin 
> functions for memcpy, memcmp, strcmp, etc. and usually does a fairly 
> efficient job of it...  I've not had to check lately, but I wouldn't 
> be surprised if it even does a string unroll for short strings.  The 
> test could be changed to:
>
> if (state_str[0] != 'S' || strcmp(&state_str[1], "howtime"))
>
>
> and I wouldn't especially mind, but I did want to keep the amount of 
> fingerprints down to a minimum.
>
> Yes, I'm also old and grouchy... I remember having to write in BAL-360 
> and manage my own stack-frame... The PDP-11 was a breath of fresh air...
>
> But anyway, like I said... wanted to keep patches to "low touch", 
> especially since a lot of folks will be back-porting these fixes to 
> 2.6.32 or even 2.6.27...
>
>
> On 3/20/11 7:11 PM, MIke Westall wrote:
>> I'll be the first to admit that (1) I'm a grouchy old guy who (2) 
>> first programmed on an IBM 1620 and then on a 360  Model 30 with 32K 
>> ram.  But why oh why do we need to use 9 byte string constants with 
>> per character compare to decide if the device is up or not :-(
>>
>>
>>
>>
>> Philip Prindeville wrote:
>>> The newest FPGA firmware on the Solos processors correctly signals 
>>> carrier transitions, bitrate, etc.
>>>
>>> The driver previously ignored these messages, and the physical state 
>>> was always ATM_PHY_SIG_UNKNOWN.
>>>
>>> Now that the board reports its state, we expose a bug whereby the 
>>> transition from UNKNOWN to LOST causes us to release all VC's.
>>>
>>> We don't delete any VC's, but instead just send an indication of 
>>> carrier change.
>>>
>>> Signed-off-by: Philip A Prindeville <ph...@re...>
>>> ---
>>>
>>> --- a/drivers/atm/solos-pci.c    2011-03-20 15:27:40.000000000 -0600
>>> +++ b/drivers/atm/solos-pci.c    2011-03-20 16:32:11.000000000 -0600
>>> @@ -382,8 +382,10 @@ static int process_status(struct solos_c
>>>
>>>       /* Anything but 'Showtime' is down */
>>>       if (strcmp(state_str, "Showtime")) {
>>>           atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
>>> +#if 0
>>>           atm_dev_release_vccs(card->atmdev[port]);
>>> +#endif
>>>           dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
>>>         return 0;
>>>     }
>>>
>>>
>
>
>

Re: [Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware

[Philip P. <phi...@re...>]

I'm not especially worried about it...  Gcc has a lot of __builtin functions for memcpy, memcmp, strcmp, etc. and usually does a fairly efficient job of it...  I've not had to check lately, but I wouldn't be surprised if it even does a string unroll for short strings.  The test could be changed to:

if (state_str[0] != 'S' || strcmp(&state_str[1], "howtime"))


and I wouldn't especially mind, but I did want to keep the amount of fingerprints down to a minimum.

Yes, I'm also old and grouchy... I remember having to write in BAL-360 and manage my own stack-frame... The PDP-11 was a breath of fresh air...

But anyway, like I said... wanted to keep patches to "low touch", especially since a lot of folks will be back-porting these fixes to 2.6.32 or even 2.6.27...


On 3/20/11 7:11 PM, MIke Westall wrote:
> I'll be the first to admit that (1) I'm a grouchy old guy who (2) first programmed on an IBM 1620 and then on a 360  Model 30 with 32K ram.  But why oh why do we need to use 9 byte string constants with per character compare to decide if the device is up or not :-(
>
>
>
>
> Philip Prindeville wrote:
>> The newest FPGA firmware on the Solos processors correctly signals carrier transitions, bitrate, etc.
>>
>> The driver previously ignored these messages, and the physical state was always ATM_PHY_SIG_UNKNOWN.
>>
>> Now that the board reports its state, we expose a bug whereby the transition from UNKNOWN to LOST causes us to release all VC's.
>>
>> We don't delete any VC's, but instead just send an indication of carrier change.
>>
>> Signed-off-by: Philip A Prindeville <ph...@re...>
>> ---
>>
>> --- a/drivers/atm/solos-pci.c    2011-03-20 15:27:40.000000000 -0600
>> +++ b/drivers/atm/solos-pci.c    2011-03-20 16:32:11.000000000 -0600
>> @@ -382,8 +382,10 @@ static int process_status(struct solos_c
>>
>>       /* Anything but 'Showtime' is down */
>>       if (strcmp(state_str, "Showtime")) {
>>           atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
>> +#if 0
>>           atm_dev_release_vccs(card->atmdev[port]);
>> +#endif
>>           dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
>>         return 0;
>>     }
>>
>>

[Linux-ATM-General] [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware

[Philip P. <phi...@re...>]

The newest FPGA firmware on the Solos processors correctly signals carrier transitions, bitrate, etc.

The driver previously ignored these messages, and the physical state was always ATM_PHY_SIG_UNKNOWN.

Now that the board reports its state, we expose a bug whereby the transition from UNKNOWN to LOST causes us to release all VC's.

We don't delete any VC's, but instead just send an indication of carrier change.

Signed-off-by: Philip A Prindeville <ph...@re...>
---

--- a/drivers/atm/solos-pci.c	2011-03-20 15:27:40.000000000 -0600
+++ b/drivers/atm/solos-pci.c	2011-03-20 16:32:11.000000000 -0600
@@ -382,8 +382,10 @@ static int process_status(struct solos_c

  	/* Anything but 'Showtime' is down */
  	if (strcmp(state_str, "Showtime")) {
  		atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
+#if 0
  		atm_dev_release_vccs(card->atmdev[port]);
+#endif
  		dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
		return 0;
	}

[Linux-ATM-General] [PATCH 1/1] solos-pci: Fix regression introduced by newest firmware

[Philip P. <phi...@re...>]

The newest FPGA firmware on the Solos processors correctly signals carrier transitions, bitrate, etc.

The driver previously ignored these messages, and the physical state was always ATM_PHY_SIG_UNKNOWN.

Now that the board reports its state, we expose a bug whereby the transition from UNKNOWN to LOST causes us to release all VC's.  It should not: only transitions from FOUND to LOST or UNKNOWN should do this (actually, it's bears examining if the VC's should be released at all).

So we add a check to the previous state on transitions for leaving FOUND state.

Signed-off-by: Philip A Prindeville <ph...@re...>
---

--- a/drivers/atm/solos-pci.c	2011-03-20 15:27:40.000000000 -0600
+++ b/drivers/atm/solos-pci.c	2011-03-20 16:32:11.000000000 -0600
@@ -382,8 +382,11 @@ static int process_status(struct solos_c

  	/* Anything but 'Showtime' is down */
  	if (strcmp(state_str, "Showtime")) {
+		char old_signal = card->atmdev[port]->signal;
+
  		atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
-		atm_dev_release_vccs(card->atmdev[port]);
+		if (old_signal == ATM_PHY_SIG_FOUND)
+			atm_dev_release_vccs(card->atmdev[port]);
  		dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
		return 0;
	}

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[Philip P. <phi...@re...>]

Looking at the function atm_init() in the Solos driver, it's not clear to me why we have:

	atm_dev_signal_change(card->atmdev[i], ATM_PHY_SIG_UNKNOWN);


why would the device come up in state UNKNOWN and not LOST?  If the driver has just loaded up, it's a safe bet that the PHY is down, right?

-Philip

[Linux-ATM-General] [PATCH 1/1] solos-pci: Use shared code for VCC management

[Philip P. <phi...@re...>]

The solos-pci driver duplicates the net/atm/common.c function atm_dev_release_vccs() locally as the static function release_vccs().  Let's have the driver share code.

Signed-off-by: Philip A. Prindeville <ph...@re...>

---

--- a/drivers/atm/solos-pci.c	2011-03-20 01:42:22.000000000 -0600
+++ b/drivers/atm/solos-pci.c	2011-03-20 14:23:26.000000000 -0600
@@ -165,7 +165,6 @@ static uint32_t fpga_tx(struct solos_car
  static irqreturn_t solos_irq(int irq, void *dev_id);
  static struct atm_vcc* find_vcc(struct atm_dev *dev, short vpi, int vci);
  static int list_vccs(int vci);
-static void release_vccs(struct atm_dev *dev);
  static int atm_init(struct solos_card *, struct device *);
  static void atm_remove(struct solos_card *);
  static int send_command(struct solos_card *card, int dev, const char *buf, size_t size);
@@ -384,7 +383,7 @@ static int process_status(struct solos_c
  	/* Anything but 'Showtime' is down */
  	if (strcmp(state_str, "Showtime")) {
  		atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
-		release_vccs(card->atmdev[port]);
+		atm_dev_release_vccs(card->atmdev[port]);
  		dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
  		return 0;
  	}
@@ -837,28 +836,6 @@ static int list_vccs(int vci)
  	return num_found;
  }

-static void release_vccs(struct atm_dev *dev)
-{
-        int i;
-
-        write_lock_irq(&vcc_sklist_lock);
-        for (i = 0; i<  VCC_HTABLE_SIZE; i++) {
-                struct hlist_head *head =&vcc_hash[i];
-                struct hlist_node *node, *tmp;
-                struct sock *s;
-                struct atm_vcc *vcc;
-
-                sk_for_each_safe(s, node, tmp, head) {
-                        vcc = atm_sk(s);
-                        if (vcc->dev == dev) {
-                                vcc_release_async(vcc, -EPIPE);
-                                sk_del_node_init(s);
-                        }
-                }
-        }
-        write_unlock_irq(&vcc_sklist_lock);
-}
-

  static int popen(struct atm_vcc *vcc)
  {
--- a/net/atm/common.c	2011-01-04 17:50:19.000000000 -0700
+++ b/net/atm/common.c	2011-03-20 15:22:59.000000000 -0600
@@ -252,6 +252,7 @@ void atm_dev_release_vccs(struct atm_dev
  	}
  	write_unlock_irq(&vcc_sklist_lock);
  }
+EXPORT_SYMBOL(atm_dev_release_vccs);

  static int adjust_tp(struct atm_trafprm *tp, unsigned char aal)
  {
--- a/include/linux/atmdev.h	2011-01-04 17:50:19.000000000 -0700
+++ b/include/linux/atmdev.h	2011-03-20 15:25:08.000000000 -0600
@@ -443,6 +443,7 @@ void atm_dev_signal_change(struct atm_de

  void vcc_insert_socket(struct sock *sk);

+void atm_dev_release_vccs(struct atm_dev *dev);

  /*
   * This is approximately the algorithm used by alloc_skb.

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[Philip P. <phi...@re...>]

Actually, the originally *is* an entry in the vc table, but it silently goes away:

root@OpenWrt:/proc/1465/net/atm# head *
==>  br2684<==
dev nas0: num=1, mac=00:0a:fa:22:00:84 (set)
   vcc 0.0.35: encaps=LLC payload=bridged, failed copies 0/70

==>  devices<==
Itf Type    ESI/"MAC"addr AAL(TX,err,RX,err,drop) ...               [refcnt]
   0 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 70 0 0 0 0 )    [2]
   1 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 0 0 0 0 0 )     [1]

==>  pvc<==
Itf VPI VCI   AAL RX(PCR,Class) TX(PCR,Class)
   0   0    35 5         0 UBR         0 UBR

==>  svc<==
Itf VPI VCI           State      Remote

==>  vc<==
Address Itf VPI VCI   Fam Flags Reply Send buffer     Recv buffer      [refcnt]
dde93800   0   0    35 PVC 0043      0       0/   4080       0/ 110592 [2]
root@OpenWrt:/proc/1465/net/atm#


then mysteriously....


root@OpenWrt:/proc/1465/net/atm# head *
==>  br2684<==
dev nas0: num=1, mac=00:0a:fa:22:00:84 (set)
   vcc 0.0.35: encaps=LLC payload=bridged, failed copies 0/71

==>  devices<==
Itf Type    ESI/"MAC"addr AAL(TX,err,RX,err,drop) ...               [refcnt]
   0 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 71 0 0 0 0 )    [2]
   1 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 0 0 0 0 0 )     [1]

==>  pvc<==
Itf VPI VCI   AAL RX(PCR,Class) TX(PCR,Class)

==>  svc<==
Itf VPI VCI           State      Remote

==>  vc<==
Address Itf VPI VCI   Fam Flags Reply Send buffer     Recv buffer      [refcnt]
root@OpenWrt:/proc/1465/net/atm#


So the entry is there... until it's not.

-Philip



On 3/20/11 1:34 PM, Philip Prindeville wrote:
> Ok, so my previous posting fixed the preamble issue...  I'm digging more into the driver and had a few more questions.
>
> First, it calls a local (static) function release_vccs(struct atm_dev *dev) but from what I can tell, this is identical to what the function atm_dev_release_vccs(struct atm_dev *dev) does in net/atm/common.c, right?
>
> The function find_vcc() is duplicated (almost verbatim) in solos-pci.c and atmtcp.c ... why not move it into atm/common.c?
>
> Getting into /proc/net/atm/ and looking at the files, I get:
>
> root@OpenWrt:/proc/1485/net/atm# pwd
> /proc/net/atm
> root@OpenWrt:/proc/1485/net/atm# head *
> ==>   br2684<==
> dev nas0: num=1, mac=00:0a:fa:22:00:84 (set)
>     vcc 0.0.35: encaps=LLC payload=bridged, failed copies 0/236
>
> ==>   devices<==
> Itf Type    ESI/"MAC"addr AAL(TX,err,RX,err,drop) ...               [refcnt]
>     0 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 236 0 0 0 0 )   [2]
>     1 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 0 0 0 0 0 )     [1]
>
> ==>   pvc<==
> Itf VPI VCI   AAL RX(PCR,Class) TX(PCR,Class)
>
> ==>   svc<==
> Itf VPI VCI           State      Remote
>
> ==>   vc<==
> Address Itf VPI VCI   Fam Flags Reply Send buffer     Recv buffer      [refcnt]
> root@OpenWrt:/proc/1485/net/atm#
>
>
>
> so it seems that there really is something broken, at least in that the VPI/VCI failed to get plumbed if it's not showing up in the "vc" file.
>
> -Philip
>

Re: [Linux-ATM-General] Solos driver weirdness in bridged mode

[Philip P. <phi...@re...>]

Ok, so my previous posting fixed the preamble issue...  I'm digging more into the driver and had a few more questions.

First, it calls a local (static) function release_vccs(struct atm_dev *dev) but from what I can tell, this is identical to what the function atm_dev_release_vccs(struct atm_dev *dev) does in net/atm/common.c, right?

The function find_vcc() is duplicated (almost verbatim) in solos-pci.c and atmtcp.c ... why not move it into atm/common.c?

Getting into /proc/net/atm/ and looking at the files, I get:

root@OpenWrt:/proc/1485/net/atm# pwd
/proc/net/atm
root@OpenWrt:/proc/1485/net/atm# head *
==>  br2684<==
dev nas0: num=1, mac=00:0a:fa:22:00:84 (set)
   vcc 0.0.35: encaps=LLC payload=bridged, failed copies 0/236

==>  devices<==
Itf Type    ESI/"MAC"addr AAL(TX,err,RX,err,drop) ...               [refcnt]
   0 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 236 0 0 0 0 )   [2]
   1 solos-pci000000000000  0 ( 0 0 0 0 0 )  5 ( 0 0 0 0 0 )     [1]

==>  pvc<==
Itf VPI VCI   AAL RX(PCR,Class) TX(PCR,Class)

==>  svc<==
Itf VPI VCI           State      Remote

==>  vc<==
Address Itf VPI VCI   Fam Flags Reply Send buffer     Recv buffer      [refcnt]
root@OpenWrt:/proc/1485/net/atm#



so it seems that there really is something broken, at least in that the VPI/VCI failed to get plumbed if it's not showing up in the "vc" file.

-Philip



On 3/18/11 5:10 PM, Philip Prindeville wrote:
> I'm seeing the following.  I have a Geos box running Openwrt from SVN (about 2 weeks old from trunk), and using the Geos platform target. I've configured RFC-2684 bridged mode for my Frontier Communications ADSL connection.
>
> Openwrt shows me that:
>
> br2684ctl -c 0 -e 0 -p 1 -a 0.0.35 -s 2040
>
> is running as we'd expect.
>
> However, I rebuilt the solos-pci driver to call:
>
> list_vccs(0);
>
> whenever it enters find_vcc(), which was always returning NULL will called with '35' as the argument.  I compiled the module with:
>
> #define DEBUG 1
> #define VERBOSE_DEBUG 1
>
> It should be printing the entire table out whenever a packet is received...  But it doesn't... or it does but the table is empty.
>
> Mar 18 16:25:07 OpenWrt kern.info kernel: solos 0000:00:0c.0: Received: device 0
> Mar 18 16:25:07 OpenWrt kern.info kernel: solos 0000:00:0c.0: size: 43 VPI: 0 VCI: 35
> Mar 18 16:25:07 OpenWrt kern.debug kernel: 00: 31 0A 31 36 33 32 30 30
> Mar 18 16:25:07 OpenWrt kern.debug kernel: 08: 30 0A 34 34 37 38 30 30
> Mar 18 16:25:07 OpenWrt kern.debug kernel: 10: 0A 53 68 6F 77 74 69 6D
> Mar 18 16:25:07 OpenWrt kern.debug kernel: 18: 65 0A 36 2E 37 30 20 64
> Mar 18 16:25:07 OpenWrt kern.debug kernel: 20: 42 0A 36 39 2E 30 20 64
> Mar 18 16:25:07 OpenWrt kern.debug kernel: 28: 42 20 0A
> Mar 18 16:25:07 OpenWrt kern.info kernel: solos 0000:00:0c.0: Port 0: Showtime @1632/447 kb/s, SNR 6.70 dB, Attn 69.0 dB
> Mar 18 16:25:08 OpenWrt kern.info kernel: solos 0000:00:0c.0: Transmitted: port 0
> Mar 18 16:25:08 OpenWrt kern.debug kernel: 00: 9D 01 00 00 23 00 00 00
> Mar 18 16:25:08 OpenWrt kern.debug kernel: 08: AA AA 03 00 80 C2 00 07
> Mar 18 16:25:08 OpenWrt kern.debug kernel: 10: 00 00 FF FF FF FF FF FF
> Mar 18 16:25:08 OpenWrt kern.debug kernel: 18: 00 0A FA 22 00 84 08 00
> Mar 18 16:25:08 OpenWrt kern.debug kernel: 20: 45 00 01 85 00 00 00 00
> Mar 18 16:25:08 OpenWrt kern.debug kernel: 28: 40 11 79 69 00 00 00 00
> Mar 18 16:25:08 OpenWrt kern.debug kernel: 30: FF FF FF FF 00 44 00 43
> Mar 18 16:25:08 OpenWrt kern.debug kernel: 38: 01 71 14 57 01 01 06 00
> Mar 18 16:25:08 OpenWrt kern.debug kernel: 40: C1 48 78 3B 00 00 00 00
> Mar 18 16:25:08 OpenWrt kern.debug kernel: 48: 00 00 00 00 00 00 00 00
> Mar 18 16:25:10 OpenWrt kern.info kernel: solos 0000:00:0c.0: Received: device 0
> Mar 18 16:25:10 OpenWrt kern.info kernel: solos 0000:00:0c.0: size: 145 VPI: 0 VCI: 35
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 00: AA AA 03 00 80 C2 00 07
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 08: 00 00 0C D5 02 58 DC B3
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 10: 00 90 1A 41 45 FE 08 00
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 18: 45 00 00 79 7D 84 40 00
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 20: 38 06 7A 59 C6 89 CA 12
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 28: 47 6F 72 96 03 E1 E3 CD
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 30: 28 7D 87 1A 59 6E EE 7B
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 38: 80 18 82 18 19 95 00 00
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 40: 01 01 08 0A 29 5A 4D 3F
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 48: 21 87 4F 95 17 03 01 00
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 50: 40 0E 30 D7 94 BD D6 41
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 58: D8 1D 1D 6C FF 97 CC 3A
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 60: 01 67 D4 DB 7E 6C D5 A7
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 68: 80 BA 37 F5 F0 AB 4C FC
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 70: 37 6D 62 E9 70 A4 5C 6C
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 78: B4 80 4A ED 19 81 06 DE
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 80: 74 45 18 2A FC 86 58 C3
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 88: 63 F1 68 C7 E0 EB 9D B3
> Mar 18 16:25:10 OpenWrt kern.debug kernel: 90: 3F
> Mar 18 16:25:10 OpenWrt kern.info kernel: solos 0000:00:0c.0: find_vcc: ddd39e00, 0.35
> Mar 18 16:25:10 OpenWrt kern.info kernel: solos 0000:00:0c.0: head=e04dd42c, first=  (null), mask=3
> Mar 18 16:25:10 OpenWrt kern.warn kernel: solos 0000:00:0c.0: Received packet for unknown VPI.VCI 0.35 on port 0
> Mar 18 16:25:11 OpenWrt kern.info kernel: solos 0000:00:0c.0: Transmitted: port 0
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 00: 9D 01 00 00 23 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 08: AA AA 03 00 80 C2 00 07
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 10: 00 00 FF FF FF FF FF FF
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 18: 00 0A FA 22 00 84 08 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 20: 45 00 01 85 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 28: 40 11 79 69 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 30: FF FF FF FF 00 44 00 43
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 38: 01 71 14 57 01 01 06 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 40: C1 48 78 3B 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 48: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 50: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 58: 00 0A FA 22 00 84 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 60: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 68: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 70: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 78: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 80: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 88: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 90: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 98: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: A0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: A8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: B0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: B8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: C0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: C8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: D0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: D8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: E0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: E8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: F0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: F8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 100: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 108: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 110: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 118: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 120: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 128: 63 82 53 63 35 01 01 3D
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 130: 07 01 00 0A FA 22 00 84
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 138: 3C 0C 75 64 68 63 70 20
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 140: 31 2E 31 37 2E 33 39 02
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 148: 02 40 37 08 01 03 06 0C
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 150: 0F 11 1C 2A FF 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 158: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 160: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 168: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 170: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 178: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 180: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 188: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 190: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 198: 00 00 00 00 00 00 00 00
> Mar 18 16:25:11 OpenWrt kern.debug kernel: 1A0: 00 00 00 00 00
> Mar 18 16:25:12 OpenWrt kern.info kernel: solos 0000:00:0c.0: Received: device 0
> Mar 18 16:25:12 OpenWrt kern.info kernel: solos 0000:00:0c.0: size: 136 VPI: 0 VCI: 35
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 00: AA AA 03 00 80 C2 00 07
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 08: 00 00 0C D5 02 58 DC B3
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 10: 00 90 1A 41 45 FE 08 00
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 18: 45 00 00 70 81 AE 00 00
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 20: 38 06 EB B6 D8 9B 82 82
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 28: 47 6F 72 96 1A 0B E3 AC
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 30: CC 49 2D 12 EE 82 FC BC
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 38: 80 18 20 14 0B 67 00 00
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 40: 01 01 08 0A 2C 60 20 A1
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 48: 21 87 4F DB 3A 65 6D 61
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 50: 6C 64 6F 6E 61 5F 6D 74
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 58: 76 21 7E 65 6D 61 6C 64
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 60: 6F 6E 61 40 32 30 39 2E
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 68: 31 33 32 2E 31 38 31 2E
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 70: 38 36 20 4A 4F 49 4E 20
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 78: 3A 23 66 65 64 6F 72 61
> Mar 18 16:25:12 OpenWrt kern.debug kernel: 80: 2D 64 65 76 65 6C 0D 0A
> Mar 18 16:25:12 OpenWrt kern.info kernel: solos 0000:00:0c.0: find_vcc: ddd39e00, 0.35
> Mar 18 16:25:12 OpenWrt kern.info kernel: solos 0000:00:0c.0: head=e04dd42c, first=  (null), mask=3
> Mar 18 16:25:12 OpenWrt kern.warn kernel: solos 0000:00:0c.0: Received packet for unknown VPI.VCI 0.35 on port 0
> Mar 18 16:25:14 OpenWrt kern.info kernel: solos 0000:00:0c.0: Transmitted: port 0
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 00: 9D 01 00 00 23 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 08: AA AA 03 00 80 C2 00 07
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 10: 00 00 FF FF FF FF FF FF
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 18: 00 0A FA 22 00 84 08 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 20: 45 00 01 85 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 28: 40 11 79 69 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 30: FF FF FF FF 00 44 00 43
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 38: 01 71 14 57 01 01 06 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 40: C1 48 78 3B 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 48: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 50: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 58: 00 0A FA 22 00 84 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 60: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 68: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 70: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 78: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 80: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 88: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 90: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 98: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: A0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: A8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: B0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: B8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: C0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: C8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: D0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: D8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: E0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: E8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: F0: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: F8: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 100: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 108: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 110: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 118: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 120: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 128: 63 82 53 63 35 01 01 3D
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 130: 07 01 00 0A FA 22 00 84
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 138: 3C 0C 75 64 68 63 70 20
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 140: 31 2E 31 37 2E 33 39 02
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 148: 02 40 37 08 01 03 06 0C
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 150: 0F 11 1C 2A FF 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 158: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 160: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 168: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 170: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 178: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 180: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 188: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 190: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 198: 00 00 00 00 00 00 00 00
> Mar 18 16:25:14 OpenWrt kern.debug kernel: 1A0: 00 00 00 00 00
>
>
> And I see 24 bytes of preamble from the AA AA 03 SNAP preamble to the 45 00 of the beginning of the IP packet.
>
> Not sure why there are an extra 8 bytes of prefix on transmit... as "9D 01 ... 00 00 00".
>
>
> Retrying in bridged mode, I get:
>
>
> Mar 18 16:28:08 OpenWrt kern.info kernel: solos 0000:00:0c.0: Received: device 0
> Mar 18 16:28:08 OpenWrt kern.info kernel: solos 0000:00:0c.0: size: 110 VPI: 0 VCI: 35
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 00: AA AA 03 00 80 C2 00 07
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 08: 00 00 0C D5 02 58 DC B3
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 10: 00 90 1A 41 45 FE 08 00
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 18: 45 00 00 56 63 AE 00 00
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 20: 35 06 9E 61 4A 7D 7F 10
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 28: 47 6F 72 96 03 E1 E3 D2
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 30: 01 52 43 20 B4 88 66 AE
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 38: 80 18 00 6A 3D 50 00 00
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 40: 01 01 08 0A 2F 42 B1 2B
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 48: 21 87 4D 8D 17 03 01 00
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 50: 1D 59 D6 25 B7 98 89 39
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 58: 87 FF 9B 83 BD CC C0 3E
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 60: 18 5A 9B 29 76 63 18 A8
> Mar 18 16:28:08 OpenWrt kern.debug kernel: 68: 59 53 CE D9 C5 C7
> Mar 18 16:28:08 OpenWrt kern.info kernel: solos 0000:00:0c.0: find_vcc: ddd74a00, 0.35
> Mar 18 16:28:08 OpenWrt kern.info kernel: solos 0000:00:0c.0: head=e04dd42c, first=  (null), mask=3
> Mar 18 16:28:08 OpenWrt kern.warn kernel: solos 0000:00:0c.0: Received packet for unknown VPI.VCI 0.35 on port 0
> Mar 18 16:28:11 OpenWrt kern.info kernel: solos 0000:00:0c.0: Transmitted: port 0
> Mar 18 16:28:11 OpenWrt kern.debug kernel: 00: 8D 01 00 00 23 00 00 00
> Mar 18 16:28:11 OpenWrt kern.debug kernel: 08: AA AA 03 00 00 00 08 00
> Mar 18 16:28:11 OpenWrt kern.debug kernel: 10: 45 00 01 85 00 00 00 00
> Mar 18 16:28:11 OpenWrt kern.debug kernel: 18: 40 11 79 69 00 00 00 00
> Mar 18 16:28:11 OpenWrt kern.debug kernel: 20: FF FF FF FF 00 44 00 43
> Mar 18 16:28:11 OpenWrt kern.debug kernel: 28: 01 71 D3 C7 01 01 06 00
> Mar 18 16:28:11 OpenWrt kern.debug kernel: 30: 90 28 DF 4C 00 00 00 00
> Mar 18 16:28:11 OpenWrt kern.debug kernel: 38: 00 00 00 00 00 00 00 00
> Mar 18 16:28:11 OpenWrt kern.debug kernel: 40: 00 00 00 00 00 00 00 00
> Mar 18 16:28:11 OpenWrt kern.debug kernel: 48: 00 00 00 00 00 00 00 00
> Mar 18 16:28:14 OpenWrt kern.info kernel: solos 0000:00:0c.0: Transmitted: port 0
> Mar 18 16:28:14 OpenWrt kern.debug kernel: 00: 8D 01 00 00 23 00 00 00
> Mar 18 16:28:14 OpenWrt kern.debug kernel: 08: AA AA 03 00 00 00 08 00
> Mar 18 16:28:14 OpenWrt kern.debug kernel: 10: 45 00 01 85 00 00 00 00
> Mar 18 16:28:14 OpenWrt kern.debug kernel: 18: 40 11 79 69 00 00 00 00
> Mar 18 16:28:14 OpenWrt kern.debug kernel: 20: FF FF FF FF 00 44 00 43
> Mar 18 16:28:14 OpenWrt kern.debug kernel: 28: 01 71 D3 C7 01 01 06 00
> Mar 18 16:28:14 OpenWrt kern.debug kernel: 30: 90 28 DF 4C 00 00 00 00
> Mar 18 16:28:14 OpenWrt kern.debug kernel: 38: 00 00 00 00 00 00 00 00
> Mar 18 16:28:14 OpenWrt kern.debug kernel: 40: 00 00 00 00 00 00 00 00
> Mar 18 16:28:14 OpenWrt kern.debug kernel: 48: 00 00 00 00 00 00 00 00
> Mar 18 16:28:16 OpenWrt kern.info kernel: solos 0000:00:0c.0: Received: device 0
> Mar 18 16:28:16 OpenWrt kern.info kernel: solos 0000:00:0c.0: size: 110 VPI: 0 VCI: 35
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 00: AA AA 03 00 80 C2 00 07
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 08: 00 00 0C D5 02 58 DC B3
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 10: 00 90 1A 41 45 FE 08 00
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 18: 45 00 00 56 63 AF 00 00
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 20: 35 06 9E 60 4A 7D 7F 10
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 28: 47 6F 72 96 03 E1 E3 D2
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 30: 01 52 43 20 B4 88 66 AE
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 38: 80 18 00 6A 1C 30 00 00
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 40: 01 01 08 0A 2F 42 D2 4B
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 48: 21 87 4D 8D 17 03 01 00
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 50: 1D 59 D6 25 B7 98 89 39
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 58: 87 FF 9B 83 BD CC C0 3E
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 60: 18 5A 9B 29 76 63 18 A8
> Mar 18 16:28:16 OpenWrt kern.debug kernel: 68: 59 53 CE D9 C5 C7
> Mar 18 16:28:16 OpenWrt kern.info kernel: solos 0000:00:0c.0: find_vcc: ddd74a00, 0.35
> Mar 18 16:28:16 OpenWrt kern.info kernel: solos 0000:00:0c.0: head=e04dd42c, first=  (null), mask=3
> Mar 18 16:28:16 OpenWrt kern.warn kernel: solos 0000:00:0c.0: Received packet for unknown VPI.VCI 0.35 on port 0
> Mar 18 16:28:17 OpenWrt kern.info kernel: solos 0000:00:0c.0: Transmitted: port 0
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 00: 8D 01 00 00 23 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 08: AA AA 03 00 00 00 08 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 10: 45 00 01 85 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 18: 40 11 79 69 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 20: FF FF FF FF 00 44 00 43
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 28: 01 71 D3 C7 01 01 06 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 30: 90 28 DF 4C 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 38: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 40: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 48: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 50: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 58: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 60: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 68: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 70: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 78: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 80: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 88: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 90: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 98: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: A0: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: A8: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: B0: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: B8: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: C0: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: C8: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: D0: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: D8: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: E0: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: E8: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: F0: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: F8: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 100: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 108: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 110: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 118: 63 82 53 63 35 01 01 3D
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 120: 07 01 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 128: 3C 0C 75 64 68 63 70 20
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 130: 31 2E 31 37 2E 33 39 02
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 138: 02 40 37 08 01 03 06 0C
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 140: 0F 11 1C 2A FF 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 148: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 150: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 158: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 160: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 168: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 170: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 178: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 180: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 188: 00 00 00 00 00 00 00 00
> Mar 18 16:28:17 OpenWrt kern.debug kernel: 190: 00 00 00 00 00
> Mar 18 16:28:20 OpenWrt kern.info kernel: solos 0000:00:0c.0: Transmitted: port 0
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 00: 8D 01 00 00 23 00 00 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 08: AA AA 03 00 00 00 08 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 10: 45 00 01 85 00 00 00 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 18: 40 11 79 69 00 00 00 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 20: FF FF FF FF 00 44 00 43
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 28: 01 71 D3 C7 01 01 06 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 30: 90 28 DF 4C 00 00 00 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 38: 00 00 00 00 00 00 00 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 40: 00 00 00 00 00 00 00 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 48: 00 00 00 00 00 00 00 00
> Mar 18 16:28:20 OpenWrt kern.info kernel: solos 0000:00:0c.0: Received: device 0
> Mar 18 16:28:20 OpenWrt kern.info kernel: solos 0000:00:0c.0: size: 214 VPI: 0 VCI: 35
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 00: AA AA 03 00 80 C2 00 07
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 08: 00 00 0C D5 02 58 DC B3
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 10: 00 90 1A 41 45 FE 08 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 18: 45 00 00 BE BD 19 40 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 20: 38 06 3A 7F C6 89 CA 12
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 28: 47 6F 72 96 03 E1 E3 CD
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 30: 28 7D 87 1A 59 6E EE 7B
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 38: 80 18 82 18 61 C0 00 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 40: 01 01 08 0A 29 5D 34 4F
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 48: 21 87 4F 95 17 03 01 00
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 50: 40 0E 30 D7 94 BD D6 41
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 58: D8 1D 1D 6C FF 97 CC 3A
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 60: 01 67 D4 DB 7E 6C D5 A7
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 68: 80 BA 37 F5 F0 AB 4C FC
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 70: 37 6D 62 E9 70 A4 5C 6C
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 78: B4 80 4A ED 19 81 06 DE
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 80: 74 45 18 2A FC 86 58 C3
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 88: 63 F1 68 C7 E0 EB 9D B3
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 90: 3F 17 03 01 00 40 14 E9
> Mar 18 16:28:20 OpenWrt kern.debug kernel: 98: D7 D4 E3 C4 2A DF EA 5D
> Mar 18 16:28:20 OpenWrt kern.debug kernel: A0: 6E 00 4B 9A 1F 27 F9 07
> Mar 18 16:28:20 OpenWrt kern.debug kernel: A8: 55 67 5B 45 D6 76 09 A4
> Mar 18 16:28:20 OpenWrt kern.debug kernel: B0: 69 28 B1 4F 54 80 DB 15
> Mar 18 16:28:20 OpenWrt kern.debug kernel: B8: 3A 01 3A A1 6E 89 F8 E7
> Mar 18 16:28:20 OpenWrt kern.debug kernel: C0: 2A EA 2E 59 13 09 44 A1
> Mar 18 16:28:20 OpenWrt kern.debug kernel: C8: F7 06 85 74 A0 07 20 88
> Mar 18 16:28:20 OpenWrt kern.debug kernel: D0: 55 7E 4A C4 D0 75
> Mar 18 16:28:20 OpenWrt kern.info kernel: solos 0000:00:0c.0: find_vcc: ddd74a00, 0.35
> Mar 18 16:28:20 OpenWrt kern.info kernel: solos 0000:00:0c.0: head=e04dd42c, first=  (null), mask=3
> Mar 18 16:28:20 OpenWrt kern.warn kernel: solos 0000:00:0c.0: Received packet for unknown VPI.VCI 0.35 on port 0
>
>
> So we're receiving 24 bytes of preamble (AA AA 03 ... 00 80), but we send either 16 bytes of MAC header with a 8 byte prefix in bridged mode (that's probably just the logging showing something before the header), or we send 8 bytes of prefix and 8 bytes of MAC header in routed mode.
>
> My money is on routed mode.
>
> Two things stand out from these traces...
>
> (1) minor, we're seeing 8 bytes of prefix on transmit that we don't see on transmit (is that buffer descriptor or what?)... which incidentally is the same size as the pkt_hdr structure.
> (2) we're consistently seeing find_vcc() return NULL
>
> also not clear why "vpi" is usually a short in the code, but "vci" is more often an "int".
>
> This is running 2.6.37...  I was previously using the same image with Qwest and PPPoA, and that seemed to work fine.
>
> It's not clear to me why the hash of VC's is kept on a per-driver basis... shouldn't that go in atm common stuff?
>
> Taking the 8-bytes of prefix and disassembling it as a struct pkt_hdr, I get:
>
> 9D 01 00 00 23 00 00 00
>
> 0x019d (413) == size
> 0x0000 (0)   == vpi
> 0x0023 (35)  == vci
> 0x0000 (0)   == type (PKT_DATA)
>
> Oh, and another couple of nits, we say "Received: device 0", but "Transmitted: port 0"... and we dump the first 3 fields of the pkt_hdr on receive but not on transmit.
>
> Thanks,
>
> -Philip
>

[Linux-ATM-General] [PATCH 1/1] solos-pci: Fix debugging to include size, vpi/vci, but omit preamble

[Philip P. <phi...@re...>]

Show the buffer length, vpi, and vci as we do on receive.  Use the word "port" instead of "device" consistently.

Don't display the "struct pkt_hdr" preamble on the sk_buff when doing hexdump of frame data.

Signed-off-by: Philip Prindeville <ph...@re...>
---

--- a/drivers/atm/solos-pci.c.orig	2011-03-19 12:19:06.000000000 -0600
+++ b/drivers/atm/solos-pci.c	2011-03-19 12:45:18.000000000 -0600
@@ -697,7 +697,7 @@ void solos_bh(unsigned long card_arg)
  					      size);
  			}
  			if (atmdebug) {
-				dev_info(&card->dev->dev, "Received: device %d\n", port);
+				dev_info(&card->dev->dev, "Received: port %d\n", port);
  				dev_info(&card->dev->dev, "size: %d VPI: %d VCI: %d\n",
  					 size, le16_to_cpu(header->vpi),
  					 le16_to_cpu(header->vci));
@@ -1025,8 +1025,15 @@ static uint32_t fpga_tx(struct solos_car

  			/* Clean up and free oldskb now it's gone */
  			if (atmdebug) {
+				struct pkt_hdr *header = (void *)oldskb->data;
+				int size = le16_to_cpu(header->size);
+
+				skb_pull(oldskb, sizeof(*header));
  				dev_info(&card->dev->dev, "Transmitted: port %d\n",
  					 port);
+				dev_info(&card->dev->dev, "size: %d VPI: %d VCI: %d\n",
+					 size, le16_to_cpu(header->vpi),
+					 le16_to_cpu(header->vci));
  				print_buffer(oldskb);
  			}