On 22.05.2014 06:15, bodie wrote:
On 21.05.2014 21:54, Giancarlo Razzolini wrote:
Em 21-05-2014 16:17, Stuart Henderson escreveu:
On 2014-05-21, Giancarlo Razzolini <grazzol...@gmail.com> wrote:
Well,
Without you providing the mac address of your gateways/aps, I
can
only guess. But I know some access points do very funny things.
The most
notorious example are apple airports. It will simply change your
mac
with their own and anything on the wired side of the lan will get
theses
arp messages. But it seems to me more likely to be something
misconfigured in your network.
Not sure if it applies here, but this ("L2 NAT") is standard
behaviour
for any AP repeaters (or "client bridges") that don't do WDS..
Yes, it is. The ap repeating the signal connects on the first as a
client and then broadcast with the same mac address. That's is the
reason why the transfer rate is cut in half when using this kind of
repeater. If it was the case that the OP were in an edge case where
he
was equidistant from both access points, it would connect to one of
them, then the signal detection would tell the other is with a
stronger
signal, it connects to the other, and so on. But as he mentioned,
it's
the same IP address with 2 different mac addresses. This is weird.
And
most likely will keep giving him trouble, unless they fix it, or he
blocks one of them using vether and bridge (which I'm not really
sure
would work).
Cheers,
So first morning test with DragonflyBSD amd64 snapshot from 21.5.:
arping result is 23 packets transmitted, 21 packets received.
All were returned from only one MAC which is in my arp -a output.
MAC starts on 44:1e:a1 so it's something from HP (?)
In /var/log/messages I can see similar arp related messages, but
rate is way lower like initial 2 messages, then after 5 minutes 4
messages
and then already 3 minutes quiet. Try another arping till index=20
result in
24 transmitted, 21 received, 12% unanswered. Such arping initialized
another
2 messages in /var/log/messages (they always occur in double)
kernel: arp: GW_IP moved from 44:1e:a1:c2:XX:XX to 44:1e:a1:c2:YY:YY
on wlan0
kernel: arp: GW_IP moved from 44:1e:a1:c2:YY:YY to 44:1e:a1:c2:XX:XX
on wlan0
DNS which is GW_IP is returning for ALL internal or external web
pages of company
always 123.123.123.123 , if I will try external like google.com and
such they are
translated properly). Interestingly enough after some time at least
public pages
of company are accessible in firefox 29 browser even as DNS returns
123.123.123.123
for them.
That is simply weird :-(
Need to have working machine till tomorrow as I will be working
remotely and OpenBSD
works in that scenario perfectly fine, so will just probably do quick
test of Bitrig
now and then I will install OpenBSD back to collect and test other
stuff we talked about.
Now it's getting even more interesting :-)
Bitrig latest snapshot.
First difference:
/etc/resolv.conf has last line lookup file bind (it's not there in
OpenBSD received from DHCP)
Second difference:
arping returns replies only from one MAC, no unanswered packets, no
extra packets and
time is around 1ms, where on OpenBSD it's around 10ms
/var/log/messages is continuously filled with those doubled messages I
already posted and
DNS still returns 123.123.123.123 for company sites, but is ok for
external webs.
Will collect pcap here as well of whole process for interested devs in
private replies.
