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

Re: [Linux-ATM-General] Fwd: Re: [PATCH] pppoatm carrier status

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

On Tue, 21 Sep 2010 21:19:45 -0700
Philip Prindeville <phi...@re...> wrote:


> BUG: unable to handle kernel NULL pointer dereference at 00000090

like it said, null pointer dereference.  i.e. (null)->something

> IP: [<e0133050>] :ppp_generic:ppp_channel_carrier_on+0x16/0x31

very early in ppp_channel_carrier_on() which means it is likely
'struct channel *pch = chan->ppp;' where chan is null for some reason.
there could be an ordering issue here.  pvcc->chan might not be
assigned by the time the event is ready to fire.  it is reasonable to
expect that the carrier status of the hardware device will change
before the vcc is even assigned to the ppp layer.

Re: [Linux-ATM-General] Fwd: Re: [PATCH] pppoatm carrier status

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

On 09/22/10 07:21, Philip Prindeville wrote:
>  On 9/21/10 2:24 AM, Karl Hiramoto wrote:
>> On 09/21/10 05:49, Philip Prindeville wrote:
>>>   Let me know if you need me to test new patches.
>>>
>>
>> Attached is another patch that replaces the previous patch.
>>
>> Thanks.
> 
> +    read_lock_irqsave(&devs_lock, flags);
> +    list_for_each(lh,&pppoa_vccs) {
> +        pvcc = list_entry(lh, struct pppoatm_vcc, list_head);
> 
> Do we need here:
> 
> if (!pvcc)
>     continue;
> 
> or should this never be empty?
Should never be empty.  I attached another version of the patch.

Thanks,

Karl

Re: [Linux-ATM-General] Fwd: Re: [PATCH] pppoatm carrier status

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

  On 9/21/10 2:24 AM, Karl Hiramoto wrote:
> On 09/21/10 05:49, Philip Prindeville wrote:
>>   Let me know if you need me to test new patches.
>>
>
> Attached is another patch that replaces the previous patch.
>
> Thanks.

+	read_lock_irqsave(&devs_lock, flags);
+	list_for_each(lh,&pppoa_vccs) {
+		pvcc = list_entry(lh, struct pppoatm_vcc, list_head);

Do we need here:

if (!pvcc)
	continue;

or should this never be empty?


+		atm_vcc = pvcc->atmvcc;
+		if (atm_vcc&&  atm_vcc->dev == atm_dev) {
+
+			if (atm_vcc->dev->signal == ATM_PHY_SIG_LOST)
+					ppp_channel_carrier_off(&pvcc->chan);
+				else
+					ppp_channel_carrier_on(&pvcc->chan);
+		}
+	}
+	read_unlock_irqrestore(&devs_lock, flags);

Re: [Linux-ATM-General] Fwd: Re: [PATCH] pppoatm carrier status

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

  On 9/21/10 2:24 AM, Karl Hiramoto wrote:
> On 09/21/10 05:49, Philip Prindeville wrote:
>>   Let me know if you need me to test new patches.
>>
>
> Attached is another patch that replaces the previous patch.
>
> Thanks.

No joy.

pppoatm_assign_vcc:359 dev=de63f000
BUG: unable to handle kernel NULL pointer dereference at 00000090
IP: [<e0133050>] :ppp_generic:ppp_channel_carrier_on+0x16/0x31
*pde = 00000000
Oops: 0000 [#1] PREEMPT
Modules linked in: pppoatm pppox ppp_generic slhc bridge stp llc solos_pci atm d
ummy ath5k mac80211 ath cfg80211 rfkill_backport compat dahdi sha512_generic sha
256_generic deflate zlib_deflate arc4 ecb sha1_generic blowfish des_generic cbc
cryptosoft cryptodev(P) ocf(P) geodewdt geode_rng geode_aes crypto_blkcipher 813
9cp rtc lm90 hwmon i2c_core cs5535_gpio

Pid: 1606, comm: pppd Tainted: P          (2.6.27.49-astlinux #1)
EIP: 0060:[<e0133050>] EFLAGS: 00010002 CPU: 0
EIP is at ppp_channel_carrier_on+0x16/0x31 [ppp_generic]
EAX: 00000000 EBX: de715f80 ECX: ffffffff EDX: c033e4d8
ESI: 00000246 EDI: de89f800 EBP: 00000000 ESP: de6fdf0c
  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
Process pppd (pid: 1606, ti=de6fc000 task=df020a60 task.ti=de6fc000)
Stack: df1b9de0 e010a3c3 df1b9dfc 00000001 00000001 e010ae54 400261f2 e010ae5c
        bfc742e4 e0085a30 dec04480 e010ae54 e0088050 400261f2 bfc742e4 bfc742e4
        c0248564 dec04480 c02483b7 df16dec0 bfc742e4 400261f2 c0159c98 df16dec0
Call Trace:
  [<e010a3c3>] pppoatm_ioctl+0x1b0/0x248 [pppoatm]
  [<e0085a30>] vcc_ioctl+0x221/0x281 [atm]
  [<c0248564>] sock_ioctl+0x1ad/0x1d1
  [<c02483b7>] sock_ioctl+0x0/0x1d1
  [<c0159c98>] vfs_ioctl+0x1c/0x5e
  [<c0159f03>] do_vfs_ioctl+0x229/0x235
  [<c02a9d62>] do_page_fault+0x2ee/0x60d
  [<c0159f3b>] sys_ioctl+0x2c/0x45
  [<c01037e6>] syscall_call+0x7/0xb
  =======================
Code: 00 e0 ff ff ff 48 14 f6 40 08 08 74 06 5b e9 0f 42 17 e0 5b c3 53 8b 58 10
  e8 eb 5b fe df 89 e0 25 00 e0 ff ff ff 40 14 8b 43 4c<8b>  80 90 00 00 00 e8 67
  ab 12 e0 89 e0 25 00 e0 ff ff ff 48 14
EIP: [<e0133050>] ppp_channel_carrier_on+0x16/0x31 [ppp_generic] SS:ESP 0068:de6
fdf0c
Kernel panic - not syncing: Fatal exception in interrupt

Re: [Linux-ATM-General] Fwd: Re: [PATCH] pppoatm carrier status

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

  On 9/21/10 2:24 AM, Karl Hiramoto wrote:
> On 09/21/10 05:49, Philip Prindeville wrote:
>>   Let me know if you need me to test new patches.
>>
>
> Attached is another patch that replaces the previous patch.
>
> Thanks.

Building it now.  I'll test it this evening.

Thanks.

Re: [Linux-ATM-General] Fwd: Re: [PATCH] pppoatm carrier status

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

On 09/21/10 05:49, Philip Prindeville wrote:
>  Let me know if you need me to test new patches.
> 


Attached is another patch that replaces the previous patch.

Thanks.

Re: [Linux-ATM-General] [PATCH] pppoatm carrier status

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

  On 9/15/10 1:57 AM, Karl Hiramoto wrote:
> Philip,
>
> I attached a patch you can try for pppoatm, I have no way to test this
> myself.  It compiles OK I'm not sure if the changes in
> drivers/net/ppp_generic.c are OK.
>
> If your going to try and use 2.6.27 you'll have to backport all the
> other patches I sent earlier.
>
>
>
> --
> Karl

Crashed the test box.  Didn't have a console hooked up.  I'll look at it this evening.

Re: [Linux-ATM-General] [PATCH] pppoatm carrier status

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

  On 9/15/10 1:57 AM, Karl Hiramoto wrote:
> Philip,
>
> I attached a patch you can try for pppoatm, I have no way to test this
> myself.  It compiles OK I'm not sure if the changes in
> drivers/net/ppp_generic.c are OK.
>
> If your going to try and use 2.6.27 you'll have to backport all the
> other patches I sent earlier.
>
>
>
> --
> Karl

Giving it a try now.  The first patch set (v5) dropped in with only two modifications.

The patch you sent only needed one modification (so far... haven't run it yet).

Btw, in the original patches, you had:

+               list_for_each_entry(brvcc,&BRPRIV(net_dev)->brvccs, brvccs) {
+                       atm_vcc = brvcc->atmvcc;
+                       if (atm_vcc&&  brvcc->atmvcc->dev == atm_dev) {

This should be:

   if (atm_vcc&&  atm_vcc->atmvcc->dev == atm_dev) {

just for consistency (or if you've compiled this with optimization off, and breakpoint and then modify the value of atm_vcc ...



+
+                               if (atm_vcc->dev->signal == ATM_PHY_SIG_LOST)
+                                       netif_carrier_off(net_dev);
+                               else
+                                       netif_carrier_on(net_dev);

Re: [Linux-ATM-General] [PATCH] pppoatm carrier status

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

Philip,

I attached a patch you can try for pppoatm, I have no way to test this
myself.  It compiles OK I'm not sure if the changes in
drivers/net/ppp_generic.c are OK.

If your going to try and use 2.6.27 you'll have to backport all the
other patches I sent earlier.



--
Karl

Re: [Linux-ATM-General] Sync status in userspace

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

  Could that be handled in atm/common.c and then shared between atm/br2684.c and atm/pppoatm.c ?

Actually, netif_carrier_{on,off} in sched/sch_generic.c would also be a good place to handle that, wouldn't it?

But in the case of pppoatm.c, it never does a register_netdev().

Sigh.


On 9/13/10 1:42 PM, chas williams - CONTRACTOR wrote:
> sorry i mispoke.  i meant net/atm/br2684.c not the userspace control
> program.  like i said, i dont know of a way to get those atm events to
> a user space process.  you would need to add something like
> netevents/rt-netlink.
>
> On Mon, 13 Sep 2010 13:33:31 -0700
> Philip Prindeville<phi...@re...>  wrote:
>
>>    I looked in br2684ctl.c but didn't see (at least not in 2.5.1)
>> where carrier events were handled.  What am I missing?  I'd like to
>> port carrier transition handling to the PPP daemon for use with the
>> rp-pppoe and pppoatm userspace plugins.
>>
>> I looked in atm/br2684.c and noticed that it registers a notifier,
>> which it then uses to detect ATM_PHY_SIG_* events...
>>
>> atm/pppoatm.c has no such support, but I don't think it would be that
>> hard to add it.
>>
>> As for your comment, not sure I get it.  I thought that netlink
>> messages were agnostic (at least for the sender) about whether the
>> listener was in kernel or userspace?
>>
>>
>> On 9/13/10 10:16 AM, chas williams - CONTRACTOR wrote:
>>> in the kernel yes, but i dont know if there is a userspace
>>> mechanism to watch for this kind of thing.  as mentioned br2684ctl
>>> shows you how to watch for carrier changes in the kernel.
>>>
>>> On Mon, 13 Sep 2010 09:05:05 -0700
>>> Philip Prindeville<phi...@re...>   wrote:
>>>
>>>>     So I can't use rtnetlink RTM_NEWLINK messages to monitor state
>>>> changes?
>>>>
>>>>
>>>> On 9/13/10 8:29 AM, chas williams - CONTRACTOR wrote:
>>>>> this patch added event monitoring for the carrier/line status.  it
>>>>> also fixed some assumptions about the carrier state.  carrier is
>>>>> now assumed to be UP (it used to be not well defined) unless the
>>>>> hardware is capable of updating the state.  userspace can
>>>>> determine the carrier status by examining /sys/class/atm/<device
>>>>> instance>/carrier.  we dont have an ioctl or ethtool type
>>>>> instance>interface to get this data.
>>>>>
>>>>> On Mon, 13 Sep 2010 09:30:16 +0200
>>>>> Karl Hiramoto<ka...@hi...>    wrote:
>>>>>
>>>>>>      On 13/09/2010 6:32, Philip Prindeville wrote:
>>>>>>>      I think a few weeks ago I saw a patch fly by on
>>>>>>> linux-kernel on signaling sync status from the DSL driver to an
>>>>>>> upper layer, with the remark that it would be useful to
>>>>>>> userspace. There's something there.
>>>>>>>
>>>>>>> Ciao.
>>>>>>> Vincent.
>>>>>>>
>>>>>>> I'm not on linux-kernel but I'll check gmane... Thanks.
>>>>>>>
>>>>>>> Actually, just checked but couldn't find it.  If you remember
>>>>>>> who wrote it or what the subject was, that would help a lot...
>>>>>>>
>>>>>>>
>>>>>> I wrote the patch.  It should be in this list's archives and the
>>>>>> netdev list at the beginning of july.  The patches are in
>>>>>> mainline now, but only work on br2684 VCs so it passes the
>>>>>> LOWER_UP flag.
>>>>>>
>>>>>> The patches are in mainline now see commits
>>>>>> 49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f,
>>>>>> 7313bb8f3dd6e28bcf9c42adfd54a5cf9a4949e0,
>>>>>> 005066122b58f3b350736cc896af46aea2e32d23,  and others for each
>>>>>> device.
>>>>>>
>>>>>> --
>>>>>> Karl

Re: [Linux-ATM-General] Sync status in userspace

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

sorry i mispoke.  i meant net/atm/br2684.c not the userspace control
program.  like i said, i dont know of a way to get those atm events to
a user space process.  you would need to add something like
netevents/rt-netlink.

On Mon, 13 Sep 2010 13:33:31 -0700
Philip Prindeville <phi...@re...> wrote:

>   I looked in br2684ctl.c but didn't see (at least not in 2.5.1)
> where carrier events were handled.  What am I missing?  I'd like to
> port carrier transition handling to the PPP daemon for use with the
> rp-pppoe and pppoatm userspace plugins.
> 
> I looked in atm/br2684.c and noticed that it registers a notifier,
> which it then uses to detect ATM_PHY_SIG_* events...
> 
> atm/pppoatm.c has no such support, but I don't think it would be that
> hard to add it.
> 
> As for your comment, not sure I get it.  I thought that netlink
> messages were agnostic (at least for the sender) about whether the
> listener was in kernel or userspace?
> 
> 
> On 9/13/10 10:16 AM, chas williams - CONTRACTOR wrote:
> > in the kernel yes, but i dont know if there is a userspace
> > mechanism to watch for this kind of thing.  as mentioned br2684ctl
> > shows you how to watch for carrier changes in the kernel.
> >
> > On Mon, 13 Sep 2010 09:05:05 -0700
> > Philip Prindeville<phi...@re...>  wrote:
> >
> >>    So I can't use rtnetlink RTM_NEWLINK messages to monitor state
> >> changes?
> >>
> >>
> >> On 9/13/10 8:29 AM, chas williams - CONTRACTOR wrote:
> >>> this patch added event monitoring for the carrier/line status.  it
> >>> also fixed some assumptions about the carrier state.  carrier is
> >>> now assumed to be UP (it used to be not well defined) unless the
> >>> hardware is capable of updating the state.  userspace can
> >>> determine the carrier status by examining /sys/class/atm/<device
> >>> instance>/carrier.  we dont have an ioctl or ethtool type
> >>> instance>interface to get this data.
> >>>
> >>> On Mon, 13 Sep 2010 09:30:16 +0200
> >>> Karl Hiramoto<ka...@hi...>   wrote:
> >>>
> >>>>     On 13/09/2010 6:32, Philip Prindeville wrote:
> >>>>>     I think a few weeks ago I saw a patch fly by on
> >>>>> linux-kernel on signaling sync status from the DSL driver to an
> >>>>> upper layer, with the remark that it would be useful to
> >>>>> userspace. There's something there.
> >>>>>
> >>>>> Ciao.
> >>>>> Vincent.
> >>>>>
> >>>>> I'm not on linux-kernel but I'll check gmane... Thanks.
> >>>>>
> >>>>> Actually, just checked but couldn't find it.  If you remember
> >>>>> who wrote it or what the subject was, that would help a lot...
> >>>>>
> >>>>>
> >>>> I wrote the patch.  It should be in this list's archives and the
> >>>> netdev list at the beginning of july.  The patches are in
> >>>> mainline now, but only work on br2684 VCs so it passes the
> >>>> LOWER_UP flag.
> >>>>
> >>>> The patches are in mainline now see commits
> >>>> 49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f,
> >>>> 7313bb8f3dd6e28bcf9c42adfd54a5cf9a4949e0,
> >>>> 005066122b58f3b350736cc896af46aea2e32d23,  and others for each
> >>>> device.
> >>>>
> >>>> --
> >>>> Karl
> 

Re: [Linux-ATM-General] Sync status in userspace

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

  I looked in br2684ctl.c but didn't see (at least not in 2.5.1) where carrier events were handled.  What am I missing?  I'd like to port carrier transition handling to the PPP daemon for use with the rp-pppoe and pppoatm userspace plugins.

I looked in atm/br2684.c and noticed that it registers a notifier, which it then uses to detect ATM_PHY_SIG_* events...

atm/pppoatm.c has no such support, but I don't think it would be that hard to add it.

As for your comment, not sure I get it.  I thought that netlink messages were agnostic (at least for the sender) about whether the listener was in kernel or userspace?


On 9/13/10 10:16 AM, chas williams - CONTRACTOR wrote:
> in the kernel yes, but i dont know if there is a userspace mechanism to
> watch for this kind of thing.  as mentioned br2684ctl shows you how to
> watch for carrier changes in the kernel.
>
> On Mon, 13 Sep 2010 09:05:05 -0700
> Philip Prindeville<phi...@re...>  wrote:
>
>>    So I can't use rtnetlink RTM_NEWLINK messages to monitor state
>> changes?
>>
>>
>> On 9/13/10 8:29 AM, chas williams - CONTRACTOR wrote:
>>> this patch added event monitoring for the carrier/line status.  it
>>> also fixed some assumptions about the carrier state.  carrier is
>>> now assumed to be UP (it used to be not well defined) unless the
>>> hardware is capable of updating the state.  userspace can determine
>>> the carrier status by examining /sys/class/atm/<device
>>> instance>/carrier.  we dont have an ioctl or ethtool type interface
>>> instance>to get this data.
>>>
>>> On Mon, 13 Sep 2010 09:30:16 +0200
>>> Karl Hiramoto<ka...@hi...>   wrote:
>>>
>>>>     On 13/09/2010 6:32, Philip Prindeville wrote:
>>>>>     I think a few weeks ago I saw a patch fly by on linux-kernel on
>>>>> signaling sync status from the DSL driver to an upper layer, with
>>>>> the remark that it would be useful to userspace. There's something
>>>>> there.
>>>>>
>>>>> Ciao.
>>>>> Vincent.
>>>>>
>>>>> I'm not on linux-kernel but I'll check gmane... Thanks.
>>>>>
>>>>> Actually, just checked but couldn't find it.  If you remember who
>>>>> wrote it or what the subject was, that would help a lot...
>>>>>
>>>>>
>>>> I wrote the patch.  It should be in this list's archives and the
>>>> netdev list at the beginning of july.  The patches are in mainline
>>>> now, but only work on br2684 VCs so it passes the LOWER_UP flag.
>>>>
>>>> The patches are in mainline now see commits
>>>> 49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f,
>>>> 7313bb8f3dd6e28bcf9c42adfd54a5cf9a4949e0,
>>>> 005066122b58f3b350736cc896af46aea2e32d23,  and others for each
>>>> device.
>>>>
>>>> --
>>>> Karl

Re: [Linux-ATM-General] Sync status in userspace

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

  On 13/09/2010 18:05, Philip Prindeville wrote:
>  So I can't use rtnetlink RTM_NEWLINK messages to monitor state changes?
>
>
Yes for br2864.  works for me.

Re: [Linux-ATM-General] Sync status in userspace

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

in the kernel yes, but i dont know if there is a userspace mechanism to
watch for this kind of thing.  as mentioned br2684ctl shows you how to
watch for carrier changes in the kernel.

On Mon, 13 Sep 2010 09:05:05 -0700
Philip Prindeville <phi...@re...> wrote:

>   So I can't use rtnetlink RTM_NEWLINK messages to monitor state
> changes?
> 
> 
> On 9/13/10 8:29 AM, chas williams - CONTRACTOR wrote:
> > this patch added event monitoring for the carrier/line status.  it
> > also fixed some assumptions about the carrier state.  carrier is
> > now assumed to be UP (it used to be not well defined) unless the
> > hardware is capable of updating the state.  userspace can determine
> > the carrier status by examining /sys/class/atm/<device
> > instance>/carrier.  we dont have an ioctl or ethtool type interface
> > instance>to get this data.
> >
> > On Mon, 13 Sep 2010 09:30:16 +0200
> > Karl Hiramoto<ka...@hi...>  wrote:
> >
> >>    On 13/09/2010 6:32, Philip Prindeville wrote:
> >>>    I think a few weeks ago I saw a patch fly by on linux-kernel on
> >>> signaling sync status from the DSL driver to an upper layer, with
> >>> the remark that it would be useful to userspace. There's something
> >>> there.
> >>>
> >>> Ciao.
> >>> Vincent.
> >>>
> >>> I'm not on linux-kernel but I'll check gmane... Thanks.
> >>>
> >>> Actually, just checked but couldn't find it.  If you remember who
> >>> wrote it or what the subject was, that would help a lot...
> >>>
> >>>
> >> I wrote the patch.  It should be in this list's archives and the
> >> netdev list at the beginning of july.  The patches are in mainline
> >> now, but only work on br2684 VCs so it passes the LOWER_UP flag.
> >>
> >> The patches are in mainline now see commits
> >> 49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f,
> >> 7313bb8f3dd6e28bcf9c42adfd54a5cf9a4949e0,
> >> 005066122b58f3b350736cc896af46aea2e32d23,  and others for each
> >> device.
> >>
> >> --
> >> Karl
> 

Re: [Linux-ATM-General] Sync status in userspace

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

  So I can't use rtnetlink RTM_NEWLINK messages to monitor state changes?


On 9/13/10 8:29 AM, chas williams - CONTRACTOR wrote:
> this patch added event monitoring for the carrier/line status.  it also
> fixed some assumptions about the carrier state.  carrier is now assumed
> to be UP (it used to be not well defined) unless the hardware is
> capable of updating the state.  userspace can determine the carrier
> status by examining /sys/class/atm/<device instance>/carrier.  we dont
> have an ioctl or ethtool type interface to get this data.
>
> On Mon, 13 Sep 2010 09:30:16 +0200
> Karl Hiramoto<ka...@hi...>  wrote:
>
>>    On 13/09/2010 6:32, Philip Prindeville wrote:
>>>    I think a few weeks ago I saw a patch fly by on linux-kernel on
>>> signaling sync status from the DSL driver to an upper layer, with
>>> the remark that it would be useful to userspace. There's something
>>> there.
>>>
>>> Ciao.
>>> Vincent.
>>>
>>> I'm not on linux-kernel but I'll check gmane... Thanks.
>>>
>>> Actually, just checked but couldn't find it.  If you remember who
>>> wrote it or what the subject was, that would help a lot...
>>>
>>>
>> I wrote the patch.  It should be in this list's archives and the
>> netdev list at the beginning of july.  The patches are in mainline
>> now, but only work on br2684 VCs so it passes the LOWER_UP flag.
>>
>> The patches are in mainline now see commits
>> 49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f,
>> 7313bb8f3dd6e28bcf9c42adfd54a5cf9a4949e0,
>> 005066122b58f3b350736cc896af46aea2e32d23,  and others for each device.
>>
>> --
>> Karl

Re: [Linux-ATM-General] Sync status in userspace

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

  On 9/13/10 12:30 AM, Karl Hiramoto wrote:
> On 13/09/2010 6:32, Philip Prindeville wrote:
>>
>>   I think a few weeks ago I saw a patch fly by on linux-kernel on signaling
>> sync status from the DSL driver to an upper layer, with the remark that
>> it would be useful to userspace. There's something there.
>>
>> Ciao.                                                            Vincent.
>>
>> I'm not on linux-kernel but I'll check gmane... Thanks.
>>
>> Actually, just checked but couldn't find it.  If you remember who wrote it or what the subject was, that would help a lot...
>>
>>
> I wrote the patch.  It should be in this list's archives and the netdev list at the beginning of july.  The patches are in mainline now, but only work on br2684 VCs so it passes the LOWER_UP flag.
>
> The patches are in mainline now see commits  49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f, 7313bb8f3dd6e28bcf9c42adfd54a5cf9a4949e0, 005066122b58f3b350736cc896af46aea2e32d23,  and others for each device.
>
> --
> Karl

I'm running 2.6.27.48, so I'd have to backport them.

But I was also hoping to get them to work with pppoatm.so as well as rp-pppoe.so, in which case only the later would be using br2684ctl...

Re: [Linux-ATM-General] Sync status in userspace

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

this patch added event monitoring for the carrier/line status.  it also
fixed some assumptions about the carrier state.  carrier is now assumed
to be UP (it used to be not well defined) unless the hardware is
capable of updating the state.  userspace can determine the carrier
status by examining /sys/class/atm/<device instance>/carrier.  we dont
have an ioctl or ethtool type interface to get this data.

On Mon, 13 Sep 2010 09:30:16 +0200
Karl Hiramoto <ka...@hi...> wrote:

>   On 13/09/2010 6:32, Philip Prindeville wrote:
> >
> >   I think a few weeks ago I saw a patch fly by on linux-kernel on
> > signaling sync status from the DSL driver to an upper layer, with
> > the remark that it would be useful to userspace. There's something
> > there.
> >
> > Ciao.
> > Vincent.
> >
> > I'm not on linux-kernel but I'll check gmane... Thanks.
> >
> > Actually, just checked but couldn't find it.  If you remember who
> > wrote it or what the subject was, that would help a lot...
> >
> >
> I wrote the patch.  It should be in this list's archives and the
> netdev list at the beginning of july.  The patches are in mainline
> now, but only work on br2684 VCs so it passes the LOWER_UP flag.
> 
> The patches are in mainline now see commits  
> 49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f, 
> 7313bb8f3dd6e28bcf9c42adfd54a5cf9a4949e0, 
> 005066122b58f3b350736cc896af46aea2e32d23,  and others for each device.
> 
> --
> Karl

Re: [Linux-ATM-General] Sync status in userspace

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

  On 13/09/2010 6:32, Philip Prindeville wrote:
>
>   I think a few weeks ago I saw a patch fly by on linux-kernel on signaling
> sync status from the DSL driver to an upper layer, with the remark that
> it would be useful to userspace. There's something there.
>
> Ciao.                                                            Vincent.
>
> I'm not on linux-kernel but I'll check gmane... Thanks.
>
> Actually, just checked but couldn't find it.  If you remember who wrote it or what the subject was, that would help a lot...
>
>
I wrote the patch.  It should be in this list's archives and the netdev 
list at the beginning of july.  The patches are in mainline now, but 
only work on br2684 VCs so it passes the LOWER_UP flag.

The patches are in mainline now see commits  
49d49106fc6cbb48c832aa58e3e6cee8b49d5e8f, 
7313bb8f3dd6e28bcf9c42adfd54a5cf9a4949e0, 
005066122b58f3b350736cc896af46aea2e32d23,  and others for each device.

--
Karl

Re: [Linux-ATM-General] Sync status in userspace

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

  On 9/12/10 3:55 AM, Vincent Zweije wrote:
> On Tue, Sep 07, 2010 at 06:36:24PM -0700, Philip Prindeville wrote:
>
> ||  On a side-note: does ATM even advertise "carrier" (such as sync on a DSL
> ||  link) in any detectable way to user-space?
> ||
> ||  I'd like to have the pppoe and pppoatm plugins bomb out if carrier is down
> ||  on the DSL link you're trying to use them with.
>
> I think a few weeks ago I saw a patch fly by on linux-kernel on signaling
> sync status from the DSL driver to an upper layer, with the remark that
> it would be useful to userspace. There's something there.
>
> Ciao.                                                            Vincent.
>

I'm not on linux-kernel but I'll check gmane... Thanks.

Actually, just checked but couldn't find it.  If you remember who wrote it or what the subject was, that would help a lot...

Re: [Linux-ATM-General] Sync status in userspace (was: Supporting tcpdump, pseudo interfaces, and DSL MTU's)

[Vincent Z. <vin...@se...>]

On Tue, Sep 07, 2010 at 06:36:24PM -0700, Philip Prindeville wrote:

||  On a side-note: does ATM even advertise "carrier" (such as sync on a DSL
||  link) in any detectable way to user-space?
||  
||  I'd like to have the pppoe and pppoatm plugins bomb out if carrier is down
||  on the DSL link you're trying to use them with.

I think a few weeks ago I saw a patch fly by on linux-kernel on signaling
sync status from the DSL driver to an upper layer, with the remark that
it would be useful to userspace. There's something there.

Ciao.                                                            Vincent.
-- 
Vincent Zweije <zw...@xs...>    | "If you're flamed in a group you
<http://www.xs4all.nl/~zweije/>      | don't read, does anybody get burnt?"
[Xhost should be taken out and shot] |            -- Paul Tomblin on a.s.r.

[Linux-ATM-General] Link state not indicated

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

  On 9/7/10 6:36 PM, Philip Prindeville wrote:
> On a side-note: does ATM even advertise "carrier" (such as sync on a DSL link) in any detectable way to user-space?
>
> I'd like to have the pppoe and pppoatm plugins bomb out if carrier is down on the DSL link you're trying to use them with.
>
> -Philip
>
>

Didn't see an answer to this one...  So on DSL there's no way to indicate train (carrier)?

And ATM also has the concept of 'sync' on a fiber or copper circuit...

-Philip

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

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

  On 9/7/10 10:37 AM, ashgupta wrote:
> On Tuesday 07 September 2010 09:17 PM, chas williams - CONTRACTOR wrote:
>> 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.
>>
>>    
> pppd will not create net_device till lcp is not negotiated successfully. so either way is to dump pkt some where (like inpppoatm_push or in atm driver  <http://lxr.linux.no/linux+*/+code=pppoatm_push>)
> or clone skb and redirect it to some Ethernet interface (if your box has one) there you can connect some pc with Ethernet interface and snoop those
> lcp pkts.

Why do we even need an Ethernet interface?

Tcpdump understands non-Ethernet packets, and I think there might be some value to having certain low-level dialog (such as OAM and OLMI) be dumpable (although tcpdump might need hacking to support the AAL's and OAM).

On a side-note: does ATM even advertise "carrier" (such as sync on a DSL link) in any detectable way to user-space?

I'd like to have the pppoe and pppoatm plugins bomb out if carrier is down on the DSL link you're trying to use them with.

-Philip

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

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

On Tuesday 07 September 2010 09:17 PM, chas williams - CONTRACTOR wrote:
> 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.
>
>    
pppd will not create net_device till lcp is not negotiated successfully. so either way is to dump pkt some where (like inpppoatm_push or in atm driver  <http://lxr.linux.no/linux+*/+code=pppoatm_push>)
or clone skb and redirect it to some Ethernet interface (if your box has one) there you can connect some pc with Ethernet interface and snoop those
lcp pkts.


> ------------------------------------------------------------------------------
> 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
>    

Re: [Linux-ATM-General] Anyone using pppoa?

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

On Tue, 31 Aug 2010 13:11:03 -0700
Philip Prindeville <phi...@re...> wrote:

>   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

this might need to be 8.32?  use atmpdump to snoop on 0.32, 0.33 and see
if anything is arriving.

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

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

On Mon, 30 Aug 2010 12:11:59 +0530
mahendra varman <mah...@gm...> wrote:

> 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.. ?

what hardware are you using?  what is your line rate and usage?  at a
guess i would say that your num status queue entries is too small,
especially at an oc-3 rate and 40 byte packets.  since there is some
latency from getting the interrupt and handling the interrupt, you need
to allow for the status queue to grow while you are getting ready to
handle it.  at oc-3 and 40-byte packets, that is 3,500,000 packets per
second.  with a queue length of 256, you need to handle the interrupt
in less than 72us to avoid overflowing the status queue.

as for underflow, it seems like there might not be enough reassembly
memory thus the early packet discard.  most cards have some sort of
onboard memory to assemble the pdu's since the pdu's from multiple
vpi's can arrive interleaved.  i would need to see the programmer's
guide to go any further on this one.