From: James Blackburn <fjb31@cam.ac.uk>
To: bridge@lists.osdl.org
Subject: [Bridge] <kernel BUG> generated on bridge up/down & other issues
Date: Mon, 7 Nov 2005 18:07:37 +0000 [thread overview]
Message-ID: <269ECEEB-C04F-45C9-9F16-46ACF4703265@cam.ac.uk> (raw)
Hi,
I've been encountering some problems with bridging under linux
2.6.12-9 (ubuntu Breezy Badger). Apologies for the newbie-ish email:
problem is likely a config issues, but docs appear to be sparse and I
can't find much reference to the problem/solution on the 'net; trial
and error really isn't working...
Am attempting to bridge an offsite network to the central network
over the internet with vtun (2.6-4). The configuration I have works
intermittently. vtun seems to work reliably - am using the -p
(persist) option to force reconnect on disconnect. However I have
the following problems:
1) On system startup vtun connects to the server correctly, but
the bridge does not come up. (my vtund.conf attached)
brctl show - shows the "brookf" bridge, but 'Interfaces' declares:
"can't get port info: Function not implemented"
Restarting vtun with /etc/init.d/vtun restart brings the bridge up
correctly. Why is this? Currently I'm having to restart vtun on
system startup to have it function at all.
2) At the moment if I perform /etc/init.d/vtun restart as often as
not there will be a kernel bug dump to the console. It begins:
<kernel BUG at <bad filename>:21387!
invalid operand: 0000[#1]
... Process brctl
(For some reason it's not being logged to kern.log, but I could
attempt to resolve that and get the whole dump if it would be useful...)
From then on, ifconfig, hangs the console, as does sudo. Also
restart/halt freezes on putting down the interfaces. This means
that, with the persist option (as up/down are called on every connect/
disconnect), the box quickly becomes unusable.
I've read that there may be issues with IPv6 and kernel support.
Although I don't use it, it's enabled by default on this kernel -
should this be disabled?
I presume I'm doing something wrong in the vtund.conf. Should I be
creating and removing the bridge here, or should I create the bridge
once when the system starts up? How would vutn interact with the tap
interface - should I configure it (eg tap0) with IP 0.0.0.0 on
startup, then specify the interface in vtun and change persist yes; -
> persist keep;?
If anyone can give any suggestions, I would be most grateful!
Many thanks,
James
persist yes;
type ether; # Ethernet tunnel
up {
program /usr/sbin/brctl "addbr brookf";
ifconfig "%% 0.0.0.0"; #i.e. first available tap interface
ifconfig "eth1 down";
ifconfig "eth1 promisc";
program /usr/sbin/brctl "addif brookf %d";
program /usr/sbin/brctl "addif brookf eth1";
#Bring the bridge up
ifconfig "eth1 0.0.0.0";
ifconfig "brookf 172.28.22.223 netmask 255.255.255.0";
};
down {
ifconfig "brookf down";
ifconfig "%% down";
ifconfig "eth1 down";
# Clear up bridge stuff
program /usr/sbin/brctl "delif brookf %%";
program /usr/sbin/brctl "delif brookf eth1";
program /usr/sbin/brctl "delbr brookf";
};
next reply other threads:[~2005-11-07 18:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-07 18:07 James Blackburn [this message]
2005-11-07 18:31 ` [Bridge] <kernel BUG> generated on bridge up/down & other issues Stephen Hemminger
2005-11-07 19:45 ` James Blackburn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=269ECEEB-C04F-45C9-9F16-46ACF4703265@cam.ac.uk \
--to=fjb31@cam.ac.uk \
--cc=bridge@lists.osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.