Author Topic: certain routers not working...even with simulator  (Read 4329 times)

Offline alager

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
certain routers not working...even with simulator
« on: December 23, 2009, 04:30:40 AM »
Mark,

I've have two routers so far with this issue, one was a Belkin and the other is a 2wire 2700HG-B.  Something in the uTasker isn't working with them.
The Belkin we updated the firmware and it started working with the uTasker project.  The 2wire already has the latest firmware and it is a very prevalent brand here in the US. 
The issue is duplicatable in the simulator as well.  In the simulator the link and activity lights never blink.

There is an interrupt every once in a while which triggers fnNetworkIndicator() and it hits both ACTIVITY_LED_ON() and TURN_LINK_LED_ON() and it never hits LINK_DOWN_LEDS().
The heartbeat works fine on PORT TC bit 0.

There are never any DHCP requests sent out on wireshark, even though the code is going through fnSendDHCP().  It's very bizzar to me.
I have the network settings set to 100MB.

Any ideas?

Thanks,
Aaron



Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: certain routers not working...even with simulator
« Reply #1 on: December 23, 2009, 11:59:21 AM »
Hi Aaron

Could you send me a wireshark recording with the simulator running (recorded from the PC running the simulator)? That is, of communication attempts that are not working.
Also make sure that the MAC address is not 00-00-00-00-00-00 - some DHCP servers don't like this address.

I don't think that this is a HW related problem since the simulator behaves the same. What I can't explain is how the simulator can send Ethernet data to the network but this is not seen.

Regards

Mark

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: certain routers not working...even with simulator
« Reply #2 on: January 06, 2010, 02:13:51 AM »
For anyone monitoring this thread, the reason was identified to be due to the way the router handled DNS requests.

It was identified that it was ignoring DNS requests with the same ID number when these were sent without a long delay between them. I believe that it is legal to use a fixed one (it is for the requester to check that the answer is from its request ID and I don't think that the server should really use it, apart from putting it into the reply).

In fact a second report of the same problem was received recently too (a different router type).

Both were fixed by randomising the used DNS message ID - this is included in the new V1.4 releases from 3.1.2010

Regards

Mark