On Sat, 2012-12-08 at 15:06 +0100, Felix Fietkau wrote:
> >> The proper long term solution is to make sure that the kernel does the
> >> right thing and doesn't require userspace fixup for these devices.
>>
> > As per previous discussion, this just isn't going to happen on lantiq.
>
> Well, doing a
On Sat, 2012-12-08 at 15:06 +0100, Felix Fietkau wrote:
> On 2012-12-08 2:51 PM, Daniel Gimpelevich wrote:
> > On Sat, 2012-12-08 at 14:44 +0100, Felix Fietkau wrote:
> >> As for the time when hotplug is running wrt. loaded modules - normally
> >> udevtrigger should take care of generating the rig
On 2012-12-08 2:51 PM, Daniel Gimpelevich wrote:
> On Sat, 2012-12-08 at 14:44 +0100, Felix Fietkau wrote:
>> As for the time when hotplug is running wrt. loaded modules - normally
>> udevtrigger should take care of generating the right events.
>
> Modules are loaded before any of this is possible
On Sat, 2012-12-08 at 14:44 +0100, Felix Fietkau wrote:
> As for the time when hotplug is running wrt. loaded modules - normally
> udevtrigger should take care of generating the right events.
Modules are loaded before any of this is possible, in /etc/init.d/boot
as currently written.
> I was sugg
On 2012-12-08 2:34 PM, Daniel Gimpelevich wrote:
> On Sat, 2012-12-08 at 10:49 +, David Woodhouse wrote:
>> On Fri, 2012-12-07 at 18:58 -0800, Daniel Gimpelevich wrote:
>> > > > OK, but hotplug never generates any atm events, so Felix suggested this
>> > > > instead.
>> > >
>> > > Hm, it shou
On Sat, 2012-12-08 at 10:49 +, David Woodhouse wrote:
> On Fri, 2012-12-07 at 18:58 -0800, Daniel Gimpelevich wrote:
> > > > OK, but hotplug never generates any atm events, so Felix suggested this
> > > > instead.
> > >
> > > Hm, it should do. We have other scripts in /etc/hotplug.d/atm, and
On Fri, 2012-12-07 at 18:58 -0800, Daniel Gimpelevich wrote:
> > > OK, but hotplug never generates any atm events, so Felix suggested this
> > > instead.
> >
> > Hm, it should do. We have other scripts in /etc/hotplug.d/atm, and
> > hotplug2.rules definitely *looks* like it should be invoking them
On Fri, 2012-12-07 at 22:12 +, David Woodhouse wrote:
> On Fri, 2012-12-07 at 12:59 -0800, Daniel Gimpelevich wrote:
> > > It'd be better to put that in /etc/hotplug.d/atm so that you don't have
> > > to worry about the timing of when the atm driver loads at startup, and
> > > it gets done pro
On Fri, 2012-12-07 at 12:59 -0800, Daniel Gimpelevich wrote:
> > It'd be better to put that in /etc/hotplug.d/atm so that you don't have
> > to worry about the timing of when the atm driver loads at startup, and
> > it gets done properly if the driver is ever unloaded and reloaded, etc.
> >
>
> O
On Fri, 2012-12-07 at 12:59 -0800, Daniel Gimpelevich wrote:
> On Fri, 2012-12-07 at 20:56 +, David Woodhouse wrote:
> > On Fri, 2012-12-07 at 12:34 -0800, Daniel Gimpelevich wrote:
> > > Index: target/linux/lantiq/base-files/etc/init.d/ifx-esi
> > > ==
On Fri, 2012-12-07 at 20:56 +, David Woodhouse wrote:
> On Fri, 2012-12-07 at 12:34 -0800, Daniel Gimpelevich wrote:
> > Index: target/linux/lantiq/base-files/etc/init.d/ifx-esi
> > ===
> > --- target/linux/lantiq/base-files/etc/i
On Fri, 2012-12-07 at 12:34 -0800, Daniel Gimpelevich wrote:
> Index: target/linux/lantiq/base-files/etc/init.d/ifx-esi
> ===
> --- target/linux/lantiq/base-files/etc/init.d/ifx-esi (revision 0)
> +++ target/linux/lantiq/base-files/e
On Fri, 2012-12-07 at 12:24 -0800, Daniel Gimpelevich wrote:
> On Fri, 2012-12-07 at 12:15 -0800, Daniel Gimpelevich wrote:
> > On Thu, 2012-11-29 at 07:40 -0800, Daniel Gimpelevich wrote:
> > > On Thu, 2012-11-29 at 10:35 +, Conor O'Gorman wrote:
> > > > I don't want to drag this out longer
On Fri, 2012-12-07 at 12:15 -0800, Daniel Gimpelevich wrote:
> On Thu, 2012-11-29 at 07:40 -0800, Daniel Gimpelevich wrote:
> > On Thu, 2012-11-29 at 10:35 +, Conor O'Gorman wrote:
> > > I don't want to drag this out longer than necessary. You used the phrase
> > > 'hack'. What do you think i
On Thu, 2012-11-29 at 07:40 -0800, Daniel Gimpelevich wrote:
> On Thu, 2012-11-29 at 10:35 +, Conor O'Gorman wrote:
> > I don't want to drag this out longer than necessary. You used the phrase
> > 'hack'. What do you think is the preferred solution?
>
> If I had a better one, I would have use
On Thu, 2012-11-29 at 10:35 +, Conor O'Gorman wrote:
> I don't want to drag this out longer than necessary. You used the phrase
> 'hack'. What do you think is the preferred solution?
If I had a better one, I would have used it. RFC, again.
___
openw
On Wed, 2012-11-28 at 17:24 -0800, Daniel Gimpelevich wrote:
> The config option is already in place, as I said above. The sensible
> default _is_ the increment, which is what the vast majority of DSL
> routers do. In most of the AR7 ones, however, this incremented MAC is
> already a separate boot
On Thu, 2012-11-29 at 00:32 +, Conor O'Gorman wrote:
> br2684 picks that address if there is no 'set' mac and if the lower
> level provides nothing. It is a valid address, Xerox.
Whether or not it is technically valid might be rather open to
interpretation at the other end. The validity of a M
On Thu, 2012-11-29 at 00:17 +, David Woodhouse wrote:
> On Wed, 2012-11-28 at 14:35 -0800, Daniel Gimpelevich wrote:
> > The br2684 driver seems to expect that the MAC is already on the device
> > before a virtual circuit is created, but it seems to leave the mechanism
> > for doing so to the A
On Wed, 2012-11-28 at 16:28 -0800, Daniel Gimpelevich wrote:
> On Thu, 2012-11-29 at 00:17 +, David Woodhouse wrote:
> > I mostly use that with PPPoA, rather than PPPoEoA with the pointless MTU
> > breakage that that implies. But it does work fine with BR2684 with the
> > MAC address 00:00:01:0
On Thu, 2012-11-29 at 00:17 +, David Woodhouse wrote:
> I mostly use that with PPPoA, rather than PPPoEoA with the pointless MTU
> breakage that that implies. But it does work fine with BR2684 with the
> MAC address 00:00:01:00:00:00, which is what it ends up with.
>
> Do you actually *need* t
On Wed, 2012-11-28 at 14:35 -0800, Daniel Gimpelevich wrote:
> The br2684 driver seems to expect that the MAC is already on the device
> before a virtual circuit is created, but it seems to leave the mechanism
> for doing so to the ATM driver. The only other working ATM driver in
> OpenWrt is for A
On Wed, 2012-11-28 at 19:35 +, Conor O'Gorman wrote:
> Hi Daniel,
>
> Thank you for consider my comments.
>
> There are a couple of points I'd make. AFAIK this is only needed for
> ethernet bridging over atm. I am not familiar with an ethernet style
> mac
> being used in straight atm connecti
On Wed, 2012-11-28 at 06:18 -0800, Daniel Gimpelevich wrote:
> On Wed, 2012-11-28 at 10:09 +, Conor O'Gorman wrote:
> > This will affect all lantiq atm boards? I specify an ethernet MAC via
> > the command line, but I don't necessarily want it in the atm.
> >
> The existing code leaves the MA
On Wed, 2012-11-28 at 10:09 +, Conor O'Gorman wrote:
> This will affect all lantiq atm boards? I specify an ethernet MAC via
> the command line, but I don't necessarily want it in the atm.
>
>
> Conor
>
The existing code leaves the MAC at all zeros. Do you require that
instead of the MAC yo
On Tue, 2012-11-27 at 23:09 -0800, Daniel Gimpelevich wrote:
> On Wed, 2012-11-28 at 07:53 +0100, John Crispin wrote:
> > On 28/11/12 02:47, Daniel Gimpelevich wrote:
> > > This corrects a few oversights in mach-netgear.c, adds a diag.sh with
> > > per-board conditionals, in line with the uci-defa
On Wed, 2012-11-28 at 07:53 +0100, John Crispin wrote:
> On 28/11/12 02:47, Daniel Gimpelevich wrote:
> > This corrects a few oversights in mach-netgear.c, adds a diag.sh with
> > per-board conditionals, in line with the uci-defaults "leds" file, fixes
> > the Netgear eth0 MAC address detection, a
On 28/11/12 02:47, Daniel Gimpelevich wrote:
This corrects a few oversights in mach-netgear.c, adds a diag.sh with
per-board conditionals, in line with the uci-defaults "leds" file, fixes
the Netgear eth0 MAC address detection, and provides a mechanism for the
DSL driver to have a preset MAC addr
This corrects a few oversights in mach-netgear.c, adds a diag.sh with
per-board conditionals, in line with the uci-defaults "leds" file, fixes
the Netgear eth0 MAC address detection, and provides a mechanism for the
DSL driver to have a preset MAC address.
Signed-off-by: Daniel Gimpelevich
Index
29 matches
Mail list logo
