JEmplode "ethernet broadcase" discovery protocol bug?

Quote:
Quote:
Okay, I just traced what Emplode does. It sends completely different discovery broadcast packets, compared with JEmplode. And Emplode actually finds the empeg.

So, somehow JEmplode just has the wrong discovery protocol altogether.

Ah, that makes a certain amount of sense. Jemplode is sort-of the same thing as Rio Music Manager Light, aimed at the Rio Karma... and you do indeed find Karmas using UPnP-style (actually SSDP) multicasting. The Empeg, on the other hand, was invented before SSDP was and uses a custom protocol. Maybe the most recent Jemplode build accidentally has the Karma discovery code enabled and not the Empeg discovery code?

SSDP discovery was slated to be added to car-player v3 software, but never made it beyond the experimental stage.

Peter

Yup, that all makes sense -- the IP address and port matches the Karma discovery.

Mmm.. I suppose I could just have Hijack listen/respond to those requests, if I knew what the correct response was supposed to be.

But it's probably simpler (ha!) to try and get JEmplode rebuilt with the correct protocol enabled.

Cheers

Posted by: mlord

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 02/11/2006 14:11

And ensure the options are set up like this:

Posted by: andy

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 02/11/2006 14:51

I am using jEmplode 69.0000000000000000001 that I downloaded from the jempeg.org website today.

File size 1,969,173 bytes

Options are set only to Ethernet Broadcast, running on WinXP SP2.

Posted by: mlord

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 02/11/2006 16:09

Quote:
I am using jEmplode 69.0000000000000000001 that I downloaded from the jempeg.org website today.

File size 1,969,173 bytes

Options are set only to Ethernet Broadcast, running on WinXP SP2.

Mmm. Looking inside jemplode.jar, one can see that the code seems to be present for both SSDP (karma) and "IDiscovery" (empeg?) -- so somehow it's choosing not to run the other protocol here. A network trace proves this point (no normal empeg discovery is ever attempted, only the SSDP crap).

What java version?

Thanks

Posted by: peter

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 02/11/2006 16:24

Quote:
Mmm. Looking inside jemplode.jar, one can see that the code seems to be present for both SSDP (karma) and "IDiscovery" (empeg?) -- so somehow it's choosing not to run the other protocol here. A network trace proves this point (no normal empeg discovery is ever attempted, only the SSDP crap).

Can you strace the java process, or is that just asking for trouble? Is the Jemplode host multi-homed?

Peter

Posted by: JBjorgen

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 02/11/2006 17:01

Just as another datapoint, ditto what Andy said on both jEmplode 69.0000000000000000001 and jEmplode 70. Also running XP SP2

Posted by: andy

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 02/11/2006 19:37

Quote:

What java version?

I have 1.4.2 on this machine, but I have 1.5.something on my other machine that also works.

I have rarely seen discovery not work with jEmplode, over a series of versions of jEmplode and Java. All of this on Windows.

Posted by: mlord

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 02/11/2006 20:37

Quote:

Can you strace the java process, or is that just asking for trouble? Is the Jemplode host multi-homed?

strace on it seems to work. I wonder what to look for inside the trace? "send", I suppose:

Code:

[pid 22137] sendto(5, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22137] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22137] sendto(5, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 22137] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 22137] sendto(5, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22137] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22140] sendto(10, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("255.255.255.255")}, 16) = 1
[pid 22140] sendto(10, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.255.255.255")}, 16) = 1
[pid 22140] sendto(10, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.0.255.255")}, 16) = 1
[pid 22140] sendto(10, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.0.1.255")}, 16) = 1
[pid 22145] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("255.255.255.255")}, 16 <unfinished ...>
[pid 22144] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22144] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22144] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 22144] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 22144] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22144] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 22145] <... sendto resumed> )      = 1
[pid 22145] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.255.255.255")}, 16 <unfinished ...>
[pid 22145] <... sendto resumed> )      = 1
[pid 22145] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.0.255.255")}, 16) = 1
[pid 22145] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("127.0.1.255")}, 16) = 1

Mmm.. well, the references to port 8300 are for the regular empeg discovery method. But for some reason it's not using a valid broadcast IP address for them. Hmmph.
Code:

eth0      Link encap:Ethernet  HWaddr 00:11:43:7A:5A:B9
          inet addr:10.0.0.14  Bcast:10.0.0.127  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1860566 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1570532 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1199584566 (1.1 GiB)  TX bytes:470436122 (448.6 MiB)
          Interrupt:19

Posted by: mlord

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 02/11/2006 20:56

Ahh.. bingo. Something is causing it to parse /etc/hosts to try and find the local ip address. Why does it do such a silly thing? Dunno, but it does.

Of course, my machine just has the loopback entries there, since the actual IP address depends very much upon the whims of whichever DHCP server I'm connecting through.

Duh.

If I hardcode my current IP address in /etc/hosts, then it works, but that's not a great solution.

Cheers

Posted by: mlord

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 02/11/2006 20:57

Ahh.. waitaminute.. there was a loopback entry in /etc/hosts for the local hostname.. delete that line completely and it also now works.

Yippie!

Thanks for suggesting the obvious, peter!

Posted by: peter

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 03/11/2006 07:31

Glad you got it working, though I'm still a bit confused. If this is a single-homed Linux box, the all-ones address should have worked. And reading /etc/hosts wouldn't tell it that your netmask was /25 as opposed to /8 or /24. So it'd be interesting to see what packets it's sending now that it works. It's almost as if it was successfully sending to the all-ones address, but saying "reply to 127.0.0.1" because that's what it thinks its IP address is, so the reply never went anywhere -- but in that case, Wireshark should have seen the outgoing packet.

Peter

Posted by: mlord

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 03/11/2006 13:37

Quote:
Glad you got it working, though I'm still a bit confused. If this is a single-homed Linux box, the all-ones address should have worked.

I think Linux may be set to filter out anything that doesn't match the subnet -- but I'll check that again with the analyser shortly.

Quote:
And reading /etc/hosts wouldn't tell it that your netmask was /25 as opposed to /8 or /24.

Right. And yes indeed, it is just blindly attempting 8/16/24 bit subnet masks regardless.

So it'd be interesting to see what packets it's sending now that it works.

Code:

[pid 26117] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 26117] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 26117] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 26117] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 115, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 115
[pid 26117] sendto(9, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 26117] sendto(10, "M-SEARCH * HTTP/1.1\r\nHost: 239.2"..., 109, 0, {sa_family=AF_INET, sin_port=htons(1900), sin_addr=inet_addr("239.255.255.250")}, 16) = 109
[pid 26120] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("255.255.255.255")}, 16) = 1
[pid 26120] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.255.255.255")}, 16) = 1
[pid 26120] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.255.255")}, 16) = 1
[pid 26120] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.0.255")}, 16) = 1
[pid 26120] recvfrom(5, "id=10101984\nname=george", 4096, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.0.16")}, [16]) = 23

Posted by: mlord

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 03/11/2006 13:49

Hmm.. it works (mostly), but is still flakey for some reason. Witness this:
Code:

[pid 26183] bind(5, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.0.14")}, 16 <unfinished ...>
[pid 26185] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("255.255.255.255")}, 16 <unfinished ...>
[pid 26185] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.255.255.255")}, 16) = 1
[pid 26185] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.255.255")}, 16) = 1
[pid 26185] sendto(5, "?", 1, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.0.255")}, 16) = 1
[pid 26185] recvfrom(5, "id=10101984\nname=george", 4096, 0, {sa_family=AF_INET, sin_port=htons(8300), sin_addr=inet_addr("10.0.0.16")}, [16]) = 23

Another machine on the same *switch* saw only the 255.255.255.255 broadcast, along with the reply from george. I wonder where the other broadcast packets went to?

[EDIT]Oh, wait.. the other packets were not valid broadcast addresses, so they either got dropped or just not delivered by the switch to the monitoring machine (nor to any of the empegs!).[/EDIT]

Mmm.. I suppose I really have to use a hub rather than a switch to know for sure. But enough is enough. It works now (mostly).

Cheers

Posted by: mlord

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 03/11/2006 13:52

Mmm.. I wonder of the nagle algorithm is getting in the way, or is that strictly just a TCP thing?

[EDIT] Scratch that. It all makes sense now in the edited post above. The 255.255.255.255 address is the only one that is actually working here, because of my 7-bit subnet.[/EDIT]

Posted by: BAKup

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 03/11/2006 15:05

Something I've noticed on my linux box that I'm using for a router/NAT is that unless I put in a route for 255.255.255.255 to go out through the internal interface, it will go out the external interface due to the default route. I learned that one by dealing with xPL where all the hubs on the network talk to each other using the broadcast address.

Posted by: wfaulk

Re: JEmplode "ethernet broadcase" discovery protocol bug? - 03/11/2006 15:17

Quote:
Quote:
The last time I looked at this, the problem was that jEmplode was sending out guesses as to the broadcast address because Java doesn't have hooks low enough in the OS in order to find the real broadcast address. On several of my networks, its guesses were wrong. Are you sure that's not your problem?

Quite positive, thanks.

It's simply using the Karma protocol rather than the Empeg protocol.

...

Posted by: wfaulk

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 03/11/2006 15:19

Quote:
Ahh.. bingo. Something is causing it to parse /etc/hosts to try and find the local ip address. Why does it do such a silly thing? Dunno, but it does.

Again, because Java doesn't have hooks low enough in the IP stack to get it to return quality IP addressing information.

Posted by: wfaulk

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 03/11/2006 15:22

Quote:
Ahh.. waitaminute.. there was a loopback entry in /etc/hosts for the local hostname.. delete that line completely and it also now works.

Speaking of which:

You probably have a decent amount of pull in the Linux community. Can you tell everybody that this default of having the local hostname in /etc/hosts as 127.0.0.1 is complete brokenness, please? I know it's not a Linux issue, but virtually every distribution does it and it's 100% wrong. It causes a lot of problems like this.

Posted by: peter

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 03/11/2006 16:04

Quote:
It all makes sense now in the edited post above. The 255.255.255.255 address is the only one that is actually working here, because of my 7-bit subnet.

Except that that doesn't make sense -- because it was sending to 255.255.255.255 even before you changed /etc/hosts...?

Peter

Posted by: mlord

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 03/11/2006 16:09

Quote:
Quote:
It all makes sense now in the edited post above. The 255.255.255.255 address is the only one that is actually working here, because of my 7-bit subnet.

Except that that doesn't make sense -- because it was sending to 255.255.255.255 even before you changed /etc/hosts...?

Peter

Yeah, but then I'll bet it was using 127.* as the reply address..

Posted by: peter

Re: JEmplode "ethernet broadcast" discovery protocol bug? - 03/11/2006 16:13

Quote:
Yeah, but then I'll bet it was using 127.* as the reply address..

Packets with 127.0.0.1 as the src_ip? Oooh, by binding the local UDP socket to it? Is that even allowed? If so then I guess that would explain why Wireshark didn't see the packet -- if you had it set up to filter on src_ip=<the.correct.address>...

Peter

JEmplode "ethernet broadcase" discovery protocol bug?