Koozali.org: home of the SME Server
Contribs.org Forums => Koozali SME Server 10.x Contribs => Topic started by: mauro on January 17, 2022, 11:46:12 AM
-
I have a SME10 in server+gw mode and the windows client have troubles browsing the samba shares.
WSDD is up and running and attached to eth1 which is my internal interface:
]# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.246.1 netmask 255.255.255.0 broadcast 192.168.246.255
ether 0a:7f:1e:7a:c4:df txqueuelen 1000 (Ethernet)
RX packets 657233 bytes 256013205 (244.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 595846 bytes 816491654 (778.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.2.2 netmask 255.255.255.0 broadcast 192.168.2.255
ether 94:f1:28:95:37:5c txqueuelen 1000 (Ethernet)
RX packets 683340 bytes 640609872 (610.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 564923 bytes 336431911 (320.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 18
eth1: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500
ether 94:f1:28:95:37:5d txqueuelen 1000 (Ethernet)
RX packets 609016 bytes 257659684 (245.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 809086 bytes 756478193 (721.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 19
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 56239 bytes 10050844 (9.5 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 56239 bytes 10050844 (9.5 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
tap0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500
ether 0a:7f:1e:7a:c4:df txqueuelen 100 (Ethernet)
RX packets 53982 bytes 11910738 (11.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 86736 bytes 81155432 (77.3 MiB)
TX errors 0 dropped 57 overruns 0 carrier 0 collisions 0
I found out that if I attach wsdd to br0 the samba shares appear visible from windows.
Is this the expected behaviour, and if so how can I change the default interface?
If instead it should work attached to eth1, I will open a bug.
There's a note on the wiki page about bridged interfaces which I admit I do not fully understand.
-
Before you race off and open a bug you know that there is potentially an issue with bridge connections. Try and establish if this is a config issue first.
What interfaces have you bridged? Is that via a contrib eg openvpn?
We need a bit more background please.
Can you show this:
cat /usr/lib/systemd/system/wsdd.service.d/50-koozali.conf
The contrib tries to set the wsdd Interface as the InternalInterface.
What does this show?
config getprop InternalInterface Name
It gets set via this template:
/etc/e-smith/templates/usr/lib/systemd/system/wsdd.service.d/50-koozali.conf/20Service
So I can also see eth0 has an IP but not eth1. Why?
-
The bridged interface comes from (I believe) the OpenVPN-bridge contrib.
The systemd wsdd configuration file is:
#------------------------------------------------------------
# !!DO NOT MODIFY THIS FILE!!
#
# Manual changes will be lost when this file is regenerated.
#
# Please read the developer's guide, which is available
# at http://www.contribs.org/development/
#
# Copyright (C) 1999-2006 Mitel Networks Corporation
#------------------------------------------------------------
[Unit]
After=bootstrap-console.service
Wants=
Wants=network-online.target
[Service]
ExecStartPre=
ExecStart=
ExecStart=/usr/bin/wsdd -4 -i eth1 -w chemcharter -s
[Install]
WantedBy=sme-server.target
however:
#config getprop InternalInterface Name
br0
I have manually assigned the IP address to eth0 in order to be able to reach the web management interface of the external VDSL modem from the internal network. The server was upgraded from SME9, if that helps.
-
Hmmm.
Not sure what you have done there.
You show InternalInterface as br0 but the unit file as eth1?
Which interface is bridged?
Might be an idea to remove the bridge contrib (you really ought to know what contrib creates a bridge!!), reconfigure your network, get your IP addresses correct and wssd working, and then look at the bridge.
-
You show InternalInterface as br0 but the unit file as eth1?
Correct. And I did a reconfigure+reboot yesterday morning (after upgrading systemd).
Which interface is bridged?
The bridged interfaces are eth1 (the ethernet port LAN side) and tap0 (belonging to OpenVPN).
Might be an idea to remove the bridge contrib (you really ought to know what contrib creates a bridge!!), reconfigure your network, get your IP addresses correct and wssd working, and then look at the bridge.
Good idea but I can't do right now as there's a colleague working from home in VPN.
Is there a command to force a rebuild of /usr/lib/systemd/system/wsdd.service.d/50-koozali.conf without reconfiguring the whole server, just to see if it binds to the right interface?
-
Is there a command to force a rebuild of /usr/lib/systemd/system/wsdd.service.d/50-koozali.conf without reconfiguring the whole server, just to see if it binds to the right interface?
Juts expand the template 0 # expand-template /usr/lib/systemd/system/wsdd.service.d/50-koozali.conf
and good idea to restart the service
-
I think I'm getting somewhere...
As I said, yesterday morning around 8:50 I did a reconfigure+reboot because of updates.
As far as I can see, at reboot InternalInterface bounces between eth1 and br0 a couple of times before settling to br0:
]# journalctl -b | grep InternalInter
Jan 17 08:55:02 wintermute.chemcharter.com /etc/e-smith/events/bootstrap-console-save/S00initialize-default-databases[1000]: /home/e-smith/db/configuration: OLD InternalInterface=interface|Broadcast|192.168.246.255|Configuration|static|Driver|tg3|IPAddress|192.168.246.1|NICBondingOptions|miimon=200 mode=active-backup|Name|eth1|Netmask|255.255.255.0|Network|192.168.246.0
Jan 17 08:55:02 wintermute.chemcharter.com /etc/e-smith/events/bootstrap-console-save/S00initialize-default-databases[1000]: /home/e-smith/db/configuration: NEW InternalInterface=interface|Broadcast|192.168.246.255|Configuration|static|Driver|tg3|IPAddress|192.168.246.1|NICBondingOptions|miimon=200 mode=active-backup|Name|br0|Netmask|255.255.255.0|Network|192.168.246.0
Jan 17 08:55:04 wintermute.chemcharter.com /etc/e-smith/events/bootstrap-console-save/S02bridge-disable[1007]: /home/e-smith/db/configuration: OLD InternalInterface=interface|Broadcast|192.168.246.255|Configuration|static|Driver|tg3|IPAddress|192.168.246.1|NICBondingOptions|miimon=200 mode=active-backup|Name|br0|Netmask|255.255.255.0|Network|192.168.246.0
Jan 17 08:55:04 wintermute.chemcharter.com /etc/e-smith/events/bootstrap-console-save/S02bridge-disable[1007]: /home/e-smith/db/configuration: NEW InternalInterface=interface|Broadcast|192.168.246.255|Configuration|static|Driver|tg3|IPAddress|192.168.246.1|NICBondingOptions|miimon=200 mode=active-backup|Name|eth1|Netmask|255.255.255.0|Network|192.168.246.0
Jan 17 08:55:45 wintermute.chemcharter.com /etc/e-smith/events/bootstrap-console-save/S98bridge-enable[1625]: /home/e-smith/db/configuration: OLD InternalInterface=interface|Broadcast|192.168.246.255|Configuration|static|Driver|tg3|IPAddress|192.168.246.1|NICBondingOptions|miimon=200 mode=active-backup|Name|eth1|Netmask|255.255.255.0|Network|192.168.246.0
Jan 17 08:55:45 wintermute.chemcharter.com /etc/e-smith/events/bootstrap-console-save/S98bridge-enable[1625]: /home/e-smith/db/configuration: NEW InternalInterface=interface|Broadcast|192.168.246.255|Configuration|static|Driver|tg3|IPAddress|192.168.246.1|NICBondingOptions|miimon=200 mode=active-backup|Name|br0|Netmask|255.255.255.0|Network|192.168.246.0
But the wsdd configuration file gets created at 08:55:13, in a moment where InternalInterface has the wrong value:
# journalctl -b | grep wsdd.service
Jan 17 08:55:13 wintermute.chemcharter.com esmith::event[998]: expanding /usr/lib/systemd/system/wsdd.service.d/50-koozali.conf
Looks like this event should be pushed back.
-
Looks like this event should be pushed back.
No, because as per the wiki, you don't want wsdd on a bridged interface as it may create a lot of issues.
You need wsdd pinned to a single real interface - as per the wiki.
If tunnel/bridge interfaces like those created by OpenVPN or Docker exist, they may interfere with wsdd if executed without providing an interface that it should bind to (so it binds to all). In such cases, the wsdd hosts appears after wsdd has been started but it disappears when an update of the Network view in Windows Explorer is forced, either by refreshing the view or by a reboot of the Windows machine
To solve this issue, the interface that is connected to the network on which the host should be announced needs to be specified with the -i/--interface option. This prevents the usage of the tunnel/bridge interfaces.
The real issue here is running bridges with wsdd but I am no guru on bridging.
Perhaps JP would like to comment on this.
-
From the source, Github..worth a quick read
https://github.com/christgau/wsdd#tunnelbridge-interface
-
As far as I read it that means don't use wssd on bridge interfaces.
Note wsdd only updates the config file when instructed during normal operation. (yes most config files get re-expanded on reconfig/reboot so no surprise)
It isn't dynamic. It doesn't really expect interfaces to keep flipping about.
I'm not sure how you can best deal with this in a consistent fashion.
Either wsdd has to detect changes or bridge has to update and restart wsdd.
I think the masq templates probably also need to be reviewed as they open up broadcast traffic and only expect that on the local/internal interface.
From github:
To solve this issue, the interface that is connected to the network on which the host should be announced needs to be specified with the -i/--interface option.
Yes, we do that expecting a standard network interface. Eg eth0/1 etc.
This prevents the usage of the tunnel/bridge interfaces.
And that tells me we should not use tunnel or bridge interfaces. So no br0.
I'm not sure if or how there is a way we can utilise it in this sutuation. Open to suggestions.
(Yes, it *may* work for you now but not as intended and there are potential issues as above)
-
Tunnel/Bridge Interface https://github.com/christgau/wsdd#tunnelbridge-interface
this is more referring to tunnel interface, ie : tun or tap interfaces
for the bridge used here br0, the only occasion it should be modified is when an event is triggered.
so yes as a server might have wireshark, openvpn ... interfaces that could be altered whenver the connexion is reinitialized we should define an if with -i option, but the way to choose it should be improved
# config show InternalInterface
InternalInterface=interface
Broadcast=192.168.1.255
Configuration=static
Driver=r8169
IPAddress=192.168.1.1
Name=br0
Netmask=255.255.255.0
Network=192.168.1.0
so normally config getprop InternalInterface Nameshould be the way to get it.
smeserver-wsdd-0.2/root/usr/lib/systemd/system/wsdd.service.d/
/etc/e-smith/templates/usr/lib/systemd/system/wsdd.service.d/50-koozali.conf/20Service
[Service]
ExecStartPre=
ExecStart=
{
$OUT .= "ExecStart=/usr/bin/wsdd -4 -i $InternalInterface{Name} -w $smb{Workgroup} -s";
}
is already good
however from memory there was moment where it should be expanded...
foreach (qw(
/usr/lib/systemd/system/wsdd.service.d/50-koozali.conf
))
{
templates2events("$_", qw(
post-upgrade
console-save
bootstrap-console-save
remoteaccess-update
ibay-modify
ibay-create
ibay-delete
workgroup-update
));
}
also latter in createlinks you can list
- smeserver-wssd-update
also to note in smeserver-bridge-interface you can see
foreach my $event (qw/console-save bootstrap-console-save/){
event_link("bridge-disable", "$event", "02");
event_link("bridge-enable", "$event", "98");
}
meaning between 02 and 98 in an event the bridge is disabled....
expand template is at 05
service adjust is at 90
as a result when expanding your file /usr/lib/systemd/system/wsdd.service.d/50-koozali.conf at console-save bootstrap-console-save it gets set to the real internal interface $InternalInterface{Name} and not the bridge (br0) as the action script bridge-disable reset this value to the default.. untill bridge-enable set again the bridge.
one easy hack would be to remove them from expanding at those tow event and write a small action to expand it at 01
#!/usr/bin/perl
use esmith::templates;
esmith::templates::processTemplate({
TEMPLATE_PATH => "/usr/lib/systemd/system/wsdd.service.d/50-koozali.conf",
OUTPUT_FILENAME => "/usr/lib/systemd/system/wsdd.service.d/50-koozali.conf",
});
alternative would be to check if bridge is installed and if so and prop('bridge', 'OldStatus', 'enabled'); then use $bridge->prop('bridgeInterface') if prop('InternalInterface', 'Name') is also equal to $bridge->prop('ethernetInterface')