ozirus’

Staj sonuçları açıklandığında Pardus’ta staj yapacağım için gerçekten çok sevinmiştim. Hatta bu sevinç yurtta bilgisayar odasındaki ” ‘Yaşasın!’ diyerek sandalyeden fırlayan genç gören insan” ‘larca da bizzat tasdik edilip onaylanmıştı. Proje tercihimi her ne kadar “İnternet Bağlantısı Paylaşım Projesi” için kullanmış olsam ve bu proje GSoC‘cu bir arkadaşımız olan ve projesinin hakkını gayet güzel veren Cihangir‘e gitse de yine de “güzel ve eğlenceli” şeyler yaşayacağımı biliyordum Eskişehir’den staj için Gebze’ye gelirken. Herkes birbiriyle tanışıp iş projelerin dağıtılması aşamasına gelince eğlenceli olabileceğini düşündüğümden ‘ağ yöneticisine ad-hoc desteği eklenmesi’ projesini seçtim. Proje danışmanım ise Bahadır oldu. İşte, bu yazı buraya kadar yazdıklarımla tamamen alakasız olarak projeyi nasıl yaptığımla ilgili bir takım teknik şeylerle alakalı olacak. (Ayrıca umarım içeriğine bağlı olarak staj defteri doldurma sancımı da değerli kopyala ve yapıştır arkadaşların yardımıyla bir nebze olsun azaltacak.)

İşe nasıl başlayacağımı kestirebilmek adına çalışmalarımın ilk aşamasına ağ yöneticisinin kodlarını inceleyerek başladım. Epey vakit alan bu süreç sonunda işimi bitirdiğimde bu sürecin neyin-nerden-nasıl geldiği ile alakalı olarak bana epey birşey kattığını farkettim. Tabii olarak bu okuma ve inceleme aşaması süresince başta ÇOMAR olmak üzere kimi başka konulara da girdim.

Ağ yöneticisinin işleyişini anladığımı düşündüğümde normalde/her hangi bir GUI olmadan bilgisayarları ad-hoc bağlamak için gerekli olan; kablosuz ağ arayüzü modunu ad-hoc’a ayarlamak, arayüze ip vermek, isteniyorsa arayüze şifre vermek, kanal ayarı yapmak gibi işleri ağ yöneticisinden yapılabilir hale getirebilmek için ÇOMAR’a ait Net_Link_wireless_tools.py betiğini düzenlemeye başladım. Bu betiğin özellikle Dev sınıfına ait up metoduna bağlantı moduna göre değişen bir işlerlik kazandırmam gerekiyordu. Bu sebeple ağ yöneticisine ait connection.py dosyasından gelen mod bilgisine -ki kendileri Net_Link_wireless_tools.py betiğinde bir Python listesinin içinde ikamet ediyorlar- göre (bir erişim noktası ile internete çıkılan kablosuz bağlantılarda managed, ad-hoc bağlantılarda ad-hoc) up metodunda bir dallanma gerçekledim ve geriye sadece Wireless sınıfına ait metodlarla yada standart bir metodu yok ise eğer subprocess modülü yardımıyla up metodunun ad-hoc dallanmasının içini doldurmak kaldı.

Buraya kadar yaptıklarımla ve connection.py‘yi düzenleyerek yaptığım kimi GUI değişiklikleri ile ağ yöneticisini bilgisayarları ad-hoc bağlayabilir hale getirebildim. Fakat projenin buraya kadar yaptığım kadarı ad-hoc modda birbirlerine bağlanacak olan bilgisayarlara el ile ip verme zorunluluğu getiriyordu. Bu noktada bir takım RFC okuma çabalarına daldım ve bir-iki günümü bu hevese harcadım.

Okumaya çalıştığım RFC’lerden öğrendiğim şey yapmaya çalıştığım şeyin (ad-hoc bağlananan makinelere otomatik ip vermek ve ip çakışmasının önüne geçmek) makineler arası Link-Local bağlantı yapmak olduğunu öğrenmem oldu. Bu tipteki bir bağlantı (ki kendisi RFC 3927 ile efendi gibi anlatılmış) ad-hoc bağlı makinelere 169.254.0.0/16 aralığından bir ip tahsis ediyor ve çakışma olduğunda çakışmaya sebep olan makinelerden birine farklı bir ip atıyor.

Bu bağlantı şeklini projeme uygulayabilmek amacıyla birtakım kütüphane arayışlarına girdim. Arayışlarım sırasında avahi-autoipd adlı bir uygulamanın var olduğunu gördüm ve teknik ayrıntılar için freenode’un #avahi kanalında biraz vakit geçirdim. Daha sonra bunu yine up metodunun ilgili kısmına ekleyerek bağlanırken üzerinde mod, şifre vb… ayarları yaptığım ağ arayüzüne ip adresi vermede kullandım. Burda avahi-autoipd‘ye ip adresi verdirirken getirilecek sınırlandırma ve özelleştirmelerin ayarlandığı avahi-autoipd.action dosyası üzerinde de bir takım düzenlemeler yapmam gerekti. Bu işlemle birlikte artık ad-hoc bağlantı yapılan makinelere elle ip verme zorunluluğu ortadan kalkmış ve ağ yöneticisinin ad-hoc desteği projesi testler hariç tamamlanmış olmuştu.

Proje bittikten sonra testleri yaparken karşılaştığım en büyük sorun kimi kablosuz cihazların geriye dönük uyumsuzlukları oldu. Intel PRO/Wireless 2200BG chipset’e sahip dizüstümde yazdığım ve düzgün çalışan bir kodun mod değiştirme kısmı Intel PRO/Wireless 3945ABG‘lı bir başka dizüstünde “Device is busy” hatası verebiliyordu örneğin. Bu sorun biraz vaktimi aldı ama olay sonuçta Ubuntu forumlarında gördüğüm ve “Neden daha önce aklıma gelmedi ki?” şaşkınlığıyla karşıladığım; arayüzü önce pasif et, değişiklikleri yap, sonra aktif et tandansında çözümlendi.