Menu
▾
▴
linux-atm-general
|
From: Philip P. <phi...@re...> - 2010-09-05 23:15:38
|
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 |
|
From: MIke W. <we...@cs...> - 2010-09-05 23:45:54
|
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 > > > |
|
From: Philip P. <phi...@re...> - 2010-09-06 01:04:27
|
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 |
|
From: chas w. - C. <ch...@cm...> - 2010-09-07 15:47:59
|
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. |
|
From: ashgupta <wri...@gm...> - 2010-09-07 17:38:05
|
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 > |
|
From: Philip P. <phi...@re...> - 2010-09-08 01:36:41
|
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 |
|
From: Philip P. <phi...@re...> - 2010-09-11 23:44:04
|
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 |
|
From: Vincent Z. <vin...@se...> - 2010-09-12 10:55:31
|
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. |
|
From: Philip P. <phi...@re...> - 2010-09-13 04:32:40
|
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... |
|
From: Karl H. <ka...@hi...> - 2010-09-13 07:30:34
|
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 |
|
From: chas w. - C. <ch...@cm...> - 2010-09-13 15:30:20
|
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 |
|
From: Philip P. <phi...@re...> - 2010-09-13 16:06:33
|
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 |
|
From: chas w. - C. <ch...@cm...> - 2010-09-13 17:17:14
|
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 > |
|
From: Philip P. <phi...@re...> - 2010-09-13 20:35:00
|
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 |
|
From: chas w. - C. <ch...@cm...> - 2010-09-13 20:43:13
|
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 > |
|
From: Philip P. <phi...@re...> - 2010-09-13 20:51:49
|
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
|
|
From: Karl H. <ka...@hi...> - 2010-09-15 08:57:45
Attachments:
pppoa.carrier.patch
|
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 |
|
From: Philip P. <phi...@re...> - 2010-09-15 18:57:17
|
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);
|
|
From: Philip P. <phi...@re...> - 2010-09-15 20:31:28
|
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. |
|
From: Karl H. <ka...@hi...> - 2010-09-13 17:39:43
|
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. |
|
From: Philip P. <phi...@re...> - 2010-09-13 15:59:29
|
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... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X