[bulug] Re: BU 802.1x
- From: Benjamin Kraus <bkraus@xxxxxx>
- To: bulug-list@xxxxxxxxxxxxx
- Date: Sat, 20 Sep 2008 21:26:37 -0400
I didn't get a chance to diagnose the problem, but when I last tried to
use the BU (802.1x) network, I experienced what I assume was the same
problem: I could connect, but my routing wasn't being set up, so I
couldn't go anywhere.
Just letting you know that you aren't the only one having the same problem.
- Ben
on 2008-09-20 18:11, Jimmy C. Chau said the following:
> After manually adding a route to 168.122.0.1 through eth1 and setting
> the default gateway to 168.122.0.1, I can get Internet access through
> "BU (802.1x)". In fact, I'm sending you this email that way!
>
> $ sudo route add 168.122.0.1 dev eth1
> $ sudo route add default gw 168.122.0.1
>
>
> Then route shows (with the irrelevant interfaces edited out),
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref
> Use Iface
> 168.122.0.1 * 255.255.255.255 UH 0
> 0 0 eth1
> wireless1x-3-0. * 255.255.255.0 U 2000
> 0 0 eth1
> default 168.122.0.1 0.0.0.0 UG 0
> 0 0 eth1
>
> Where "wireless1x-3-0." used to be "168.122.3.0". So it needs a little
> tweaking, but it works. Good luck!
>
> -Jimmy C. Chau
> <jchau@xxxxxx>
>
> Jimmy C. Chau wrote:
>> Using this network block for wpa_supplicant.conf, I manage to connect,
>> authenticate, & get a DHCP lease. However, while my DHCP client tries
>> to add a default route for 168.122.0.1, netlink for the same interface
>> complains that "Network is unreachable". As a result, no default
>> route is set.
>>
>> # BU wireless. Does not need vpnc to go online.
>> network={
>> ssid="BU (802.1x)"
>> priority=15
>> key_mgmt=WPA-EAP
>> eap=PEAP MSCHAPV2
>> identity="jchau"
>> password="3ULU6 |r0cks|"
>> phase2="auth=MSCHAPV2"
>> }
>> # The BU website says to disable fast reconnect
>> fast_reauth=0
>>
>> Here's the syslog for the DHCP client in case anyone decides to take a
>> whack at this problem:
>>
>> Sep 20 17:12:12 Hostname wpa_cli: interface eth1 CONNECTED
>> Sep 20 17:12:13 Hostname dhcpcd[12345]: eth1: dhcpcd 3.2.3 starting
>> Sep 20 17:12:13 Hostname dhcpcd[12345]: eth1: hardware address =
>> 00:f0:0d:22:be:ef
>> Sep 20 17:12:13 Hostname dhcpcd[12345]: eth1: DUID =
>> 00:ca:fe:0f:ee:d8:de:ad:00:f0:0d:22:be:ef
>> Sep 20 17:12:13 Hostname dhcpcd[12345]: eth1: broadcasting for a lease
>> Sep 20 17:12:14 Hostname dhcpcd[12345]: eth1: offered 168.122.3.41
>> from 2.2.2.2 `BU DHCP Server #2'
>> Sep 20 17:12:14 Hostname dhcpcd[12345]: eth1: checking 168.122.3.41
>> is available on attached networks
>> Sep 20 17:12:15 Hostname dhcpcd[12345]: eth1: leased 168.122.3.41
>> for 3600 seconds
>> Sep 20 17:12:15 Hostname dhcpcd[12345]: eth1: adding IP address
>> 168.122.3.41/24
>> Sep 20 17:12:15 Hostname dhcpcd[12345]: eth1: adding route to
>> 168.122.3.0/24 metric 2000
>> Sep 20 17:12:15 Hostname dhcpcd[12345]: eth1: removing route to
>> 168.122.3.0/24 metric 0
>> Sep 20 17:12:15 Hostname dhcpcd[12345]: eth1: adding default route
>> via 168.122.0.1 metric 2000
>> Sep 20 17:12:15 Hostname dhcpcd[12345]: eth1: netlink: Network is
>> unreachable
>> Sep 20 17:12:15 Hostname dhcpcd[12345]: eth1: exiting
>>
>>
>> Here's the output of route for the eth1 interface:
>>
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric Ref
>> Use Iface
>> 168.122.3.0 * 255.255.255.0 U 2000
>> 0 0 eth1
>>
>>
>> Feels like the problem is mostly solved. The last hurdle doesn't seem
>> to be a wireless or 802.1x problem; rather it feels like a network
>> config. or DHCP problem.
>> (Some parts of the logs and network config block has been modified to
>> protect myself.)
>>
>> -Jimmy C. Chau
>> <jchau@xxxxxx>
>>
>> Ryan Mullen wrote:
>>> Hi,
>>>
>>> On Mon, 8 Sep 2008, phil kurs wrote:
>>>> BU recently added a new wireless network option that uses 802.1x for
>>>> authentication instead of the Cisco VPN solution. Instructions for
>>>> other operating systems besides linux are here:
>>>> http://www.bu.edu/pcsc/wireless/8021x/.
>>>
>>> It appears that wpa_supplicant can be used, but I haven't and won't
>>> have enough time to check out exactly how or confirm that it works.
>>> Either way, it might have what we need.
>>>
>>> Ryan
>>> _________
>>> BU LUG: http://lug.bu.edu. To unsubscribe, email
>>> bulug-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject
>>> field.
>>
>
> _________
> BU LUG: http://lug.bu.edu. To unsubscribe, email
> bulug-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field.
--
Benjamin Kraus
bkraus@xxxxxx
Ph.D. Candidate
Biomedical Engineering Department
Boston University College of Engineering
_________
BU LUG: http://lug.bu.edu. To unsubscribe, email
bulug-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field.
Other related posts:
