From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.5) Gecko/20011015 Description of problem: Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.rhn_register - ensuring that hw and/or sw profiles are selected 2. 3. Actual Results: RHN server drops connection due to numerous delays and retransmissions of packets. Expected Results: Database should include my hw/sw profiles and the task should have completed successfully. Additional info: I have a tcpdump trace showing the packet activity produced during one attempt to run rhn_register
Created attachment 42715 [details] tcpdump output
Same problem also manifests itself with the 'up2date -p' command (update profiles). Running a plain 'up2date' also exhibits some the same problems, but the data exchanges are smaller and are thus more likely to succeed - albeit with numerous packet retries.
I have discovered a VERY temporary work-around for this problem! Running sysctl -w net.ipv4.ip_no_pmtu_disc=1 seems to allow my system to register and update profiles - albeit sloooowly.
are you connecting from behind a modem or through a firewall/vpn? This looks awfully close o an MTU size mismatch (ie, using an MTU that is higher than what the connection path allows)
Closing this out due to lack of activity.