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

Re: [Linux-ATM-General] Supporting tcpdump, pseudo interfaces, and DSL MTU's

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

On Sun, 05 Sep 2010 16:15:21 -0700
Philip Prindeville <phi...@re...> wrote:

> You can make the argument that the end-systems sitting behind a
> router/firewall *might* be connected by 10mb/s Ethernet II over coax
> and/or a dumb hub, hence 1500 byte MTU makes sense.  But frankly this
> is highly unlikely.

i think it might be safest to use an mtu of 1500.  if you use anything
else you are doing to be asking some device somewhere to fragment your
traffic and that is going to impose some cpu load.  for embedded
devices, might be too much load.  you cant rely on path mtu detection
since many isp's just blindly block all icmp.

> Which, wanting to investigate this, brought me to the fact that (a) I
> couldn't run tcpdump on an ATM (DSL) interface and look at the actual
> MAC stream, and (b) while PPPoE creates a pseudo-interface (nas0) via
> br2648ctl, using the popular pppoatm.so kernel plugin doesn't create
> a similar pseudo-interface.  Should the pppox kernel module create a
> pseudo-interface that supports hooks for tcpdump inspection?  I'm
> thinking it should.

i dont know how pppoatm works exactly but i gather that pppd eventually
delivers the traffic to the network stack.  you should be able to
capture with at that point.  tcpdump'ing a native atm stream isnt
supported but there is a tool to look at the data on on vpi.vci,
atmdump.  however, you cannot dump vpi.vci that is already in use.

i suppose we could fix push() to send a cloned skb to the network stack
so that tcpdump dump could see it (only for 'raw' connections i guess
that you cant watch any other way). however, it will be missing any atm
headers so i am not sure how useful this would be.

Re: [Linux-ATM-General] Supporting tcpdump, pseudo interfaces, and DSL MTU's

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

  On 9/5/10 4:45 PM, MIke Westall wrote:
> I'm not really sure what the question is here.  But here are few ideas.
>
> (1) 1500 byte NPDUs don't impose an "unreasonable" level of link level overhead.
> If you include MAC header,  CRC,  Prefix its only 44/1544 (as I recall).  Anyway
> its way less than ATMs 11% cell header penalty.
> (2) 1500 bytes DO hurt you in a BIG WAY  at GBit+ speeds because of the overhead
> of processing them.  At 1 Gbps they arrive or need to be sent every 12 usec or so.
>
> But at current DSL speeds there is truly no significant PERFORMANCE benefit
> for using Phat Phrames AT THE ENDPOINT.

I guess the question I was asking was, "In the case of having a router with DSL built into it directly, should we assume that the (NPDU) MTU is always going to be 1500?"  If you had a router with a separate external Ethernet/DSL "bridge/modem" that you needed to speak PPPoE to, then I could understand the 1472 (or whatever) MTU... but not in the case of the router using an internal DSL NIC.

-Philip

>
> I wrote a paper on the impact of fat frames and interrupt
> coalescing a few years ago.  If you are interested, I can send it at you.
>
> I have a couple of (albeit 2+ year old)  Linksys routers  and  while Cisco's
> high end products  support  the "jumbo frame (9K  quasi standard)" these
> don't.
>
> Regards,
> Mike Westall
> Professor of Computer Science
> School of Computing
> Clemson University
>
>
> Philip Prindeville wrote:
>>   I was writing some new startup scripts for an embedded box that supports DSL, and it occurred to me that I didn't know what the optimal DSL (PPPoE or PPPoA) MTU's should be.
>>
>> You can make the argument that the end-systems sitting behind a router/firewall *might* be connected by 10mb/s Ethernet II over coax and/or a dumb hub, hence 1500 byte MTU makes sense.  But frankly this is highly unlikely.
>>
>> Everyone is using twisted pair, switches, and 100M, 1G, or 10G hardware these days... and the 1500 byte limit seems completely arbitrary since "jumbogram" support is more the rule than the exception (I remember when I was at Cisco 5 years ago, we did regression suites to make sure that all 100M interfaces could indeed support jumbograms of at least 4096 bytes, at least on routers running IOS).
>>
>> So given that, you'd think that the prevailing logic would be that all *transit links* (including the DSL hop from the C.O. to the subscriber) should be able to support *at least* the MTU that the end-user might send, yet I keep seeing numbers like 1478 or smaller crop up.
>>
>> All of the "fat pipe" connectivity within the ISP/IXC is going to be able to support jumbograms... so why should the DSL hop to the end-user ever be smaller than 1500 bytes?  What would be the point?  And indeed, do most DSL providers support larger MTU's?
>>
>> Which, wanting to investigate this, brought me to the fact that (a) I couldn't run tcpdump on an ATM (DSL) interface and look at the actual MAC stream, and (b) while PPPoE creates a pseudo-interface (nas0) via br2648ctl, using the popular pppoatm.so kernel plugin doesn't create a similar pseudo-interface.  Should the pppox kernel module create a pseudo-interface that supports hooks for tcpdump inspection?  I'm thinking it should.
>>
>> Anyone else have an opinion?
>>
>> Thanks,
>>
>> -Philip

Re: [Linux-ATM-General] Supporting tcpdump, pseudo interfaces, and DSL MTU's

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

I'm not really sure what the question is here.  But here are few ideas.

(1) 1500 byte NPDUs don't impose an "unreasonable" level of link level 
overhead.
If you include MAC header,  CRC,  Prefix its only 44/1544 (as I 
recall).  Anyway
its way less than ATMs 11% cell header penalty.
(2) 1500 bytes DO hurt you in a BIG WAY  at GBit+ speeds because of the 
overhead
of processing them.  At 1 Gbps they arrive or need to be sent every 12 
usec or so.

But at current DSL speeds there is truly no significant PERFORMANCE benefit
for using Phat Phrames AT THE ENDPOINT.

I wrote a paper on the impact of fat frames and interrupt
coalescing a few years ago.  If you are interested, I can send it at you.

I have a couple of (albeit 2+ year old)  Linksys routers  and  while Cisco's
high end products  support  the "jumbo frame (9K  quasi standard)" these
don't.

Regards,
Mike Westall
Professor of Computer Science
School of Computing
Clemson University


Philip Prindeville wrote:
>   I was writing some new startup scripts for an embedded box that supports DSL, and it occurred to me that I didn't know what the optimal DSL (PPPoE or PPPoA) MTU's should be.
>
> You can make the argument that the end-systems sitting behind a router/firewall *might* be connected by 10mb/s Ethernet II over coax and/or a dumb hub, hence 1500 byte MTU makes sense.  But frankly this is highly unlikely.
>
> Everyone is using twisted pair, switches, and 100M, 1G, or 10G hardware these days... and the 1500 byte limit seems completely arbitrary since "jumbogram" support is more the rule than the exception (I remember when I was at Cisco 5 years ago, we did regression suites to make sure that all 100M interfaces could indeed support jumbograms of at least 4096 bytes, at least on routers running IOS).
>
> So given that, you'd think that the prevailing logic would be that all *transit links* (including the DSL hop from the C.O. to the subscriber) should be able to support *at least* the MTU that the end-user might send, yet I keep seeing numbers like 1478 or smaller crop up.
>
> All of the "fat pipe" connectivity within the ISP/IXC is going to be able to support jumbograms... so why should the DSL hop to the end-user ever be smaller than 1500 bytes?  What would be the point?  And indeed, do most DSL providers support larger MTU's?
>
> Which, wanting to investigate this, brought me to the fact that (a) I couldn't run tcpdump on an ATM (DSL) interface and look at the actual MAC stream, and (b) while PPPoE creates a pseudo-interface (nas0) via br2648ctl, using the popular pppoatm.so kernel plugin doesn't create a similar pseudo-interface.  Should the pppox kernel module create a pseudo-interface that supports hooks for tcpdump inspection?  I'm thinking it should.
>
> Anyone else have an opinion?
>
> Thanks,
>
> -Philip
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> Linux-atm-general mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-atm-general
>
>
>   

[Linux-ATM-General] Supporting tcpdump, pseudo interfaces, and DSL MTU's

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

  I was writing some new startup scripts for an embedded box that supports DSL, and it occurred to me that I didn't know what the optimal DSL (PPPoE or PPPoA) MTU's should be.

You can make the argument that the end-systems sitting behind a router/firewall *might* be connected by 10mb/s Ethernet II over coax and/or a dumb hub, hence 1500 byte MTU makes sense.  But frankly this is highly unlikely.

Everyone is using twisted pair, switches, and 100M, 1G, or 10G hardware these days... and the 1500 byte limit seems completely arbitrary since "jumbogram" support is more the rule than the exception (I remember when I was at Cisco 5 years ago, we did regression suites to make sure that all 100M interfaces could indeed support jumbograms of at least 4096 bytes, at least on routers running IOS).

So given that, you'd think that the prevailing logic would be that all *transit links* (including the DSL hop from the C.O. to the subscriber) should be able to support *at least* the MTU that the end-user might send, yet I keep seeing numbers like 1478 or smaller crop up.

All of the "fat pipe" connectivity within the ISP/IXC is going to be able to support jumbograms... so why should the DSL hop to the end-user ever be smaller than 1500 bytes?  What would be the point?  And indeed, do most DSL providers support larger MTU's?

Which, wanting to investigate this, brought me to the fact that (a) I couldn't run tcpdump on an ATM (DSL) interface and look at the actual MAC stream, and (b) while PPPoE creates a pseudo-interface (nas0) via br2648ctl, using the popular pppoatm.so kernel plugin doesn't create a similar pseudo-interface.  Should the pppox kernel module create a pseudo-interface that supports hooks for tcpdump inspection?  I'm thinking it should.

Anyone else have an opinion?

Thanks,

-Philip

[Linux-ATM-General] Anyone using pppoa?

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

  I've got pppoe working with Qwest here in the US using rp-pppoe, but I've not been able to get pppoa working.

The program craps out without anything resembling a useful error message:

# pppd plugin /usr/lib/pppd/2.4.5/pppoatm.so file /tmp/etc/ppp/options.nas1 dump noipdefault noauth default-asyncmap unit 1
Plugin /usr/lib/pppd/2.4.5/pppoatm.so loaded.
PPPoATM plugin_init
PPPoATM setdevname_pppoatm - SUCCESS:0.32
pppd options in effect:
debug		# (from /tmp/etc/ppp/options.nas1)
kdebug 1		# (from /tmp/etc/ppp/options.nas1)
persist		# (from /tmp/etc/ppp/options.nas1)
maxfail 0		# (from /tmp/etc/ppp/options.nas1)
unit 1		# (from command line)
dump		# (from command line)
plugin /usr/lib/pppd/2.4.5/pppoatm.so		# (from command line)
noauth		# (from command line)
0.32		# (from /tmp/etc/ppp/options.nas1)
llc-encaps		# (from /tmp/etc/ppp/options.nas1)
0.32		# (from /tmp/etc/ppp/options.nas1)
llc-encaps		# (from /tmp/etc/ppp/options.nas1)
default-asyncmap		# (from command line)
hide-password		# (from /tmp/etc/ppp/options.nas1)
noipdefault		# (from command line)
defaultroute		# (from /tmp/etc/ppp/options.nas1)
# echo $?
0
#

Any suggestions would be helpful.

Thanks,

-Philip

[Linux-ATM-General] How to clear FBQ underflow error in ATM ?

[mahendra v. <mah...@gm...>]

Hi All

In the ATM driver I have maintained rsmNumStatusQueueEntries = 256


Iam facing two types of errors.

1. Status_queue_overflow error. ( Rx data size is 40 bytes)
    Whenever I face this error, Iam setting the RSM_RESET bit and clearing
it.
    The error got cleared and Iam receiving data continuously.

2. FBQ_underflow error. (Rx data size is 1024 bytes)
    Whenever I face this error, the Early packet discard bit and underflow
bit is set in the register
    Iam setting the RSM_RESET bit and clearing it.
    Iam adding Saraddrsmbuffers.
    But the error is still not cleared and Iam not receiving any data.

Can you Please tell me a way how I can solve this error to receive data
continuously.. ?


Thanks
Mahendra

Re: [Linux-ATM-General] Issues with latest Solos firmware

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

  On 8/16/10 6:18 PM, Nathan Williams wrote:
> On 17/08/2010 9:59 AM, Philip Prindeville wrote:
>> Aug 16 16:39:28 pbx user.info kernel: Solos PCI Driver Version 0.11 svn-25
>> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Solos FPGA
>> Version 0.03 svn-37
>> Aug 16 16:39:28 pbx user.info kernel: firmware: requesting solos-FPGA.bin
>> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Flash upgrade
>> starting
>> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Firmware size:
>> 152064
>> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Number of
>> blocks: 36
>> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Changing FPGA
>> to Update mode
>> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Set FPGA Flash
>> mode to FPGA Chip Erase
>> Aug 16 16:40:49 pbx user.info kernel: solos 0000:00:0e.0: Returning FPGA
>> to Data mode
>> Aug 16 16:40:49 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM
>> device 0
>> Aug 16 16:40:49 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM
>> device 1
>> Aug 16 16:41:39 pbx user.warn kernel: solos 0000:00:0e.0: Received
>> packet for unknown VCI.VPI 0.0 on port 0
>> Aug 16 16:54:40 pbx user.info kernel: solos 0000:00:0e.0: Unregistering
>> ATM device 0
>> Aug 16 16:54:40 pbx user.info kernel: solos 0000:00:0e.0: Unregistering
>> ATM device 1
>> Aug 16 16:54:40 pbx user.info kernel: Solos PCI Driver 0.11 svn-25 Unloaded
>> Aug 16 16:54:40 pbx user.info kernel: NET: Unregistered protocol family 20
>> Aug 16 16:54:40 pbx user.info kernel: NET: Unregistered protocol family 8
>> Aug 16 16:55:10 pbx user.info kernel: NET: Registered protocol family 8
>> Aug 16 16:55:10 pbx user.info kernel: NET: Registered protocol family 20
>> Aug 16 16:55:10 pbx user.info kernel: Solos PCI Driver Version 0.11 svn-25
>> Aug 16 16:55:10 pbx user.info kernel: solos 0000:00:0e.0: Solos FPGA
>> Version 0.03 svn-37
>> Aug 16 16:55:10 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM
>> device 0
>> Aug 16 16:55:11 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM
>> device 1
>> pbx ~ #
>> pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
>> Error. No response from modem
>> pbx ~ #
>>
>>
>
> Hi Philip,
>
> You will need to power-cycle the PC to force the FPGA to reload its configuration.  Then you should see Solos FPGA Version 0.03 svn-38.
>
> Regards,
> Nathan

Nathan did indeed send me a new FPGA image out-of-band, and I installed it.  That seems to have resolved the issues.

-Philip

Re: [Linux-ATM-General] stop_queue for ATM?

[Nathan W. <na...@tr...>]

On Fri, 2010-08-20 at 09:25 -0400, chas williams - CONTRACTOR wrote:
> what layer are you using to talk to the solos-pci tx queue? some of the
> layers in the atm stack ignore the .send return code still.

I'm using pppoatm for PPPoA and br2684 for PPPoE.

Re: [Linux-ATM-General] stop_queue for ATM?

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

On Fri, 20 Aug 2010 10:56:18 +0200
Karl Hiramoto <ka...@hi...> wrote:

> 2.  For example when there are multiple br2684 or clip VCs  on a
> device, if one VC has the device full the other VCs don't
> netif_stop_queue()

yeah that is a problem.  i had this when i implemented this flow
control for the lec driver.  so if one vc fills up you have to stop
sending on all the vc's since the network stack doesnt have a queue per
connection.

even so, most of the atm hardware has a single transmit schedule queue
and if this is full, no one should send.  your hardware might further
have some limit for a single vc.  so if you have a single vc per br2684
interface you should be fine.  but the problem might be getting fair
utilization across all those vc's.  you never know which one will
wakeup first.  the right answer might not be to wakeup as soon as one
could send again but when some real forward progress could be made.
br2684 uses:

static void br2684_pop(struct atm_vcc *vcc, struct sk_buff *skb)
{
...
        if (atm_may_send(vcc, 0))
                netif_wake_queue(net_dev);

that is a little agressive.  you might be able to send one packet, but
you might need to stop again.  atm_may_send() doesnt have idea of the
queue utilization in the atm hardware but if you use a value a bit
larger than 0 (like 1/2 of the wmem_alloc size) you might get better
results.

Re: [Linux-ATM-General] stop_queue for ATM?

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

On Fri, 20 Aug 2010 11:12:44 +1000
Nathan Williams <na...@tr...> wrote:
> Hi,
> 
> Is there any mechanism for an ATM driver to tell the kernel that its
> TX queue is full?  I'd like to keep solos-pci's TX queue short so
> traffic priorities can be managed in the kernel.
> 
> I think network devices can use netif_stop_queue(), so I'm wondering
> if there's something similar for ATM devices.

i suspect this doesnt work the way you think it does.  the .send
routine does return a value to indicate if it was successful in
scheduling the data to be transmitted.  however, it is up the layer to
actually do something if the send fails.  using lec as an example, if
the send fails, it calls a netif_stop_queue() to pause sending for a
little while.  this generally causes whatever protocol is running over
the network interface to handle this packet loss/stoppage as congestion
and backoff in someway.

i suppose if we were considering rewriting the interface, the atm tx
layer could use some sort of callback provided by the next layer to
ask the layer to stop sending.  then the driver writer would need to
handle calling some sort of resume when the hardware is ready to send
again.

what layer are you using to talk to the solos-pci tx queue? some of the
layers in the atm stack ignore the .send return code still.

Re: [Linux-ATM-General] stop_queue for ATM?

[Karl H. <ka...@hi...>]

  On 20/08/2010 3:12, Nathan Williams wrote:
> Hi,
>
> Is there any mechanism for an ATM driver to tell the kernel that its TX
> queue is full?  I'd like to keep solos-pci's TX queue short so traffic
> priorities can be managed in the kernel.
>
> I think network devices can use netif_stop_queue(), so I'm wondering if
> there's something similar for ATM devices.
>
AFIK it's not currently possible inside device drivers.   Currently it's 
done where we have a netdevice,  see the clip and br2684 modules.  With 
br2684ctl you can adjust the sndbuff to change when netif_stop_queue() 
is called.


Two issues i have now are:
1.  There is no way for the device driver to stop the queue.

2.  For example when there are multiple br2684 or clip VCs  on a device, 
if one VC has the device full the other VCs don't netif_stop_queue()


--
Karl

Re: [Linux-ATM-General] General doubt in ATM

[Ashish <wri...@gm...>]

I am not quite sure but AAL0 support raw cell so check if your hardware has
support of  ALL0 channel.
if so then open a AAL0 type channel and receive all cells.

--Ashish Gupta

On Thu, Aug 19, 2010 at 11:18 PM, chas williams - CONTRACTOR <
ch...@cm...> wrote:

> On Thu, 19 Aug 2010 19:49:15 +0530
> mahendra varman <mah...@gm...> wrote:
>
> > Hi
> >
> > Is that possible to find what is the VPI and VCI value of a received
> > cell from the trailer or by another means ?.
>
> the vpi/vci is only contained in the header and most of the hardware
> does not expose this in the aal5 layer.
>
> > 1. Suppose in real time if the receiver does not know by what vpi/vci
> > value the transmitter is sending then how to find from the received
> > cells ?
>
> you need an atm analyzer/capture device.  some hardware has the ability
> to receive all the cells regardless of vpi/vci and deliver them to the
> user.  however, this usually cant be done at line speed since it would
> typically generate an interrupt per cell and require quite a bit of cpu
> to handle a full rate oc3, 64-bytes at a time.  the pca200e has a
> special firmware for this.  not sure about any other card.
>
> > 2. Another query is In ethernet reception we can say broadcast address
> > and it will receive from any address. Similarly is there any option to
> > open aread such that it will receive cell of any vpi/vci value ?
>
> nope.  a general solution might be to open all the possible vpi/vci
> values for a card and poll() on all the open fd's.  ugly but
> manageable.  however, most of the atm cards have a limit to the number
> of bits you can split between vpi and vci so they cannot snoop the
> whole spectrum of possible cells.
>
> >
> > Thanks
> > Mahendra
> >
>
>

[Linux-ATM-General] stop_queue for ATM?

[Nathan W. <na...@tr...>]

Hi,

Is there any mechanism for an ATM driver to tell the kernel that its TX
queue is full?  I'd like to keep solos-pci's TX queue short so traffic
priorities can be managed in the kernel.

I think network devices can use netif_stop_queue(), so I'm wondering if
there's something similar for ATM devices.

Regards,
Nathan

Re: [Linux-ATM-General] General doubt in ATM

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

On Thu, 19 Aug 2010 19:49:15 +0530
mahendra varman <mah...@gm...> wrote:

> Hi
> 
> Is that possible to find what is the VPI and VCI value of a received
> cell from the trailer or by another means ?.

the vpi/vci is only contained in the header and most of the hardware
does not expose this in the aal5 layer.

> 1. Suppose in real time if the receiver does not know by what vpi/vci
> value the transmitter is sending then how to find from the received
> cells ?

you need an atm analyzer/capture device.  some hardware has the ability
to receive all the cells regardless of vpi/vci and deliver them to the
user.  however, this usually cant be done at line speed since it would
typically generate an interrupt per cell and require quite a bit of cpu
to handle a full rate oc3, 64-bytes at a time.  the pca200e has a
special firmware for this.  not sure about any other card.

> 2. Another query is In ethernet reception we can say broadcast address
> and it will receive from any address. Similarly is there any option to
> open aread such that it will receive cell of any vpi/vci value ?

nope.  a general solution might be to open all the possible vpi/vci
values for a card and poll() on all the open fd's.  ugly but
manageable.  however, most of the atm cards have a limit to the number
of bits you can split between vpi and vci so they cannot snoop the 
whole spectrum of possible cells.

> 
> Thanks
> Mahendra
> 

Re: [Linux-ATM-General] General doubt in ATM

[Giampaolo T. <Gia...@To...>]

> Hi
> 
> Is that possible to find what is the VPI and VCI value of a received
> cell from the trailer or by another means ?.
> 
> 1. Suppose in real time if the receiver does not know by what vpi/vci
> value the transmitter is sending then how to find from the received
> cells ?
>
> 
> 2. Another query is In ethernet reception we can say broadcast address
> and it will receive from any address. Similarly is there any option to
> open aread such that it will receive cell of any vpi/vci value ?

You should probably try opening an ATM_AAL0 channel on
ATM_VPI_ANY/ATM_VCI_ANY (or ATM_VPI_UNSPEC/ATM_VCI_UNSPEC, can't readily say
which one of the two).

Then, *provided that your interface supports all this* you should start
getting 53-bytes (or 52-bytes, again depending on interface) bytes cells.

Please note that, even if your interface doesn't "burps" on your setup, it
may change some of the fields in the header before yielding them to you.

Also note you may start getting idle-cells too, so beware. And also setup
your fingers to a ^C...

Giampaolo

> Thanks
> Mahendra

Re: [Linux-ATM-General] General doubt in ATM

[Karl H. <ka...@hi...>]

  On 19/08/2010 16:19, mahendra varman wrote:
> Hi
>
> Is that possible to find what is the VPI and VCI value of a received
> cell from the trailer or by another means ?.
>
> 1. Suppose in real time if the receiver does not know by what vpi/vci
> value the transmitter is sending then how to find from the received
> cells ?
VPI/VCI is in every cell in ATM AAL0.   If your hadware is using AAL5  
it depends if your hardware makes available the VCI/VPI

> 2. Another query is In ethernet reception we can say broadcast address
> and it will receive from any address. Similarly is there any option to
> open aread such that it will receive cell of any vpi/vci value ?
>
I assume your talking about RFC2684,   yes you can send broadcast.  See 
RFC2864

[Linux-ATM-General] General doubt in ATM

[mahendra v. <mah...@gm...>]

Hi

Is that possible to find what is the VPI and VCI value of a received
cell from the trailer or by another means ?.

1. Suppose in real time if the receiver does not know by what vpi/vci
value the transmitter is sending then how to find from the received
cells ?

2. Another query is In ethernet reception we can say broadcast address
and it will receive from any address. Similarly is there any option to
open aread such that it will receive cell of any vpi/vci value ?

Thanks
Mahendra

Re: [Linux-ATM-General] zeppelin causes kernel oops in 2.6.31 with linux-atm-2.5.1 with LEC interfaces.

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

In message <OF2...@gd...>,Jayson A Dyke writes:
>I'm using the linux kernel v2.6.31 and using linux-atm to create a LEC 
>interface. Every time I go to start zeppelin it causes a kernel oops. The 
>text of that kernel oops is BUG: unable to handle kernel NULL pointer 
>dereferenced at (null). After some investigation by git bisecting the 
>kernel, I narrowed it down to one commit (SHA1: e3804cbebb67887) that 
>removed a deprecated kernel configuration option of COMPAT_NET_DEV_OPS.
>
>I tried this with linux-atm 2.4.1, 2.5.1 and pulling the current 
>development source and compiling it.
>
>Does anyone have any ideas on how to fix this? I need that interface for 
>something and its only a LEC.

there have been two problems recently in the kernel with the lec driver.
i have attached there here in hopes of solving your problem.  it would
be a bit more helpful to get a traceback though from your oops.  the
first one is likely your problem, lec_init() was happening too late.

commit eb0445887a45a3705522aac6c2d8367e90358792
Author: chas williams - CONTRACTOR <ch...@cm...>
Date:   Fri Dec 4 05:19:30 2009 +0000

    atm: [lec] initialize .netdev_ops before calling register_netdev()
    
    fix oops when initializing lane interfaces. lec should probably be
    changed to use alloc_netdev() instead.
    
    Signed-off-by: Chas Williams - CONTRACTOR <ch...@cm...>
    Signed-off-by: David S. Miller <da...@da...>

diff --git a/net/atm/lec.c b/net/atm/lec.c
index b2d6445..42749b7 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -62,7 +62,6 @@ static int lec_open(struct net_device *dev);
 static netdev_tx_t lec_start_xmit(struct sk_buff *skb,
 				  struct net_device *dev);
 static int lec_close(struct net_device *dev);
-static void lec_init(struct net_device *dev);
 static struct lec_arp_table *lec_arp_find(struct lec_priv *priv,
 					  const unsigned char *mac_addr);
 static int lec_arp_remove(struct lec_priv *priv,
@@ -670,13 +669,6 @@ static const struct net_device_ops lec_netdev_ops = {
 	.ndo_set_multicast_list	= lec_set_multicast_list,
 };
 
-
-static void lec_init(struct net_device *dev)
-{
-	dev->netdev_ops = &lec_netdev_ops;
-	printk("%s: Initialized!\n", dev->name);
-}
-
 static const unsigned char lec_ctrl_magic[] = {
 	0xff,
 	0x00,
@@ -893,6 +885,7 @@ static int lecd_attach(struct atm_vcc *vcc, int arg)
 			dev_lec[i] = alloc_etherdev(size);
 		if (!dev_lec[i])
 			return -ENOMEM;
+		dev_lec[i]->netdev_ops = &lec_netdev_ops;
 		snprintf(dev_lec[i]->name, IFNAMSIZ, "lec%d", i);
 		if (register_netdev(dev_lec[i])) {
 			free_netdev(dev_lec[i]);
@@ -901,7 +894,6 @@ static int lecd_attach(struct atm_vcc *vcc, int arg)
 
 		priv = netdev_priv(dev_lec[i]);
 		priv->is_trdev = is_trdev;
-		lec_init(dev_lec[i]);
 	} else {
 		priv = netdev_priv(dev_lec[i]);
 		if (priv->lecd)


commit cf932353403c7e477a6c6596c0a6a23c6db5f406
Author: root <ro...@re...>
Date:   Fri Jul 16 19:33:19 2010 -0400

    atm: [lec] hold the rtnl lock around dev_set_mtu()
    
    Signed-off-by: Chas Williams - CONTRACTOR <ch...@cm...>

diff --git a/net/atm/lec.c b/net/atm/lec.c
index d98bde1..d6b5511 100644
--- a/net/atm/lec.c
+++ b/net/atm/lec.c
@@ -491,9 +491,11 @@ static int lec_atm_send(struct atm_vcc *vcc, struct sk_buff *skb)
 		priv->lane2_ops = NULL;
 		if (priv->lane_version > 1)
 			priv->lane2_ops = &lane2_ops;
+		rtnl_lock();
 		if (dev_set_mtu(dev, mesg->content.config.mtu))
 			pr_info("%s: change_mtu to %d failed\n",
 				dev->name, mesg->content.config.mtu);
+		rtnl_unlock();
 		priv->is_proxy = mesg->content.config.is_proxy;
 		break;
 	case l_flush_tran_id:

Re: [Linux-ATM-General] Issues with latest Solos firmware

[Nathan W. <na...@tr...>]

On 17/08/2010 9:59 AM, Philip Prindeville wrote:
> Aug 16 16:39:28 pbx user.info kernel: Solos PCI Driver Version 0.11 svn-25
> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Solos FPGA
> Version 0.03 svn-37
> Aug 16 16:39:28 pbx user.info kernel: firmware: requesting solos-FPGA.bin
> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Flash upgrade
> starting
> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Firmware size:
> 152064
> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Number of
> blocks: 36
> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Changing FPGA
> to Update mode
> Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Set FPGA Flash
> mode to FPGA Chip Erase
> Aug 16 16:40:49 pbx user.info kernel: solos 0000:00:0e.0: Returning FPGA
> to Data mode
> Aug 16 16:40:49 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM
> device 0
> Aug 16 16:40:49 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM
> device 1
> Aug 16 16:41:39 pbx user.warn kernel: solos 0000:00:0e.0: Received
> packet for unknown VCI.VPI 0.0 on port 0
> Aug 16 16:54:40 pbx user.info kernel: solos 0000:00:0e.0: Unregistering
> ATM device 0
> Aug 16 16:54:40 pbx user.info kernel: solos 0000:00:0e.0: Unregistering
> ATM device 1
> Aug 16 16:54:40 pbx user.info kernel: Solos PCI Driver 0.11 svn-25 Unloaded
> Aug 16 16:54:40 pbx user.info kernel: NET: Unregistered protocol family 20
> Aug 16 16:54:40 pbx user.info kernel: NET: Unregistered protocol family 8
> Aug 16 16:55:10 pbx user.info kernel: NET: Registered protocol family 8
> Aug 16 16:55:10 pbx user.info kernel: NET: Registered protocol family 20
> Aug 16 16:55:10 pbx user.info kernel: Solos PCI Driver Version 0.11 svn-25
> Aug 16 16:55:10 pbx user.info kernel: solos 0000:00:0e.0: Solos FPGA
> Version 0.03 svn-37
> Aug 16 16:55:10 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM
> device 0
> Aug 16 16:55:11 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM
> device 1
> pbx ~ #
> pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
> Error. No response from modem
> pbx ~ #
>
>

Hi Philip,

You will need to power-cycle the PC to force the FPGA to reload its 
configuration.  Then you should see Solos FPGA Version 0.03 svn-38.

Regards,
Nathan

Re: [Linux-ATM-General] Issues with latest Solos firmware

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

  On 8/12/10 5:47 PM, Nathan Williams wrote:
> On Thu, 2010-08-12 at 08:40 -0700, Philip Prindeville wrote:
>> No joy:
>>
>> pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
>> Sequence incorrect.
>> Expected x3803, buffer was:
>>
>> o data.
>>
>> pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
>> Error. No response from modem
>> pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
>> Error. No response from modem
>> pbx ~ #
> Hi Philip,
>
> I noticed that your FPGA version is 0.03-37, not 0.03-38.
> Some timing issues between the FPGA and Solos ADSL chipset were fixed in
> 0.03-38.
>
> I have emailed a binary and upgrade instructions for you off list.
>
> Regards,
> Nathan
>

I must be braindead...

Aug 16 16:39:14 pbx user.info kernel: solos 0000:00:0e.0: Unregistering ATM device 0
Aug 16 16:39:14 pbx user.info kernel: solos 0000:00:0e.0: Unregistering ATM device 1
Aug 16 16:39:14 pbx user.info kernel: Solos PCI Driver 0.11 svn-25 Unloaded
Aug 16 16:39:14 pbx user.info kernel: NET: Unregistered protocol family 20
Aug 16 16:39:14 pbx user.info kernel: NET: Unregistered protocol family 8
Aug 16 16:39:28 pbx user.info kernel: NET: Registered protocol family 8
Aug 16 16:39:28 pbx user.info kernel: NET: Registered protocol family 20
Aug 16 16:39:28 pbx user.info kernel: Solos PCI Driver Version 0.11 svn-25
Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Solos FPGA Version 0.03 svn-37
Aug 16 16:39:28 pbx user.info kernel: firmware: requesting solos-FPGA.bin
Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Flash upgrade starting
Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Firmware size: 152064
Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Number of blocks: 36
Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Changing FPGA to Update mode
Aug 16 16:39:28 pbx user.info kernel: solos 0000:00:0e.0: Set FPGA Flash mode to FPGA Chip Erase
Aug 16 16:40:49 pbx user.info kernel: solos 0000:00:0e.0: Returning FPGA to Data mode
Aug 16 16:40:49 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM device 0
Aug 16 16:40:49 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM device 1
Aug 16 16:41:39 pbx user.warn kernel: solos 0000:00:0e.0: Received packet for unknown VCI.VPI 0.0 on port 0
Aug 16 16:54:40 pbx user.info kernel: solos 0000:00:0e.0: Unregistering ATM device 0
Aug 16 16:54:40 pbx user.info kernel: solos 0000:00:0e.0: Unregistering ATM device 1
Aug 16 16:54:40 pbx user.info kernel: Solos PCI Driver 0.11 svn-25 Unloaded
Aug 16 16:54:40 pbx user.info kernel: NET: Unregistered protocol family 20
Aug 16 16:54:40 pbx user.info kernel: NET: Unregistered protocol family 8
Aug 16 16:55:10 pbx user.info kernel: NET: Registered protocol family 8
Aug 16 16:55:10 pbx user.info kernel: NET: Registered protocol family 20
Aug 16 16:55:10 pbx user.info kernel: Solos PCI Driver Version 0.11 svn-25
Aug 16 16:55:10 pbx user.info kernel: solos 0000:00:0e.0: Solos FPGA Version 0.03 svn-37
Aug 16 16:55:10 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM device 0
Aug 16 16:55:11 pbx user.info kernel: solos 0000:00:0e.0: Registered ATM device 1
pbx ~ #
pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
Error. No response from modem
pbx ~ #

[Linux-ATM-General] zeppelin causes kernel oops in 2.6.31 with linux-atm-2.5.1 with LEC interfaces.

[Jayson A D. <jd...@gd...>]

Hi,

I'm using the linux kernel v2.6.31 and using linux-atm to create a LEC 
interface. Every time I go to start zeppelin it causes a kernel oops. The 
text of that kernel oops is BUG: unable to handle kernel NULL pointer 
dereferenced at (null). After some investigation by git bisecting the 
kernel, I narrowed it down to one commit (SHA1: e3804cbebb67887) that 
removed a deprecated kernel configuration option of COMPAT_NET_DEV_OPS.

I tried this with linux-atm 2.4.1, 2.5.1 and pulling the current 
development source and compiling it.

Does anyone have any ideas on how to fix this? I need that interface for 
something and its only a LEC.


Jayson Dyke
D737, NEO
401-848-8504 (Office)
401-464-1661 (Cell)
jd...@gd...

Re: [Linux-ATM-General] Issues with latest Solos firmware

[Nathan W. <na...@tr...>]

On Thu, 2010-08-12 at 08:40 -0700, Philip Prindeville wrote:
> No joy:
> 
> pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
> Sequence incorrect.
> Expected x3803, buffer was:
> 
> o data.
> 
> pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
> Error. No response from modem
> pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
> Error. No response from modem
> pbx ~ #

Hi Philip,

I noticed that your FPGA version is 0.03-37, not 0.03-38.
Some timing issues between the FPGA and Solos ADSL chipset were fixed in
0.03-38.

I have emailed a binary and upgrade instructions for you off list.

Regards,
Nathan

Re: [Linux-ATM-General] Issues with latest Solos firmware

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

  On 8/11/10 5:03 PM, Nathan Williams wrote:
> On Thu, 2010-08-12 at 07:05 +1000, Guy Ellis wrote:
>> Hi Philip,
>>
>> What version does soloscli report?
>>
>>    - Guy.
>>
>> On 10/08/2010 3:28 PM, Philip Prindeville wrote:
>>>     I've tried both the canned soloscli sources in the tarball and the latest SVN version (r26), and both get the same result:
>>>
>>> # soloscli -s 0 SupportedAnnexes T1.413A
>>> Error. No response from modem
>>> #
> Try increasing TIMEOUT in soloscli.h to 300.


No joy:

pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
Sequence incorrect.
Expected x3803, buffer was:

o data.

pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
Error. No response from modem
pbx ~ # soloscli -s 0 SupportedAnnexes T1413A
Error. No response from modem
pbx ~ #

Re: [Linux-ATM-General] Issues with latest Solos firmware

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

Increasing timeout values is a sometimes effective way to recover
from various errors in broken drivers (or firmware!) :-(

For relatively high performance (OC-3 +) systems, the cost is often
severe performance hurts.  For DSL speed stuff it's ugly but typically not
noticeable performance-wise.

Been there, done that.

Mike

Re: [Linux-ATM-General] Issues with latest Solos firmware

[Nathan W. <na...@tr...>]

On Thu, 2010-08-12 at 07:05 +1000, Guy Ellis wrote:
> Hi Philip,
> 
> What version does soloscli report?
> 
>   - Guy.
> 
> On 10/08/2010 3:28 PM, Philip Prindeville wrote:
> >    I've tried both the canned soloscli sources in the tarball and the latest SVN version (r26), and both get the same result:
> >
> > # soloscli -s 0 SupportedAnnexes T1.413A
> > Error. No response from modem
> > #

Try increasing TIMEOUT in soloscli.h to 300.