Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
VLAN config on Jessie
585 views
Skip to first unread message
Andrew Wood
Jul 30, 2015, 5:10:06 PM7/30/15
to
Can I please clarify the correct way to configure VLANS on Jessie as Im
having problems with DHCPD giving out IP addresses for the wrong VLAN
subnet but only for certain clients - Windows 7, & Apple iOS whereas
Debian clients and Windows XP clients are working fine.
Ive got a Jessie machine acting as a router with eth0 being the WAN
connection to the internet and eth1 being the LAN connection with 2
VLANS on it (VLAN1 has addresses 192.168.10.x and VLAN2 192.168.100.x)
If I assign addresses statically on the clients its all fine but on Wifi
via DHCP the Wifi AP is set to map two separate SSIDs to the two VLANS
and in such cases the clients use DHCP.
As I say, if a Debian or Windows XP client connects via wifi it works
fine but if a Windows 7 client connects to VLAN2s SSID DHCPD is giving
it an IP on VLAN1 and then nothing works.
This is the /etc/network/interfaces file:
auto eth0
iface eth0 inet dhcp
#LAN (MZ)
auto eth1
iface eth1 inet static
address 192.168.10.254
broadcast 192.168.10.255
netmask 255.255.255.0
up /etc/network/if-up.d/iptables
auto eth1.2
iface eth1.2 inet static
address 192.168.100.254
netmask 255.255.255.0
vlan-raw-device eth1
I want vlan 1 to be the default hence I decared it as eth1 not eth1.1
however I did try that and it reversed the problem - vlan1 gets vlan2 ip
addresses!
Whats the correct way to do this please?
Thanks
Andrew
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/55BA8C6D...@comms.org.uk
having problems with DHCPD giving out IP addresses for the wrong VLAN
subnet but only for certain clients - Windows 7, & Apple iOS whereas
Debian clients and Windows XP clients are working fine.
Ive got a Jessie machine acting as a router with eth0 being the WAN
connection to the internet and eth1 being the LAN connection with 2
VLANS on it (VLAN1 has addresses 192.168.10.x and VLAN2 192.168.100.x)
If I assign addresses statically on the clients its all fine but on Wifi
via DHCP the Wifi AP is set to map two separate SSIDs to the two VLANS
and in such cases the clients use DHCP.
As I say, if a Debian or Windows XP client connects via wifi it works
fine but if a Windows 7 client connects to VLAN2s SSID DHCPD is giving
it an IP on VLAN1 and then nothing works.
This is the /etc/network/interfaces file:
auto eth0
iface eth0 inet dhcp
#LAN (MZ)
auto eth1
iface eth1 inet static
address 192.168.10.254
broadcast 192.168.10.255
netmask 255.255.255.0
up /etc/network/if-up.d/iptables
auto eth1.2
iface eth1.2 inet static
address 192.168.100.254
netmask 255.255.255.0
vlan-raw-device eth1
I want vlan 1 to be the default hence I decared it as eth1 not eth1.1
however I did try that and it reversed the problem - vlan1 gets vlan2 ip
addresses!
Whats the correct way to do this please?
Thanks
Andrew
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/55BA8C6D...@comms.org.uk
Matt Ventura
Jul 30, 2015, 5:40:04 PM7/30/15
to
Matt Ventura
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Arno Schuring
Jul 30, 2015, 6:20:05 PM7/30/15
to
> Date: Thu, 30 Jul 2015 21:43:25 +0100
> From: aw...@comms.org.uk
>
> Ive got a Jessie machine acting as a router with eth0 being the WAN
> connection to the internet and eth1 being the LAN connection with 2
> VLANS on it (VLAN1 has addresses 192.168.10.x and VLAN2 192.168.100.x)
> From: aw...@comms.org.uk
>
> Ive got a Jessie machine acting as a router with eth0 being the WAN
> connection to the internet and eth1 being the LAN connection with 2
> VLANS on it (VLAN1 has addresses 192.168.10.x and VLAN2 192.168.100.x)
Your /e/n/interfaces does not match that description...
> auto eth1
> iface eth1 inet static
> address 192.168.10.254
> broadcast 192.168.10.255
> netmask 255.255.255.0
> up /etc/network/if-up.d/iptables
This configures an untagged connection, which is not the same as vlan 1.
Also, there's no need to set that broadcast address manually, it's inferred
from the netmask.
> auto eth1.2
> iface eth1.2 inet static
> address 192.168.100.254
> netmask 255.255.255.0
> vlan-raw-device eth1
>
>
> I want vlan 1 to be the default hence I decared it as eth1 not eth1.1
That is most likely wrong. You set a "default interface" by configuring
the default gateway with the lowest metric. Other than that, there's no
"default" between network interfaces.
> Whats the correct way to do this please?
I would expect you only configure eth1.1 and eth1.2, and leave eth1
itself unconfigured. Or perhaps, if that configuration confuses
ifupdown:
iface eth1 inet manual
up ip link set eth1 up
Regards,
Arno
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/DUB130-W4309EA24D...@phx.gbl
Andrew Wood
Jul 31, 2015, 3:50:06 PM7/31/15
to
On 30/07/15 22:34, Matt Ventura wrote:
> Could you post the DHCPD config?
>
max-lease-time 7200;
option web-proxy code 252 = text;
#Subnet 192.168.10.d our private network
#As a convention we're using d values 1 to 199 for DHCP (192.168.10.1
etc), 200
and above for static
subnet 192.168.10.0 netmask 255.255.255.0{
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.10.255;
option routers 192.168.10.254;
range 192.168.10.1 192.168.10.199;
option domain-name-servers 192.168.10.254;
#option web-proxy "http://192.168.10.254/wpad.dat\000";
option domain-name "commsmuseum.local";
#option ntp-servers 192.168.10.200;
}
#Subnet 192.168.100.0 the public (wifi) network
subnet 192.168.100.0 netmask 255.255.255.0{
option subnet-mask 255.255.255.0;
option routers 192.168.100.254;
range 192.168.100.1 192.168.100.253;
option domain-name-servers 192.168.100.254;
#option web-proxy "http://192.168.100.254/wpad.dat\000";
option domain-name "commsmuseumpublic.local";
on release {
set clip = binary-to-ascii(10, 8, ".", leased-address);
set clhw = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
execute("/var/publicwifisessions/clearsession.sh", clip);
execute("/var/publicwifisessions/logdhcp.sh", clip, clhw, "released");
}
on expiry {
set clip = binary-to-ascii(10, 8, ".", leased-address);
set clhw = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
execute("/var/publicwifisessions/clearsession.sh", clip);
execute("/var/publicwifisessions/logdhcp.sh", clip, clhw, "released");
}
on commit {
set clip = binary-to-ascii(10, 8, ".", leased-address);
set clhw = binary-to-ascii(16, 8, ":", substring(hardware, 1, 6));
execute("/var/publicwifisessions/clearsession.sh", clip);
execute("/var/publicwifisessions/logdhcp.sh", clip, clhw, "assigned");
}
}
class "MSFT" {
match if substring(option vendor-class-identifier, 0, 4) = "MSFT";
# Send PAC file to Windows clients
# They put 252 on the DHCPINFORM's, but not on the DHCPREQUEST's
# PRL. So we over-ride the PRL to include 252 = 0xFC, which will
# send the option at DHCPDISCOVER/DHCPREQUEST time, and wil also
# suppress the DHCPINFORMS! They seem to cache it.
option dhcp-parameter-request-list = concat(option
dhcp-parameter-request-list, fc);
}
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/55BBCF44...@perpetualmotion.co.uk
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrew Wood
Aug 1, 2015, 4:40:04 AM8/1/15
to
On 30/07/15 23:14, Arno Schuring wrote:
> This configures an untagged connection, which is not the same as vlan
> 1. Also, there's no need to set that broadcast address manually, it's
> inferred from the netmask.
>> auto eth1.2
>> iface eth1.2 inet static
>> address 192.168.100.254
>> netmask 255.255.255.0
>> vlan-raw-device eth1
>>
>>
>> I want vlan 1 to be the default hence I decared it as eth1 not eth1.1
> That is most likely wrong. You set a "default interface" by configuring
> the default gateway with the lowest metric. Other than that, there's no
> "default" between network interfaces.
>
>
handle ethernet frames with no vlan tag arriving on eth1
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Matt Ventura
Aug 1, 2015, 8:40:08 PM8/1/15
to
On 8/1/2015 1:30 AM, Andrew Wood wrote:
>
>
> On 30/07/15 23:14, Arno Schuring wrote:
>> This configures an untagged connection, which is not the same as vlan
>> 1. Also, there's no need to set that broadcast address manually, it's
>> inferred from the netmask.
>>> auto eth1.2
>>> iface eth1.2 inet static
>>> address 192.168.100.254
>>> netmask 255.255.255.0
>>> vlan-raw-device eth1
>>>
>>>
>>> I want vlan 1 to be the default hence I decared it as eth1 not eth1.1
>> That is most likely wrong. You set a "default interface" by configuring
>> the default gateway with the lowest metric. Other than that, there's no
>> "default" between network interfaces.
>>
>>
> Im not talking about the default route Im talking about how it should
> handle ethernet frames with no vlan tag arriving on eth1
>
>
untagged frames on the same port is far from best practices. You either
want to have a port be an untagged member of a single vlan, or a tagged
member of one or more vlans. It's hard to tell at this point if that's
what's actually causing the problem or if that's unrelated.
Matt Ventura
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bonno Bloksma
Aug 3, 2015, 9:50:05 AM8/3/15
to
Hi,
>> On 30/07/15 23:14, Arno Schuring wrote:
>>> This configures an untagged connection, which is not the same as vlan
>>> 1. Also, there's no need to set that broadcast address manually, it's
>>> inferred from the netmask.
>>>> auto eth1.2
>>>> iface eth1.2 inet static
>>>> address 192.168.100.254
>>>> netmask 255.255.255.0
>>>> vlan-raw-device eth1
>>>>
>>>>
>>>> I want vlan 1 to be the default hence I decared it as eth1 not
>>>> eth1.1
>>> That is most likely wrong. You set a "default interface" by
>>> configuring the default gateway with the lowest metric. Other than
>>> that, there's no "default" between network interfaces.
>>>
>>>
>> Im not talking about the default route Im talking about how it should
>> handle ethernet frames with no vlan tag arriving on eth1
>>
I have a similar setup but.... the untagged network is the management network for the APs. All traffic on the WiFi network is done in VLANS. That is how I have it setup.
So in that case you should have 3 definitions on eth1 (assuming traffic for the clients is using VLAN 10 and 11)
auto eth1 eth1.10 eth1.11
iface eth1 inet static
address .....
etc
iface eth1.10 inet static
address .....
etc
iface eth1.11 inet static
address .....
etc
This should also prevent any miscommunication when clients are part of the management network.
The "management network" does not NEED to be a separate network. In my case I combine it with another network which has restricted access.
Also be aware that I have found VLAN aware routing on a Debian machine to be slower then straight interface routing. However, my last test was on an old Lenny system so that might have been improved.
Bonno Bloksma
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/89D1798A7351D040B4E7...@EinExch-01.tio.nl
>> On 30/07/15 23:14, Arno Schuring wrote:
>>> This configures an untagged connection, which is not the same as vlan
>>> 1. Also, there's no need to set that broadcast address manually, it's
>>> inferred from the netmask.
>>>> auto eth1.2
>>>> iface eth1.2 inet static
>>>> address 192.168.100.254
>>>> netmask 255.255.255.0
>>>> vlan-raw-device eth1
>>>>
>>>>
>>>> I want vlan 1 to be the default hence I decared it as eth1 not
>>>> eth1.1
>>> That is most likely wrong. You set a "default interface" by
>>> configuring the default gateway with the lowest metric. Other than
>>> that, there's no "default" between network interfaces.
>>>
>>>
>> Im not talking about the default route Im talking about how it should
>> handle ethernet frames with no vlan tag arriving on eth1
>>
So in that case you should have 3 definitions on eth1 (assuming traffic for the clients is using VLAN 10 and 11)
auto eth1 eth1.10 eth1.11
iface eth1 inet static
address .....
etc
iface eth1.10 inet static
address .....
etc
iface eth1.11 inet static
address .....
etc
This should also prevent any miscommunication when clients are part of the management network.
The "management network" does not NEED to be a separate network. In my case I combine it with another network which has restricted access.
Also be aware that I have found VLAN aware routing on a Debian machine to be slower then straight interface routing. However, my last test was on an old Lenny system so that might have been improved.
Bonno Bloksma
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrew Wood
Aug 3, 2015, 4:40:05 PM8/3/15
to
On 03/08/15 14:44, Bonno Bloksma wrote:
> I have a similar setup but.... the untagged network is the management network for the APs. All traffic on the WiFi network is done in VLANS. That is how I have it setup.
> So in that case you should have 3 definitions on eth1 (assuming traffic for the clients is using VLAN 10 and 11)
> auto eth1 eth1.10 eth1.11
> iface eth1 inet static
> address .....
> etc
> iface eth1.10 inet static
> address .....
> etc
> iface eth1.11 inet static
> address .....
> etc
>
> This should also prevent any miscommunication when clients are part of the management network.
> The "management network" does not NEED to be a separate network. In my case I combine it with another network which has restricted access.
>
> Also be aware that I have found VLAN aware routing on a Debian machine to be slower then straight interface routing. However, my last test was on an old Lenny system so that might have been improved.
>
> Bonno Bloksma
>
>
>
So eth1 needs its own IP separate from eth1.1 and eth1.2? Can this be on
> I have a similar setup but.... the untagged network is the management network for the APs. All traffic on the WiFi network is done in VLANS. That is how I have it setup.
> So in that case you should have 3 definitions on eth1 (assuming traffic for the clients is using VLAN 10 and 11)
> auto eth1 eth1.10 eth1.11
> iface eth1 inet static
> address .....
> etc
> iface eth1.10 inet static
> address .....
> etc
> iface eth1.11 inet static
> address .....
> etc
>
> This should also prevent any miscommunication when clients are part of the management network.
> The "management network" does not NEED to be a separate network. In my case I combine it with another network which has restricted access.
>
> Also be aware that I have found VLAN aware routing on a Debian machine to be slower then straight interface routing. However, my last test was on an old Lenny system so that might have been improved.
>
> Bonno Bloksma
>
>
>
the same subnet as eth1.1 or not?
eth1 (as opposed to eth1.1 and 1.2) isnt really 'used' so to speak so it
would just be a dummy IP.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Bonno Bloksma
Aug 4, 2015, 2:20:04 AM8/4/15
to
Hello Andrew,
> On 03/08/15 14:44, Bonno Bloksma wrote:
>> I have a similar setup but.... the untagged network is the management network for the APs. All traffic on the WiFi network is done in VLANS. That is how I have it setup.
>> So in that case you should have 3 definitions on eth1 (assuming
>> traffic for the clients is using VLAN 10 and 11)
>> auto eth1 eth1.10 eth1.11
>> iface eth1 inet static
>> address .....
>> etc
>> iface eth1.10 inet static
>> address .....
>> etc
>> iface eth1.11 inet static
>> address .....
>> etc
>
So in this case one could use (and I hope this time it does NOT reformat)
broadcast 192.168.1.255
netmask 255.255.255.0
up /etc/network/if-up.d/iptables
iface eth1.10 inet static
address 192.168.10.0
broadcast 192.168.10.255
netmask 255.255.255.0
iface eth1.11 inet static
address 192.168.11.0
broadcast 192.168.11.255
netmask 255.255.255.0
If you have the option, as in this case, it might make sense to use the same number for the VLAN and for the address range. It does not NEED to be so, and most cases it will not be so. But if it is a simple situation like this, one can take advantage of it.
Remember to set the VLANs correctly on the ports to the Debian router / firewall / dhcp server and on the ports to the WiFi APs. In this case untagged VLAN 1, tagged VLAN 10 and 11.
Bonno Bloksma
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/89D1798A7351D040B4E7...@EinExch-01.tio.nl
> On 03/08/15 14:44, Bonno Bloksma wrote:
>> I have a similar setup but.... the untagged network is the management network for the APs. All traffic on the WiFi network is done in VLANS. That is how I have it setup.
>> So in that case you should have 3 definitions on eth1 (assuming
>> traffic for the clients is using VLAN 10 and 11)
>> auto eth1 eth1.10 eth1.11
>> iface eth1 inet static
>> address .....
>> etc
>> iface eth1.10 inet static
>> address .....
>> etc
>> iface eth1.11 inet static
>> address .....
>> etc
>
> So eth1 needs its own IP separate from eth1.1 and eth1.2? Can this be on the same subnet as eth1.1 or not?
> eth1 (as opposed to eth1.1 and 1.2) isnt really 'used' so to speak so it would just be a dummy IP.
When you use VLANS essentialy what you are doing is creating different networks. So all should have their own ip address range. If not you get problems when you want to connect them via a router which would then see the same ip range on different networks and would be unable to route.
> eth1 (as opposed to eth1.1 and 1.2) isnt really 'used' so to speak so it would just be a dummy IP.
So in this case one could use (and I hope this time it does NOT reformat)
auto eth1 eth1.10 eth1.11
iface eth1 inet static
address 192.168.1.0
iface eth1 inet static
broadcast 192.168.1.255
netmask 255.255.255.0
up /etc/network/if-up.d/iptables
iface eth1.10 inet static
address 192.168.10.0
broadcast 192.168.10.255
netmask 255.255.255.0
iface eth1.11 inet static
address 192.168.11.0
broadcast 192.168.11.255
netmask 255.255.255.0
If you have the option, as in this case, it might make sense to use the same number for the VLAN and for the address range. It does not NEED to be so, and most cases it will not be so. But if it is a simple situation like this, one can take advantage of it.
Remember to set the VLANs correctly on the ports to the Debian router / firewall / dhcp server and on the ports to the WiFi APs. In this case untagged VLAN 1, tagged VLAN 10 and 11.
Bonno Bloksma
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrew Wood
Aug 6, 2015, 4:00:04 PM8/6/15
to
On 04/08/15 07:11, Bonno Bloksma wrote:
> Hello Andrew,
>
> When you use VLANS essentialy what you are doing is creating different networks. So all should have their own ip address range. If not you get problems when you want to connect them via a router which would then see the same ip range on different networks and would be unable to route.
>
> So in this case one could use (and I hope this time it does NOT reformat)
> auto eth1 eth1.10 eth1.11
> iface eth1 inet static
> address 192.168.1.0
> broadcast 192.168.1.255
> netmask 255.255.255.0
> up /etc/network/if-up.d/iptables
> iface eth1.10 inet static
> address 192.168.10.0
> broadcast 192.168.10.255
> netmask 255.255.255.0
> iface eth1.11 inet static
> address 192.168.11.0
> broadcast 192.168.11.255
> netmask 255.255.255.0
>
> If you have the option, as in this case, it might make sense to use the same number for the VLAN and for the address range. It does not NEED to be so, and most cases it will not be so. But if it is a simple situation like this, one can take advantage of it.
> Remember to set the VLANs correctly on the ports to the Debian router / firewall / dhcp server and on the ports to the WiFi APs. In this case untagged VLAN 1, tagged VLAN 10 and 11.
>
>
> Bonno Bloksma
>
>
Great thanks Bonno
> When you use VLANS essentialy what you are doing is creating different networks. So all should have their own ip address range. If not you get problems when you want to connect them via a router which would then see the same ip range on different networks and would be unable to route.
>
> So in this case one could use (and I hope this time it does NOT reformat)
> auto eth1 eth1.10 eth1.11
> iface eth1 inet static
> address 192.168.1.0
> broadcast 192.168.1.255
> netmask 255.255.255.0
> up /etc/network/if-up.d/iptables
> iface eth1.10 inet static
> address 192.168.10.0
> broadcast 192.168.10.255
> netmask 255.255.255.0
> iface eth1.11 inet static
> address 192.168.11.0
> broadcast 192.168.11.255
> netmask 255.255.255.0
>
> If you have the option, as in this case, it might make sense to use the same number for the VLAN and for the address range. It does not NEED to be so, and most cases it will not be so. But if it is a simple situation like this, one can take advantage of it.
> Remember to set the VLANs correctly on the ports to the Debian router / firewall / dhcp server and on the ports to the WiFi APs. In this case untagged VLAN 1, tagged VLAN 10 and 11.
>
>
> Bonno Bloksma
>
>
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrew Wood
Aug 7, 2015, 2:50:04 PM8/7/15
to
>
> On 04/08/15 07:11, Bonno Bloksma wrote:
>>
>>
>> If you have the option, as in this case, it might make sense to use
>> the same number for the VLAN and for the address range. It does not
>> NEED to be so, and most cases it will not be so. But if it is a
>> simple situation like this, one can take advantage of it.
>> Remember to set the VLANs correctly on the ports to the Debian router
>> / firewall / dhcp server and on the ports to the WiFi APs. In this
>> case untagged VLAN 1, tagged VLAN 10 and 11.
>>
>>
>> Bonno Bloksma
>
>
The annoying thing is Ive got an almost identical system working on
Wheezy no problems, something has changed in Jessie.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Brian
Aug 7, 2015, 3:00:04 PM8/7/15
to
On Fri 07 Aug 2015 at 19:46:09 +0100, Andrew Wood wrote:
>
>
> >
> >On 04/08/15 07:11, Bonno Bloksma wrote:
> >>
> >>
> >>If you have the option, as in this case, it might make sense to use the
> >>same number for the VLAN and for the address range. It does not NEED to
> >>be so, and most cases it will not be so. But if it is a simple situation
> >>like this, one can take advantage of it.
> >>Remember to set the VLANs correctly on the ports to the Debian router /
> >>firewall / dhcp server and on the ports to the WiFi APs. In this case
> >>untagged VLAN 1, tagged VLAN 10 and 11.
> >>
> >>
> >>Bonno Bloksma
> >
> >
> I think avahi is causing some problems how do I disable it completely?
apt-get purge avahi-daemon
>
>
> >
> >On 04/08/15 07:11, Bonno Bloksma wrote:
> >>
> >>
> >>If you have the option, as in this case, it might make sense to use the
> >>same number for the VLAN and for the address range. It does not NEED to
> >>be so, and most cases it will not be so. But if it is a simple situation
> >>like this, one can take advantage of it.
> >>Remember to set the VLANs correctly on the ports to the Debian router /
> >>firewall / dhcp server and on the ports to the WiFi APs. In this case
> >>untagged VLAN 1, tagged VLAN 10 and 11.
> >>
> >>
> >>Bonno Bloksma
> >
> >
> I think avahi is causing some problems how do I disable it completely?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrew Wood
Aug 7, 2015, 3:10:04 PM8/7/15
to
On 07/08/15 19:49, Brian wrote:
> apt-get purge avahi-daemon
That wants to remove all of Gnone too. Im starting to think this is
related to systemd and that Id be better going back to Wheezy. Things
are not behaving as expected.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Brian
Aug 7, 2015, 3:10:04 PM8/7/15
to
On Fri 07 Aug 2015 at 20:00:33 +0100, Andrew Wood wrote:
>
>
> On 07/08/15 19:49, Brian wrote:
> >apt-get purge avahi-daemon
> That wants to remove all of Gnone too. Im starting to think this is related
> to systemd and that Id be better going back to Wheezy. Things are not
> behaving as expected.
Oh dear!
>
>
> On 07/08/15 19:49, Brian wrote:
> >apt-get purge avahi-daemon
> That wants to remove all of Gnone too. Im starting to think this is related
> to systemd and that Id be better going back to Wheezy. Things are not
> behaving as expected.
For a gentler approach
systemctl stop avahi-daemon avahi-socket
Maybe
systemctl disable avahi-daemon avahi-socket
before this.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mart van de Wege
Aug 7, 2015, 4:30:06 PM8/7/15
to
Andrew Wood <and...@perpetualmotion.co.uk> writes:
>>
>> On 04/08/15 07:11, Bonno Bloksma wrote:
>>>
>>>
>>> If you have the option, as in this case, it might make sense to use
>>> the same number for the VLAN and for the address range. It does not
>>> NEED to be so, and most cases it will not be so. But if it is a
>>> simple situation like this, one can take advantage of it.
>>> Remember to set the VLANs correctly on the ports to the Debian
>>> router / firewall / dhcp server and on the ports to the WiFi
>>> APs. In this case untagged VLAN 1, tagged VLAN 10 and 11.
>>>
>>>
>>> Bonno Bloksma
>>
>>
> I think avahi is causing some problems how do I disable it completely?
Why do you think that? Avahi does multicast DNS, which, as far as I
>>
>> On 04/08/15 07:11, Bonno Bloksma wrote:
>>>
>>>
>>> If you have the option, as in this case, it might make sense to use
>>> the same number for the VLAN and for the address range. It does not
>>> NEED to be so, and most cases it will not be so. But if it is a
>>> simple situation like this, one can take advantage of it.
>>> Remember to set the VLANs correctly on the ports to the Debian
>>> router / firewall / dhcp server and on the ports to the WiFi
>>> APs. In this case untagged VLAN 1, tagged VLAN 10 and 11.
>>>
>>>
>>> Bonno Bloksma
>>
>>
> I think avahi is causing some problems how do I disable it completely?
know, has nothing to do with VLANs.
So what makes you think Avahi is the culprit?
That said, if you want to disable it completely:
systemctl stop avahi-daemon.service
systemctl disable avahi-daemon.service
systemctl stop avahi-daemon.socket
systemctl disable avahi-daemon.socket
Then edit /etc/nsswitch.conf and remove all references to mdns4
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrew Wood
Aug 8, 2015, 2:10:05 PM8/8/15
to
On 07/08/15 21:03, Mart van de Wege wrote:
>
> Why do you think that? Avahi does multicast DNS, which, as far as I
> know, has nothing to do with VLANs.
>
> So what makes you think Avahi is the culprit?
>
> That said, if you want to disable it completely:
>
> systemctl stop avahi-daemon.service
> systemctl disable avahi-daemon.service
>
> systemctl stop avahi-daemon.socket
> systemctl disable avahi-daemon.socket
>
> Then edit /etc/nsswitch.conf and remove all references to mdns4
>
> Mart
>
eth1.1 and eth1.2 and there are entries like this in syslog:
avahi-daemon[687]: Withdrawing address record for 192.168.10.254 on eth1.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: Leaving mDNS multicast
group on interface eth1.IPv4 with address 192.168.10.254.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: Interface eth1.IPv4 no
longer relevant for mDNS.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: Joining mDNS multicast
group on interface eth1.IPv4 with address 192.168.10.254.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: New relevant interface
eth1.IPv4 for mDNS.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: Registering new address
record for 192.168.10.254 on eth1.IPv4.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: Withdrawing address record
for 192.168.10.254 on eth1.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: Leaving mDNS multicast
group on interface eth1.IPv4 with address 192.168.10.254.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: Interface eth1.IPv4 no
longer relevant for mDNS.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: Joining mDNS multicast
group on interface eth1.IPv4 with address 192.168.10.254.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: New relevant interface
eth1.IPv4 for mDNS.
Aug 7 19:34:09 sentrybox avahi-daemon[687]: Registering new address
record for 192.168.10.254 on eth1.IPv4.
It seems that the old settings are persisted somewhere and I suspect
either avahi or systemd.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mart van de Wege
Aug 8, 2015, 4:40:05 PM8/8/15
to
Andrew Wood <and...@perpetualmotion.co.uk> writes:
> On 07/08/15 21:03, Mart van de Wege wrote:
>>
>> Why do you think that? Avahi does multicast DNS, which, as far as I
>> know, has nothing to do with VLANs.
>>
>> So what makes you think Avahi is the culprit?
>>
>> That said, if you want to disable it completely:
>>
>> systemctl stop avahi-daemon.service
>> systemctl disable avahi-daemon.service
>>
>> systemctl stop avahi-daemon.socket
>> systemctl disable avahi-daemon.socket
>>
>> Then edit /etc/nsswitch.conf and remove all references to mdns4
>>
>> Mart
>>
> Because even with nothing in /etc/network/interfaces dhcpd is seeing
> eth1.1 and eth1.2 and there are entries like this in syslog:
>
<snip logging>
> On 07/08/15 21:03, Mart van de Wege wrote:
>>
>> Why do you think that? Avahi does multicast DNS, which, as far as I
>> know, has nothing to do with VLANs.
>>
>> So what makes you think Avahi is the culprit?
>>
>> That said, if you want to disable it completely:
>>
>> systemctl stop avahi-daemon.service
>> systemctl disable avahi-daemon.service
>>
>> systemctl stop avahi-daemon.socket
>> systemctl disable avahi-daemon.socket
>>
>> Then edit /etc/nsswitch.conf and remove all references to mdns4
>>
>> Mart
>>
> Because even with nothing in /etc/network/interfaces dhcpd is seeing
> eth1.1 and eth1.2 and there are entries like this in syslog:
>
That's just avahi trying to work with an interface it thinks still
exists.
what does the output of cat /proc/net/vlan/config show?
>
> It seems that the old settings are persisted somewhere and I suspect
> either avahi or systemd.
ids. VLAN interfaces are meant to persist until you issue a vconfig rem
command, but I don't know if systemd persists the interfaces across
reboots.
As far as I know, it shouldn't. VLANs require an explicit .netdev
service file.
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/86d1yxi...@gaheris.avalon.lan
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrew Wood
Aug 11, 2015, 10:30:06 AM8/11/15
to
On 08/08/15 21:25, Mart van de Wege wrote:
> That's just avahi trying to work with an interface it thinks still
> exists.
> what does the output of cat /proc/net/vlan/config show?
>> It seems that the old settings are persisted somewhere and I suspect
>> either avahi or systemd.
> I don't know if it is particularly systemd that's persisting VLAn
> ids. VLAN interfaces are meant to persist until you issue a vconfig rem
> command, but I don't know if systemd persists the interfaces across
> reboots.
>
> As far as I know, it shouldn't. VLANs require an explicit .netdev
> service file.
>
Given that the issue seems to be centered on dhcpd and it not knowing
which subet relates to which vlan interface why with nothing in
/etc/network/interfaces does syslog show this when trying to start dhcpd:
Aug 11 12:08:19 sentrybox dhcpd: Wrote 13 leases to leases file.
Aug 11 12:08:19 sentrybox dhcpd:
Aug 11 12:08:19 sentrybox dhcpd: No subnet declaration for eth1.2 (no
IPv4 addresses).
Aug 11 12:08:19 sentrybox dhcpd: ** Ignoring requests on eth1.2. If
this is not what
Aug 11 12:08:19 sentrybox dhcpd: you want, please write a subnet
declaration
Aug 11 12:08:19 sentrybox dhcpd: in your dhcpd.conf file for the
network segment
Aug 11 12:08:19 sentrybox dhcpd: to which interface eth1.2 is
attached. **
Aug 11 12:08:19 sentrybox dhcpd:
Aug 11 12:08:19 sentrybox dhcpd:
Aug 11 12:08:19 sentrybox dhcpd: No subnet declaration for eth1.1 (no
IPv4 addresses).
Aug 11 12:08:19 sentrybox dhcpd: ** Ignoring requests on eth1.1. If
this is not what
Aug 11 12:08:19 sentrybox dhcpd: you want, please write a subnet
declaration
Aug 11 12:08:19 sentrybox dhcpd: in your dhcpd.conf file for the
network segment
Aug 11 12:08:19 sentrybox dhcpd: to which interface eth1.1 is
attached. **
Aug 11 12:08:19 sentrybox dhcpd:
Aug 11 12:08:19 sentrybox dhcpd:
Aug 11 12:08:19 sentrybox dhcpd: Not configured to listen on any interfaces!
Aug 11 12:08:19 sentrybox dhcpd:
Aug 11 12:08:19 sentrybox dhcpd: If you think you have received this
message due to a bug rather
Aug 11 12:08:19 sentrybox dhcpd: than a configuration issue please read
the section on submitting
Aug 11 12:08:19 sentrybox dhcpd: bugs on either our web page at
www.isc.org or in the README file
Aug 11 12:08:19 sentrybox dhcpd: before submitting a bug. These pages
explain the proper
Aug 11 12:08:19 sentrybox dhcpd: process and the information we find
helpful for debugging..
Aug 11 12:08:19 sentrybox dhcpd:
Aug 11 12:08:19 sentrybox dhcpd: exiting.
Aug 11 12:08:21 sentrybox isc-dhcp-server[1309]: Starting ISC DHCP
server: dhcpdcheck syslog for diagnostics. ... failed!
With this in dhcpd.conf:
#ddns-update-style interim;
default-lease-time 7200; #2 hours
max-lease-time 7200;
option web-proxy code 252 = text;
max-lease-time 7200;
option web-proxy code 252 = text;
subnet 192.168.10.0 netmask 255.255.255.0{
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.10.255;
option routers 192.168.10.254;
range 192.168.10.1 192.168.10.199;
option domain-name-servers 192.168.10.254;
#option web-proxy "http://192.168.10.254/wpad.dat\000";
option domain-name "commsmuseum.local";
#option ntp-servers 192.168.10.200;
}
With no vlans defined in /etc/network/interfaces and no ip addresses
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.10.255;
option routers 192.168.10.254;
range 192.168.10.1 192.168.10.199;
option domain-name-servers 192.168.10.254;
#option web-proxy "http://192.168.10.254/wpad.dat\000";
option domain-name "commsmuseum.local";
#option ntp-servers 192.168.10.200;
}
assigned to the plain eth0 or eth1 how come its still referring to
eth1.1 and eth1.2 even after a reboot?
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Mart van de Wege
Aug 11, 2015, 4:30:05 PM8/11/15
to
Andrew Wood <and...@perpetualmotion.co.uk> writes:
> On 08/08/15 21:25, Mart van de Wege wrote:
>> That's just avahi trying to work with an interface it thinks still
>> exists.
>
>> what does the output of cat /proc/net/vlan/config show?
>>> It seems that the old settings are persisted somewhere and I suspect
>>> either avahi or systemd.
>> I don't know if it is particularly systemd that's persisting VLAn
>> ids. VLAN interfaces are meant to persist until you issue a vconfig rem
>> command, but I don't know if systemd persists the interfaces across
>> reboots.
>>
>> As far as I know, it shouldn't. VLANs require an explicit .netdev
>> service file.
>>
> cat /proc/net/vlan/config gives no such file
>
That would mean that the 8021q module is not loaded.
> On 08/08/15 21:25, Mart van de Wege wrote:
>> That's just avahi trying to work with an interface it thinks still
>> exists.
>
>> what does the output of cat /proc/net/vlan/config show?
>>> It seems that the old settings are persisted somewhere and I suspect
>>> either avahi or systemd.
>> I don't know if it is particularly systemd that's persisting VLAn
>> ids. VLAN interfaces are meant to persist until you issue a vconfig rem
>> command, but I don't know if systemd persists the interfaces across
>> reboots.
>>
>> As far as I know, it shouldn't. VLANs require an explicit .netdev
>> service file.
>>
> cat /proc/net/vlan/config gives no such file
>
So your interfaces don't have VLANs at all, as the VLAN driver isn't
even loaded.
So somehow there is some configuration left that refers to non-existent
interfaces.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/86k2t1o...@gaheris.avalon.lan
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Andrew Wood
Aug 11, 2015, 5:50:06 PM8/11/15
to
On 11/08/15 21:09, Mart van de Wege wrote:
>
>> cat /proc/net/vlan/config gives no such file
>>
> That would mean that the 8021q module is not loaded.
>
> So your interfaces don't have VLANs at all, as the VLAN driver isn't
> even loaded.
>
> So somehow there is some configuration left that refers to non-existent
> interfaces.
>
> Mart
>
time as no vlans are defined in /etc/network/interfaces?
So why does dhcpd still think they exist? Im tempted to do a re-install
with Wheezy just to prove that something weird has changed in Jessie.
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages