Guys,
Id like to work a bit on this issue in my free time, I have 2 weeks
holiday
after Xmass.
First an update on lagg for the case you boot with wired coupled:
1. I previously said lagg0 switches correctly when I unplug the wired
interface, but it is not so. It appeared so because I used
Hi!
On 20 December 2013 01:52, dan_partelly dan_parte...@rdsor.ro wrote:
Guys,
Id like to work a bit on this issue in my free time, I have 2 weeks
holiday
after Xmass.
First an update on lagg for the case you boot with wired coupled:
1. I previously said lagg0 switches correctly when I
Hi all,
I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as
described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop.
What happens is:
If I boot the system with the Ethernet cable attached, I correctly get
lagg0 active port on master- bg0- and the network is working
On 12/17/13 08:06, dan_partelly wrote:
Hi all,
I've set up wireless link aggregation on FreeBSD 10 RC1 and RC2 as
described in the FreeBSD handbook, on an oldish Compaq nc6320 laptop.
What happens is:
If I boot the system with the Ethernet cable attached, I correctly get
lagg0
Hi,
The MAC of the lagg needs to be the same as the wireless interface.
I'm going to just state right now that using lagg as the failover
method for doing wireless/wired integration isn't supported by me. If
someone wants to make it supported then they need to claim it. :)
-a
On 17 December
On 12/17/13 10:54, Adrian Chadd wrote:
Hi,
The MAC of the lagg needs to be the same as the wireless interface.
I'm going to just state right now that using lagg as the failover
method for doing wireless/wired integration isn't supported by me. If
someone wants to make it supported then
On Tue, 17 Dec 2013 07:54:52 -0800, Adrian Chadd adr...@freebsd.org
wrote:
Hi,
All 3 MACs are the same. wpi0 is set to the MAC of bg0. Wlan0 inherits the
MAC of
wpi0. Lagg0 is set up to the MAC of master. So everything checks out. All
are the same.
I have to check if the systems sends packets
On 12/17/13 10:54, Adrian Chadd wrote:
Hi,
The MAC of the lagg needs to be the same as the wireless interface.
I'm going to just state right now that using lagg as the failover
method for doing wireless/wired integration isn't supported by me. If
someone wants to make it supported then
I'm the wireless stack maintainer and I currently don't support that.
Sorry.
-a
On 17 December 2013 08:10, dan_partelly dan_parte...@rdsor.ro wrote:
On Tue, 17 Dec 2013 07:54:52 -0800, Adrian Chadd adr...@freebsd.org
wrote:
Hi,
All 3 MACs are the same. wpi0 is set to the MAC of bg0.
On 17 December 2013 08:12, Nikolai Lifanov lifa...@mail.lifanov.com wrote:
Also, this method is still described in the handbook:
https://www.freebsd.org/doc/handbook/network-aggregation.html#networking-lagg-wired-and-wireless
If this isn't supposed to work, then the handbook needs to be
No problem. Can you point me to the relevant source files in the
kernel tree, please ?
Dan
On Tue, 17 Dec 2013 08:43:09 -0800, Adrian Chadd adr...@freebsd.org
wrote:
I'm the wireless stack maintainer and I currently don't support that.
Sorry.
-a
On 17 December 2013 08:10,
On 2013-12-17 10:54, Adrian Chadd wrote:
Hi,
The MAC of the lagg needs to be the same as the wireless interface.
I'm going to just state right now that using lagg as the failover
method for doing wireless/wired integration isn't supported by me. If
someone wants to make it supported then
On 12/17/13 12:34, Allan Jude wrote:
On 2013-12-17 10:54, Adrian Chadd wrote:
Hi,
The MAC of the lagg needs to be the same as the wireless interface.
I'm going to just state right now that using lagg as the failover
method for doing wireless/wired integration isn't supported by me. If
Yes, this is correct. A simple list of the interfaces with ifconfig
makes the system recover and restart activity on the secondary port.
Its a good starting point to hunt down the problem. One of the ioctls sent
has this side effect.
Dan
If I am am understanding correctly, Dan and Nikolai
Ive no idea sorry. Its likely an ifnet change and not anything WiFi
specific. :(
On Dec 17, 2013 12:04 PM, dan_partelly dan_parte...@rdsor.ro wrote:
Yes, this is correct. A simple list of the interfaces with ifconfig
makes the system recover and restart activity on the secondary port.
Its a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/17/13 09:34, Allan Jude wrote:
If I am am understanding correctly, Dan and Nikolai say that just
running 'ifconfig' brings the lagg back to life. Why would that
make a difference at all? Running ifconfig with no parameters
shouldn't be
Hi,
On Tue, 17 Dec 2013 17:02:03 -0800
Xin Li delp...@delphij.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/17/13 09:34, Allan Jude wrote:
If I am am understanding correctly, Dan and Nikolai say that just
running 'ifconfig' brings the lagg back to life. Why would
What claims you do not believe ? Not important anyway. This is
engineering, so you need not believe, you need to know. Go and replicate
the bug. You will know then.
I don't really believe these claim.
I had similar issue in the past and found an 'arp -a -d' would fix
it so I didn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12/17/13, 11:28 PM, dan_partelly wrote:
What claims you do not believe ? Not important anyway. This is
engineering, so you need not believe, you need to know. Go and
replicate the bug. You will know then.
I don't believe in merely doing
I guarantee you that a simple interface list with ifconfig un-stucks the
net on my setup, at lest in the case (master is wired, unplug ethernet,
fail to wireless) I agree that it doesn't makes much sense, but no matter
how unlikely it seems, it is a **fact**.
I don't believe in merely
20 matches
Mail list logo
