Is anyone out there using the UIP stack on their nanode? I've been playing with the MQTT port https://github.com/njh/NanodeMQTT but I'm seeing some wierd setup issues
If I reflash (original nanode5 + ftdi cable, arduino 1.0) with the mqtt_publish example (IP addresss changed to local IP, added gateway [ uip.set_gateway_addr(192, 168, 1, 1); ] and setting the broker to be a local machine ( mqtt.set_server_addr(192, 168, 1, 251); ) I see the link up quickly but the connect often takes an excessive time and seems to hang
tapping the reset button quickly often works and then the thing will happily publish in loop()
Before I continue digging (tcpdump on broker) has anyone else experienced this?
> Is anyone out there using the UIP stack on their nanode? I've been > playing with the MQTT port https://github.com/njh/NanodeMQTT but I'm > seeing some wierd setup issues
> If I reflash (original nanode5 + ftdi cable, arduino 1.0) with the > mqtt_publish example (IP addresss changed to local IP, added gateway [ > uip.set_gateway_addr(192, 168, 1, 1); > ] > and setting the broker to be a local machine ( > mqtt.set_server_addr(192, 168, 1, 251); ) I see the link up quickly > but the connect often takes an excessive time and seems to hang
> tapping the reset button quickly often works and then the thing will > happily publish in loop()
> Before I continue digging (tcpdump on broker) has anyone else experienced > this?
Ah. I had all sorts of problems with intermittent function on the Ethernet chip - the problem is that at power up, all SPI chips are enabled. At least, explicitly disabling them fixes the problem.
Its actually kinda obvious that something is horribly wrong, at least with the code I'm using: it flashes the lights on the Ethernet port during initialisation, and when this problem occurs, the flash does not happen (lights still light up, tho - it seems the default config for the chip has at least carrier detect...).
On Monday, 23 April 2012 10:21:48 UTC+1, Andrew Elwell wrote:
> Hi Folks,
> Is anyone out there using the UIP stack on their nanode? I've been > playing with the MQTT port https://github.com/njh/NanodeMQTT but I'm > seeing some wierd setup issues
> If I reflash (original nanode5 + ftdi cable, arduino 1.0) with the > mqtt_publish example (IP addresss changed to local IP, added gateway [ > uip.set_gateway_addr(192, 168, 1, 1); > ] > and setting the broker to be a local machine ( > mqtt.set_server_addr(192, 168, 1, 251); ) I see the link up quickly > but the connect often takes an excessive time and seems to hang
> tapping the reset button quickly often works and then the thing will > happily publish in loop()
> Before I continue digging (tcpdump on broker) has anyone else experienced > this?
I would recommend having a look using tcpdump. If you're making connections from the Nanode, as the MQTT example does, you might run into problems because it'll use the same port and sequence number each time you start it up. tcpdump should let you know if this is what's happening!
Yes, the uIP stack gets very confused after a reset when it starts reusing TCP sequence numbers. Apologies, I got a bit distracted with some other projects, I should go back and sort this out.
Was thinking of storing a boot counter in an EEPROM somewhere, that can then be used as a seed.
Sent from my phone
On 23 Apr 2012, at 18:48, Stephen Early <s...@individualpubs.co.uk> wrote:
> On Monday, 23 April 2012 10:21:48 UTC+1, Andrew Elwell wrote: > Hi Folks, > Is anyone out there using the UIP stack on their nanode? I've been > playing with the MQTT port https://github.com/njh/NanodeMQTT but I'm > seeing some wierd setup issues
> If I reflash (original nanode5 + ftdi cable, arduino 1.0) with the > mqtt_publish example (IP addresss changed to local IP, added gateway [ > uip.set_gateway_addr(192, 168, 1, 1); > ] > and setting the broker to be a local machine ( > mqtt.set_server_addr(192, 168, 1, 251); ) I see the link up quickly > but the connect often takes an excessive time and seems to hang
> tapping the reset button quickly often works and then the thing will > happily publish in loop()
> Before I continue digging (tcpdump on broker) has anyone else experienced this?
> I would recommend having a look using tcpdump. If you're making connections from the Nanode, as the MQTT example does, you might run into problems because it'll use the same port and sequence number each time you start it up. tcpdump should let you know if this is what's happening!
> Yes, the uIP stack gets very confused after a reset when it starts reusing > TCP sequence numbers. Apologies, I got a bit distracted with some other > projects, I should go back and sort this out.
Bingo! That seems to be the problem -- got a trace and shows the port nos wrapping and then MQTT stops as it gets the FIN from an earlier packet.
>> Yes, the uIP stack gets very confused after a reset when it starts reusing >> TCP sequence numbers. Apologies, I got a bit distracted with some other >> projects, I should go back and sort this out.
> Bingo! That seems to be the problem -- got a trace and shows the port > nos wrapping and then MQTT stops as it gets the FIN from an earlier > packet.
> Ho Hum. I guess poking in the innards of uip is next then?
I would be very surprised if there was a problem in the core of uIP - it is very mature code and something like that would have been picket up by now. I did some work to sync up NanodeUip with the latest version of uIP. The only bit I haven't done is a complete update of the DHCP and DNS resolver code.
So I think it is more likely to be a problem with the interaction with the Arduino or ENC28J60 code. I have wondering if tweaking the uIP clock rate / code might help.
> I would be very surprised if there was a problem in the core of uIP - it is very mature code and something like that would have been picket up by now. I did some work to sync up NanodeUip with the latest version of uIP. The only bit I haven't done is a complete update of the DHCP and DNS resolver code.
I initially was trying to do the once-per-5-sec to test.mosquitto.org (hence the commented out IP and addition of gateway) but when that didn't work I hacked it to go to a local broker
> So I think it is more likely to be a problem with the interaction with the Arduino or ENC28J60 code. I have wondering if tweaking the uIP clock rate / code might help.
