PDA

View Full Version : bug in gerrelts squeezelite.sh



DJanGo
2017-11-30, 14:28
Hi,

in another thread (http://forums.slimdevices.com/showthread.php?108321-Max-instances-of-squeezelite-is-4) here we had some disccusion about gerrelts script.


True..

However, the mac adress should work without uncommenting it...


Since i am not using this script but i do know it - i know that line is from gerrelt.
Hopefully he sees that thread.

These are the lines that didnt work anymore...


# get mac address from wifi adapter or on board network card
SL_MAC_ADDRESS=$(ifconfig | grep '^wlan0 ' | tr -s ' ' | rev | sed -e 's/^[ \t]*//' | cut -d ' ' -f1 | rev)
[ -n "$SL_MAC_ADDRESS" ] || SL_MAC_ADDRESS=$(ifconfig | grep 'eth0' | tr -s ' ' | rev | sed -e 's/^[ \t]*//' | cut -d ' ' -f1 | rev)

Even on my rpi these lines didnt work anymore.

I would use something like that instead:
written / tested under rasbian 9.1



# ping your localhost subnet once
ping -c1 127.0.0.0
# find the active networkdevice
device=$(arp -a|grep ":"|cut -d ' ' -f7|sort -u)
# find the macaddress of that device and use it as SL_MAC_ADDRESS
SL_MAC_ADDRESS=$(cat /sys/class/net/$device/address)
# make sure SL_MAC_ADDRESS contains : otherwise its malformed /useless and we clear the variable
echo $SL_MAC_ADDRESS|grep ":" ||SL_MAC_ADDRESS=


the last line should be at least added to the script - it clears SL_MAC_ADDRESS if its not containing the char :

epoch1970
2017-11-30, 16:43
Yeah, I've read the thread, I don't know the script but if its purpose is to define a MAC address as player ID, why not define as many MAC as needed out of something (almost) completely arbitrary like "02:0a:0b:0c:0d:01", "02:0a:0b:0c:0d:02", etc.

I see quite often my pCPs start with a nil player ID these days. Somehow it boots and starts squeezelite before the DHCP server had time to react. Or a switch gets in the way. So I use -m systematically.
Yes, I do use the actual MAC from the host for that. It is sort of a nice touch, but frankly copying the real MAC serves no purpose and I have time to do it by hand, one setup at a time.

The old script (whatever it does) is definitely dead thanks to systemd's last wonderful implementation of predictable network device names. "grep wlan" no more.
Your script runs on raspbian 8, but it returns junk on the machine I used, which has 2 bridges (one with a wireless interface for AP use) active.
I didn't try your snippet on pCP, but between busybox and sysfs I fear there could (will) be some portability issue.

So why not go arbitrary all the way? I think my proposal breaks at 255 instances...

DJanGo
2017-11-30, 23:32
I don't know the script but if its purpose is to define a MAC address as player ID, why not


Hi,

hell yeah - it was too late yesterday....

My script didnt work on a non enu debian eather :mad:

arp -a
? (192.168.199.103) auf it auf not on.

Since squeezelite didnt need -m and always uses a hardware address - that whole script to find the hardwareadress is bullshit!

thanks

Greg Erskine
2017-12-01, 17:22
I see quite often my pCPs start with a nil player ID these days. Somehow it boots and starts squeezelite before the DHCP server had time to react. Or a switch gets in the way. So I use -m systematically.

Hi epoch1970,

:confused: I haven't seen this happen for a long time. I have never had the need to use the -m option. I am using slow wifi and a very old wifi router with DHCP.

regards
Greg

DJanGo
2017-12-02, 02:17
I see quite often my pCPs start with a nil player ID these days.
did you use some "3rd party stuff or a regular simple service for squeezelite?
my squeezelite sessions have always the networkstack as dependency - yours too?

Somehow it boots and starts squeezelite before the DHCP server had time to react. Or a switch gets in the way. So I use -m systematically.
Thats maybe the solution for another problem...
Your Macadresses are not called "Hardwareadress" by accident its exactly what this name told you.

Your system knows its hardwareadress whenever the networkdevice is starting.
There is no dhcp involed - dhcp only gives a ip address to a hardwareaddress - nothing else!


Yes, I do use the actual MAC from the host for that. It is sort of a nice touch, but frankly copying the real MAC serves no purpose and I have time to do it by hand, one setup at a time.
yapp IMHO fake something like a mac address is fake / in harder words bullsh1t if there is only a single squeezelitesession on a hardware involved.
And thats AFAIK the reason to fake the mac to allow more than a single squeezelitesession on a single hardwaredevice.

epoch1970
2017-12-02, 12:50
Hi epoch1970,

:confused: I haven't seen this happen for a long time. I have never had the need to use the -m option. I am using slow wifi and a very old wifi router with DHCP.

regards
Greg
I have 4 players that are using DHCP, the network path has 2 "pro" switches along the way plus a software bridge, there is a dedicated VLAN, and the DHCP server is running on the (raspbian) Pi that runs LMS. The Pi runs a bit of routing/filtering and applications but it is normally not busy.
The players boot fast and network config comes later, almost guaranteed. As a consequence, Squeezelite uses the nil player ID.
That's a pain because when multiple players have the nil ID you only see one via LMS, so reaching to every one of them and setting the appropriate "-m" option can take a little time and guesswork.
I'm using pCP 3.2.0 but I am fairly confident the culprit is either the Pi server or the switches which take their time learning the MACs. I'm using a MAC-defined VLAN for the players, maybe that doesn't help either.

epoch1970
2017-12-02, 13:18
yapp IMHO fake something like a mac address is fake / in harder words bullsh1t if there is only a single squeezelitesession on a hardware involved.
Strong words, friend ;)

The issue is a little confusing, I have to admit:
1 - There are people who need multiple instances
2 - There are people who want to force the player to a specific identity, a good reason for that would be to retain player preferences when swapping hardware. (I've used active/backup wifi+ether bonding on a Pi player once or twice, it's funnier than useful, but it also makes a strong case for using option "-m")
3 - There is a very specific condition that can happen in squeezelite: http://forums.slimdevices.com/showthread.php?107352-Announce-piCorePlayer-3-20&p=890873&viewfull=1#post890873
(you can backtrack to the beginning of the conversation, it is short.)

In my case, I use Pi 3s as pCP players. Wifi is disabled. I use a single instance of Squeezelite. Ok, my tc archive "is a little large" but really I don't think it has anything to do with the issue. The MAC address of the network interface is never a problem, my players always get a DHCP lease. But this takes a few seconds (10 secs?)
So I get this problem: Squeezelite has started before networking has settled, it doesn't know what player ID to report, so it reports a nil ID.
And "-m" solves it.

(-m is a good option. It got a bad rap when people started "recycling" slimdevices MACs to software players and put unwarranted load over mysb.com, but it does have legitimate uses.)

bakker_be
2017-12-03, 03:49
Strong words, friend ;)

The issue is a little confusing, I have to admit:
1 - There are people who need multiple instances
2 - There are people want to force the player to a specific identity, a good reason for that would be to retain player preferences when swapping hardware. (I've used active/backup wifi+ether bonding on a Pi player once or twice, it's funnier than useful, but it also makes a strong case for using option "-m")
3 - There is a very specific condition that can happen in squeezelite: http://forums.slimdevices.com/showthread.php?107352-Announce-piCorePlayer-3-20&p=890873&viewfull=1#post890873
(you can backtrack to the beginning of the conversation, it is short.)

In my case, I use Pi 3s as pCP players. Wifi is disabled. I use a single instance of Squeezelite. Ok, my tc archive "is a little large" but really I don't think it has anything to do with the issue. The MAC address of the network interface is never a problem, my players always get a DHCP lease. But this takes a few seconds (10 secs?)
So I get this problem: Squeezelite has started before networking has settled, it doesn't know what player ID to report, so it reports a nil ID.
And "-m" solves it.

(-m is a good option. I got a bad rap when people started "recycling" slimdevices MACs to software players and put unwarranted load over mysb.com, but it does have legitimate uses.)
Couldn't this be solved by modifying the start-up timing of squeezelite? Don't really know for PiCore, but on an OS where services are managed by systemd you'd add the following lines to the service file, to make it wait until runlevel 3:


[Install]
WantedBy=multi-user.target

epoch1970
2017-12-03, 06:12
Couldn't this be solved by modifying the start-up timing of squeezelite?
If my theory is right, then yes it could solve the issue.
But a nil ID is not a blocker, it is more of a nuisance. The issue doesn’t happen to everyone, obviously.
And if you start waiting, when do you stop waiting, really?

EDIT. Also, here is a super simple way of getting the ID right: reboot pCP or restart squeezelite. In the case of rebooting, this works because the switches and other devices in the path haven't had time to unlearn the MAC of the client yet, so the whole DHCP lease deal is faster than with a really cold start and SL can report an ID.


Don't really know for PiCore, but on an OS where services are managed by systemd ...
I am glad to report systemd is nowhere near in sight under Tiny Core. sysVinit triggers a chain of shell scripts that bring the machine up to order. Simple, sequential, and predictable.

I for one am very happy with the way PCP works. I had this intriguing issue, I could find a probable cause, and solve it with 100% reliability via an easy config option. Can’t really ask for more...

paul-
2017-12-03, 09:41
For what it's worth, pCP does wait for the network to get a IP/Broadcast address before starting squeezelite. The timeout is set to 20 seconds. Take a look a the log (/var/log/pcp_boot.log)



Waiting for network........... Done (11).


Every dot between network and Done is 0.5seconds

Squeezelite is what is picking up the interface address. For some reason that is failing on your system. Are you doing something that would be setting an environment variable called UTMAC?

epoch1970
2017-12-03, 10:08
Are you doing something that would be setting an environment variable called UTMAC?
Nope. As written here and elsewhere the only peculiarities on my systems are a 1.5MB archive tgz, a thick asound.conf, and one or 2 processes launched after startup.

When I take such a config to my home network, it runs fine, IIRC. Don't get all hot and bothered about it, it's not pCP (or SL), it is the network I tell you ;)
Get 2 of these (http://www.tp-link.com/us/products/details/cat-40_T1600G-28TS.html) between your pCP clients and a slow DHCP server like a Pi and I bet you'll have my "problem".

DJanGo
2017-12-03, 11:11
In the case of rebooting, this works because the switches and other devices in the path haven't had time to unlearn the MAC of the client yet, so the whole DHCP lease deal is faster than with a really cold start and SL can report an ID.

sorry....


client sends a broadcast with his mac and the ip 0.0.0.0
dhcp server answers him
client tells this particular server "need IP address"
Server may check fpr a free ip and tells it to the client
client tells server thanks i am using it


All devices even Switches always "unlearn" foreign MAC Addresses - thats the only way for them to be up2date if something is changed somewhere.

cheers

paul-
2017-12-03, 12:05
I'm not bothered by it, I was merely trying to avoid confusion about the pCP startup process. And how the MAC address is delivered to the LMS server. Your system must take over 20 seconds to get a valid IP address (timeout in pCP). The mac address used by the LMS server does not come from any switching equip or the packet headers. Squeezelite detects hardware address (unless overridden with the -m) That address is broadcast to the LMS server in the Slimproto HELO packet.

epoch1970
2017-12-03, 12:30
Your system must take over 20 seconds to get a valid IP address (timeout in pCP).
That is quite possible.
I haven't timed it really (or don't remember), these machines are on 24/7. What really mattered was clients always latching into the right VLAN and getting their IP address, and that they do very reliably.

@Django.
If you're keen have a look at the configuration guide for the switch model I linked above. On page 135 (english edition) you can read

Aging Time
Set the length of time that a dynamic entry remains in the MAC address table after the entry is used or updated. The valid values are from 10 to 630 seconds, and the default value is 300.
A short aging time is applicable to networks where network topology changes frequently, and a long aging time is applicable to stable networks. We recommend that you keep the default value if you are unsure about settings in your case.
So yes we are both right. Switches do unlearn MACs.

K.Clemens
2017-12-06, 10:52
I've sended Gerrelt an e-mail with the link of this topic. Let's see if he will reply.

Gerrelt
2017-12-09, 14:08
Hi K.Clemens,

Thank you for your e-mail and heads-up for this problem (edit: and of course thanks to everyone joining in on this thread).
This finally explains why my living room and kitchen squeezelite-raspberries weren't always synchronized in the morning. :D

Indeed on the latest Raspbian Stretch the "ifconfig" command (used for determining MAC address) gives a different output then on earlier versions, which made my code incorrect.

I've now changed my script so that it basically uses the script proposed by DJanGo (thanks!).
At first it executes these commands to get the wlan0 mac addres, or the eth0 mac address:


# get mac address from wifi adapter or on board network card
SL_MAC_ADDRESS=$(cat /sys/class/net/wlan0/address)
[ -n "$SL_MAC_ADDRESS" ] || SL_MAC_ADDRESS=$(cat /sys/class/net/eth0/address)

Then it loads the squeezelite_settings.sh file, in which the mac address might be set too.
After loading the settings, it checks if the MAC adddres has a correct format. If the format isn't correct, it generates a random mac address:


# check if valid mac address is obtained
if [[ ! "$SL_MAC_ADDRESS" =~ ^([a-fA-F0-9]{2}:){5}[a-fA-F0-9]{2}$ ]]; then
echo "Warning: no valid mac addres found in SL_MAC_ADDRESS, generating random one."
hexchars="0123456789ABCDEF"
RANDOMMAC=$( for i in {1..12} ; do echo -n ${hexchars:$(( $RANDOM % 16 )):1} ; done | sed -e 's/\(..\)/:\1/g' )
SL_MAC_ADDRESS=${RANDOMMAC:1}
fi

This way the mac address will allways be set.

One additional benefit might be that if you would enter "random" as value in SL_MAC_ADDRESS in the settings file, it will force the script to use a random mac address.
This might be usefull when using multiple squeezelite instances on one machine.
A "drawback" is that the player will have a different mac address after each reboot.

I've tested these changes on piCore, Raspbian Jessie and Raspbian Stretch.

Comments/suggestions, welcome!

Greetings,
Gerrelt.

K.Clemens
2017-12-10, 01:34
Gerrelt,

A big thank you for keeping your scripts up-to-date.

Just wondering why someone would use a random MAC adress? Probably I'm scripting all my things wrong (trial & error style :d) but I juse JSON with MAC adresses. So if the MAC adress keeps on changing, my scripts stop working. Offcourse this is not the case since I give a specific MAC adress in the squeezelite_settings.sh file.

DJanGo
2017-12-10, 05:53
Hi,

in the case of using a rpi3 not with lan or the builtin (worst) wlan - or the new adapternames - your script would'nt get the real mac of the used adapter.

squeezelite (unless you told it with -m) always uses a mac from an active adapter.

My script unset your var SL_MAC_ADDRESS cause in your squeezelite init script is this code:

# add mac address if set
if [ ! -z "$SL_MAC_ADDRESS" ]; then
DAEMON_ARGS="${DAEMON_ARGS} -m ${SL_MAC_ADDRESS}"
fi


That didnt make any sense, if you force SL_MAC_ADDRESS to a (random) mac

Just unset the SL_MAC_ADDRESS...

@ K.Clemens:

my lms player scripts always checks lms for active players amd lms tolds me what id/ mac addreses are in use right now.
may thats an option for you?

Gerrelt
2017-12-10, 06:52
Hi DJanGo,

Thank you for your feedback.
You are right, that piece of code is useless now, it will always use -m with my lateste change. I will try to add a check not to check for MAC address validity when the variable is empty.

Are you sure squeezelite now uses the correct MAC address when not using the -m option? In the first days of squeezelite (in 2012) it didn't do that. It used a blank MAC address (IIRC), which was a problem when using more then one raspberry with squeezelite. LMS would see them both as the same player.
Anyway, I will see if it does that when implementing above change.

Greetings,
Gerrelt.

DJanGo
2017-12-10, 08:10
Are you sure squeezelite now uses the correct MAC address when not using the -m option? In the first days of squeezelite (in 2012) it didn't do that. It used a blank MAC address (IIRC), which was a problem when using more then one raspberry with squeezelite.

Hi Gerrelt,

iam using the localplayer plugin from the very first version and i never had any issues without using -m (i didnt use -m @ any of my players.)

But i do also know your first Version of your squeezelite init script (the one that didnt have the lsb info) since your not using [at this time] $network as Required-Start that might start squeezelite without knewing a active Lan/Wlan Adapter and therefore squeezelite uses 00:00:00:00:00:00 as Mac.

Gerrelt
2017-12-10, 08:31
But i do also know your first Version of your squeezelite init script (the one that didnt have the lsb info) since your not using [at this time] $network as Required-Start that might start squeezelite without knewing a active Lan/Wlan Adapter and therefore squeezelite uses 00:00:00:00:00:00 as Mac.

Yes, I juste encountered that again too. That was the reason the script now always uses the -m option. Using it without will indeed make squeezelite use the 00:00:00:00:00:00 mac address, which is a problem when using more then one raspberry pi with squeezelite on it.
I will keep the current implementation for now, it's a dependable and flexible implementation.

When not using SL_MAC_ADDRESS, it will choose the wlan0 or eth0 mac addres
When using SL_MAC_ADDRESS without value, it will create a random mac address.
When using SL_MAC_ADDRESS with an invalid value, it will create a random mac address.
When using SL_MAC_ADDRESS with a valid value, it will use that mac address.

I am contemplating creating something that will convert a playername to a mac-address. That would create a persistent and unique mac address.