T3.6 & WIZ820io + Bonjour

Status
Not open for further replies.

holynoise

Member
Hi.
My T3.6 with WIZ820io using the adaptor plate works perfectly on DHCP and static ip. I want to add Bonjour support and installed this library (https://github.com/TrippyLighting/EthernetBonjour) which installs and compiles successfully.

it reads the MAC address correctly and also I can ping the DHCP-assigned IP. As soon as the code uses Bonjour things get mixed up.
EthernetBonjour.begin("arduino");
is ok - however I can't resolve arduino.local on my mac.

2nd line:
int res = EthernetBonjour.addServiceRecord("test._http",
80,
MDNSServiceTCP, NULL);

works sometimes. after unplugging the Teensy it always continues and res = 1 which means success. Sometimes it hangs/crashes inside this method. When I use:

int res = EthernetBonjour.addServiceRecord("test._http",
80,
MDNSServiceTCP);

without the TXT record, it crashes way more often.

The NULL thing is something I came up with by looking at the library code:
Code:
// return values:
// 1 on success
// 0 otherwise
int EthernetBonjourClass::addServiceRecord(const char* name, uint16_t port,
                                           MDNSServiceProtocol_t proto)
{
#if defined(__MK20DX128__) || defined(__MK20DX256__)
	 return this->addServiceRecord(name, port, proto, NULL); //works for Teensy 3 (32-bit Arm Cortex)
#else
   return this->addServiceRecord(name, port, proto, ""); //works for Teensy 2 (8-bit Atmel)
#endif
}

No matter what I do, when having a good spin (no crashes) the loop() get's executed I can see the webserver page using the ip address but the Teensy will never register it's hostname nor any Bonjour service records (using OSX Bonjour Browser application I can see a lot of Bonjour services of other devices in my LAN but never my arduino).

In addition none of the example sketches bundled with the library works correctly. My network seems to be OK, I tried different routers - no luck.

I tried for hours but couldn't narrow it down so far. I would like to ask:

- my WIZ820 works basically. But multicast doesn't seem to work. Is this a known limitation?
- is this library (which I think it's the newest I've found and is built on EthernetUDP rather than direct HW calls to w5100) compatible with the T3.6? Which library is a good one to test?
- are there any differences between a Teensy 3.0 to Teensy 3.6 in regards to this? Could it be that this library simply won't work on a 3.6 but would work fine on 3.0/3.1/3.2?
- Are there any plans to include Bonjour in the Teensy library of Ethernet?
- any pointer on how to troubleshoot this?

any help would be very much appreciated! thanks!!!!

This is my code:

Code:
//  Illustrates how to register a Bonjour service.

#include <SPI.h>
#include <Ethernet.h>
#include <EthernetBonjour.h>
#include <T3Mac.h>

EthernetServer server(80);

  // for measuring how long a routine takes
uint32_t time_start, time_stop;

void setup()
{

  //pinMode(4, INPUT_PULLUP);
  //pinMode(10, INPUT_PULLUP);
  delay(1);  // allow time for both pins to reach 3.3V

  // Open serial communications and wait for port to open:
  Serial.begin(115200);

  // Wait here for up to 10 seconds to see if we will use Serial Monitor, so output is not lost
  while((!Serial) && (millis()<10000));    // wait until serial monitor is open or timeout,
  Serial.print(millis());
  Serial.println(" msec to start serial");

  Serial.println("myBonjour");

  char ID[32];
  sprintf(ID, "%08lX %08lX %08lX %08lX", SIM_UIDH, SIM_UIDMH, SIM_UIDML, SIM_UIDL);
  Serial.print("Teensy3 128-bit UniqueID: ");
  Serial.println(ID);

  pinMode(12, INPUT);   // help make sure MISO is input to Teensy

  delay(1000);


  Serial.print("MAC from Teensy: ");
  read_mac();
  print_mac();
  Serial.println();

  uint8_t tries=1;
  uint8_t flag=0;

  // start the Ethernet connection, try 8 times
  do
    {
    Serial.print("Try ");
    Serial.print(tries);
    Serial.print(":");
    flag = ethernet_start(mac, true); // 0 if failed
    Serial.print(flag);
    Serial.print(" ");
    }
  while ((tries++ < 5) && (flag == 0));

  if (0!=flag)
  {
    // Ethernet started OK
    Serial.print("Ethernet started after ");
  }
  else
  {
    Serial.print("Ethernet start failed even after ");
  }
  Serial.print(tries-1);  // loop already incremented it
  Serial.println(" attempts");


    for (byte thisByte = 0; thisByte < 4; thisByte++)
    {
      // print the value of each byte of the IP address:
      Serial.print(Ethernet.localIP()[thisByte], DEC);
      if (thisByte < 3) Serial.print(".");  // don't print trailing period
      
    }

    Serial.println();

  // Initialize the Bonjour/MDNS library. You can now reach or ping this
  // Arduino via the host name "arduino.local", provided that your operating
  // system is Bonjour-enabled (such as MacOS X).
  // Always call this before any other method!
  EthernetBonjour.begin("arduino"); //standart name is arduino

  // Now let's register the service we're offering (a web service) via Bonjour!
  // To do so, we call the addServiceRecord() method. The first argument is the
  // name of our service instance and its type, separated by a dot. In this
  // case, the service type is _http. There are many other service types, use
  // google to look up some common ones, but you can also invent your own
  // service type, like _mycoolservice - As long as your clients know what to
  // look for, you're good to go.
  // The second argument is the port on which the service is running. This is
  // port 80 here, the standard HTTP port.
  // The last argument is the protocol type of the service, either TCP or UDP.
  // Of course, our service is a TCP service.
  // With the service registered, it will show up in a Bonjour-enabled web
  // browser. As an example, if you are using Apple's Safari, you will now see
  // the service under Bookmarks -> Bonjour (Provided that you have enabled
  // Bonjour in the "Bookmarks" preferences in Safari).
  
  int res = EthernetBonjour.addServiceRecord("test._http",
                                   80,
                                   MDNSServiceTCP, NULL);
  
  
  Serial.println("res="+String(res));
}

/**
 * Try to begin ethernet with mac value, which means using DHCP.
 *
 * For non-DHCP different constructor with GW, etc is used.
 * @param verbose output status if true
 * @see https://www.arduino.cc/en/Reference/Ethernet
 * @return 0 if failed, 1 if success
 */
int8_t ethernet_start(uint8_t mac[], boolean verbose)
{
  int8_t status = 0;  // 0 = failed
  time_start = millis();
  status = Ethernet.begin(mac);
  time_stop = millis();

  if (verbose)
  {
    if (0==status)
    {
      Serial.print("Fail DHCP after ");
    }
    else
    {
      Serial.print("OK DHCP after ");
    }
    Serial.print(time_stop-time_start);
    Serial.println(" msec");
  }
  return status;
}


void loop()
{ 
  // This actually runs the Bonjour module. YOU HAVE TO CALL THIS PERIODICALLY,
  // OR NOTHING WILL WORK! Preferably, call it once per loop().
  EthernetBonjour.run();

  // The code below is just taken from the "WebServer" example in the Ethernet
  // library. The only difference here is that this web server gets announced
  // over Bonjour, but this happens in setup(). This just displays something
  // in the browser when you connect.
  EthernetClient client = server.available();
  if (client) {
    // an http request ends with a blank line
    boolean current_line_is_blank = true;
    while (client.connected()) {
      if (client.available()) {
        char c = client.read();
        // if we've gotten to the end of the line (received a newline
        // character) and the line is blank, the http request has ended,
        // so we can send a reply
        if (c == '\n' && current_line_is_blank) {
          // send a standard http response header
          client.println("HTTP/1.1 200 OK");
          client.println("Content-Type: text/html");
          client.println();
          
          client.println("Hello from a Bonjour-enabled web-server running ");
          client.println("on your Arduino board!");

          break;
        }
        if (c == '\n') {
          // we're starting a new line
          current_line_is_blank = true;
        } else if (c != '\r') {
          // we've gotten a character on the current line
          current_line_is_blank = false;
        }
      }
    }
    // give the web browser time to receive the data
    delay(1);
    client.stop();
  }
}
 
probably won't solve your problem, but you need to increase the size of ID to at least 36
 
probably won't solve your problem, but you need to increase the size of ID to at least 36

Thanks. Which id do you refer to? the mac address array?


Using a static address and some further troubleshooting I managed to see a MDNS package on Wireshark. However it is being sent to destination address 0.0.0.0 instead of the multicast address 224.0.0.251.

Screenshot 2017-02-10 02.32.12.jpg

Using DHCP I see malformed BOOTP request instead of MDNS packages. Very strange - although the ip is set correctly and I can ping it.

It's sending this "semi-correct" MDNS package as it should repeatedly - so part of it is working. However Bonjour Browser will not see it and I guess it's due to the destination address not being the correct. Drilling down to the libraries, I cannot see where i looses the correctly set multicast address.

In EthernetBonjour.cpp I see the calls to
Code:
statusCode = this->beginMulticast(mdnsMulticastIPAddr, MDNS_SERVER_PORT);

with:
Code:
#define  MDNS_SERVER_PORT        (5353)
static uint8_t mdnsMulticastIPAddr[] = { 224, 0, 0, 251 };

(correct destination address and port)

In EthernetUdp.cpp (in the Teensy Ethernet library) I see:

Code:
uint8_t EthernetUDP::beginMulticast(IPAddress ip, uint16_t port)
{
	if (sockindex < MAX_SOCK_NUM) Ethernet.socketClose(sockindex);
	sockindex = Ethernet.socketBegin(SnMR::UDP | SnMR::MULTI, port);
	if (sockindex >= MAX_SOCK_NUM) return 0;
	_port = port;
	_remaining = 0;
	// Calculate MAC address from Multicast IP Address
	byte mac[] = {  0x01, 0x00, 0x5E, 0x00, 0x00, 0x00 };
	mac[3] = ip[1] & 0x7F;
	mac[4] = ip[2];
	mac[5] = ip[3];
	W5100.writeSnDIPR(sockindex, rawIPAddress(ip));   //239.255.0.1
	W5100.writeSnDPORT(sockindex, port);
	W5100.writeSnDHAR(sockindex, mac);
	return 1;
}

which should respect the arguments value, no?

any pointer on this?

many thanks.
 
char ID[32];

your sprintf() is over-writing stack

Thanks! I increased the array but obviously it doesn't solve my main problem. Destination IP address is always set to 0.0.0.0. I traced all calls from Bonjour down to the w5100 library and everywhere the correct destination ip address is set - it's lost somewhere. The payload itself looks fine and is a valid MDNS packet. The same thing happens when I create and send a Multicast UDP packet "by hand" without the use of the Bonjour library. Wireshark will report it as 0.0.0.0 but all other devices have destination ip set correctly (and these ones will appear in Bonjour Browser).

The library sets the SnDIPR and SnDPORT registers before filling and SPI transmitting the data buffer with a final execCmdSn(s, Sock_SEND), waiting until sent, then reporting success and writing back SnIR::SEND_OK to the SnIR register of the W5100 abstraction class. This is correct behavior as the SnDIPR and SnDPORT registers must be set before opening the socket itself which I thought could have been the problem but apparently the destination ip address is not respected either by SPI or the firmware of the w5100 chip....

No Bonjour for me... really bad ;-(

PS: my network was everything from fully fledged back to direct cross-over cable without a router - it's not the network...
 
Have you tested the library on a T3.1 or T3.2?

Re: #if defined(__MK20DX128__) || defined(__MK20DX256__)
In EthernetBonjour.cpp you probably need to add the symbols for the T3.5/T3.6
__MK66FX1M0__
__MK64FX512__
 
Thank you very much! This should solve my "NULL" problem when using a TXT record.

I doesn't help about the destination IP and destination mac. But just 5min ago I managed to get it work. Destination IP and Destination MAC is now correctly sent (I had massive impact in the socket and Udp library by chaning the order when the registers are set. It appears that with the latest Ethernet library the socket reference is taken from the chip (4 or 8 sockets - don't know) and THEN the destination IP and destination MAC is set but this will not be respected. Those registers must be set BEFORE retaining the socket but this can't be done as the multi-socket management will first query all free sockets and then opens it immediatly - too early to set the destination ip and mac). The packet now looks like a "correct" MDNS packet on wireshark but it still doesn't show in Bonjour Browser. I have a feeling that response and query is mixed up... will chase this down....
 
I don't have a T3.2 to test. Maybe somebody can run the Bonjour example on a T3.6 and confirm the issue?!

After having the libraries sending mdns correctly it turned out that parsePacket on socket 0 (which is the first one and is the one opened with beginMulticast()) will never report any bytes received even when sending data manually to the 5353 port using udp and the mdns multicast adress. The packet arrives as the led is blinking but it's either the socket management is mixed up or the packet gets dropped for another reason. Receiving on another socket (tcp port 80) is working.

Can't wait to have a working Bonjour library on T3.6 and wiz820/w5200.



Thank you very much! This should solve my "NULL" problem when using a TXT record.

I doesn't help about the destination IP and destination mac. But just 5min ago I managed to get it work. Destination IP and Destination MAC is now correctly sent (I had massive impact in the socket and Udp library by chaning the order when the registers are set. It appears that with the latest Ethernet library the socket reference is taken from the chip (4 or 8 sockets - don't know) and THEN the destination IP and destination MAC is set but this will not be respected. Those registers must be set BEFORE retaining the socket but this can't be done as the multi-socket management will first query all free sockets and then opens it immediatly - too early to set the destination ip and mac). The packet now looks like a "correct" MDNS packet on wireshark but it still doesn't show in Bonjour Browser. I have a feeling that response and query is mixed up... will chase this down....
 
Do you have an UNO or any Arduino boards? I wonder if the Arduino ethernet lib still works with bonjour lib. Paul has been optimizing the Teensy version of the ethernet lib, it's possible that has introduced some bugs? I don't know if the Arduino ethernet lib will work with the T3.6, but that might be something to try. Or maybe compare the source files ...

As you noted, when i look at beginMulticast() in EthernetUdp.cpp, the teensy version has re-orered the socket() call.
 
Last edited:
Yes I do have a arduino (mega und uno) but no ethernet shield. And my application needs Teensy features. I really hope that somebody can help here as I'm new to all this. Would it be a good test to install a old Ethernet library together with a hopefully matching Bonjour library on the Teensy 3.6? Or should I just write my own Multicast listener specifically for incoming mDNS questions? I think it really is only about the receiving side now... no packets are reported but all other socket / protocol-type work.



Do you have an UNO or any Arduino boards? I wonder if the Arduino ethernet lib still works with bonjour lib. Paul has been optimizing the Teensy version of the ethernet lib, it's possible that has introduced some bugs? I don't know if the Arduino ethernet lib will work with the T3.6, but that might be something to try. Or maybe compare the source files ...

As you noted, when i look at beginMulticast() in EthernetUdp.cpp, the teensy version has re-orered the socket() call.
 
If I have some time next week to look into this (a pretty big "if"), can you guys give me any suggestions about the quickest way I could test this library? My main system is Ubuntu Linux, so ideally I'd prefer to run something on Linux to talk with a particular program running on the Teensy (or Arduino). Imagine I know absolutely nothing about this protocol or software that uses it, and I want to minimize time taken away from progress on EHCI USB support. How should I try testing this stuff?
 
Paul: i have C/linux multicast chat program (also java, python, perl) that should work as a simple test with teensy beginMulticast(). it would appear that multicast mac address needs to be set before the socket command to the wiz chip, but there could be other issues ....

holynoise: the other Ethernet lib's all have something missing. the Arduino version is w5100 only. there is a set of patches that could be applied to support w5200. there is an Ethernetv2 lib that supports w5200, but has no beginMulticast(). Fixing beginMulticast in teensy lib might be doable, but then there could be other issues.

i haven't ever tried multicast on wiznet ... yet
 
Last edited:
Ok, sounds good. Can I get the code, and any specific steps I need to know to run it and know whether it's working?
ok, attached is the old C code (you'll get lots of warnings compiling it). You can run C program on multiple boxes on the local net, and what you type to one, should print out on the others. Or a simple test with nc sending a multicast packet
echo "1234" | nc -u 224.7.8.9 7654
 

Attachments

  • mtalk.c
    3.3 KB · Views: 140
Last edited:
Here is what I'd do:

0) make sure you are non-routed/local-link and both endpoints are on wireline (sometimes wifi will not forward multicast to another segment)
1) Install the mentioned library (which claims to be T3 compatible)
2) Open the RegisteringServices example - alternatively you can run my sketch - they are similar but mine has DHCP.
3) what should happen now is:
a) it should compile and run without errors. Do something in loop() so you see it's working or ping the ip address or visit the webserver's page for a quick healthcheck
b) in regular intervals (2 mins) you should see the mDNS/Bonjour packet in Wireshark (set the filter to mdns or ip.src eq 192.168....). Since this is multicast the wiz820 will send a IGMPv2 membership report package automaticaly. This is the effect of the
Code:
int res = EthernetBonjour.addServiceRecord("tiny._http",80,MDNSServiceTCP);
line and is correct behavior.
c) running Bonjour browsers (OSX) or simliar tools on linux you should now see arduino.local offering a service tiny._http on port 80 on the ip address of the teensy.

this is service discovery. Now the other direction (which includes listening to multicast on the Teensy):

for every ping arduino.local on your OSX/linux there should be a mDNS packet including a so called "question". The question simply says: Hey, arduino.local where are you, what is your ipadress and send along your services. This is where the BonjourLibrary should reply (but it doesn't) with a mDNS so called answer. You will see that the package resembles unicast DNS with a A, PTR, SRV record. this is correct.

I have sniffed some samples of this request/response thing using my printer. see attached. This should show you how the packet should look like. I can generate the "Standary query response" which is the proactive method where arduino.local will send it's services without a prior questions/query in 2min interval. Too sad it doesn't show up in Bonjour Browser as the library readme indicates it should.

to break this even more down. Since the sending part if working here and I kinda know where the problem was I think the focus should now be on the receiving side. So let's say we send a malformed mdns packet directly on the CLI on OSX or any linux by entering
Code:
echo "1234" | nc -u -w0 224.0.0.251 5353
which sends the packet as attched in the picture.
upon receiving this (teensy side) this should at least generate some data at the
Code:
if (Ethernet.socketRecvAvailable(sockindex) > 0) {
line in EthernetUdp.cpp in parsePacket method. But it doesn't. one thing I know is that before OPENING the socket the registers must be set to allow multicast and setting the ip address of the one that mDNS uses (which is the correct in the library). Since the pool of the 4 threads will return socket 0 for udp/multicast (because we used the first opened socket for multicast and socket 1... for the webserver) the socket should listen to the multicast address. But it doesn't and I don't know why?!

Screenshot 2017-02-11 20.25.32.jpgScreenshot 2017-02-11 20.24.55.jpgScreenshot 2017-02-11 20.23.35.jpgScreenshot 2017-02-11 20.23.35.jpgScreenshot 2017-02-11 20.22.22.jpgScreenshot 2017-02-11 20.21.54.jpg
 
I can't believe it but I've found the problem!!!!!! ;-)

in the original socket.cpp in method socketSendUDP the Sn_CR register is written with Sock_SEND (0x20) but as the custom multicast MAC address must be sent along with it the correct value is Sock_SEND_MAC (0x21). The manual says:

he basic operation is same as SEND. Normally SEND operation needs Destination Hardware Address that is received in ARP(Address Resolution Protocol) process. SEND_MAC uses Socket n Destination Hardware Address(Sn_DHAR) that is written by users without ARP process.

now it's receiving fine (maybe to accept multicast frames that are being sent to the mac address which is not the burned it one).... and yes finally after hours: I can see my teensy in Bonjour Browser!!!

I consider this as a bug. I will now clean up all my changes and narrow it down until I only have the relevant changes condensed and will propose this for a next release! I guess there must be a socketSendUDPMulticast() that uses this new value... Will do that right now and report my success....

Many thanks for all your help...

patch in socket.cpp (dirty hack):

Code:
int EthernetClass::socketSendUDP(uint8_t s)
{
	SPI.beginTransaction(SPI_ETHERNET_SETTINGS);
	//MULTICAST PATCH was Sock_SEND
	W5100.execCmdSn(s, Sock_SEND_MAC);
	//END OF MULTICAST PATCH

	/* +2008.01 bj */
	while ( (W5100.readSnIR(s) & SnIR::SEND_OK) != SnIR::SEND_OK ) {
		if (W5100.readSnIR(s) & SnIR::TIMEOUT) {
			/* +2008.01 [bj]: clear interrupt */
			W5100.writeSnIR(s, (SnIR::SEND_OK|SnIR::TIMEOUT));
			SPI.endTransaction();
			Serial.printf("sendUDP timeout\n");
			return 0;
		}
		SPI.endTransaction();
		yield();
		SPI.beginTransaction(SPI_ETHERNET_SETTINGS);
	}

	/* +2008.01 bj */
	W5100.writeSnIR(s, SnIR::SEND_OK);
	SPI.endTransaction();

	Serial.printf("sendUDP ok\n");
	/* Sent ok */
	return 1;
}
 
Excellent. I'll give it a try. i just dusted off on old W5100 breakout board and hooked it up to UNO running the following sketch.
https://github.com/manitou48/teensy3/blob/master/mtalk.ino
It does multicast send and recv OK to the linux mtalk program


tcpdump packet from uno
19:04:35.206375 0a:1b:3c:4d:5e:6f > 01:00:5e:07:08:09, ethertype IPv4 (0x0800), length 60: 192.168.1.15.7654 > 224.7.8.9.7654: UDP, length 16

the arduino socket.cpp is still using
W5100.execCmdSn(s, Sock_SEND);

hooked w5100 up to T3.2, it doesn't hear the multicasts from the linux host. it does send out a packet every 5s, but malformed
19:13:19.815484 0a:1b:3c:4d:5e:6f > 00:00:00:00:00:00, ethertype IPv4 (0x0800), length 60: 192.168.1.15.7654 > 0.0.0.0.0: UDP, length 17
(IDE 1.81./1.35) no changes to teensy ether lib
 
Last edited:
Here is the summary:
the registers must not necessarily be written before opening the socket AS LONG AS endPacket->socketSendUDP will write the send Command (Sock_SEND_MAC). So this is all which was needed.
I changed the following files to introduce an additional method name (having multicast in the end). no change on the UDP or TCP side so this is fully backwards-compatible. It should probably find its way to the next main teensy release, if my changes are accepted. Until then, overwrite the stock files.

in the teensy library folder inside the application file (on OSX: /Applications/Arduino.app/Contents/Java/hardware/teensy/avr/libraries/Ethernet) replace:
Ethernet.h -> View attachment Ethernet.h
EthernetUdp.cpp -> View attachment EthernetUdp.cpp
socket.cpp -> View attachment socket.cpp

In the EthernetBonjour library which installs in the users document folder and based on this download, replace:
EthernetBonjour.cpp -> View attachment EthernetBonjour.cpp

Have some mdns fun!!!
 
i removed the teensy Ethernet library, and built the mtalk.ino sketch again for T3.2 (so now it is using the Arduino Ether lib) and multicast works (send and recv) on the w5100. so as holynoise also showed, the problem is with the teensy ether lib.

EDIT the multicast talk sketch also worked on T3.5 and T3.6 with the Arduino ethernet lib on w5100
? however, the packet receive on mtalk.c from the teensy is delayed by about 5 seconds?? the delayed packets are also seen on UNO? (see DNS problem in post #22 below)

in the teensy ether lib, i hacked socket.cpp to send Sock_SEND_MAC in socketSendUDP() and confirmed the teensy lib worked on T3.2 with either w5100 or w5200.
 
Last edited:
Here is the summary:
the registers must not necessarily be written before opening the socket AS LONG AS endPacket->socketSendUDP will write the send Command (Sock_SEND_MAC).

Since your patches change the API, it may be better to fix the teensy beginMulticast() to set the mac registers properly. Your changes would require Arduino to change the Ethernet API (or the teensy version would no longer be compatible), BUT multicast works for the Arduino ether lib. Paul will figure out what's best ...
 
I know what you mean. But here's the thing:
UDP implementation is fine and the hardware mac address should be the "regular" one.
multicast needs a special generated hardware mac access and while it is set correctly in beginMulticast() the problem is that the SEND command is in endPacket(). To end a packet I think the user must have a choice what to do with the mac address. the best implementation would probably be to read the register and identify multicast mode before sending SEND or SEND_MAC. Then the same method is generically correct for all situations.

I agree, somebody with "higher power" should take over and correct this in the official delivery - my patch can not be a final solution - that's clear. Just wanted to say that it is no beginMulticast which was the problem but endPacket().

Many thanks for helping!

Since your patches change the API, it may be better to fix the teensy beginMulticast() to set the mac registers properly. Your changes would require Arduino to change the Ethernet API (or the teensy version would no longer be compatible), BUT multicast works for the Arduino ether lib. Paul will figure out what's best ...
 
I modified socket.cpp, Ethernet.h, and EthernetUDP.cpp in teensy Ethernet lib and created a
socketBeginMulticast(uint8_t protocol, IPAddress ip, uint16_t port)
based on socketBegin() but added the mac register settings stuff before the OPEN. (I didn't change Sock_SEND). Seems to work with my mtalk.ino multicast chat. though i still have the packet delay problem (also on UNO with Arduino ether lib)?

the w5200 manual said those registers should be set before the OPEN.

Did a fork and pull request on Paul's Ethernet lib so one can see what I did.

... experiments continue.

EDIT The delayed packets (about 5 s) must have something to do with mtalk.c on linux. the java client on linux is in sync with the teensy output. Also tcpdump on linux is in sync with teensy mtalk output. (in fact, even with the teensy powered off, pkts continue to show up on linux mtalk.c for a while)

EDIT 2: the delay of mtalk.c on my linux box is the gethostbyaddr() call. something amiss with DNS on my linux box. ;)
 
Last edited:
it wasn't enough to get the mdns working. I managed to send correct packages when setting the registers before opening the socket but I couldn't receive anything. I guess because the way SEND_MAC sets the HW MAC (even when not writing to the register before opening) makes it also listening on the HW MAC address which explains I could only get multicast packages from mdns by doing so.

multicast with any the regular address will probably work the way your chat program works but mdns requests to have a special set HW MAC address for both sending and receiving. The only change I did now was using SEND_MAC and despite not setting the registers before OPENing I can send and receive multicast packages that work with mdns/bonjour. So I guess multicast is not multicast and both should be supported which is why I added a method instead of changing the existing one. All the files are in the teensy library folder and not in the core folder so I guess this will not lead into becoming an arduino-compatibility issue at all.

many thanks.

I modified socket.cpp, Ethernet.h, and EthernetUDP.cpp in teensy Ethernet lib and created a
socketBeginMulticast(uint8_t protocol, IPAddress ip, uint16_t port)
based on socketBegin() but added the mac register settings stuff before the OPEN. (I didn't change Sock_SEND). Seems to work with my multicast chat. though i still have the packet delay problem (also on UNO with Arduino ether lib)?

the w5200 manual said those registers should be set before the OPEN.


... experiments continue.
 
Hi, I am using a teensy 3.6 with a wi520io and try to use the ethernetBonjour lib. I am unable to see my device onto the network using the hostname I give it.
It was working fine last year with a teensy 3.2. I read this thread but I am not sure if the problem was solved, or if I need to make some modification... I took arduinoEthernet from this github: https://github.com/TrippyLighting/EthernetBonjour.git

Thanks in advance,

Alex
 
Status
Not open for further replies.
Back
Top