[prev in list] [next in list] [prev in thread] [next in thread]
List: open1x-xsupplicant
Subject: Re: [Open1x-xsupplicant] Versions conflict with personal firewall
From: Chris Hessing <chris () open1x ! org>
Date: 2008-12-22 17:54:24
Message-ID: 494FD450.8020608 () open1x ! org
[Download RAW message or body]
Hi Dan,
Sorry for the slow reply. There isn't a way to tell the supplicant to
stop trying to authenticate after "x" times. If you happen to have a
build environment set up (which on Windows can be a real pain), you
could put a counter in to the failure and timeout states, and call
context_disconnect() when it reaches your count. (This call is only
available in newer versions of the source.)
Hope this helps!
dan symc wrote:
> Hi Chris,
>
> I will gather the logs as you say.
>
> When there is a "failed authentication" or the supplicant is trying to
> authenticate, it keeps doing that all the time instead of
> disconnecting the session to try to authenticate again. It will be
> better to do that so the timestamps can make sense. Is there a way to
> configure this retries or tell the supplicant to stop reauthenticating
> after x times?
>
> thanks
> Dan
>
> On Wed, Dec 17, 2008 at 11:57 AM, Chris Hessing <chris@open1x.org
> <mailto:chris@open1x.org>> wrote:
>
> Hi Dan,
>
> Troubleshooting these packet discards isn't the easiest thing to
> do, unfortunately. You basically have two choices on how to
> deal with this. You can either send me debug logs of the working
> and broken case and I can look in to it, or you can try to take it
> on yourself. No matter what you choose, you are going to want to
> get debug logs. There are two ways to get a debug log out of the
> supplicant. You can enable it in the configuration, or create a
> trouble ticket and let BirdDog create the logs for you. To turn
> it on in the config, do this :
>
> 1. Double click the tray icon to open the "Connect to Network" dialog.
> 2. From the tools menu option, select "Configure".
> 3. Select the "Options" tab
> 4. Click the "Show Advanced Configuration" button
> 5. In the window pane on the left, expand the "Globals" option in
> the tree view.
> 6. Select the "Logging" option that will show up under "Globals".
> 7. Make sure that "Enable logging to a file" is checked (it should
> be by default)
> 8. Make sure that you are okay with the log directory that log
> files will be written to.
> 9. Set the Log level to "Debug"
>
> The supplicant should start writing more detail to a file called
> xsupplicant.log once you click on save. When that log file
> reaches the size specified in "Log size to roll files at", the
> xsupplicant.log file will get renamed to xsupplicant_1.log, and a
> new xsupplicant.log is created to continue logging.
>
> BirdDog makes this a little easier to do, and doesn't result in as
> much disk space being used in the mean time. To create a trouble
> ticket you need to go to the "Tools" menu, and select "Create
> Troubleticket". It will ask you where to write the troubleticket
> .zip file. Be aware that depending on a lot of different factors
> it can take some time to create a trouble ticket!
>
> If you open the newly created troubleticket .zip file, you should
> find a BirdDog.log file. Inside that file should be some debug
> level logs, followed by a listing of services running on your
> machine. One thing to keep in mind about the trouble ticket
> method. BirdDog uses a circular buffer to keep the log level
> messages. As a result, it doesn't take very long for the buffer
> to roll over and start erasing data that might be important to
> troubleshooting your problem. So, you should attempt a
> connection, then immediately create a trouble ticket file, then
> set up your next test, and create a second trouble ticket file.
>
> It is also useful if you can note the approximate time that you
> started and finished each authentication attempt. It makes
> digging around in the log files a LOT easier! If you go to
> "Tools" and select "View Log" you will see a message in the log
> that identifies when the authentication started. It will look
> something like this :
>
> 2008-12-17 10:29:44.926 - Interface : Intel(R) PRO/Wireless
> 3945ABG Network Connection - Packet Scheduler Miniport ---
> Starting Authentication (Phase 1) ---
>
> Knowing at least the timestamp for the authentication starting is
> critical to getting through the logs quickly. If you attempted
> several different authentications and they all show up in a log
> file, it can take a while to sift through all of them and find the
> authentication that is breaking.
>
> If you want me to look it over, you can stop here, and e-mail me
> the trouble ticket files, and timestamp information. Sometimes it
> takes me a couple of days to find time to look, but I'll
> eventually get back with you with what went wrong and some
> information on how it needs to be fixed. In the case of your
> question, the response is going to probably be either "The
> firewall still filtered the frame even though it wasn't told to",
> or "There was a bug in the state machine, I am working on a fix."
>
> If you want to dive in yourself and start to understand the debug
> level logs, keep reading. (As a side note to anyone else reading
> this. If you are thinking about doing any development with the
> supplicant, read on. It will save you MUCH pain!)
>
> Open up the log file (either xsupplicant.log if you enabled debug
> logs, or the birddog.log file if you used the trouble ticket
> method). When debugging is enabled, there will be a LOT of
> technical information that can be used to troubleshoot all kinds
> of interesting problems. If you find your timestamp like I
> listed above, you should notice lines similar to these directly
> above it. (The "Starting Authentication" message comes when the
> state machine transitions in to IDENTITY state, which basically
> means it is ready to go.)
>
> [1X_BE_STATE] 2008-12-17 10:29:44.926 - Supplicant PAE has issued
> a restart.
> [1X_BE_STATE] 2008-12-17 10:29:44.926 - [backend_sm] IDLE ->
> INITIALIZE
> [1X_BE_STATE] 2008-12-17 10:29:44.926 - [backend_sm] INITIALIZE
> -> IDLE
> [EAP_STATE ] 2008-12-17 10:29:44.926 - (EAP State Machine --
> Phase 1) UNKNOWN!!! -> INITIALIZE
> [EAP_STATE ] 2008-12-17 10:29:44.926 - (EAP State Machine --
> Phase 1) INITIALIZE -> IDLE
> [IPC ] 2008-12-17 10:29:44.926 - (IPC) Sending 303 bytes
> total.
> [DOT1X_STATE] 2008-12-17 10:29:44.926 - Intel(R) PRO/Wireless
> 3945ABG Network Connection - Packet Scheduler Miniport - Changing
> from RESTART to AUTHENTICATING.
> [IPC ] 2008-12-17 10:29:44.926 - (IPC) Sending 242 bytes
> total.
> [1X_BE_STATE] 2008-12-17 10:29:44.926 - [backend_sm] IDLE -> REQUEST
> [EAP_STATE ] 2008-12-17 10:29:44.926 - (EAP State Machine --
> Phase 1) IDLE -> RECEIVED
> [EAP_STATE ] 2008-12-17 10:29:44.926 - Got an EAP request.
> [EAP_STATE ] 2008-12-17 10:29:44.926 - Requested method 1.
> [EAP_STATE ] 2008-12-17 10:29:44.926 - EAP ID : 1
> [EAP_STATE ] 2008-12-17 10:29:44.926 - ---- EAP State Dump
> (Phase 1) ----
> [EAP_STATE ] 2008-12-17 10:29:44.926 - rxReq = TRUE reqId = 1
> lastId = 255
> [EAP_STATE ] 2008-12-17 10:29:44.926 - reqMethod = 1 (Identity)
> selectedMethod = 0 (None)
> [EAP_STATE ] 2008-12-17 10:29:44.926 - methodState = 0 (UNKNOWN)
> allowNotifications = TRUE decision = FAIL
> [EAP_STATE ] 2008-12-17 10:29:44.926 - rxSuccess = FALSE
> rxFailure = FALSE
> [EAP_STATE ] 2008-12-17 10:29:44.926 - ---- EAP State Dump
> Finished ----
> [EAP_STATE ] 2008-12-17 10:29:44.926 - (EAP State Machine --
> Phase 1) RECEIVED -> IDENTITY
>
>
> The text inside the [] boxes indicates what part of the supplicant
> is causing the log message. The message you are trying to chase
> down is coming out of the EAP state machine, so you mainly care
> about the EAP_STATE messages. Messages like this :
>
> [EAP_STATE ] 2008-12-17 10:29:44.926 - (EAP State Machine --
> Phase 1) IDLE -> RECEIVED
>
> Indicate that the state machine transitioned from idle to received
> state. (Yeah, I know it is obvious, but I am getting to a point
> here.) There two ways that the state machine will transition.
> The first is the result of a global state change. The second is
> a state specific change. A global state change will show up as
> "(global) -> " followed by the state being transitioned to. These
> state changes are the result of checks that take place in
> eap_sm_check_globals(). (As an aside, in most cases, the starting
> of the function name indicates the file it is in. This isn't true
> for some of the really old code, but in most cases it is a good
> rule of thumb. So, since we are looking for
> eap_sm_check_globals(), we need to look in the eap_sm.c file.)
>
> In the case of the message above, we are transitioning from IDLE
> -> RECEIVED state. So, if the next few lines in the log show our
> error happening, we probably want to look in
> eap_sm_change_to_received().
>
> For the issue you list, you are running in to a situation where
> the state machine doesn't know what state it should transition to.
> This happens when an 802.1X frame comes in but for whatever
> reason the state machine isn't sure what to make of it. This
> particular error comes if we get to the end of the
> eap_sm_change_to_received() function without processing the frame.
>
> To understand what went wrong, we may need to look at a couple of
> different things. The first place to look is at the state of the
> state machine when we started to process the frame. The state
> machine dump will look like this :
>
> [EAP_STATE ] 2008-12-17 10:29:44.926 - ---- EAP State Dump
> (Phase 1) ----
> [EAP_STATE ] 2008-12-17 10:29:44.926 - rxReq = TRUE reqId = 1
> lastId = 255
> [EAP_STATE ] 2008-12-17 10:29:44.926 - reqMethod = 1 (Identity)
> selectedMethod = 0 (None)
> [EAP_STATE ] 2008-12-17 10:29:44.926 - methodState = 0 (UNKNOWN)
> allowNotifications = TRUE decision = FAIL
> [EAP_STATE ] 2008-12-17 10:29:44.926 - rxSuccess = FALSE
> rxFailure = FALSE
> [EAP_STATE ] 2008-12-17 10:29:44.926 - ---- EAP State Dump
> Finished ----
>
> This will show up *AFTER* the state transition line. (These dumps
> happen in each state transition, so it is important to make sure
> you get the right one. ;)
>
> Armed with the values of the state machine, you can work down
> through the eap_sm_change_to_received() function and verify that
> it should have fallen through. If you match this up with the EAP
> state machine RFC, you can determine if the state machine should
> have done something with the data, and start to understand what
> went wrong.
>
> If the state machine seems to be doing the right thing, then you
> may need to look more closely at a network sniff, or the frame
> dumps in the log file. If some of the frames coming from the
> authenticator are getting dropped, then you will need to start
> looking for why they are being dropped. The other common problems
> are that the native Windows supplicant may have gotten turned on
> somehow, and it is also trying to answer the 802.1X requests. If
> this is the case, you will see lots of extra 802.1X frames a sniff.
>
> Hopefully this helps you get on your way to finding a solution to
> the problem you are having.
>
> Thanks!
>
>
>
> dan symc wrote:
>
> Hello,
> I am testing 1x version 2.0.1 and 2.1.5.400 over WinXP.
> A bug that is fixed on 2.1 is when there is a user logoff and
> the supplicant automatically disconnects. That is something I
> need to be working.
>
> The problem that I have now with version 2.1 is that it is
> coexisting with a NAC agent and a personal FW (symantec). When
> I have those enabled and I try to authenticate the XSupp logs
> show this error:
> "Packet discarded because it didn't trigger proper state options"
> The firewall policies are allowing all traffic, and there is
> nothing being blocked on the logs. But when I disable the FW
> the authentication goes through without problems.
> On the other hand, when I turn on the FW peice using XSupp
> 2.0.1, the authentication works perfectly.
> Any advice on how to troubleshoot this through Xsupplicant?
> thanks
> Daniel
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las
> Vegas, Nevada.
> The future of the web can't happen without you. Join us at
> MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Open1x-xsupplicant mailing list
> Open1x-xsupplicant@lists.sourceforge.net
> <mailto:Open1x-xsupplicant@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/open1x-xsupplicant
>
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you. Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Open1x-xsupplicant mailing list
> Open1x-xsupplicant@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/open1x-xsupplicant
>
------------------------------------------------------------------------------
_______________________________________________
Open1x-xsupplicant mailing list
Open1x-xsupplicant@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open1x-xsupplicant
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic