You are here: Home » Topic » NSLU2 with nightly, but Soundbridge will not connect

NSLU2 with nightly, but Soundbridge will not connect

FireFly Media Server (formerly mt-daapd) Firefly Media Server Forums Firefly Media Server Setup Issues NSLU2 with nightly, but Soundbridge will not connect

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #1098
    sluggi
    Participant

    I have installed Firmware Version: V2.3R63-uNSLUng-6.8-beta and also installed nightly version mt-daapd_svn-1498-1_armeb.ipk at the NSLU2.
    But unfortunately the Soundbridge will not connect to it.

    Has some one an idea what I can check or which settings are missing to get the connection to the NSLU2.

    #9142
    jheinitz
    Participant

    Hi,

    a few things to check:

    1.) have you checked your logfile of the firefly server. Should be /opt/var/log/mt-daapd.log?

    2.) have you started the Firefly Server after installing the software? Reboot would also start the server.

    3.) Can you see your Firefly Server in iTunes? In order to see it in iTunes you need to configure iTunes to look for shared music.

    If you have anything strange in your logfile, please post it. This gives the community a more detailed view on your system.

    Kind regards

    Jens

    #9143
    sluggi
    Participant

    Hi jheinitz,

    Thanks for your quick answer. I checked the things you mentioned.

    1.) have you checked your logfile of the firefly server. Should be /opt/var/log/mt-daapd.log?

    I noticed that my log was switched off. After switching it on I got the following log after restarting the NSLU2 (file /var/log/mt-daapd.log):

    2007-02-13 21:54:38 (00000400): Firefly Version svn-1498: Starting with debuglev
    2007-02-13 21:54:38 (00000400): Starting rendezvous daemon
    2007-02-13 21:54:38 (00000400): Starting signal handler
    2007-02-13 21:54:38 (00000400): Initializing database
    2007-02-13 21:54:39 (00000400): Starting web server from /opt/share/mt-daapd/adm
    2007-02-13 21:54:39 (00000400): Registering rendezvous names
    2007-02-13 21:54:39 (00000400): Serving 31 songs. Startup complete in 1 seconds
    2007-02-13 21:54:39 (00000400): Rescanning database
    2007-02-13 21:54:39 (00000400): Starting playlist scan
    2007-02-13 21:54:39 (00000400): Updating playlists
    2007-02-13 21:54:39 (00000400): Scanned 31 songs (was 31) in 0 seconds

    2.) have you started the Firefly Server after installing the software? Reboot would also start the server.

    I think the server is running. See result of the ps command:

      PID TTY     Uid        Size State Command
    1 root 1212 S /bin/init
    2 root 0 S [keventd]
    3 root 0 S [ksoftirqd_CPU0]
    4 root 0 S [kswapd]
    5 root 0 S [bdflush]
    6 root 0 S [kupdated]
    7 root 0 S [mtdblockd]
    8 root 0 S [khubd]
    9 root 0 S [jffs2_gcd_mtd4]
    10 root 0 S [usb-storage-0]
    11 root 0 S [scsi_eh_1]
    13 root 0 S [sd-mc-thread]
    28 root 0 S [kjournald]
    50 root 0 D [ixp425_csr]
    51 root 0 S [ixp425 ixp0]
    54 ttyS0 root 1916 S /bin/sh
    55 root 1936 S /sbin/syslogd -n
    56 root 1924 S /sbin/klogd -n
    148 root 1216 S /sbin/udhcpc -H LINK
    166 root 0 S [kjournald]
    228 root 9884 S upnpd &>/dev/null
    238 root 9884 S upnpd &>/dev/null
    239 root 9884 S upnpd &>/dev/null
    242 root 9884 S upnpd &>/dev/null
    243 root 9884 S upnpd &>/dev/null
    244 root 9884 S upnpd &>/dev/null
    336 root 2144 S /usr/sbin/thttpd -C /etc/thttpd.conf
    360 root 6148 S /usr/sbin/smbd -D
    362 root 6148 S /usr/sbin/smbd -D
    363 root 4820 S /usr/sbin/nmbd -D
    389 root 1952 S /usr/sbin/QuickSet
    394 root 1904 S /usr/sbin/USB_Detect
    395 root 1900 S /usr/sbin/USB_Detect
    404 root 1884 S /usr/sbin/onetouch_detect
    407 root 1884 S /usr/sbin/onetouch_detect
    419 root 1216 S /usr/sbin/crond
    425 root 1928 S /usr/sbin/CheckResetButton
    427 root 1196 S /usr/sbin/CheckPowerButton
    429 root 1196 S /usr/sbin/do_umount
    475 guest 4008 S /opt/sbin/mt-daapd -c /opt/etc/mt-daapd/mt-
    476 guest 10368 S /opt/sbin/mt-daapd -c /opt/etc/mt-daapd/mt-
    483 guest 10368 S /opt/sbin/mt-daapd -c /opt/etc/mt-daapd/mt-
    484 guest 10368 S /opt/sbin/mt-daapd -c /opt/etc/mt-daapd/mt-
    485 guest 10368 S /opt/sbin/mt-daapd -c /opt/etc/mt-daapd/mt-
    509 root 1256 S /usr/sbin/telnetd
    510 ttyp0 root 1920 S -sh
    533 guest 10368 S /opt/sbin/mt-daapd -c /opt/etc/mt-daapd/mt-
    536 root 2148 S /usr/sbin/thttpd -C /etc/thttpd.conf
    550 root 1276 S /bin/inetd
    551 root 1256 R /usr/sbin/telnetd
    552 ttyp1 root 1920 S -sh
    560 ttyp1 root 1984 R ps

    3.) Can you see your Firefly Server in iTunes? In order to see it in iTunes you need to configure iTunes to look for shared music.

    Yes, I see the firefly server in iTunes and can access the MP3 files from there.

    If you have anything strange in your logfile, please post it. This gives the community a more detailed view on your system.

    I think in the log there is nothing strange. for further information I add my configuration file for mt-daapd:

    # $Id: mt-daapd.conf,v 1.3 2005/02/15 03:35:19 rpedde Exp $
    #
    # This is the mt-daapd config file.
    #
    # If you have problems or questions with the format of this file,
    # direct your questions to [email protected]
    #
    # You can also check the website at http://mt-daapd.sourceforge.net,
    # as there is a growing documentation library there, peer-supported
    # forums and possibly more.
    #

    [general]

    #
    # web_root (required)
    #
    # Location of the admin web pages. If you installed from
    # ipk, this is correct
    #

    web_root = /opt/share/mt-daapd/admin-root

    #
    # port (required)
    #
    # What port to listen on. It is possible to use a different
    # port, but this is the default iTunes port
    #

    port = 3689

    #
    # admin_pw (required)
    #
    # This is the password to the administrative pages
    #
    # YOU SHOULD PROBABLY CHANGE THIS
    #

    admin_pw = mt-daapd

    #
    # db_dir (depricated)
    #
    # This is where mt-daapd stores its database of song information.
    #
    # If you installed this from .ipk, this is correct
    #

    #db_dir /opt/var/mt-daapd

    #
    # db_type/db_parms
    #
    # This specifies what kind of database you want, and where
    # it should be kept. Valid db_types depend on what databases are
    # compiled in, but can include "sqlite" and "sqlite3".
    #
    # db_parms is the parameters for that database backend. For sqlite and
    # sqlite3, these parameters are the path to the database.
    #

    db_type = sqlite
    db_parms = /opt/var/mt-daapd

    #
    # mp3_dir (required)
    #
    # Location of the mp3 files to share. This corresponds
    # to a folder called "mp3" in the "DISK 1" share.
    #

    mp3_dir = /share/hdd/data/public/mp3

    #
    # servername
    #
    # This is both the name of the server as advertised
    # via rendezvous, and the name of the database
    # exported via DAAP
    #
    # defaults to the hostname if not set
    #

    #servername = NSLU2 Music

    #
    # runas (required)
    #
    # This is the user to drop privs to if running as
    # root. If mt-daapd is not started as root, this
    # configuration option is ignored. Notice that this
    # must be specified whether the server is running
    # as root or not.
    #
    # If you have not messed with permissions from
    # the console, then this should work correctly
    # without any strange chmods or anything.
    #

    runas = guest

    #
    # playlist (optional)
    #
    # This is the location of a playlist file.
    # This is for Apple-style "Smart Playlists"
    # See the mt-daapd.playlist file in the
    # contrib directory for syntax and examples
    #
    # This doesn't control static playlists... these
    # are controlled with the "process_m3u" directive
    # below.
    #

    playlist = /opt/etc/mt-daapd/mt-daapd.playlist

    #
    # password (optional)
    #
    # This is the password required to listen to MP3 files
    # i.e. the password that iTunes prompts for
    #

    #password=mp3

    #
    # extensions (optional)
    #
    # These are the file extensions that the daap server will
    # try to index and serve. By default, it only indexes and
    # serves .mp3 files. It can also server .m4a and .m4p files,
    # and just about any other files, really. Unfortunately, while
    # it can *attempt* to serve other files (.ogg?), iTunes won't
    # play them. Perhaps this would be useful on Linux with
    # Rhythmbox, once it understands daap. (hurry up!)
    #

    extensions = .mp3,.m4a,.m4p,.ogg,.flac

    #
    # ssc_extensions (optional)
    #
    # List of file extensions belonging to the files daap server
    # performs internal format conversion and present to clients
    # as WAV files. Extensions must also be present in 'extensions'
    # configuration value, or files are not probed in the first
    # place.
    #

    ssc_codectypes = ogg,flac,alac

    #
    # ssc_prog (optional)
    #
    # Program that is used in server side format conversion.
    # Program must accept following command line syntax:
    # ssc_prog filename offset
    # Parameter filename is the real name of the file that is
    # to be converted and streamed, offset is number of bytes
    # that are skipped from the beginning of the _output_ file
    # before streaming is started. The resulting wav file (or
    # rest of the file after initial seek) is written to the
    # standard output by the ssc_prog program. This is typically
    # a script that is a front end for different conversion tools
    # handling different formats.
    #

    ssc_prog = /opt/sbin/mt-daapd-ssc.sh

    #
    # logfile (optional)
    #
    # This is the file to log to. If this is not configured,
    # then it will log to the syslog.
    #
    # Not that the -d switch will control the log verbosity.
    # By default, it runs at log level 1. Log level 9 will churn
    # out scads of useless debugging information. Values in between
    # will vary the amount of logging you get.
    #

    logfile = /var/log/mt-daapd.log

    #
    # art_filename (optional)
    #
    # There is experimental support thanks to Hiren Joshi
    # ([email protected]) for dynamically adding art to the id3v2
    # header as it is streamed (!!). If you were using a music system
    # like zina or andromeda, for example, with cover art called
    # "_folderOpenImage.jpg", you could use the parameter
    # art_file _folderOpenImage.jpg and if the file _folderOpenImage.jpg
    # was located in the same folder as the .mp3 file, it would appear
    # in iTunes. Cool, eh?
    #

    #art_filename = _folderOpenImage.jpg

    #
    # rescan_interval
    #
    # How often to check the file system to see if any mp3 files
    # have been added or removed.
    #
    # if not specified, the default is 0, which disables background scanning.
    #
    # If background rescanning is disabled, a scan can still be forced from the
    # "status" page of the administrative web interface
    #
    # Setting a rescan_interval lower than the time it takes to rescan
    # won't hurt anything, it will just waste CPU, and make connect times
    # to the daap server longer.
    #

    # We'll set it to 10 minutes
    #
    rescan_interval = 600

    # always_scan
    #
    # The default behavior is not not do background rescans of the
    # filesystem unless there are clients connected. The thought is to
    # allow the drives to spin down unless they are in use. This might be
    # of more importance in IDE drives that aren't designed to be run
    # 24x7. Forcing a scan through the web interface will always work
    # though, even if no users are connected.

    always_scan = 0

    #
    # process_m3u
    #
    # By default m3u processing is turned off, since most m3u files
    # sitting around in peoples mp3 directories have bad paths, and
    # I hear about it. :)
    #
    # If you are sure your m3u files have good paths (i.e. unixly pathed,
    # with relative paths relative to the directory the m3u is in), then
    # you can turn on m3u processing by setting this directive to 1.
    #
    # I'm not sure "unixly" is a word, but you get the idea.
    #

    #process_m3u = 0

    #
    # scan_type
    #
    #
    # This sets how aggressively mp3 files should be scanned to determ.
    # file length. There are three values:
    #
    # 0 (Normal)
    # Just scan the first mp3 frame to try and calculate size. This will
    # be accurate for most files, but VBR files without an Xing tag will
    # probably have wildly inaccurate file times. This is the default.
    #
    # 1 (Aggressive)
    # This checks the bitrates of 10 frames in the middle of the song.
    # This will still be inaccurate for VBR files without an Xing tag,
    # but they probably won't be quite as inaccurate as 0. This takes
    # more time, obviously, although the time hit will only happen the
    # first time you scan a particular file.
    #
    # 2 (Painfully aggressive)
    # This walks through the entire song, counting the number of frames.
    # This should result in accurate song times, but will take the most
    # time. Again, this will only have to be incurred the first time
    # the file is indexed.
    #

    # scan_type = 0

    #
    # compress
    #
    # Whether to use gzip content-encoding when transferring playlists etc.
    # This was contributed as a patch by Ciamac Moallemi just prior to the 0.2.1
    # release, and as such, hasn't gotten as much testing as other features.
    #
    # This feature should substantially speed up transfers of large databases
    # and playlists, at least where bandwidth is limited.
    #
    # It will eventually default to 1, but currently it defaults to 0.
    #
    # DONT EVEN THINK OF ENABLING THIS ON THE SLUG. IT WILL
    # DEGRADE PERFORMANCE MASSIVELY. It might even trigger the
    # OOM killer, so just pretend this option isn't here.
    #
    # In fact, it's only here for the sake of completeness.

    # compress = 0

    [plugins]
    plugin_dir = /opt/share/mt-daapd/plugins
    plugins = rsp.so,ssc-script.so
    #9144
    rpedde
    Participant

    @sluggi wrote:

    Hi jheinitz,

    Thanks for your quick answer. I checked the things you mentioned.

    1.) have you checked your logfile of the firefly server. Should be /opt/var/log/mt-daapd.log?

    These all look good. It might be a “router not passing multicast” issue.

    What kind of router, and what firmware version do you have? Also, how is your soundbridge and NSLU2 connected? Wired? Or wireless?

    #9145
    sluggi
    Participant

    What kind of router, and what firmware version do you have? Also, how is your soundbridge and NSLU2 connected? Wired? Or wireless?

    The router is:
    Zyxel Prestige 660HW-67
    ZyNOS Firmware-Version: V3.40(SQ.0) | 09/09/2004
    DSL Firmware-Version:TI AR7 01.01.08.00
    Standard:ADSL_G.dmt

    Soundbridge is connect wireless.
    NSLU2 is connected via cable with the router.

    #9146
    rpedde
    Participant

    @sluggi wrote:

    What kind of router, and what firmware version do you have? Also, how is your soundbridge and NSLU2 connected? Wired? Or wireless?

    The router is:
    Zyxel Prestige 660HW-67
    ZyNOS Firmware-Version: V3.40(SQ.0) | 09/09/2004
    DSL Firmware-Version:TI AR7 01.01.08.00
    Standard:ADSL_G.dmt

    Soundbridge is connect wireless.
    NSLU2 is connected via cable with the router.

    There is a 12/25/2005 firmware update here:

    http://www.zyxel.com/web/support_download_list.php?indexflag=20040906164737&ModelIndexflags=0,420050117110858,420041221102511,420041221102520,420050117110916,420050117110934,420050831093216,420050831095441,420060420161739,420060420160946

    It also says 3.40, so I’m not sure if it actually adds any features. I’m prett sure on the Zyxel you just have to enable IGMP v2 in the web admin. The default username is blank with a password of 1234, iirc.

    I’m downloading the user guide right now, so I’ll post more if I find more info on it.

    — Ron

    #9147
    sluggi
    Participant

    There is a 12/25/2005 firmware update here:

    http://www.zyxel.com/web/support_download_list.php?indexflag=20040906164737&ModelIndexflags=0,420050117110858,420041221102511,420041221102520,420050117110916,420050117110934,420050831093216,420050831095441,420060420161739,420060420160946

    It also says 3.40, so I’m not sure if it actually adds any features. I’m prett sure on the Zyxel you just have to enable IGMP v2 in the web admin. The default username is blank with a password of 1234, iirc.

    I’m downloading the user guide right now, so I’ll post more if I find more info on it.

    I have enabled IGMP v2 on the Zyxel. Restart the router. But the result is the same. The SB will not connect/find the mt-daapd.
    The TCP/IP settings on the Zyxel are now:

    TCP/IP
    IP-Adresse 192.168.1.1
    IP-Subnet-Maske 255.255.255.0
    RIP Direction none
    RIP Version not available
    Multicast IGMP-v2

    Up to now I haven’t upgrade the firmware on the Zyxel. Because I’m not sure if my provider settings are lost afterwards.
    — Olaf

    #9148
    rpedde
    Participant

    @sluggi wrote:

    Up to now I haven’t upgrade the firmware on the Zyxel. Because I’m not sure if my provider settings are lost afterwards.

    Don’t blame you on that one.

    Can you attach your soundbridge via wired temporarily for the purposes to testing?

    Also, do you have a PC or a Mac?

    #9149
    sluggi
    Participant

    @rpedde wrote:

    @sluggi wrote:

    Can you attach your soundbridge via wired temporarily for the purposes to testing?
    Also, do you have a PC or a Mac?

    I have a PC.

    Crazy situation.
    I did the following.
    1.Connect the SB wired to the router.
    2.mt-daapd was recognized by the SB
    3.I could connect to the NSLU2. Everything is fine.
    4. I disconnect the SB from the router.
    5. Connect it wireless to the router.
    6. The NSLU32 was recoginzed also if the connection is wireless.
    I’m able to access the MP3 from the slug
    7. I leave my flat for 3 hours.
    8. Fater 3 hours I tried to connect to SB to the slug to mt-daappd wireless. Not possible. Not recognized.
    9. Connect the SB wired to the router again.
    10. mt-daapd was recognized by the SB again
    11. I could connect to the NSLU2
    12. I disconnect from the router by cable.
    13. Try to connect wireless again.
    14. The NSLU2 was recoginzed also if the connection is wireless.
    I’m able to access the MP3 from the slug

    I think there is something strange being connected for a while and
    after a time frame of being switched off the SB is not able to reconnect to the NSLU2/mt-daapd again.

    I don’t know what to do to have a stable connection from the SB wireless to the mt_daapd mediaserver.
    This all happens witout upgrading the firmware of the Zyxel router.

    #9150
    sluggi
    Participant

    In the meantime I’m able to connect the SB to the NSLU2 via WLAN without connecting it before wired.
    The only issue is that I have to restart the SB after a period of inactivity of the SB.
    After this restart I’m able to connect to the mt-daapd via WLAN.

    This is a little bit circumstantially.
    Have some an idea how to solve this problem.

    #9151
    rpedde
    Participant

    @sluggi wrote:

    In the meantime I’m able to connect the SB to the NSLU2 via WLAN without connecting it before wired.
    The only issue is that I have to restart the SB after a period of inactivity of the SB.
    After this restart I’m able to connect to the mt-daapd via WLAN.

    This is a little bit circumstantially.
    Have some an idea how to solve this problem.

    The fundamental cause is that your router isn’t passing multicast between the wired and wireless sides of the network. When you plug it into wired, suddenly your pc sees the stuff, and adds it to itunes and the soundbridge. But after you plug it back into the wireless, then it stops seeing the announcements, and eventually it disappears from both devices. That’s what’s happening.

    The only fix I know is updated firmware, or a router that passes multicast between wired and wireless.

    #9152
    christoph.dahlen
    Participant

    Has there been any update to this issue? I am currently facing the same problem in a pre-buy situation. I have mt-daapd set as included in debian etch and can “see” it on any of my cable-connected workstations using iTunes with Windows or Rythmbox with Ubuntu Linux.

    However, the server is not found when using iTunes on Windows on my wireless connected Laptop.

    I am using the Zyxel Prestige 660HW-63/67 too, the System Status page says:

    System Name:
    ZyNOS F/W Version: V3.40(QQ.7) | 12/13/2005
    DSL FW Version:TI AR7 05.00.03.00
    Standard:ADSL_G.dmt

    #9153
    christoph.dahlen
    Participant

    Okay, ich kann mir (und euch) die Antwort selber geben: Man muß den Router per telnet konfigurieren.

    Im Menü 21.1.4 ist dann der ICMP Filter zu deaktivieren, dann läuft es. Allerdings weiß ich nicht, was für Sicherheitslöcher damit gerissen werden, ober ob ich meine iTunes Bibliothek gerade in der ganzen Welt verteile.

    Gruß,

    Christoph

    #9154
    christoph.dahlen
    Participant

    Ups, sorry, language intermix. Anyhow, solution for me was to log into this router using telnet, then go to menu 21 -> 1 -> 4 and disable the (only) ICMP filter found.

    But beware – I do not know wether this opens any attack vector or spreads your music library throughout the entire internet.

    #9155
    clouseau
    Guest

    Before stumbling on the solution presented by Christoph (thanks), I found another (slightly more aggressive) workaround that worked well for me so far: On the FireFly server (wired), I enabled a firewall rule to convert (matching) outgoing multicast packets into (local) broadcast packets, which my Zyxel router *does* forward to the wireless domain.

    Even though I prefer Christoph’s fix (I’ll try it soon), I’m posting my workaround here as it may be useful for other multicast eating routers as well and it points out a strange difference between the iTunes and FireFly servers.

    My setup: I don’t have any Soundbridge (yet?), my client is iTunes on a wireless old (and hence small) iBook and my server is a wired linux box running FireFly (actually another, slightly more recent iBook). I also have a Zyxel Prestige router (660HW-67, FW version V3.40(QD.7)).

    I experienced the same effect, i.e. things worked well while the client was plugged in wired but not if it was connected wirelessly. By sniffing packets on client and server, I could prove the suspect, which was already stated multiple times, that the router isn’t forwarding multicasts from wired -> wireless domain while wireless -> wired works for whatever reason.

    Setting up the following firewall rule on the FireFly box `solved’ the problem:


    iptables -t nat -v -A OUTPUT -d 224.0.0.251 -p udp --dport 5353 -j DNAT --to-destination 192.168.1.255
    # (replace 192.168.1.255 with your local subnet broadcast address, of course)

    However, the thing that still wonders me is that even without the workaround, things work well if I use iTunes instead of FireFly as the (still wired) music server. (Even though it’s running only on a virtual OSX on the same linux iBook via MOL).

    I’ve seen that in this case, the MDNS packets, that are sent from the server to the client during client startup phase are *NOT* using multicast but unicast, directed directly to the client, which has sent several MDNS multicast packets before. (Which makes sense to me as the client is now known, but note that I’ve absolutely no knowledge about the whole MDNS stuff, I don’t even know what it stands for, it’s just what wireshark is telling me). And even more strange, this is not always the case: If I plug in the iTunes client wired (where multicasts are well forwarded by the router), the server *is* using multicast for his MDNS packets. As if iTunes knowed when to prefer unicast to multicast. Maybe I should repeat this test with Christian’s router fix…

    However, here are my wireshark logs during client iTunes startup phase. Sorry for the CUPS stuff in between. Let me know if you need the full logs.

    my IP addresses:

    192.168.1.1 – Zyxel router
    192.168.1.33 – wired FireFly server
    192.168.1.34 – wireless iTunes client
    192.168.1.37 – wired iTunes client
    192.168.1.50 – wired iTunes server (virtual)

    (1) wired iTunes server, wireless iTunes client:


    No. Time Size Source S-port Destination D-port Protocol Info
    1 0.000000 70 fe80::230:65ff:fe1d:cef0 ff02::2 ICMPv6 Router solicitation
    2 1.494134 231 192.168.1.33 631 192.168.1.255 631 CUPS ipp://192.168.1.33:631/printers/hpcolor-2 (idle)
    3 6.624196 46 192.168.1.34 51219 192.168.1.1 192 UDP Source port: 51219 Destination port: 192
    4 7.474241 247 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query PTR _afpovertcp._tcp.local, "QM" question PTR _smb._tcp.local, "QM" question[Packet size limited during capture]
    5 7.969598 526 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query response[Packet size limited during capture]
    6 8.209587 78 192.168.1.34 51220 239.255.255.253 427 SRVLOC Service Request
    7 8.212093 78 192.168.1.34 51221 239.255.255.253 427 SRVLOC Service Request
    8 8.214295 78 192.168.1.34 51222 239.255.255.253 427 SRVLOC Service Request
    9 8.216470 78 192.168.1.34 51223 239.255.255.253 427 SRVLOC Service Request
    10 8.312628 70 fe80::230:65ff:fe1d:cef0 ff02::2 ICMPv6 Router solicitation
    11 10.138452 92 192.168.1.34 51224 192.168.1.255 137 NBNS Name query NB WORKGROUP<1d>
    12 10.414420 92 192.168.1.34 51224 192.168.1.255 137 NBNS Name query NB WORKGROUP<1d>
    13 10.755506 92 192.168.1.34 51224 192.168.1.255 137 NBNS Name query NB WORKGROUP<1d>
    14 12.382816 92 192.168.1.34 51225 192.168.1.255 137 NBNS Name query NB WORKGROUP<00>
    15 12.658288 92 192.168.1.34 51225 192.168.1.255 137 NBNS Name query NB WORKGROUP<00>
    16 12.980166 92 192.168.1.34 51225 192.168.1.255 137 NBNS Name query NB WORKGROUP<00>
    17 15.211276 78 192.168.1.34 51220 239.255.255.253 427 SRVLOC Service Request
    18 15.212986 78 192.168.1.34 51221 239.255.255.253 427 SRVLOC Service Request
    19 15.215217 78 192.168.1.34 51222 239.255.255.253 427 SRVLOC Service Request
    20 15.217522 78 192.168.1.34 51223 239.255.255.253 427 SRVLOC Service Request
    21 15.898782 104 192.168.1.50 49293 192.168.1.34 51220 UDP Source port: 49293 Destination port: 51220
    22 15.903162 104 192.168.1.50 49294 192.168.1.34 51220 UDP Source port: 49294 Destination port: 51220
    23 16.328913 70 fe80::230:65ff:fe1d:cef0 ff02::2 ICMPv6 Router solicitation
    24 17.515005 222 192.168.1.33 631 192.168.1.255 631 CUPS ipp://192.168.1.33:631/printers/hpcolor (idle)
    25 20.251739 84 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query PTR _appletv-pair._tcp.local, "QU" question
    26 20.352655 79 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query PTR _appletv._tcp.local, "QU" question
    27 20.453208 76 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query PTR _daap._tcp.local, "QU" question
    28 20.466010 311 192.168.1.50 5353 192.168.1.34 5353 MDNS Standard query response PTR Jever OSX._daap._tcp.local[Packet size limited during capture]
    29 20.642771 125 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query[Packet size limited during capture]
    30 20.892840 125 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query[Packet size limited during capture]
    31 21.143958 125 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query[Packet size limited during capture]
    32 21.251533 135 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query PTR _appletv-pair._tcp.local, "QM" question[Packet size limited during capture]
    33 21.395122 386 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query response AAAA, cache flush fe80::230:65ff:fe1d:cef0[Packet size limited during capture]
    34 22.394255 386 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query response AAAA, cache flush fe80::230:65ff:fe1d:cef0[Packet size limited during capture]
    35 23.444972 171 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query PTR _appletv-pair._tcp.local, "QM" question[Packet size limited during capture]
    36 24.379173 265 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query SRV Jever OSX._daap._tcp.local, "QU" question TXT Jever OSX._daap._tcp.local, "QU" question[Packet size limited during capture]
    37 24.509087 386 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query response AAAA, cache flush fe80::230:65ff:fe1d:cef0[Packet size limited during capture]
    38 24.730718 70 fe80::230:65ff:fe1d:cef0 ff02::2 ICMPv6 Router solicitation
    39 25.384780 498 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query SRV Jever OSX._daap._tcp.local, "QM" question TXT Jever OSX._daap._tcp.local, "QM" question[Packet size limited during capture]
    40 27.463268 356 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query PTR _appletv-pair._tcp.local, "QM" question[Packet size limited during capture]
    41 28.508214 386 192.168.1.34 5353 224.0.0.251 5353 MDNS Standard query response AAAA, cache flush fe80::230:65ff:fe1d:cef0[Packet size limited during capture]

    (2) wired iTunes server, wired iTunes client:


    No. Time Size Source S-port Destination D-port Protocol Info
    1 0.000000 235 192.168.1.33 631 192.168.1.255 631 CUPS ipp://192.168.1.33:631/printers/hpcolor-2 (idle)
    2 5.822212 247 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query PTR _afpovertcp._tcp.local, "QM" question PTR _smb._tcp.local, "QM" question[Packet size limited during capture]
    3 6.662941 195 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query response PTR[Packet size limited during capture]
    4 16.001773 226 192.168.1.33 631 192.168.1.255 631 CUPS ipp://192.168.1.33:631/printers/hpcolor (idle)
    5 22.457521 84 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query PTR _appletv-pair._tcp.local, "QU" question
    6 22.558238 79 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query PTR _appletv._tcp.local, "QU" question
    7 22.658735 100 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query PTR _daap._tcp.local, "QU" question[Packet size limited during capture]
    8 22.867931 125 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query[Packet size limited during capture]
    9 23.118196 125 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query[Packet size limited during capture]
    10 23.368666 125 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query[Packet size limited during capture]
    11 23.470204 135 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query PTR _appletv-pair._tcp.local, "QM" question[Packet size limited during capture]
    12 23.620209 386 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query response AAAA, cache flush fe80::203:93ff:fe46:ff5e[Packet size limited during capture]
    13 24.316159 363 192.168.1.50 5353 224.0.0.251 5353 MDNS Standard query[Packet size limited during capture]
    14 24.620557 386 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query response AAAA, cache flush fe80::203:93ff:fe46:ff5e[Packet size limited during capture]
    15 25.470377 171 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query PTR _appletv-pair._tcp.local, "QM" question[Packet size limited during capture]
    16 26.916340 386 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query response AAAA, cache flush fe80::203:93ff:fe46:ff5e[Packet size limited during capture]
    17 27.052508 80 192.168.1.50 5353 224.0.0.251 5353 MDNS Standard query PTR _raop._tcp.local, "QM" question
    18 28.724075 498 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query SRV Jever OSX._daap._tcp.local, "QM" question TXT Jever OSX._daap._tcp.local, "QM" question[Packet size limited during capture]
    19 29.470108 171 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query PTR _appletv-pair._tcp.local, "QM" question[Packet size limited during capture]
    20 29.672458 352 192.168.1.50 5353 224.0.0.251 5353 MDNS Standard query response A, cache flush 192.168.1.50 AAAA, cache flush[Packet size limited during capture]
    21 30.915906 386 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query response AAAA, cache flush fe80::203:93ff:fe46:ff5e[Packet size limited during capture]
    22 31.022144 235 192.168.1.33 631 192.168.1.255 631 CUPS ipp://192.168.1.33:631/printers/hpcolor-2 (idle)
    23 34.725444 498 192.168.1.37 5353 224.0.0.251 5353 MDNS Standard query SRV Jever OSX._daap._tcp.local, "QM" question TXT Jever OSX._daap._tcp.local, "QM" question[Packet size limited during capture]
Viewing 15 posts - 1 through 15 (of 16 total)
  • The forum ‘Setup Issues’ is closed to new topics and replies.