Open ganghuang opened 2 years ago
Instead of broadcasting, if I give the ip range or the specific ip address by -b -e, the idiscover can recognize the returned pong.
The two packets seems pretty similar from wireshark, but the one with specific ip (-b, -e) can reach idiscover and identified as a response, while the other one with broadcasting doesn't.
Interesting. The problem could be either something unique about the broadcast reply, or something with the IPMI LAN configuration on the Arduino system. A few bits of information would help to determine that:
Results of ipmiutil discover with a range (will probably work), example:
traceroute from 192.168.1.103 to 192.168.1.244 (verify that they are on the same subnet, probably so)
Output of 'ipmiutil lan' run on the Arduino system. (perhaps the netmask is wrong?)
Andy
On Tue, Feb 22, 2022 at 10:03 AM ganghuang @.***> wrote:
Instead of broadcasting, if I give the ip range or the specific ip address by -b -e, the idiscover can recognize the returned pong. [image: image] https://user-images.githubusercontent.com/7526459/155159602-0c708709-6d08-4199-90d8-67ab6a844c05.png I don't know why so?
— Reply to this email directly, view it on GitHub https://github.com/arcress0/ipmiutil/issues/4#issuecomment-1047887296, or unsubscribe https://github.com/notifications/unsubscribe-auth/AO3NLW3EXVTS3R5SVKZK4PLU4OQTLANCNFSM5PAUTZCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
@Andy Thank you for the reply, please see below:
Results of ipmiutil discover with a range (will probably work), example: # ipmiutil discover -b 192.168.1.50 -e 192.168.1.250 This runs much slower as it seems ping each ip in sequence. But at the end, it does got the result.
traceroute from 192.168.1.103 to 192.168.1.244 (verify that they are on the same subnet, probably so) Seems it just go there directly
Output of 'ipmiutil lan' run on the Arduino system. (perhaps the netmask is wrong?) The arduino system does not have a OS, so I can not run ipmiutil on that system. But I can check the netmask for the arduino network shield and it give me 255.255.255.0
Another test with root: ipmiutil discover -a -m -x > /tmp/t1 I got the t1 attached as t1.txt. It got 33 responses, but most of them are not pong. I don't know why there are so many responses on my network, but the pong response does recognized at line 42. t1.txt
And if I do ipmiutil discover -m, I can get the response, but if I don't do the -m, there is 0 response
This is an issue specific to the arduino platform, and using idiscover -m (raw mode) does get a response. The fact that arduino does not respond to normal broadcast pings seems to be an error with the platform, not ipmiutil.
I am trying to make an arduino together with an ethernet shield board to enable ipmi turn a PC power on/off etc.
I can use the ipmiutil discover to send out ASF ping and my board does return ASF pong as the wireshark captured below.
But the ipmituil does not recognize the pong as a response, so still report back 0 response.
I even copied the mac address of a supermicro board over but the ipmiutil still says 0 responses. What else does the discover waiting for?