GNOME.org
 

Re: [GnomeMeeting-devel-list] Registration failure after resume

Damien Sandras a écrit :


Le mardi 21 février 2006 à 19:23 +0100, Daniel Huhardeaux a écrit :

Hi all,
I'm running Ekiga on my laptop through Wifi PCMCIA card - ndiswrapper. I have a dhcp server which give me all time same IP, let's say 192.168 .10.4.
When I hibernate my laptop and resume (Suspend2 + hibernate), wlan is coming up with IP 169.254.90.168 (bonjour or zeroconf IP - yes I have mDNSResponder and Bonjour installed) and have normal network access, can ping my computer from network with his fixed IP, ... 

Route give me:

Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 wlan0 
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0 192.168.10.2 0.0.0.0 UG 0 0 0 wlan0
Since the 2 last updates of Ekiga, I can't now register to GW as Ekiga is sending SIP with user 169 254 90 168 This is a -d 4 output:
2006/02/21 18:43:11.982 0:04.177 Opal Listener:83fe3e0 Listen Started listening thread on tcp$169.254.90.168:1720 2006/02/21 18:43:11.983 0:04.178 Opal Listener:83fe3e0 Listen Waiting on socket accept on tcp$169.254.90.168:1720 2006/02/21 18:43:12.059 0:04.255 ekiga-snapshot AVAHI Adding service Huhardeaux Daniel 2006/02/21 18:43:12.235 0:04.431 Opal Listener:83fef48 Listen Started listening thread on udp$169.254.90.168:5060 2006/02/21 18:43:12.237 0:04.437 Opal Listener:83fef48 Listen Waiting on UDP packet on udp$169.254.90.168:5060 2006/02/21 18:43:12.823 0:05.018 GMAccounts...t:084025d0 OpalUDP Binding to interface: 169.254.90.168:35070 2006/02/21 18:43:12.824 0:05.019 GMAccounts...t:084025d0 SIP Created transport udp$0.0.0.0<if=udp$169.254.90.168:35070> 2006/02/21 18:43:14.027 0:06.223 GMAccounts...t:084025d0 OpalUDP Started connect to 83.22.253.19:5060 2006/02/21 18:43:14.028 0:06.223 GMAccounts...t:084025d0 OpalUDP Connect on pre-bound interface: 169.254.90.168 2006/02/21 18:43:14.029 0:06.224 GMAccounts...t:084025d0 SIP Created Transport for Registrar udp$83.22.253.19:5060<if=udp$169.254.90.168:5061> 2006/02/21 18:43:14.033 0:06.228 GMAccounts...t:084025d0 SIP Sending PDU on udp$83.22.253.19:5060<if=udp$169.254.90.168:5061> 
REGISTER sip:voip.tootai.net SIP/2.0
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 169.254.90.168:5061;branch=z9hG4bK32789e33-6fa1-da11-85ce-000ea6217592;rport 
User-Agent: Ekiga/1.99.1-20060220-01
From: <sip:104 voip tootai net>;tag=5a5f9e33-6fa1-da11-85ce-000ea6217592
Call-ID: bcf7e532-6fa1-da11-85ce-000ea6217592 nomade
To: <sip:104 voip tootai net>
Contact: <sip:104 169 254 90 168:5061;transport=udp>
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, SUBSCRIBE, NOTIFY, REFER, MESSAGE 
Expires: 3600
Content-Length: 0
Max-Forwards: 70
2006/02/21 18:43:14.082 0:06.277 SIP Transport:84011d8 SIP Read thread started. 2006/02/21 18:43:14.083 0:06.278 SIP Transport:84011d8 SIP Waiting for PDU on udp$83.22.253.19:5060<if=udp$169.254.90.168:5061> 2006/02/21 18:43:18.046 0:10.241 Housekeeper SIP Transaction 1 REGISTER timeout, making retry 1 2006/02/21 18:43:18.046 0:10.241 Housekeeper SIP Sending PDU on udp$83.22.253.19:5060<if=udp$169.254.90.168:5061> 
REGISTER sip:voip.tootai.net SIP/2.0
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 169.254.90.168:5061;branch=z9hG4bK32789e33-6fa1-da11-85ce-000ea6217592;rport 
User-Agent: Ekiga/1.99.1-20060220-01
From: <sip:104 voip tootai net>;tag=5a5f9e33-6fa1-da11-85ce-000ea6217592
Call-ID: bcf7e532-6fa1-da11-85ce-000ea6217592 nomade
To: <sip:104 voip tootai net>
Contact: <sip:104 169 254 90 168:5061;transport=udp>
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, SUBSCRIBE, NOTIFY, REFER, MESSAGE 
Expires: 3600
Content-Length: 0
Max-Forwards: 70
2006/02/21 18:43:26.054 0:18.250 Housekeeper SIP Transaction 1 REGISTER timeout, making retry 2 2006/02/21 18:43:26.055 0:18.250 Housekeeper SIP Sending PDU on udp$83.22.253.19:5060<if=udp$169.254.90.168:5061> 
REGISTER sip:voip.tootai.net SIP/2.0
CSeq: 1 REGISTER
Via: SIP/2.0/UDP 169.254.90.168:5061;branch=z9hG4bK32789e33-6fa1-da11-85ce-000ea6217592;rport 
User-Agent: Ekiga/1.99.1-20060220-01
From: <sip:104 voip tootai net>;tag=5a5f9e33-6fa1-da11-85ce-000ea6217592
Call-ID: bcf7e532-6fa1-da11-85ce-000ea6217592 nomade
To: <sip:104 voip tootai net>
Contact: <sip:104 169 254 90 168:5061;transport=udp>
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER, SUBSCRIBE, NOTIFY, REFER, MESSAGE 
Expires: 3600
Content-Length: 0
Max-Forwards: 70
2006/02/21 18:43:29.043 0:21.238 Housekeeper SIP Set state Terminated_Timeout for transaction 1 REGISTER 2006/02/21 18:44:08.529 1:00.724 Housekeeper SIP Transaction 1 REGISTER destroyed. 2006/02/21 18:44:08.530 1:00.725 Housekeeper Opal Transport clean up on termination 2006/02/21 18:44:08.530 1:00.725 Housekeeper OpalUDP Close 2006/02/21 18:44:08.531 1:00.726 SIP Transport:84011d8 OpalUDP Error on connection read select. 2006/02/21 18:44:08.531 1:00.726 SIP Transport:84011d8 SIP Read thread finished. 2006/02/21 18:44:08.531 1:00.726 Housekeeper Opal Deleted transport udp$83.22.253.19:5060<if=udp$169.254.90.168:5061>
Ifdown/ifup of wlan0 make things running smooth again as I get back fixed IP. So what code was changed in the last updates of Ekiga/Opal to create this behaviour? 



Nothing that I can think of related to that sorry.
I think I found: it's zeroconf related. I don't know how you get the IP address from the workstation on which Ekiga is running, but this is what I have: 

nomade:/etc# ip addr show wlan0
4: wlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:0f:66:59:08:fe brd ff:ff:ff:ff:ff:ff
   inet 169.254.90.168/16 scope link wlan0
   inet 192.168.10.4/24 brd 192.168.10.255 scope global wlan0
nomade:/etc#
OPAL is connecting to the first inet address from interface (here wlan0). Here is part of man ip: 

[...]

scope SCOPE_VALUE
the scope of the area where this address is valid. The available scopes are listed in file 
             /etc/iproute2/rt_scopes.  Predefined scope values are:

                     global - the address is globally valid.
site - (IPv6 only) the address is site local, i.e. it is valid inside this site.
link - the address is link local, i.e. it is valid only on this device. 

                     host - the address is valid only inside this host.
As you see, the first IP is _link_ so valide only this device. To have a normal behaviour, OPAL should take the first 
*global* IP

--
Daniel
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]