Problem with hotspot and interface arp=reply-only

sja · Thu Feb 16, 2012 1:54 pm

I have an RB750GL with ROS v5.13 and a working hotspot (with hotspot masquerading).

Hotspot access is no longer possible after I change to use arp=reply-only on the ethernet interface and add-arp=yes on the dhcp-server.

What I am doing wrong?

Here are some configuration details and description of the symptons:

[admin@XXX] > ip dhcp-server lease print
Flags: X - disabled, R - radius, D - dynamic, B - blocked 
 #   ADDRESS                                      MAC-ADDRESS       HO SER.. RA
31 D 172.22.176.254                               20:CF:30:2C:75:20 DI dhcp2
    
[admin@XXX] > ip hotspot host print   
Flags: S - static, H - DHCP, D - dynamic, A - authorized, P - bypassed 
 #    MAC-ADDRESS       ADDRESS         TO-ADDRESS      SERVER     IDLE-TIMEOUT
 0  A 20:CF:30:2C:75:20 172.22.176.254  172.22.129.254  hotspot   

[admin@XXX] > ip dhcp-server print detail
Flags: X - disabled, I - invalid 
 0   name="dhcp2" interface=ether2 lease-time=1h address-pool=unknown-dhcp 
     bootp-support=static add-arp=yes authoritative=after-2sec-delay 

[admin@XXX] > interface ethernet print detail 
Flags: X - disabled, R - running, S - slave 

 1 R  name="ether2" mtu=1500 l2mtu=1598 mac-address=00:0C:42:AA:7B:CF 
      arp=reply-only auto-negotiation=yes full-duplex=yes speed=100Mbps 
      master-port=none bandwidth=unlimited/unlimited switch=switch1

For the host that I am using for this test, logon is via a cookie or http chap. At the time of the test the cookie is fresh.

When I fire up the browser (Firefox on Ubuntu 11.10) I always get redirected to the hotspot logon page which is odd because the cookie is fresh. I fill in the access credentials and the browser hangs looking up my hotspot dns.

Wiresharking shows that a reply to the dns request is made to the routerboards MAC and not the PCs (for the test the PC is directly connected to the RB):

No.     Time            Source                Destination           Protocol Length Info
    818 11:12:57.560750 172.22.176.254        172.22.0.1            DNS      70     Standard query A faraday-hs

Frame 818: 70 bytes on wire (560 bits), 70 bytes captured (560 bits)
Ethernet II, Src: AsustekC_2c:75:20 (20:cf:30:2c:75:20), Dst: Routerbo_aa:7b:cf (00:0c:42:aa:7b:cf)
Internet Protocol Version 4, Src: 172.22.176.254 (172.22.176.254), Dst: 172.22.0.1 (172.22.0.1)
User Datagram Protocol, Src Port: 46512 (46512), Dst Port: domain (53)
Domain Name System (query)

No.     Time            Source                Destination           Protocol Length Info
    819 11:12:57.561900 172.22.0.1            172.22.176.254        DNS      86     Standard query response A 172.22.0.1

Frame 819: 86 bytes on wire (688 bits), 86 bytes captured (688 bits)
Ethernet II, Src: Routerbo_aa:7b:cf (00:0c:42:aa:7b:cf), Dst: Routerbo_aa:7b:cf (00:0c:42:aa:7b:cf)
Internet Protocol Version 4, Src: 172.22.0.1 (172.22.0.1), Dst: 172.22.176.254 (172.22.176.254)
User Datagram Protocol, Src Port: domain (53), Dst Port: 46512 (46512)
Domain Name System (response)

guilhermeramires · Thu Feb 16, 2012 2:01 pm

Hello sja,

2 questions:

1-Did you add mac/address of all people you want to authenticate?
2-Are these pcs in bridge together to the interface that hotspot listen?

sja · Thu Feb 16, 2012 2:25 pm

Thanks for your time guilhermeramires.

1. I cannot know the MAC's before so I have not configured them anywhere. The test PC collects an ip address the pool associated with his user name. I have configured the dhcp-server to add an arp when it hands out a lease.

2. No bridges. At the moment, the RB is not directly connected to the internet (it is via lan to another internet facing router).

Your question did make me think and so I checked again my configuration, and to my embarassment found a firewall rule left over from a different test. Removing that rogue rule makes everything work as it should!

So thanks for prodding me with the right question.

1 Karma on the way to you!

guilhermeramires · Thu Feb 16, 2012 2:40 pm

You're welcome.

sja · Thu Feb 16, 2012 2:51 pm

More embarassment for me. Something is still not correct - its stopped working again with exactly the same symptons.
Later today I shall reset my RB to a known and tested simple configuration and try again.

sja · Sat Feb 18, 2012 9:39 am

I've now reset the router to a known working fairly simple configuration.

The problem still exists with the same symptons as I described before.

Using Wireshark, the following shows exactly from which tcp packet the RB starts using the incorrect MAC:

No.     Time            Source                Destination           Protocol Length Info
    574 14:20:05.495643 172.22.176.254        172.22.0.1            HTTP     733    POST /login HTTP/1.1  (application/x-www-form-urlencoded)

Frame 574: 733 bytes on wire (5864 bits), 733 bytes captured (5864 bits)
Ethernet II, Src: AsustekC_2c:75:20 (20:cf:30:2c:75:20), Dst: Routerbo_aa:7b:cf (00:0c:42:aa:7b:cf)
Internet Protocol Version 4, Src: 172.22.176.254 (172.22.176.254), Dst: 172.22.0.1 (172.22.0.1)
Transmission Control Protocol, Src Port: 42366 (42366), Dst Port: http (80), Seq: 1, Ack: 1, Len: 667
Hypertext Transfer Protocol
Line-based text data: application/x-www-form-urlencoded
    username=stephen&password=e26bf742bb89715b4e49b6a9ecf13be1&dst=http%3A%2F%2Fwww.bbc.co.uk%2Fgo%2Frss%2Fint%2Fnews%2F-%2Fnews%2Fhealth-17024714&popup=true

No.     Time            Source                Destination           Protocol Length Info
    575 14:20:05.496531 172.22.0.1            172.22.176.254        TCP      66     http > 42366 [ACK] Seq=1 Ack=668 Win=7126 Len=0 TSval=24986 TSecr=2896702

Frame 575: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: Routerbo_aa:7b:cf (00:0c:42:aa:7b:cf), Dst: AsustekC_2c:75:20 (20:cf:30:2c:75:20)
Internet Protocol Version 4, Src: 172.22.0.1 (172.22.0.1), Dst: 172.22.176.254 (172.22.176.254)
Transmission Control Protocol, Src Port: http (80), Dst Port: 42366 (42366), Seq: 1, Ack: 668, Len: 0

No.     Time            Source                Destination           Protocol Length Info
    576 14:20:05.586572 172.22.0.1            172.22.176.254        TCP      1716   http > 42366 [PSH, ACK] Seq=1 Ack=668 Win=7126 Len=1650 TSval=24995 TSecr=2896702

Frame 576: 1716 bytes on wire (13728 bits), 1716 bytes captured (13728 bits)
Ethernet II, Src: Routerbo_aa:7b:cf (00:0c:42:aa:7b:cf), Dst: Routerbo_aa:7b:cf (00:0c:42:aa:7b:cf)
Internet Protocol Version 4, Src: 172.22.0.1 (172.22.0.1), Dst: 172.22.176.254 (172.22.176.254)
Transmission Control Protocol, Src Port: http (80), Dst Port: 42366 (42366), Seq: 1, Ack: 668, Len: 1650

By the way the user and credentials are just for test.

Is this a bug?
Or is it simply not possible to use arp=reply-only / add-arp=yes with hotspots?

MayestroPW · Thu Oct 27, 2016 7:28 pm

I have the same problem. ROS 6.37.1. Firewall Filter: clear, NAT: clear, Mangle: clear, Arp Reply-Only: ON, DHCP Add DHCP for Leases: ON. I don't know what causes the problem.

Problem with hotspot and interface arp=reply-only

Problem with hotspot and interface arp=reply-only

Re: Problem with hotspot and interface arp=reply-only

Re: Problem with hotspot and interface arp=reply-only

Re: Problem with hotspot and interface arp=reply-only

Re: Problem with hotspot and interface arp=reply-only

Re: Problem with hotspot and interface arp=reply-only

Re: Problem with hotspot and interface arp=reply-only

Who is online