Anonymous | Login | 2024-12-02 18:25 EST |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | Project | Category | View Status | Date Submitted | Last Update | |||
0001535 | PacketFence | upstream | public | 2012-08-31 07:20 | 2012-09-13 10:57 | |||
Reporter | fgaudreault | |||||||
Assigned To | fgaudreault | |||||||
Priority | normal | Severity | major | Reproducibility | always | |||
Status | resolved | Resolution | fixed | |||||
Platform | OS | OS Version | ||||||
Product Version | 3.5.0 | |||||||
Target Version | Fixed in Version | |||||||
Summary | 0001535: Inline mode and OSX DNS Caching issues for home page | |||||||
Description | When visiting a mac based shop, we were having some issues using inline mode. Let me describe the problem that will impact most 10.6 users. 10.7 and 10.8 have the thin client browser that mitigate the issue, but the problem is still there is you use a real browser. So what appears to happen is when you open a browser while unregistered, the browser will try to hit your home page. PacketFence will then resolve it to its inline ip address so that you can hit the portal. But, by doing so, the system caches the result, and when you are registered, the cache wins. When you try to go back to visit your home page, you won't be able to. I was able to reproduce it all the time even with the ipset feature. Now to fix this, why aren't we using DNAT for http/https traffic only if your mark is 0x2 or 0x3 (unreg/isol)? Let's resolve the real IP, but forward the packets to the inline interface for portal. | |||||||
Tags | No tags attached. | |||||||
fixed in git revision | 986f432a2dc277819e76c8556b0e91d392e78169 | |||||||
fixed in mtn revision | ||||||||
Attached Files | ||||||||
Notes | |
(0002994) obilodeau (reporter) 2012-08-31 07:27 |
I think we would face the Apache vhost problem we had before doing DNS DNAT but I'm not sure. Just an idea that I would like you to try: How about putting a TTL of 1 in named in inline? Could you try that? |
(0002995) fgaudreault (viewer) 2012-08-31 07:28 |
Hmmm interesting. I can try to reduce the TTL of the zone yes. Ill let you know how it goes :) |
(0003004) fgaudreault (viewer) 2012-08-31 12:07 |
TTL 1 fixed the problem. |
(0003037) fgaudreault (viewer) 2012-09-10 14:42 |
Is the "TTL 1" a fair solution? I mean the only downside really is the number of DNS queries that the DNS server will have to handle. I am sure a decent server can handle it. |
(0003041) obilodeau (reporter) 2012-09-10 15:25 |
Yes, I think we should go with the TTL of 1 approach. I think we should do this change in a major release so we test thoroughly w/ several different devices before releasing. |
(0003045) fgaudreault (viewer) 2012-09-11 09:29 |
Commited in devel with id b770fd2e04f63969b3a97d4a8534fe70960f5418 I don't think we need to test more, it has been live at a customer site since last week, and everything is A1. |
(0003046) obilodeau (reporter) 2012-09-11 09:36 |
This could also help with javascript redirection in VLAN mode. Should we perform a similar change there? |
(0003047) fgaudreault (viewer) 2012-09-11 09:38 |
Good idea. I think it will help too. |
(0003060) fgaudreault (viewer) 2012-09-13 10:57 |
Fixed in devel. Commit 986f432a2dc277819e76c8556b0e91d392e78169 |
Issue History | |||
Date Modified | Username | Field | Change |
2012-08-31 07:20 | fgaudreault | New Issue | |
2012-08-31 07:21 | fgaudreault | Description Updated | |
2012-08-31 07:27 | obilodeau | Note Added: 0002994 | |
2012-08-31 07:28 | fgaudreault | Note Added: 0002995 | |
2012-08-31 12:07 | fgaudreault | Note Added: 0003004 | |
2012-09-10 14:42 | fgaudreault | Note Added: 0003037 | |
2012-09-10 15:25 | obilodeau | Note Added: 0003041 | |
2012-09-11 09:29 | fgaudreault | Note Added: 0003045 | |
2012-09-11 09:30 | fgaudreault | git revision | => b770fd2e04f63969b3a97d4a8534fe70960f5418 |
2012-09-11 09:36 | obilodeau | Note Added: 0003046 | |
2012-09-11 09:38 | fgaudreault | Note Added: 0003047 | |
2012-09-13 10:57 | fgaudreault | git revision | b770fd2e04f63969b3a97d4a8534fe70960f5418 => 986f432a2dc277819e76c8556b0e91d392e78169 |
2012-09-13 10:57 | fgaudreault | Note Added: 0003060 | |
2012-09-13 10:57 | fgaudreault | Status | new => resolved |
2012-09-13 10:57 | fgaudreault | Resolution | open => fixed |
2012-09-13 10:57 | fgaudreault | Assigned To | => fgaudreault |
Copyright © 2000 - 2012 MantisBT Group |