I just added 802.1Q VLAN support to redhat initscripts. And after
support was ready, I tried to restart shorewall. Well it blew into
pieces. Seems like shorewall can''t handle device names like:
eth0.3 very properly. That''s default naming of vlan devices. eth1 is
master device and 3 is id of my test vlan.
So when I added to interfaces line:
home eth0.3 detect
seems like there is quite a much code like this:
eval ${interface}_broadcast="$subnet"
which doesn''t work at all when there is "." in interface
name.
Tom, do you have any idea how to fix this? I''d fix it myself but I
don''t
know shorewall code well enough yet. If you can give me a hint I''ll
check code and try to fix it, but that''s later, now it''s quite
late.
--
Tuomo Soini <tis@foobar.fi>
http://tis.foobar.fi/
--On Monday, January 27, 2003 12:51 AM +0200 Tuomo Soini <tis@foobar.fi> wrote:> > seems like there is quite a much code like this: > > eval ${interface}_broadcast="$subnet" > > which doesn''t work at all when there is "." in interface name. > > Tom, do you have any idea how to fix this? I''d fix it myself but I don''t > know shorewall code well enough yet. If you can give me a hint I''ll check > code and try to fix it, but that''s later, now it''s quite late. >The fix is to back out all of the recent performance improvement changes. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
--On Monday, January 27, 2003 12:51 AM +0200 Tuomo Soini <tis@foobar.fi> wrote:> I just added 802.1Q VLAN support to redhat initscripts. And after support > was ready, I tried to restart shorewall. Well it blew into pieces. Seems > like shorewall can''t handle device names like: > > eth0.3 very properly. That''s default naming of vlan devices. eth1 is > master device and 3 is id of my test vlan. > > So when I added to interfaces line: > > home eth0.3 detect > > seems like there is quite a much code like this: > > eval ${interface}_broadcast="$subnet" > > which doesn''t work at all when there is "." in interface name. > > Tom, do you have any idea how to fix this? I''d fix it myself but I don''t > know shorewall code well enough yet. If you can give me a hint I''ll check > code and try to fix it, but that''s later, now it''s quite late.Attached is a hacked 1.3.14 that works around the problem. Read the comments regarding the INTERFACE column in the attached interfaces file. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Actually Tuomo could just use another way of naming its vlan using the following command: /usr/sbin/vconfig set_name_type VLAN_PLUS_VID_NO_PAD before creating his vlans. then his newly created vlan interfaces will be called vlan2 ... vlanx which is compatible to iptables and therefore to shorewall. Pascal On Sun, 2003-01-26 at 18:11, Tom Eastep wrote:> --On Monday, January 27, 2003 12:51 AM +0200 Tuomo Soini <tis@foobar.fi> > wrote: > > > I just added 802.1Q VLAN support to redhat initscripts. And after support > > was ready, I tried to restart shorewall. Well it blew into pieces. Seems > > like shorewall can''t handle device names like: > > > > eth0.3 very properly. That''s default naming of vlan devices. eth1 is > > master device and 3 is id of my test vlan. > > > > So when I added to interfaces line: > > > > home eth0.3 detect > > > > seems like there is quite a much code like this: > > > > eval ${interface}_broadcast="$subnet" > > > > which doesn''t work at all when there is "." in interface name. > > > > Tom, do you have any idea how to fix this? I''d fix it myself but I don''t > > know shorewall code well enough yet. If you can give me a hint I''ll check > > code and try to fix it, but that''s later, now it''s quite late. > > Attached is a hacked 1.3.14 that works around the problem. > > Read the comments regarding the INTERFACE column in the attached interfaces > file. > > -Tom > -- > Tom Eastep \ Shorewall - iptables made easy > Shoreline, \ http://www.shorewall.net > Washington USA \ teastep@shorewall.net > > ______________________________________________________________________ > > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.shorewall.net > http://lists.shorewall.net/mailman/listinfo/shorewall-devel
--On Sunday, January 26, 2003 7:50 PM -0800 Pascal DeMilly <mailing-lists@newgenesys.com> wrote:> Actually Tuomo could just use another way of naming its vlan using the > following command: > > /usr/sbin/vconfig set_name_type VLAN_PLUS_VID_NO_PAD before creating his > vlans. > > then his newly created vlan interfaces will be called vlan2 ... vlanx > which is compatible to iptables and therefore to shorewall. >He feels that there are some restrictions inherent in using that option. He described them in a private post so I won''t forward his comments on to the list. As I announced a bit ago, the firewall script in the CVS development thread corrects the problem even when using the ethn.m naming convention. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
--On Sunday, January 26, 2003 7:50 PM -0800 Pascal DeMilly <mailing-lists@newgenesys.com> wrote:> > then his newly created vlan interfaces will be called vlan2 ... vlanx > which is compatible to iptables and therefore to shorewall. >Recent versions of iptables are quite tolerant of the VLAN naming convention: [root@gateway root]# iptables -N foo.1 [root@gateway root]# iptables -A foo.1 -i foo.1 -j ACCEPT [root@gateway root]# Shorewall was similarly tolerant until 1.3.12 when I implemented the performance enhancements. I broke full VLAN compatibility in that release. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> He feels that there are some restrictions inherent in using that option. > He described them in a private post so I won''t forward his comments on > to the list.Better say it here too. If vlan names in format vlan$VID is used, it limits system for one interface only with one vlanid. So if we have a router. Better not to have such limitations. That''s my inspiration on generating VLAN id support using $DEV.$VID format. This is not very usual thing, but because I want that support into next redhat (submitted changes via redhat bugzilla allready). I didn''t want those limitations.> As I announced a bit ago, the firewall script in the CVS development > thread corrects the problem even when using the ethn.m naming convention.Tom: You are way better shell programmer than I am. Your fix is clever. I had something silmilar in my mind after I wrote last mail yesterday, but I was too tired to check all shorewall code if that kind of change would have broke all. Tom: Could you change these mailinglists so that they have Reply-To: to mailinglist? -- Tuomo Soini <tis@foobar.fi> http://tis.foobar.fi/
--On Monday, January 27, 2003 10:19 AM +0200 Tuomo Soini <tis@foobar.fi> wrote:> Your fix is clever. I > had something silmilar in my mind after I wrote last mail yesterday, but > I was too tired to check all shorewall code if that kind of change would > have broke all.It is just taking advantage of the code that was already there for handling "+" in interface names. I feel stupid that I didn''t think of it originally before spending a couple of hours on the horrible hack that preceded it :-)> > Tom: Could you change these mailinglists so that they have Reply-To: to > mailinglist? >I could but I will not. From the Mailman documentation: There are many reasons not to introduce or override the Reply-To: header. One is that some posters depend on their own Reply-To: settings to convey their valid return address. Another is that modifying Reply-To: makes it much more difficult to send private replies. Here are a couple of URLs to discussions of this topic: Con: http://www.unicom.com/pw/reply-to-harmful.html Pro: http://www.metasystema.org/essays/reply-to-useful.mhtml I know for a fact that there are subscribers on at least two of the lists that depend on their own Reply-To header. If you are asking me to do this so that you avoid receiving duplicate replies, then go to the list page and update your options to select "Avoid duplicate copies of messages?"; it is the last option on the page. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net