Posted: Sun Jun 03, 2012 2:29 Post subject: Not recognized in dd-wrt but no problems in a notebook
I have a very odd situation here:
I bought a device that has an ethernet port. When I plug it in a router (have tested with one Bufallo WHR-G125 and two TP-link 1043ND - all with dd-wrt) its MAC is not shown in the router's LAN clients.
The device is supposed to support DHCP but it also does not work. Fixing an IP address to it's NIC is also worthless: I am able to ping the device from a notebook connected to the router's switch but the device is still not recognized.
Seaching in google I found some reports that droping the network speed to 10mbps would solve the problem. With a cross cable, I connected it to my notebook's ethernet port (forced to connect only at 10mbps) and indeed the problem was solved: The device was able to connect to the internet (shared over the note's wi-fi) using both DHCP and also with a fixed IP address.
So I though I was only a matter of gettig an old 10/10 hub...
But even with the hub the device is still not detected by the router...
I seached the wiki to find a way to discover why it works with the notebook and do not when connected to the router but I didn't find anything...
Any help would be greatly appreciated!
[]'s _________________ TPlink TL-WDR3600ND as WDS AP
TPlink TL-WR841ND v9 as WDS Station
TPlink TL-WR1043ND v1.8 as WDS Station (with VAP disabled)
A device will only show up among LAN clients when it is communicating through the router, ie when it has traffic for the WAN.
The LAN client list is refreshed frequently so a client that for instance only access WAN for getting the time from an NTP server but has all its other traffic inside the LAN will only show up temporarily for a minute or so and then disappear.
LAN-to-LAN traffic does not go through the routing software, it is direct in hardware between the routers LAN ports.
The client will show up as a DHCP lease if it gets it ip address from the routers DHCP server but that is apparently not the case here.
The right way to test is to open a telnet session to the router and ping the client from the cmd line, that will tell you if the client is connected to the router or not. _________________ Kernel panic: Aiee, killing interrupt handler!
Posted: Sun Jun 03, 2012 12:52 Post subject: More tests
Hi LOM,
Thank you for your answer.
I tried to ping the device from the router, but with no success as I was expecting.
To investigate why the device was able to connect through the notebook and not through the router, decided to use a snifer software (wireshark) to see if I could see any difference.
The setup was as follows:
- The bufallo WHR-G125 router set as dhcp router (but without anything connected to it's WAN port) at 192.168.1.1
- The device (whose MAC address is DF-40-C4-F7-38-A with DHCP active
- My notebook (Win7 x64) with wireshark running and configured to snif the wired ethernet port.
First, I plugged all devices in the 10mbps hub, waited for the bufallo to attribute a IP to my notebook and then started wireshark. Finally I turned on the device. The result was recorded in the attached log "wireshark - dd-wrt"
Then I removed the router, configured my notebook to share the internet through Wi-Fi, started wireshark, pluggued the notebook and the device in the hub and waited for the log to stabilize (which happened at line 402). Finally I turned on the device. The result is the attached log "wireshark - notebook"
As far as my limited knowledge can tell, the basic difference between the logs is: when connected to the router, the device keeps broadcasting a DHCP discover frame but it is not answered. When connected through the notebook, the request is answered and so the device is able to receive a IP address and then to connect.
If there are some other tests that I can do in order to give you more data, please tell me.
The most significant byte of the MAC address indicates that it is not an IEEE assigned MAC address, it is an home-brewed one
It also indicates that the device is using multicast protocol and I guess that is the reason for why it doesn't get a DHCP address from your routers, DHCP is unicast. _________________ Kernel panic: Aiee, killing interrupt handler!
The most significant byte of the MAC address indicates that it is not an IEEE assigned MAC address, it is an home-brewed one
It also indicates that the device is using multicast protocol and I guess that is the reason for why it doesn't get a DHCP address from your routers, DHCP is unicast.
It is a chinese satellite receiver. I guess it will be hard to change it's MAC address (I don't know if this is even possible).
But what I can't understand until now is why when the device is plugged to the notebook, MS Windows 7's DHCP server accepts the device's request and the dd-wrt one's do not.
I forgot to mention: When the device is configured with a fixed IP, it tries to send DNS requests but it is also ignored by the router...
I do not need DHCP but I reaaly need to get some kind of communication between them.
If this is a firewall or protocol rule (not to respond to a device that has a group MAC address), is there a way to avoid it?
Thanks again!
[]'s _________________ TPlink TL-WDR3600ND as WDS AP
TPlink TL-WR841ND v9 as WDS Station
TPlink TL-WR1043ND v1.8 as WDS Station (with VAP disabled)
But what I can't understand until now is why when the device is plugged to the notebook, MS Windows 7's DHCP server accepts the device's request and the dd-wrt one's do not.
Windows DHCP server supports MADCAP (multicast dhcp)
ThunderBolt wrote:
I forgot to mention: When the device is configured with a fixed IP, it tries to send DNS requests but it is also ignored by the router...
Google multicast DNS (Bonjour/mDNSResponder and similar).
My understanding of multicast DNS is that each client keeps his own DNS records of other clients that has announced themselves with a multicast DNS announcement,there is no central DNS server.
Each client receiving a multicast DNS discovery frame will reply to it and the issuer of the discovery message will then store the responses locally.
I think it is obvious that your sat receiver is only intended to be used within a LAN segment.
Pls expand a bit of what you intend to do and how your router is involved in it. _________________ Kernel panic: Aiee, killing interrupt handler!
Windows DHCP server supports MADCAP (multicast dhcp)
I have understood . Thanks for the explanation. Is it possible to add support to MADCAP in dd-wrt as well?
LOM wrote:
Google multicast DNS (Bonjour/mDNSResponder and similar).
My understanding of multicast DNS is that each client keeps his own DNS records of other clients that has announced themselves with a multicast DNS announcement,there is no central DNS server.
Each client receiving a multicast DNS discovery frame will reply to it and the issuer of the discovery message will then store the responses locally.
Thanks again! It is much more clear to me now.
LOM wrote:
I think it is obvious that your sat receiver is only intended to be used within a LAN segment.
Pls expand a bit of what you intend to do and how your router is involved in it.
Yes, the sat receiver is intended to be used only inside a LAN network: There's no need to have access to it from outside the LAN.
The truth is that the manufacturer has made a huge mistake giving it a multicast MAC address. I could have returned the device to the seller store, but it would cost me lots of time and probably I would have had to pay importation taxes before receiving the new unit.
My intention is to install this sat receiver in my parent's house so they can watch satellite channels. But it also has to have internet access to receive updates. In my parent's house there is already a wireless network provided by one TP-Link 1043ND. As I have a Buffalo WHR-G125 not being used, I would configure it as client ( bridge, or not) to give it this access.
I have searched google for all the topics you wrote and I actually have tried to install mDNSResponder following the wiki steps but again with no success. It fails to install (but no error message is displayed: it just says that it will keep the files for a manual installation trial).
I am also going to attach a new log: this was done with the sat receiver configured to use IP address 192.168.2.12 and the Buffalo set as DHCP router at 192.168.2.1. I think that the receiver first tries to discover the router's MAC by broadcasting an ARP package and it is not answered. I keeps broadcasting until my computer does the same (but asks directily to the router and so it gets an answer). From this time on the receiver starts sending a "Standard Query A" DNS request to the router, but again without any answer.
Thanks again for helping me. At least I have learned a lot so far! And sorry for the wall text :p
with DHCP active
