On 2020-11-23 23:09, Xie He wrote:
On Mon, Nov 23, 2020 at 11:36 AM Jakub Kicinski
wrote:
> > From this point of view it will be the best to handle the NETDEV_UP in
> > the lapb event handler and establish the link analog to the
> > NETDEV_CHANGE event if the carrier is UP.
>
> Thanks! This w
On Mon, Nov 23, 2020 at 11:36 AM Jakub Kicinski wrote:
>
> > > From this point of view it will be the best to handle the NETDEV_UP in
> > > the lapb event handler and establish the link analog to the
> > > NETDEV_CHANGE event if the carrier is UP.
> >
> > Thanks! This way we can make sure LAPB wo
On Mon, 23 Nov 2020 03:17:54 -0800 Xie He wrote:
> On Mon, Nov 23, 2020 at 2:38 AM Martin Schiller wrote:
> > Well, one could argue that we would have to repair these drivers, but I
> > don't think that will get us anywhere.
>
> Yeah... One problem I see with the Linux project is the lack of
>
On Mon, Nov 23, 2020 at 2:38 AM Martin Schiller wrote:
>
> Well, one could argue that we would have to repair these drivers, but I
> don't think that will get us anywhere.
Yeah... One problem I see with the Linux project is the lack of
docs/specs. Often we don't know what is right and what is wro
On 2020-11-23 11:08, Xie He wrote:
On Mon, Nov 23, 2020 at 1:36 AM Xie He wrote:
Some drivers don't support carrier status and will never change it.
Their carrier status will always be UP. There will not be a
NETDEV_CHANGE event.
Well, one could argue that we would have to repair these drive
On Mon, Nov 23, 2020 at 1:36 AM Xie He wrote:
>
> Some drivers don't support carrier status and will never change it.
> Their carrier status will always be UP. There will not be a
> NETDEV_CHANGE event.
>
> lapbether doesn't change carrier status. I also have my own virtual
> HDLC WAN driver (for
On Mon, Nov 23, 2020 at 1:00 AM Martin Schiller wrote:
>
> AFAIK the carrier can't be up before the device is up. Therefore, there
> will be a NETDEV_CHANGE event after the NETDEV_UP event.
>
> This is what I can see in my tests (with the HDLC interface).
>
> Is the behaviour different for e.g. la
On 2020-11-23 09:31, Xie He wrote:
On Sun, Nov 22, 2020 at 10:55 PM Martin Schiller wrote:
No, they aren't independent. The carrier can only be up if the device
/
interface is UP. And as far as I can see a NETDEV_CHANGE event will
also
only be generated on interfaces that are UP.
So you ca
On Sun, Nov 22, 2020 at 10:55 PM Martin Schiller wrote:
>
> No, they aren't independent. The carrier can only be up if the device /
> interface is UP. And as far as I can see a NETDEV_CHANGE event will also
> only be generated on interfaces that are UP.
>
> So you can be sure, that if there is a N
On 2020-11-21 00:50, Xie He wrote:
On Fri, Nov 20, 2020 at 3:11 PM Xie He wrote:
Should we also handle the NETDEV_UP event here? In previous versions
of this patch series you seemed to want to establish the L2 connection
on device-up. But in this patch, you didn't handle NETDEV_UP.
Maybe on d
On Fri, Nov 20, 2020 at 3:11 PM Xie He wrote:
>
> Should we also handle the NETDEV_UP event here? In previous versions
> of this patch series you seemed to want to establish the L2 connection
> on device-up. But in this patch, you didn't handle NETDEV_UP.
>
> Maybe on device-up, we need to check i
Should we also handle the NETDEV_UP event here? In previous versions
of this patch series you seemed to want to establish the L2 connection
on device-up. But in this patch, you didn't handle NETDEV_UP.
Maybe on device-up, we need to check if the carrier is up, and if it
is, we do the same thing as
This patch allows layer2 (LAPB) to react to netdev events itself and
avoids the detour via layer3 (X.25).
1. Call lapb_disconnect_request() on NETDEV_GOING_DOWN events.
2. When a NETDEV_DOWN event occur, clear all queues, enter state
LAPB_STATE_0 and stop all timers.
3. The NETDEV_CHANGE even
13 matches
Mail list logo
