Display of MAC Information under (Puppy) Linux Doesn't Work

[ozboomer]

Running v3.3.3 of the application under Slacko 5.6.4 (kernel v3.4.52) with JRE 1.7.0_15 has a few problems... but the first one I'll hit is that the MAC address and MAC vendor information is not displayed; the text "[n/a]" is shown.

However, if I run the same release version of the application under Windows 8.1 and JRE 1.8.0_51, the MAC information IS displayed.

Thanks.

[angryziber]

Linux version of MAC address detection currently uses the 'arp' command.
Do you have it installed?

Does it work with -an option, e.g:
arp -an YOUR-IP

If it does, please paste the output here

[ozboomer]

Hmm.. it seems there was no 'arp' installed with this release. I went and collected the proper version of 'net-tools' and with '/sbin/arp' now on the system, things seem to work Ok.

The output from the command you mentioned comes up as follows:-

node:~ # arp -an 192.x.x.x
arp: in 2 entries no match found.
node:~ #

...if that's helpful?

Perhaps, as well as mentioning the need for 'oracle Java' etc on the web page, you could details some of the dependencies the program relies upon? It might be too much detail for some, I 'spose...

Anyway, thanks for pointing me in the right direction to get the issue resolved.

[ozboomer]

One thing I noticed just now... Installing the 'arp' image does mean ipscan resolves some MAC addresses... but! if I have a computer wirelessly connected to a range extender, the MAC address of the range extender is reported and NOT the computer's network interface.

This also holds true when running the Windows version.

[angryziber]

I guess the Unix version must report it if calling of arp has failed.

Hmm.. the range extender thing is interesting :-)
Does it respond to all ARP queries with its own Mac address?
Can you try using arping with some IPs?

[ozboomer]

I'm sorry, I don't know arp very well at all nor how to use it...

I've tried downloading/building arping... and also going the 'rpm' route, after finding the program was not available in any of the relevant Puppy Linux repositories... but after spending 30+ minutes setting-up a test environment and dealing with missing dependencies, I simply gave up trying. Maybe I can grab a Live CD of a linux distribution that HAS 'arping' and I can do some testing?

What I can say now is that running 'arp' before and after running 'ipscan' gives different results; the table has different/additional entries, although the entries that appear in both runs of 'arp' show the same MAC address ... and if a host that I know to be 'up' is not shown, after I 'ping' it, its name appears in the 'arp' output... although, it will have the same MAC address as the extender it is connected through.

Anything useful out of all that!? :)

[angryziber]

If arp table shows the MAC of the externder, then there is nothing ipscan
can do... Your extender completely masks the devices on the network.

On Sat, 5 Sep 2015, 10:24 ozboomer notifications@github.com wrote:

I'm sorry, I don't know arp very well at all nor how to use it...

I've tried downloading/building arping... and also going the 'rpm' route,
after finding the program was not available in any of the relevant Puppy
Linux repositories... but after spending 30+ minutes setting-up a test
environment and dealing with missing dependencies, I simply gave up trying.
Maybe I can grab a Live CD of a linux distribution that HAS 'arping' and I
can do some testing?

What I can say now is that running 'arp' before and after running 'ipscan'
gives different results; the table has different/additional entries,
although the entries that appear in both runs of 'arp' show the same MAC
address ... and if a host that I know to be 'up' is not shown, after I
'ping' it, its name appears in the 'arp' output... although, it will have
the same MAC address as the extender it is connected through.

Anything useful out of all that!? :)

—
Reply to this email directly or view it on GitHub
#38 (comment).

[ozboomer]

IN that regard, it seems to be something in the set-up of the extender(s). My research thus far has led to this discussion: http://forums.whirlpool.net.au/archive/1256584 (not talking about my actual repeater devices but maybe the concepts are relevant). I'll keep looking for something in the repeaters' set-ups and see if things become more 'transparent'...

[ozboomer]

I've been looking some more this afternoon.. and I think there's something with how this 'arp' business works... AND there's something with the extenders as well...

To test things out some, I went through the following:-

1. I connected my linux PC to the router (wireless), using the normal static routing I always use. ipscan showed the local PC and the router and the other computers, etc with the MAC address of the extenders.
2. I connected the linux PC to the extender (via wireless) and set 'WDS Mode' instead of 'Universal Mode' and rebooted the extender. I then connected my linux PC through the extender and I could only see the PC and the extender with ipscan; none of the other PCs, router, etc are visible although they're on the same network.
3. Reconnected the linux PC to the router (wireless), reconnected to the extender and went through the 'quick setup' which uses 'Universal Mode' and restarted the extender.. and connected the linux PC (wireless) to the extender... and everything works, showing MAC addresses of the actual NICs on PCs, extenders, phones, etc.

However, if I do a scan and see everything as-expected (with real MAC addresses), I thin startup an android tablet.. which connects into the network via the extender (wireless). and then do another ipscan.. and the old problem is back - the tablet has an IP but the MAC address reported is that of the extender and not the tablet.

Also, with the Windows version of ipscan, with the first scan after starting the program, the various PCs, phones, etc MIGHT be shown with their IPS and maybe the MAC addresses .. or not. If I run ipscan again, THEN I will get the MAC addresses for all the PCs, etc... except that the MAC addresses of the extenders are NEVER shown; the correct MAC addresses for the PCs, tablets, etc are all shown Ok.

Note that the behaviour I describe occurs consistently through multiple boots of PCs, etc, so I doubt there's something with caching of addresses etc... but I dunno, really..(!)

An interesting observation:

When trying to decide on the 'network' to connect to wirelessly from the linux PCs, etc, the router 'advertises' its MAC address as '...C8-AC'... but when I make the connection to that MAC address and then use ipscan, the MAC address reported for the router is '...-38-E4'. If I try to use that MAC address when making the initial connection, though, I get no connectivity at all. So, where are the 2 addresses coming from? ...and why do they change?... and why is one not usable?

I'll never get my head around this networking guff.. Even Phase IV DECnet was way simpler 'back in the day' (!)...

Update: No, the MAC addresses of the extenders are being displayed again (with arp and ipscan) after restarting the computers and/or re-starting the network connections on the PCs... Pffft. I think I'll have to wait until I can 'properly' set-up the 'WDS' mode in such a way that all the devices on the network are visible....

[angryziber]

LinuxMACFetcher will now examime ARP kernel table at /proc/net/arp instead of using the arp utility